Re: [sipcore] Happy Eyeballs for SIP

["Asveren, Tolga" <[e-mail]>]

Inline...

Thanks,
Tolga

> -----Original Message-----
> From: Dale R. Worley [mailto:[e-mail]]
> Sent: Tuesday, December 13, 2016 12:21 PM
> To: Asveren, Tolga <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [sipcore] Happy Eyeballs for SIP
> 
> "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
[TOLGA] I understand that "perfect outcome" may be hard to describe -let alone to achieve- especially considering various deployment models/expectations. OTOH, I would think that allowing some freedom in terms of ordering could be all what needs to be mentioned in the specification, e.g. 
Rather than:
One ought to use the SRV records according to their weight/priority where eventually only one of them is the winner and is resolved
This:
One may resolve all/a sub-set of available SRV records by also considering IP Address Family and IP Address Family can be also considered for the order of the queries 

I can provide text/edit the document if we can reach a conclusion/consensus on this point.
> 
> > 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?
[TOLGA]  "Usage Rules" section of RFC2782 seem to imply:
i- A list is prepared by querying all SRV records. Queries are performed by the priority/weight based ordering.
ii- And then there is "freedom" in terms of selecting the server to actually use.

I think i- is where some improvement could be useful in the context of happy-eyeballs. The IP Address Family can be used as a third parameter -in addition to priority/weight- when ordering DNS queries. Granted, one may argue that all queries can be performed in parallel but still some clarification text in the specification could be a good idea to highlight this and prevent any confusion.
> 
> > 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.
[TOLGA] I think one issue was regarding the "probing" for UDP. With TCP, connection establishment provides information about the quality of the connection toward the server. Why not using OPTIONS for UDP? It wouldn't change the "SIP state" and wouldn't cause any distraction to end users/devices.
> 
> Dale