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

[Ted Hardie <[e-mail]>]

Hi Tommy,

The charter has this text:

Measure the effectiveness of the algorithm during development. This effort
does not necessarily need to lead to a published document, but should be
captured in presentations, working group wikis, etc.

RFC 8305 describes the set of configurable client-side variables (
https://datatracker.ietf.org/doc/html/rfc8305#section-9.3) different
clients choosing different values may make it difficult to measure the
effectiveness of the algorithm or its impact (e.g. an aggressive minimum
connection attempt retry delay may improve the time to connection but also
increase the overall set of packets in flight).  You might want to specify
that the measurements either will be used to set the recommended values for
these variables (if that is the aim) or will use those values (if that is
the aim).  Either way will help bound the measurement task to something
that won't be too onerous to produce.

I will not be in Vancouver, and the side meeting will be very late in
UTC+1, so I will miss it.  I support the work, though, and I would be happy
to review documents from the WG.

regards,

Ted

On Fri, Jul 12, 2024 at 11:22 PM Tommy Pauly <tpauly=
[e-mail]> wrote:

> At IETF 118 and 119, we shared our work on updating the Happy Eyeballs
> RFCs with draft-pauly-v6ops-happy-eyeballs-v3 [1]. Specifically at IETF
> 119, we presented at the ALLDISPATCH session, and got the feedback to
> consider a new short-lived working group [2].
>
> The authors have worked on a proposed charter for the HAPPY WG (Heuristics
> and Algorithms to Prioritize Protocol deploYment), and we’ve scheduled some
> side meeting time at IETF 120 to discuss and get feedback.
>
> https://wiki.ietf.org/en/meeting/120/sidemeetings
> When: 16:30-17:30 Pacific Time
> Where: Prince of Wales / Oxford
>
> The initial text we’d be proposing for a charter can be found here:
> https://github.com/tfpauly/draft-happy-eyeballs-v3/blob/main/charter.md
>
> Feel free to also reply to this email, or file issues [3]!
>
> Best,
> Tommy, David, Nidhi, & Kenichi
>
> [1]
> https://www.ietf.org/archive/id/draft-pauly-v6ops-happy-eyeballs-v3-01.html
> [2]
> https://datatracker.ietf.org/meeting/119/materials/minutes-119-alldispatch-202403172230-00
> [3]
> https://github.com/tfpauly/draft-happy-eyeballs-v3/issues?q=is%3Aissue+is%3Aopen+label%3Acharter
>
> On Jan 23, 2024, at 3:51 PM, Tommy Pauly <[e-mail]> wrote:
>
> Hi ALLDISPATCH,
>
> 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.
>
> The draft is "Happy Eyeballs Version 3", which is an update to RFC 8305,
> which was Version 2. For those not familiar with Happy Eyeballs, it’s the
> name for the algorithm network clients use to create multiple connection
> attempts in parallel, with a small delay between attempts, for servers that
> are reachable on multiple IP addresses. This technique allows clients to
> have preferences for specific protocols or features, such as IPv6, while
> still making a user’s “eyeballs” happy in cases where there may be
> misconfigurations on networks or servers that cause the preferred protocols
> to fail or be slow. This work was originally developed in v6ops, and was
> primarily focused on handling the selection of IPv6 vs IPv4 options.
>
> In the years since RFC 8305 was published, there have been numerous
> changes to the protocol ecosystem that required a refresh on the document.
> Some of the changes include:
> - 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
>
> While the algorithm overall still focuses on selection of IP addresses and
> preferred address families, some of the new considerations (around
> transport protocol selection, ALPN selection, and preferences due to TLS
> encrypted client hello) cause the scope to potentially grow beyond the core
> expertise of V6OPS. Hence, we’d like to figure out where this work should
> go.
>
> The draft can be found here:
> https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-v3/
> https://www.ietf.org/archive/id/draft-pauly-v6ops-happy-eyeballs-v3-00.html
>
> Slides from IETF 118 can be found here:
>
> https://datatracker.ietf.org/meeting/118/materials/slides-118-v6ops-happy-eyeballs-v3-00
>
> Thanks,
> Tommy (& co-authors)
>
>
> --
> Alldispatch mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>