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

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 18 Dec 2016 13:49:19 +0000

Slightly changing the subject line for easier tracking...

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":

A) Use of Multiple IP Address Families
i- RFC2782
Defines how to resolve SRV Records
All SRVs are resolved with DNS query ordering according to priority/weight
Does not mandate any procedure regarding how/in which order learned addressed are used

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. 
Use of mechanism is allowed for connectionless transports as long as request/response semantics are achieved by application layer

iii- RFC7984
Defines DNS lookup for all IP address families instead of just one of them
The end result is that all SRV records are fully resolved. I think this covers all cases like multiple SRVs for a single IP address family as well although it is not directly mentioned in the specification.
	
iv- draft-worley-sip-he-connection-00
Defines SIP related procedures to use RFC6555 for SIP. This includes probing/keep-alive for existing connections, using an existing connection for all requests.
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?

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 (?).

C) Connectionless protocols
Will be handled by another draft

D) SIP/UDP/DTLS
Requires a new draft

Thanks,
Tolga

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 18 Dec 2016 17:29:58 +0100

> On 18 Dec 2016, at 14:49, Asveren, Tolga <[email-masked]> wrote:
> 
> Defines SIP related procedures to use RFC6555 for SIP.
ONLY for connection-oriented protocols.
> This includes probing/keep-alive for existing connections, using an existing connection for all requests.
Isn’t that why we have SIP Outbound?

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 18 Dec 2016 17:32:02 +0100

> 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 n…

A question here is how this works with SIP outbound - do we need two outbound connections per interface? How do we handle
reg-id and failover in that case?

It’s like inventing ICE for SIP… :-)

/O

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Dec 2016 21:53:53 -0500

"Asveren, Tolga" <[email-masked]> 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.

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

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

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

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 06:42:10 +0000

> -----Original Message-----
> From: Olle E. Johansson [mailto:[email-masked]]
> Sent: Sunday, December 18, 2016 11:30 AM
> To: Asveren, Tolga <[email-masked]>
> Cc: Olle E Johansson <[email-masked]>; Dale R. Worley
> <[email-masked]>; [email-masked]
> Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem
> 
> 
> > 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
> reusing the TLS connection. Is there anything SIP specific, which could help
> here?
[TOLGA] Hosting multiple registration instances is costly and not desired/preferred for many cases. I was thinking more along the lines of "How to failover the TLS connection with minimal state synchronization", which may/may not end up requiring new procedures.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 06:45:23 +0000

> Sent: Sunday, December 18, 2016 11:32 AM
> 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 (?).
> 
> A question here is how this works with SIP outbound - do we need two
> outbound connections per interface? How do we handle reg-id and failover
> in that case?
> 
[TOLGA] Yes, kind of. OTOH -like I stated in another message-, I am not keen about solutions/enhancements requiring hosting of multiple registration instances. In general, I think each address family/interface tuple should be handled as a possible combination. There *could* be cases where there is a need to extend the tuple with the destination related information as well (but I am not sure whether that would happen often enough in practice).

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 11:53:50 +0000

> > outbound connections per interface? How do we handle reg-id and
> > failover in that case?
> >
> [TOLGA] Yes, kind of. OTOH -like I stated in another message-, I am not keen
> about solutions/enhancements requiring hosting of multiple registration
> instances. In general, I think each address family/interface tuple should be
> handled as a possible combination. There *could* be cases where there is a
> need to extend the tuple with the destination related information as well
> (but I am not sure whether that would happen often enough in practice).
BTW, I don’t think this is "SIP specific". It needs to be defined in a generic way hence why I would think something for RFC6555bis.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 19:07:11 +0000

Inline...

Thanks,
Tolga

> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Sunday, December 18, 2016 9:54 PM
> Cc: [email-masked]
> 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
> > IPv4/IPv6 and does not cover other ways of learning IP Addresses, e.g.
> > provisioning, DHCP based. AFAICS, procedure described in this
> 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.
> 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.
> 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 }.