Re: [sipcore] Happy Eyeballs for SIP

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

"Asveren, Tolga" <[e-mail]> writes:
>> From: sipcore [mailto:[e-mail]] On Behalf Of Dale R. Worley
>> Sent: Monday, December 12, 2016 7:15 PM
>> To: [e-mail]
>> Subject: [sipcore] Happy Eyeballs for SIP
>> 
>> This is the start of getting the Happy Eyeballs for SIP work going in the
>> working group.
>> 
>> The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are
>> working with the following strategy (at this time):  The first
>> tranche is the case where (1) alternative addresses are provided by A
>> and AAAA records based on one host name, i.e., we are not considering
>> multiple SRV records, and (2) all of the targets use
>> connection-oriented protocols.
>
> i- Why only A/AAAA records? What about cases where a different SRV
> record is used for each supported address family? AFAIU this type of
> configuration is already mentioned in RFC7984. 

Indeed, that configuration is mentioned in 7984, and was inserted into
7984 because it is such a common configuration.  However, we decided to
not handle SRV in this tranche because a comprehensive approach to SRV
is complicated and nobody has yet proposed a solution that promises to
meet the desiderata, viz.:

- achieve the Happy Eyeballs effect, that is, traffic will be very
  rarely delayed by unreachability of one or more of the targets

- achieve the specified effect of SRV, that is, among the set of targets
  which are reachable, over the long run, the traffic will be
  distributed among them according to the specified priorities and
  weights in the SRV records

> RFC3263 is a bit vague regarding what needs to be done if there are
> multiple SRV records:
>    "If no NAPTR records are found, the client constructs SRV queries for
>    those transport protocols it supports, and does a query for each."
> Does this mean "for all transports for the selected -according to
> priority/weight- SRV Record" or "for all transport/SRV Record pairs".

Well, since the priorities/weights are extracted from the SRV records,
the priorities/weights cannot affect how the SRV records are queried
for.  My interpretation is "for each transport that the client supports
and that is permitted by the URI scheme and the 'transport' option of
the URI (if any), the client constructs an SRV query for the URI scheme,
the transport and the target domain name".  Of course, if there are
multiple SRV records for a scheme/transport/domain name combination, the
single query will return all of them.  Thus, a query for
sip/TCP/example.com would return the two SRV records you quoted:

> I tend to think the former but RFC7984 seems to differ:
> "For example, consider a server with DNS name example.com, with TCP
>    transport specified.  The relevant SRV records for example.com are:
>
>       _sip._tcp.example.com.  300 IN SRV 10 1 5060 sip-1.example.com.
>       _sip._tcp.example.com.  300 IN SRV 20 1 5060 sip-2.example.com.

Once all the SRV records are obtained, the priority/weight processing is
applied to them.

Although it is not specified in RFC 2782 (SRV records), the standard
practice seems to be that all of the SRV records obtained for all of the
protocols are considered as a single set for priority/weight processing,
which generates an ordered list of the target domain names of the SRV
records.  (Of course, in this example, that is not relevant, since both
of the SRV records are for TCP, and so are obtained by one SRV query,
while the UDP SRV query obtains no records.)

>    The processing of [RFC2782] results in this ordered list of target
>    domain names:
>
>       sip-1.example.com
>       sip-2.example.com"

> Then it lists all addresses for both of the SRV Records. Granted, it
> mentions that addresses are not interleaved but nonetheless it assumes
> that a query is performed for both of the SRV Records.

Actually, one query was done, for _sip._tcp.example.com, and it returned
both records.

> I am not sure
> what the right interpretation should be here but it is not
> well-defined to say the least. To me, it seems like RFC7984 should be
> updating RFC3263 normatively in this aspect as well -to promote the
> RFC7984 defined behavior-. And IMHO it would be up to the
> Happy-Eyeballs draft to define how addresses from multiple SRV Records
> should be used. Cases, where a dual-stack entity does not know whether
> IPv4/IPv6 is preferred and multiple SRV records are used for different
> address families on different servers should be covered as well.

Can you give an example where the procedures of RFC 2782 aren't
sufficient to resolve this problem?

> ii- Why only for connection-oriented protocols? I think the generic
> problem happy-eyeballs addresses and what is targeted with
> draft-worley-sip-he-connection-01 are different. The former can be a
> building block for the latter but that shouldn't mean that it should
> be restricted by it IMHO. Is there any technical reason why
> happy-eyeballs is not applicable -by itself- for SIP over UDP?

The *concept* of Happy Eyeballs can, should, and will be applied to UDP,
but the *details* are going to be considerably different from the
details for TCP.  For the first tranche, we are attempting to stay near
what has been done for HTTP, so we are limiting the scope to
connection-oriented protocols.

Dale