[sipcore] Happy Earballs

[[e-mail] (Dale R. Worley)]

I've submitted an update on the Happy Earballs algorithm I've been
working on, draft-worley-sipcore-happy-earballs-00, and I'd like
feedback.  The details are in the draft, of course, but the outline is
this:

RFC 3263 specifies that the various target addresses for a SIP message
must be contacted in a particular order.  If a target fails to respond,
the sender has to wait (possibly resending) for 32 seconds (by default)
before moving on to another target.  This creates a horrible user
experience if the sender thinks it has connectivity to a target (e.g.,
an IPv6 address) but doesn't.

To get around this, introduce a new rule:  a sender is allowed to change
the order of contacting targets provided that collectively, all targets
that are "responsive" still receive the traffic distribution that would
result from strict application of RFC 3263.

A sender caches information about the responsiveness of targets and uses
that, along with the DNS information, to decide what order to contact
the targets.  If a sender doesn't have responsiveness information about
a target, it first sends a non-state-changing probe communication to the
target to determine if the target is responsive.  One example of a probe
is an OPTIONS request with "Max-Forwards: 0".

(In the case of two TCP targets, which parallels RFC 6555 and
draft-johansson-sipcore-he-connection, the sender can simultaneously
initiate TCP connections to the targets because the TCP SYNs are probes
of the targets.  Whichever target responds fastest is necessarily
"responsive".)

Within this framework, and the goal of minimizing the time required to
send messages, the sender is confined to a fairly narrow range of
behaviors, which can be characterized by a generic algorithm that has
certain degrees of freedom that can be called a "policy".

Dale