Subject: Re: [v6ops] RFC6555 / Multiple interfaces

From: Fred Baker <[email-masked]>
Date: Sun, 1 Jan 2017 17:23:04 -0800

On Dec 30, 2016, at 9:01 PM, Mikael Abrahamsson <[email-masked]> wrote:
> This of course makes me a sad panda. It was done because of lack of interest, but if people are interested in working in this area then if we can gather enough people that show interest, AD might change his mind.

IMHO, MIF is readily solved, and is in fact solved in deployment in a number of implementations. You put the software or hardware equivalent of an L2 switch between the connected interfaces, so that to IP they are in fact one interface, and a packet received on one is switched to the another if and only if it is appropriate. 

Solved, and anything that is more complex probably has bugs to be worked out.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 2 Jan 2017 19:41:51 +0000

I would like to (re)express my interest in defining how happy-eyeballs (RFC6555) should behave in the context of multiple interfaces. I think draft-ietf-mif-happy-eyeballs-extension-11 could be a good candidate for that but I also have to admit I was hoping for something with less procedures/simpler -which may/may not be possible/a good idea at the end-.

Thanks,
Tolga

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Sunday, January 01, 2017 8:23 PM
> To: Mikael Abrahamsson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [v6ops] RFC6555 / Multiple interfaces
> 
> 
> > This of course makes me a sad panda. It was done because of lack of
> interest, but if people are interested in working in this area then if we can
> gather enough people that show interest, AD might change his mind.
> 
> IMHO, MIF is readily solved, and is in fact solved in deployment in a number
> of implementations. You put the software or hardware equivalent of an L2
> switch between the connected interfaces, so that to IP they are in fact one
> interface, and a packet received on one is switched to the another if and only
> if it is appropriate.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Jan 2017 12:09:18 -0800

> I would like to (re)express my interest in defining how happy-eyeballs (RFC6555) should behave in the context of multiple interfaces. I think draft-ietf-mif-happy-eyeballs-extension-11 could be a g…

Again, speaking strictly for myself.

One of the big problems with IPv6 deployment, perhaps the biggest single problem, is that the badly broken socket interface forces the application to know about and select the address that will be used for a given session. There is no need for that if an API is included that allows the application to find out what address it is using should it need that. If the application were to give the OS a character string (which might be an address literal, a domain name, or something else of local significance) and the OS returned an open socket or an error code, many applications would have ported long ago without a thought; as it is, the case needs to be made to each application individually. The best bet is steps such as Apple has taken - “how badly do you want your application to be available through our distribution service? Just Do It.”

The downside of Happy Eyeballs is that it asks the application to do something more complex than changing the name of the API called and the size of the container the address is stored in; it tells the application that it needs to walk a list of addresses and potentially have more than one connection in progress at any given time. If it were an OS service, we could change the OS once and have HE implemented for all applications. Making the requested action more complex makes “making the case to every individual application” harder.

And then there is draft-ietf-mif-happy-eyeballs-extension. IMHO, an implementation report, as in “application X, Y, and Z did it on multiple platforms, and provably interoperate using it”, would be in order.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 2 Jan 2017 15:12:30 -0800

> The downside of Happy Eyeballs is that it asks the application to do something more complex than changing the name of the API called and the size of the container the address is stored in; it tells…
On one hand we have applications such as web browsers that implement
their own stack from the ground up. Their behavior is both different and
opaque  to the operating systems.

On the other we have considerations other than which one performs the
fastest such as cost, or order of installation (e.g. if your vpn default
is the last one installed it's probably the cause that you intended to
use that), that transcend questions of whether or not I should try
multiple address families on different interfaces...

I wonder whether this can be formulated as a nice tight algorithm or if
this is just a set of heuristics that need to be incompletely applied
depending on your use case.

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Jan 2017 16:39:23 -0800

> On Jan 2, 2017, at 3:12 PM, joel jaeggli <[email-masked]> wrote:
> 

Probably that.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 3 Jan 2017 11:58:00 +0000

Maybe a two-step approach?

i- "Entities following procedures in RFC6555 SHOULD perform connection checks for each interface in parallel, if an IP Address Family can utilize more than one interface. While doing so, they MAY consider other factor and parameters, e.g. a priori knowledge about user preferences for particular applications, interface capabilities."

IMHO this should be stated in a "Standards Track" specification.

ii- Other specifications, probably all/mostly "Informational", providing recommendations about Socket API usage, interface type specific procedures etc...

Would such a split make sense? I know i- could be considered as "too little/no brainer" but that arguably may be true for RFC6555 in general -especailly the "obviousness"-.

Thanks,
Tolga

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, January 02, 2017 7:39 PM
> To: joel jaeggli <[email-masked]>
> Cc: Asveren, Tolga <[email-masked]>; [email-masked]
> > I wonder whether this can be formulated as a nice tight algorithm or
> > if this is just a set of heuristics that need to be incompletely
> > applied depending on your use case.
> 
> Probably that.

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Jan 2017 19:37:56 -0800

I worry about the implementation of the musts and shoulds. How does a random application, that doesn't necessarily know much about the OS or hardware underneath it, know whether two addresses are on the same or different interfaces? Yes, there are platforms in which they do. That's not "all platforms", not by a long shot.

Personally, I would focus on ensuring that the problem is describable, repeatable, and real before working on, or embellishing, a solution. With HE, there was a real problem - dual stack systems sometimes (demonstrably) waited for amazingly long times (anecdotal evidence says there were cases up to half an hour) before a TCP time-out occurred, making such platforms difficult for a real user to depend on without turning IPv6 off. HE is far from a perfect solution, but it turns out to be enough of a solution that the original problem isn't very real now. 

Tell me about the problem you're trying to solve. What are the symptoms? Is it reproducible? Who is feeling pain? How do we know when we have solved it?

> On Jan 3, 2017, at 3:58 AM, Asveren, Tolga <[email-masked]> wrote:
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 6 Jan 2017 10:20:05 +0000

Aren't all the technical arguments why RFC6555 was needed applicable for multiple interfaces as well? I think the same problems/outcome would be there if, for example, IPv6 connection is tried only on one interface and that happens to fail while at the same time it would have succeeded on an alternate interface.

Similarly, I think the situation is the same as far as "Isn't this obvious, why do we need to specify it" front is concerned.

Overall, one could argue that any purely local procedure without any impact on the on-the-wire protocol does not to be standardized. But then, this argument would be applicable to RFC6555 (to many other specifications) as we ll.

I think it would be better if RFC6555 briefly mentioned about use of multiple interfaces:, e.g. "Entities following procedures in RFC6555 SHOULD perform connection checks for each interface in parallel, if an IP Address Family can utilize more than one interface. While doing so, they MAY consider other factor and parameters, e.g. a priori knowledge about user preferences for particular applications, interface capabilities."
What I am looking for is just a home for such a clarification -as it is currently not present in RFC6555-.

Thanks,
Tolga

> Sent: Tuesday, January 03, 2017 10:38 PM
> To: Asveren, Tolga <[email-masked]>
> Cc: joel jaeggli <[email-masked]>; [email-masked]
> I worry about the implementation of the musts and shoulds. How does a
> random application, that doesn't necessarily know much about the OS or
> hardware underneath it, know whether two addresses are on the same or
> different interfaces? Yes, there are platforms in which they do. That's not "all
> platforms", not by a long shot.
> 
> Personally, I would focus on ensuring that the problem is describable,
> repeatable, and real before working on, or embellishing, a solution. With HE,
> there was a real problem - dual stack systems sometimes (demonstrably)
> waited for amazingly long times (anecdotal evidence says there were cases
> up to half an hour) before a TCP time-out occurred, making such platforms
> difficult for a real user to depend on without turning IPv6 off. HE is far from a
> perfect solution, but it turns out to be enough of a solution that the original
> problem isn't very real now.
> 
> Tell me about the problem you're trying to solve. What are the symptoms? Is
> it reproducible? Who is feeling pain? How do we know when we have solved
> it?
> 
> > i- "Entities following procedures in RFC6555 SHOULD perform connection
> checks for each interface in parallel, if an IP Address Family can utilize more
> than one interface. While doing so, they MAY consider other factor and
> parameters, e.g. a priori knowledge about user preferences for particular
> applications, interface capabilities."
> >
> > ii- Other specifications, probably all/mostly "Informational", providing
> recommendations about Socket API usage, interface type specific
> procedures etc...
> >
> > Would such a split make sense? I know i- could be considered as "too
> little/no brainer" but that arguably may be true for RFC6555 in general -
> especailly the "obviousness"-.
> >
> > Thanks,
> > Tolga
> >