Subject: [sipcore] Remaining Happy Eyeballs work, the simple parts

From: [email-masked] (Dale R. Worley)
Date: Wed, 18 May 2016 15:15:25 -0400

Now that draft-ietf-sipcore-dns-dual-stack is going to the IESG:

To recast what I see as the agenda for the remaining "Happy Eyeballs"
work, this is a list of what I see as the simple issues.  My goal here
is to get feedback on what the specifics of this part of the solution
should be so we can start producing text.

(The terms "flow" and "target" might not be the right vocabulary.)

- Recommend SIP Outbound (RFC 5626) between UAs and edge proxies
[everybody agrees that using SIP Outbound is the best solution in principle]

- Allow devices to change the target order prescribed by RFC 3263/2782
  using the Happy Eyeballs rules:
     - Prefer targets with existing flows
     - Prefer targets with a different address family than that of a
         non-responsive address
     - Deprecate targets known to be non-responsive
     - May simultaneously initiate flows with multiple targets as long
         as UA does not have more than one simultaneous outstanding
         copy of a request
     - Prefer simultaneously initiating flows with targets in different
         address families

- Reduce client transaction timeouts:
    Timer B and Timer F are currently 64*T1, which defaults to 32 seconds

I will summarize the vexed question of dealing with "simple" UDP (where
"simple" means "not using the full facilities of SIP Outbound") in
another message.

----------

The matter of the timers needs to be worked on.  Right now, both INVITE
and non-INVITE transactions use much the same structure:

T1 is an estimate of the network RTT, and defaults to 500ms.

Timer B/C is 64*T1, thus defaulting to 32s.

When an INVITE request is sent, if there is no response within T1, then
it is resent.  Continuing lack of a response causes resends at doubling
intervals, leading to transmissions at times:

    T0 + 0
    T0 + T1
    T0 + 3*T1
    T0 + 7*T1
    T0 + 15*T1
    T0 + 31*T1
    T0 + 63*T1
    timeout at T0 + 64*T1
    (7 transmissions in all)

For non-INVITE requests and INVITE responses, the retransmit timer has a
maximum of T2, which is 4s (= 8*T1), giving transmission times:

    T0 + 0
    T0 + T1
    T0 + 3*T1
    T0 + 7*T1
    T0 + 15*T1
    T0 + 23*T1
    T0 + 31*T1
    T0 + 39*T1
    T0 + 47*T1
    T0 + 55*T1
    T0 + 63*T1
    timeout at T0 + 64*T1
    (11 transmissions in all)

It seems to me that we should reduce the total time until failure is
declared to something like 5 seconds, on the grounds that people will
not give up on a call if it takes an extra 5 seconds to start ringing.

If we reduce T1 to 100ms, then Timer B/C becomes 6.4 seconds.

It seems to me that 100ms as the default RTT is quite acceptable, and
maybe an overestimate.  I just ran 'ping' against the web sites in the
open tabs in my web browser, and all of them had RTT of less than 50ms.
Setting T1 to 50ms would reduce Timer B/C to 3.4 seconds.

In addition, if we consider UDP networks to be relatively reliable, we
could reduce the number of retransmissions.  For instance, if the
network loses a random 30% of packets, the probability of 4
retransmissions of a request being lost is only 0.81%.

As an extreme proposal, if we reduce T1 to 50ms and Timer B/C to 16*T1
(allowing five transmissions), Timer B/C becomes 0.32 seconds.

I think the largest risk from reducing retransmissions or sending them
more densely is when networks have short-term congestion, so that the
network essentially fails for times on the order of a few seconds.

Dale