Re: [v6ops] RFC6555 / Multiple interfaces

[joel jaeggli <[e-mail]>]

On 1/2/17 12:09 PM, Fred Baker wrote:
> On Jan 2, 2017, at 11:41 AM, Asveren, Tolga <[e-mail]> wrote:
>> 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-.
> 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.
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.

>
> 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.
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>