Re: [v6ops] [Alldispatch] Dispatching Happy Eyeballs Version 3

[Tommy Pauly <[e-mail]>]

Regarding APIs, I agree that there are API implications here, and that’s exactly what the TAPS WG has been doing: https://datatracker.ietf.org/wg/taps/documents/

However, I think that the happy eyeballs layer is something that is part of the implementation of such an API system — it works for any API instantiation that works with connect-by-name, and doesn’t really require that things be standardized yet.

Regarding contributions, this certainly isn’t just something that Apple does, and just I work on. We have Google co-authors here working on Chrome, and many other implementations (like curl, etc) do happy eyeballs. I won’t speak for all other implementations, but I think this is already quite general-purpose.

Thanks,
Tommy

> On Jan 26, 2024, at 9:01 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Tommy Pauly <tpauly=[e-mail]> wrote:
>> We’d like to propose a draft to be dispatched at IETF 119. This draft
>> was discussed in a couple different working groups (V6OPS and TSVWG) at
>> IETF 118. One of the main points of discussion within those groups was
>> the question of which working group would be most appropriate to take
>> on the draft.
> 
> To me, the rework is either a set of trivial rejigging of some parameters, or
> it's really entirely new work that would actually benefit from a new WG.
> 
>> This work was originally developed in v6ops, and was primarily focused
>> on handling the selection of IPv6 vs IPv4 options.
> 
> Yes.  But, it seems to me that we now really have to do make selections among
> IPv6 ULA, GUA, multiple GUA from multiple routers,  X {TCP, QUIC}.
> 
> To me, this work is probably wasted unless we are defining new APIs.
> My understanding is that Apple has some such APIs.  I think that there is a
> tuscle that a WG needs to deal with between connect to "name" and connect to
> "address", and also connection caching vs HE-results caching vs multiple
> users/applications.  {Android applications are basically different users.  I
> don't know how IOS does this.  It would be good to spread this notion to all platforms}
> 
>> - SVCB/HTTPS records (RFC 9460), which provide additional ways to get
>> address hints, add priority between A/AAAA answers, indicate supported
>> ALPNs, and indicate support for TLS encrypted client hello
> 
>> - Growing support for QUIC (RFC 9000); previously, Happy Eyeballs was
>> defined in terms of TCP connections, and needs to have some text
>> adaptation
>> - New techniques for supporting v6-only networks and address synthesis
> 
> I am not really associated with any OS distribution, so whether or not I
> think this work should proceed may be irrelevant.  What I think we need for
> success is:
> * some core Microsoft "libc" people
> * some GNU glibc people
> * some Ubuntu/Fedora/Azure-server/Oracle-Linux people
> * some Android people
> * some Apply people (more than just Tommy)
> 
> Yes, this is API work, which some think we don't do, but this is squarly in
> the space of updating our own RFCs, and yes, fixing the "BSD socket API" for
> this century.
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>