Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem

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

Inline...

Thanks,
Tolga

> -----Original Message-----
> From: Dale R. Worley [mailto:[e-mail]]
> Sent: Sunday, December 18, 2016 9:54 PM
> To: Asveren, Tolga <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem
> 
> "Asveren, Tolga" <[e-mail]> writes:
> > I think it would be useful to get on a common understanding/consensus
> > on "what needs to be covered and in which document" as far as use of
> > multiple IP Address Families/Multiple Interfaces are concerned. Here
> > is a first attempt for "Summary of Happiness":
> 
> The current plan has been to discuss topics incrementally in order to keep
> the scope of each incremental technical discussion small enough that it will
> come to an end.  If we throw everything into the discussion at once, it will be
> difficult to both discuss things thoroughly and come to a consensus.
> 
> > ii- RFC6555
> > Defines parallel connection attempt for different IP address families.
> > Restricts itself -I don't know exactly why- to a single hostname for
> > IPv4/IPv6 and does not cover other ways of learning IP Addresses, e.g.
> > provisioning, DHCP based. AFAICS, procedure described in this
> > specification can be applied for those cases as well.
> 
> That's because RFC 6555 discusses the case of HTTP, where there is a single
> host name, the domain name from the HTTP URL.  There *are* no other
> ways of learning an IP address in HTTP.
[TOLGA] I couldn't see anything in RFC6555 restricting itself to HTTP. To the contrary, it mentions applicability even to non-connection oriented transport protocols as long as application protocol satisfies request/response semantics.
> 
> > iv- draft-worley-sip-he-connection-00
> 
> > Would any "fast-failover after connection failure", e.g. toward the
> > standby server after failure of the primary server, related procedures
> > be in scope? For connection oriented protocols, any possible
> > recommendations/improvements in this area would probably be limited to
> > reusing the TLS connection. Is there anything SIP specific, which
> > could help here?
> 
> Fast failover is, in effect, in scope because in a failure situation, what Happy
> Eyeballs attempts to do with the next SIP message is deliver it quickly.
[TOLGA] Yes, agreed. I am not sure whether there is a practical way of expediting things for TCP/TLS-TCP though.
> 
> > B) Use of Multiple Interfaces
> > v- I think the ideal place to cover this would be RFC6555-bis (also by
> > considering other restrictions as mentioned in ii- above). I wouldn't
> > think that there would be a need for defining anything new in
> > draft-worley-sip-he-connection-00 (?).
> 
> The subtle problem with multiple interfaces is that there can be multiple
> interfaces that might be able to connect to a particular target address.
> Currently in IPv6, the source address selection algorithm of RFC 6724 chooses
> which interface is to be used to contact a particular target address.  But IIRC
> Roman Shpount noted that there are times when RFC 6724 gives a non-
> working result.  It looks like in the long run we want H.E. to be able to use
> alternative source addresses if necessary.
[TOLGA] This is something to be addressed by RFC6555-bis IMHO: try to establish a connection for each { IP Address Family, Interface } tuple rather than just for each { IP Address Family }. 
> 
> Dale