Subject: [sipcore] Happy Eyeballs -- UDP and RTT

From: [email-masked] (Dale R. Worley)
Date: Wed, 02 Mar 2016 15:31:15 -0500

Happy Eyeballs has a mess of issues surrounding UDP.

Of course, the most desirable SIP transport is a TCP/TLS connection (or
a SIP Outbound UDP flow) that is already established with the
destination.  That allows the message to be transmitted in 1/2 RTT in
the common case, and the success of that particular transport is largely
assured.  But it requires that the sender has recently communicated with
the destination.

In general, UDP is undesirable.  OTOH, it is the most implemented
transport for SIP and its implementation is relatively simple.  Even in
2014, 15% of the SIP implementations at SIPit do not support TCP.  UDP
has the advantage of usually getting a message to its destination in 1/2
RTT, even if the sender has not previously communicated with the
destination.

Typically, TCP implementations have 3/2 RTT transmission time, since
data is not sent in the first packet from the initiator.  TCP Fast Open
(RFC 7413) can be used to shorten that time to 1/2 RTT, but it requires
that the sender has recently communicated with the destination.

Using TLS in a new connection adds a further RTT to TCP transmission
times.

Then again, perhaps we do not care if the message is delayed by an
additional RTT.  RFC 6555, which is really about the HTTP server case,
assumes that 3/2 RTT is acceptable.  OTOH, HTTP service already has to
tolerate 3/2 RTT.

With UDP and TCP Fast Open, if transmission time is important, it would
be useful to be able to simultaneously transmit duplicate requests --
"Simultaneously" in the sense that a second request is sent before the
failure of a first request is known, and "duplicate" in the sense that
the success of either request obtains the desired service.  In order to
support this, there needs to be a way to detect and eliminate duplicate
requests at some downstream point.

BTW, looking at RFC 6555 section 4, I see:

   4.  Algorithm Requirements

   A "Happy Eyeballs" algorithm has two primary goals:

   1.  Provides fast connection for users, by quickly attempting to
       connect using IPv6 and (if that connection attempt is not quickly
       successful) to connect using IPv4.
   [...]
   The basic idea is depicted in the following diagram:

           DNS Server                  Client                  Server
               |                          |                       |
         1.    |<--www.example.com A?-----|                       |
         2.    |<--www.example.com AAAA?--|                       |
         3.    |---192.0.2.1------------->|                       |
         4.    |---2001:db8::1----------->|                       |
         5.    |                          |                       |
         6.    |                          |==TCP SYN, IPv6===>X   |
         7.    |                          |--TCP SYN, IPv4------->|
         8.    |                          |<-TCP SYN+ACK, IPv4----|
         9.    |                          |--TCP ACK, IPv4------->|
        10.    |                          |==TCP SYN, IPv6===>X   |

               Figure 2: Happy Eyeballs Flow 1, IPv6 Broken

   In the diagram above, the client sends two TCP SYNs at the same time
   over IPv6 (6) and IPv4 (7).  In the diagram, the IPv6 path is broken
   but has little impact to the user because there is no long delay
   before using IPv4.  [...]

Am I misunderstanding this?  Item (1) says that there is a delay between
initiating an IPv6 connection and initiating an IPv4 connection, but the
text at the end says that they are initiated simultaneously.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 21:30:51 +0000

Hi Dale,

>Of course, the most desirable SIP transport is a TCP/TLS connection (or a SIP Outbound UDP flow) that is already established with the destination.  

Not sure what you mean by "destination", but an outbound flow is only created between a UA and its registrar.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 Mar 2016 10:35:20 -0500

Christer Holmberg <[email-masked]> writes:
>>Of course, the most desirable SIP transport is a TCP/TLS connection
>>(or a SIP Outbound UDP flow) that is already established with the
>>destination.  
>

By "destination" I mean "where the device is trying to send the
message".

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Mar 2016 20:38:26 +0000

Hi,

> By "destination" I mean "where the device is trying to send the message".

If you refer to the remote UA, there is no outbound flow established with the UAs. Again, the outbound flow is between a UA and its registrar.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 08 Mar 2016 13:57:46 -0500

[email-masked] (Dale R. Worley) writes:
> [etc.]

What I'm looking for here is some feedback:  Is adding one or two RTT of
delay to SIP signaling a problem or not?  If two RTT of additional delay
is not a problem, we can be much more restrictive regarding what
mechanisms we define.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 Mar 2016 14:28:14 -0500

> is not a problem, we can be much more restrictive regarding what

I have mentioned in my earlier email if UDP is replaced by TLS or TCP, then
it needs to be used in conjunction with SIP Outbound. For SIP Outbound the
initial flow setup or flow recovery adds more then two RTT.

One of the common application flows would be to wait for a new call
notification which is sent using a push notification such as Apple Push or
Android Push to a mobile device. Once push notification is received, mobile
device needs to place a call and pick up the inbound call from the proxy.
For this, mobile device needs to establish a TLS connection to the edge
proxy (3.5 RTT), send a registration message to get GRUU (2RTT, first to
get nonce, second to register and get GRUU), and then place the call over
the flow (0.5 RTT). Same delay applies to call recovery if flow gets
disconnected for any reason such as edge proxy failure or local IP address
loss.

Without SIP Outbound with UDP both scenarios take 0.5 or 1.5 RTT depending
on device having a recent nonce for authentication.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Mar 2016 12:19:12 -0500

On 3/8/16 2:28 PM, Roman Shpount wrote:
> On Tue, Mar 8, 2016 at 1:57 PM, Dale R. Worley <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]> (Dale R. Worley) writes:
> I have mentioned in my earlier email if UDP is replaced by TLS or TCP,
> then it needs to be used in conjunction with SIP Outbound. For SIP
> Outbound the initial flow setup or flow recovery adds more then two RTT.
>
> notification which is sent using a push notification such as Apple Push
> or Android Push to a mobile device. Once push notification is received,
> mobile device needs to place a call and pick up the inbound call from
> the proxy.

This is a common application flow?

I'm not aware of this being a standard usage of sip.

> For this, mobile device needs to establish a TLS connection
> to the edge proxy (3.5 RTT), send a registration message to get GRUU
> (2RTT, first to get nonce, second to register and get GRUU), and then
> place the call over the flow (0.5 RTT). Same delay applies to call
> recovery if flow gets disconnected for any reason such as edge proxy
> failure or local IP address loss.
>
> Without SIP Outbound with UDP both scenarios take 0.5 or 1.5 RTT
> depending on device having a recent nonce for authentication.

I understand that this is very "traditional".

It would also never get past a security review these days.

If we have no secure solution that is deployable in practice, then I 
guess we ought to be setting up an effort to come up with one.

Maybe the answer is "use webrtc".

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Mar 2016 13:27:48 -0500

> I'm not aware of this being a standard usage of sip.

This is not completely non-standard either. SIP here is only used to
actually place the call. SIP registration is replaced by the platform
native push functionality. This flow has an upside of reducing the server
load on the provider side (no idle registration connection waiting for
inbound calls) and reducing power usage on the client side (no  idle
registration connection waiting for inbound calls or and CPU does not need
to periodically wake up to send a keep alive).

> If we have no secure solution that is deployable in practice, then I guess
> we ought to be setting up an effort to come up with one.
>

WebRTC might be the answer. Since there is a lot of effort is already being
spent to optimize HTTP request processing and to reduce the number of round
trips required to get HTTP response, there is no reason not to reuse this
work.

Unfortunately this still leaves the question of what to do with all the
existing IP phones deployed with hosted PBXs. They would need to be
migrated to IPv6 sooner rather then later.
_____________
Roman Shpount

---

From: Brett Tate <[email-masked]>
Date: Thu, 10 Mar 2016 09:12:54 -0500

> BTW, looking at RFC 6555 section 4, I see:

<snip>

> Am I misunderstanding this?  Item (1) says that there is
> a delay between initiating an IPv6 connection and
> initiating an IPv4 connection, but the text at the end
> says that they are initiated simultaneously.

I agree that the text is contradictory.

Section 5.5 indicates that stateful algorithms can more aggressive than
the recommended 150-250 ms delay; however it still recommends "connection
attempts be paced to give connections a chance to complete".

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Mar 2016 16:31:59 -0400

> attempts be paced to give connections a chance to complete".

Thanks!  Yet another point regarding revising timeouts.

Dale