Subject: [sipcore] Happy Eyeballs: Targets

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 Jun 2016 22:20:36 -0400

This thread is about solutions for this part of the requirements:

    - Solve the "happy eyeballs" problem for INVITE, i.e., if a
      destination URI is advertised with both multiple targets (IPv4 and
      IPv6 or otherwise), but connectivity to only one target exists,
      usually message transmission will not be delayed unacceptably, and in
      particular, not by a full timeout as prescribed in 3261.

    Note that the solution may be decidedly different based on the
    transport protocol(s) for the targets.

    There is uncertainty about whether adding an RTT to signaling times is
    acceptable.  For example, in practice RTT on the overall Internet is
    less than 1/2 second, and that is an acceptable delay in call setup
    times under ordinary circumstances.

    - The solution must approximate 3263, in that if several targets are
      specified by *different* SRV records and are reachable over a long
      period of time, the relative traffic shares sent to them must be
      compatible with the priorities and weights of the SRV records.  (If
      they are alternatives that are *not* derived from different SRV
      records, the solution is unconstrained regarding relative traffic
      shares.)

Comments are invited!

Useful definitions:

a "client" is the entity that wishes to send a SIP message

a "target" or "transport target" is an address/port/protocol triple
that is an address for the transport layer of the stack.  A target is
derived from a SIP URI (for a request) or a host-port (for a
response).

a "flow" is a sequence of related messages between the client and a
target.  If the protocol is connection-oriented, the flow encompasses
the connection.  If the protocol requires cryptographic setup, the
flow encompasses the cryptographic session.

a "probe" is an operation executed on a flow by a client to determine
whether it can successfully communicate with the target, without
changing the SIP dialog state with the target.  Probes can take many
forms:

    Setting up a connection of a connection-oriented protocol.

    Performing a cryptographic handshake.

    Performing a keep-alive as defined by the protocol.

    Sending an OPTIONS request with Max-Forwards 0.

Note that the last choice can be used with any(!) protocol.  If the
OPTIONS reaches the target, the target is required to respond with
either a 200 or 483 response (without forwarding it to another
entity).  Conveniently, a server can respond to such a request
statelessly, so such requests are low-overhead.

The current state of the solution (as I know of it) is:

Note that some SIP messages are time-sensitive for the usesr
experience (e.g., initial INVITEs), while others are not (e.g., a
refreshing REGISTER).  A client MAY choose not to apply the following
rules for non-time-sensitive messages.

Devices MAY change the target order prescribed by RFC 3263/2782.
  The device SHOULD follow the Happy Eyeballs rules, viz.:
     - 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

Devices MAY contact targets in any order, including those obtained via
different SRV records, notwithstanding the priority/weight specified
in the SRV records.  But in doing this, they MUST approximate the
behavior specified by RFC 3263, in this sense:

    If a set of targets is all of the targets derived from two or more
    SRV records, and at least one target for each SRV record is
    reachable by the client over a long period of time, the relative
    shares of traffic sent to each subset of targets derived from one
    SRV record must converge to the traffic shares that would result
    if the client contacted these targets in the order specified by
    RFC 3263 (i.e., according to the priorities and weights of the SRV
    records).

    (Note that the relative traffic shares between targets that are
    *not* derived from different SRV records (e.g., alternative A
    records for a DNS name) are not constrained by this requirement.)

In general, this means that cached reachability information about
targets should time out, causing the behavior of the client to revert
to RFC 3263 over time.

(Beware that we have to define "reachable" above to include
responsiveness -- a high-priority target that has a 5 sec RTT
shouldn't be able to commandeer all of the traffic.)

If a client does not have recent reachability information for the flow
to a given target, the client SHOULD probe the flow before sending a
request to the target.

    This is because in the worst case, sending a request commits the
    client to waiting for a timeout before it can send a duplicate
    request to another target.  Note that probes do not change the SIP
    dialog state of any entity, so probes can be sent in parallel to
    multiple targets.

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

It seems that reducing the default T1 from 500 msec to 100 msec
suffices for this.  It seems that RTT to arbitrary places on the
Internet can take as long as 500 msec, but RTT to web servers
generally takes 100 msec or less.  That argues for reducing T1 to 100
msec, which makes timers B/F 6.4 sec.  In practice, SIP servers are
likely to have connectivity like web servers.  But we want global
public SIP to work (e.g., in peer-to-peer SIP), so SIP to arbitrary
addresses should only rarely time out.

The retransmission schedule specified by RFC 3261 is:

    1st send is at time 0
    2nd send is at time T1
    3rd send is at time 3*T1
    4th send is at time 7*T1
    5th send is at time 15*T1
    6th send is at time 31*T1
    7th send is at time 63*T1
    timer B fires at time 64*T1, terminating the transmission

This is just long enough to allow 7 transmissions of the message.  If
we reduce T1 to 100 msec (from 500 msec), the total length of the
schedule is reduced to 6.4 sec, which seems tolerable as a fail-over
delay.  It still alllows 7 retransmissions.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Fri, 24 Jun 2016 00:11:06 -0400

Dale,

One more mechanism for checking a UDP flows is STUN keep-alive message
described in https://tools.ietf.org/html/rfc5626#section-3.5.2. These
messages are even lower overhead then OPTIONS messages.

Regards,
_____________
Roman Shpount

---

From: Brett Tate <[email-masked]>
Date: Fri, 24 Jun 2016 12:52:56 -0400

Hi,

> suffices for this.

The issue with using a smaller T1 value is that it doesn't just impact the
desired timer.  For instance, it can cause more retries.  Because of this,
the draft might want to specify allowing the specific smaller timers in a
way which doesn't rely upon a smaller T1.

If it matters, RFC 3261 section 17.1.1.2 has normative statements
concerning the topic of lowing T1.

Thanks,
Brett

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 27 Jun 2016 15:14:16 -0400

> concerning the topic of lowing T1.

It seems to me that the core concept of that section is "T1 is an
estimate of the round-trip time (RTT)".  And while the average RTT over
the global Internet is nearly 500ms, the RTT to places that expect a lot
of traffic seems to be 100ms or less.  (I expect RTT on carrier-managed
networks to be even less.)  So I don't see cutting the default T1 as
contravening that section.

True, that does increase the number of retries, but that seems to be the
correct change if it's true that if you don't see a response in 100ms,
it is more likely that the request was lost than that it is delayed in
transit.

Do we have any data on what RTT and packet loss is like in real systems?

Dale

---

From: Roman Shpount <[email-masked]>
Date: Mon, 27 Jun 2016 15:46:57 -0400

> Do we have any data on what RTT and packet loss is like in real systems?

This all depends what you mean by the "real systems". For USA hosted PBX
systems working with office based networks, RTT is 70ms (typical delay from
east coast USA to LA datacenter) or less. If service is geo optimized
between two or more data centers, RTT is 40ms or less. Packet loss is
nearly zero. These conditions account for majority of hosted PBX traffic.

If you are dealing with international, RTT is around 500ms or less for most
locations. Brazil to Singapore is around 420ms RTT, for instance. Western
Europe to LA is around 150ms RTT. There are, of cause, locations where RTT
is much higher, especially when satellite links are involved.

Packet loss heavily depends on the last mile link utilization. There are
still links which are 128K which are used for VoIP. If someone starts
uploading things on this link, you start seeing packet loss or 2-3 sec
packet delays. Most of the time, form locations with broadband connections,
packet loss is close to zero.

If you start dealing with mobile, things are a lot less predictable. Packet
loss can be in 10-20% range. RTT delays can be up to a second. Some other
locations, such as hotels, especially internationally, are often even worse
then mobile due to random traffic blocking or deliberate attempts to block
VoIP.

Please let me know if you need any more data.
_____________
Roman Shpount