Re: [sipcore] Happy Eyeballs for SIP

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

RFC7984 => why not OPTIONS for testing without changing "status"
DNS SRV Records => not necessarily pointing to the same server's different IP Address families, could be multiple servers with each different address families => should be addressed by Happy-Eyeballs

Why only "connection oriented"? Fast /reliable/secure failover is another problem 

Please see inline for comments/questions.
 
Thanks,
Tolga

> -----Original Message-----
> 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.
[TOLGA] 
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. 
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".
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.

   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. 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.

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?

> This case is the closest to the Happy Eyeballs for HTTP work that has already
> been done, though it has some additional requirements (in particular, the
> fact that connections can be idle for a considerable time, but at unpredictable
> times, the client wants to use the connection in a soft-real-time way).
> 
> The current draft is named draft-worley-sip-he-connection-01.  (We'll be
> revising the name.)
> 
> Our idea is to start with an exposition that is not too far beyond the work for
> HTTP, so that the discussion remains manageable.  In later stages, we will
> produce successive expansions until the entire SIP operational space is
> covered.  The expansions can be done by any of several methods:
> 
> - Produce successive RFCs, each of which incorporates the preceding RFC
>   but extends it to additional operational space.  Thus, each RFC
>   obsoletes and extends its predecessor, so that an implementer only has
>   to read the current RFC of the sequence.  (This is the method that we
>   prefer at present.)
> 
> - Produce successive drafts, each of which covers a larger operational
>   space and progress the last one to an RFC.  This will slow the
>   standardization of the earlier tranches of the work but reduce the
>   overhead of formalizing the drafts as RFCs.
> 
> - Produce a series of RFCs, each of which updates the preceding RFCs.
>   This seems like the least desirable strategy, as it requires an
>   implementer to read several RFCs and collate their provisions.
[TOLGA] Please the second approach. It wouldn't significantly matter whether iterations of ideas/algorithms are captured in a series of RFCs/drafts in terms of adaptation. An RFC is supposed to be "complete" according to the best of our knowledge at a given time. So, I strongly would suggest to go with "multiple drafts" approach (Option-2).
> 
> Let the discussion begin, both on the work and on the plan for the work!
> 
> Dale
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore