Re: [v6ops] Happy Eyeballs, v3!

[Tommy Pauly <[e-mail]>]

> On Nov 6, 2023, at 11:45 AM, Momoka Yamamoto <[e-mail]> wrote:
> 
>> - Happy eyeballs (in all its versions) has been developed in v6ops
>> - This is a -bis effort, where the majority of the text is copied verbatim, and thus in majority applies to the IPv6/IPv4 racing content.
> 
> Does a draft need to be in the original wg if it is a bis?
> 
>> I’d argue that the main point of this revision is to describe how to handle SVCB queries,
> 
> I agree. However "how to handle SVCB queries" is not exclusively about IPv6.
> 
> The implementors of this algorithm are client applications. 
> Again I am still new to the IETF but I thought v6ops is a working group mainly for network operators looking at the charter of the working group.
> This draft should be adopted in the wg where the client implementors are present.

While SVCB queries are not exclusively about IPv6, they certainly have a bearing on IPv6 and dual-stack server deployments (since they communicate address hints, and priorities between services).

The fact that we are revising in order to add SVCB support should not discount the rest of the document’s intent.

Additionally, I would argue that v6ops covers implementors and operators on the client side, network side, and server sides — how they all operate together. And a lot of happy eyeballs is also about how dual-stack hosts that are advertising DNS records for A/AAAA/SVCB can ensure they are providing a good basis for clients to work well.

Thanks,
Tommy

> 
> Best,
> Momoka Y
> 
> On Mon, Nov 6, 2023 at 11:21 AM Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On Nov 6, 2023, at 11:13 AM, Momoka Yamamoto <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Thank you for your reply Tommy,
>>> 
>>> Sorry for making a fuss about the word "Happy Eyeballs" and its meaning. 
>>> I now understand that the meaning of words can change and there is no other better name for this draft.
>>> 
>>> I have read the draft. I think this is a great draft. Very informational. Very excited about this.
>>> I think it should be adopted. But v6ops wg is not the venue for this draft. 
>>> The main area of this draft is Transport and some DNS. IPv6 is not as important as it was in OG RFC6555 or HE2 RFC8305.
>>> I am still new to the IETF but I think this work should be done in a WG that specialises in Transport. (like tsvwg?)
>> 
>> Happy to have the discussion of venue with the group, but I do want to emphasize a few points:
>> 
>> - Happy eyeballs (in all its versions) has been developed in v6ops
>> - This is a -bis effort, where the majority of the text is copied verbatim, and thus in majority applies to the IPv6/IPv4 racing content.
>> - The main purpose of the document is not focused on transport details. While we are trying to generalize the previous text that existed for racing that only talked about TCP to also mention QUIC (since QUIC has come about since HEv2), work on truly racing between protocol stacks belongs elsewhere. Indeed, the TAPS WG already covers this: https://www.ietf.org/archive/id/draft-ietf-taps-impl-16.html#name-implementing-connection-est
>> - I’d argue that the main point of this revision is to describe how to handle SVCB queries, since those are an increasing requirement for client stacks — but how to handle SVCB insofar as it changes the algorithm for racing *between addresses*. The point of the racing at this level is to end up with a connection to the preferred address, which includes v6 vs v4 weighting, but has always also included other aspects. The fact that we have to also include SVCB record priority values and any local policy about available protocol details tweaks the algorithm, but does not change its core intent. 
>> 
>> Thanks,
>> Tommy 
>> 
>>> 
>>> Best,
>>> Momoka
>>> 
>>> On Tue, Oct 31, 2023 at 3:59 AM Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> 
>>>>> On Oct 30, 2023, at 4:58 PM, Momoka Yamamoto <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> > Please see my response to Bob, earlier. Happy Eyeballs is referring to the overall racing technique, and there isn’t a specific preference for SVCB, etc — just a handling of it.
>>>>> 
>>>>> Isn't Section 5.  "Sorting Addresses" giving a preference? 
>>>>> It gives addresses obtained from SVCB records priority and then QUIC over TCP.
>>>> 
>>>> While Happy Eyeballs as an algorithm inherently requires sorting based on preferences, the specific preferences are more about practical decisions, and can be changed by an implementation.
>>>> 
>>>> The choice in the draft about using SVCB priorities is based on the fact that a service that publishes SVCB records that have priorities indicates it wants clients to have a preference in that priority order; and then we are assuming that if there are any un-prioritized A/AAAA answers not associated with an SVCB record, that they’d be lower priority. However, this can be discussed and changed.
>>>> 
>>>>> 
>>>>> The preference of IPv6 over IPv4 is determined in RFC6724 (RFC3484 when og HE was published) so RFC6555 was only giving a racing technique guide.
>>>>> However, now (after HE2) this document gives advice on how to sort the order to access the addresses other than that of RFC6724.
>>>>> Is that not giving a preference on protocols?
>>>> 
>>>> I view it instead as acknowledging that there are many options that must be ranked when creating the set of connections to try, and we are trying to give the best advice based on a set of assumed preferences, but acknowledge that those preferences could be different and thus sorting could be different too.
>>>> 
>>>>> 
>>>>> 
>>>>> I've created issues in GitHub nn my comments on section 8.1.
>>>>> I would like some input on the issue I raised, "Should synthesis be done to all address spaces?" from others as well.
>>>>> https://github.com/tfpauly/draft-happy-eyeballs-v3/issues/18
>>>> 
>>>> Thanks for opening these! We’ll keep the conversation going there.
>>>> 
>>>> Best,
>>>> Tommy
>>>>> 
>>>>> Best,
>>>>> Momoka Y
>>>>> 
>>>>> 5.
>>>>> 
>>>>> 
>>>>> On Thu, Oct 26, 2023 at 9:27 PM Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> Hi Momoka,
>>>>>> 
>>>>>> Thanks for reviewing! Some comments inline.
>>>>>> 
>>>>>>> On Oct 26, 2023, at 1:16 AM, Momoka Yamamoto <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> Hi Tommy,
>>>>>>> 
>>>>>>> This draft seems to add great insight into how the Happy Eyeballs 2 algorithm changes with SVCB RRs and QUIC. 
>>>>>>> I'm very excited for this work.
>>>>>>> 
>>>>>>> Here are some comments I have.
>>>>>>> 
>>>>>>> ## The word "Happy Eyeballs" Having multiple meanings.
>>>>>>> After RFC8305 the word "Happy Eyeballs" gained a new meaning from the original. With this draft, there are the below meanings.
>>>>>>> - Fall back to IPv4 if IPv6 doesn't work preperly. (original RFC6555)
>>>>>>> - Prefer AAAA over A records when doing DNS queries and sorting them. (v2 RFC8305)
>>>>>>>     - Prefer SVCB RRs over the two (v3)
>>>>>>> - Prefer QUIC over TCP. (v3)
>>>>>>> 
>>>>>>> The confusing part about the word "Happy Eyeballs" is that the word "Happy" has two meanings.
>>>>>>> - The clinet will be happy if fallback is done after a timeout if an attempt is not working.
>>>>>>> - Prefer a better protocol over others.
>>>>>>> 
>>>>>>> I guess this is hard to fix now but not knowing which "Happy" when hearing,
>>>>>>> "This client doesn't do Happy Eyeballs" out of context is sometimes misleading.
>>>>>>> 
>>>>>> 
>>>>>> Please see my response to Bob, earlier. Happy Eyeballs is referring to the overall racing technique, and there isn’t a specific preference for SVCB, etc — just a handling of it.
>>>>>> 
>>>>>> I think we could talk about what version implementations support, where support for SVCB comes along with v3.
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ## Clairification; QUIC v.s. TCP
>>>>>>> With v3 QUIC is given preference over TCP but only when support for QUIC is detected.
>>>>>>> When support is not detected by SVCB RRs or Alt-Svc, only TCP should be attempted.
>>>>>>> 
>>>>>>> is my understanding correct?
>>>>>> 
>>>>>> I don’t think this algorithm is being prescriptive in that aspect. Connections can use QUIC based on what the application requests, apart from SVCB or Alt-Svc.
>>>>>> 
>>>>>>> 
>>>>>>> ## 8.1.  IPv4 Address Literals
>>>>>>> >  Such translation also applies to any IPv4 address hints received in SVCB RRs.
>>>>>>> The mention of SVCB RRs makes this section a lot more meaningful as IP address literals may not have been so common but with SVCB RRS they will be common even in a client/server scenario.
>>>>>> 
>>>>>> The other case that is common is when you’re using encrypted DNS (DoT/DoH/etc) and asking for both address families. That’s common to then get v4 answers that need to be translated.
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ### RFC8781
>>>>>>> > the device queries the network for the NAT64 prefix using
>>>>>>> > "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
>>>>>>> > [RFC7050] and then
>>>>>>> Regarding the use of RFC7050 for obtaining the NAT64 prefix, RA Option 38 (as specified in RFC8781) could also serve this purpose. However, given that this section is geared towards platforms not supporting 464XLAT, I assume doing rfc7050 is simpler than getting an RA message for an application so the omission of RFC8781 seems justified.
>>>>>> 
>>>>>> I think it would be fine to mention to RFC8781. Perhaps you could file an issue on GitHub for that?
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ### Should synthesis be done to all address spaces?
>>>>>>> > If client applications or users wish to connect to IPv4 address
>>>>>>> > literals, the Happy Eyeballs engine will need to perform NAT64
>>>>>>> > address synthesis for them. 
>>>>>>> I wonder if this has been discussed for RFC7050 but should this algorithm be applied to RFC1918 address space and 127.0.0.0/8 <http://127.0.0.0/8>? Maybe we should discuss if these address spaces should NOT be translated.
>>>>>>> 
>>>>>>> For the loopback address range (127.0.0.0/8 <http://127.0.0.0/8>), it should not be translated as the client in question should have a route to the loopback network resulting in the synthesis not being needed.
>>>>>>> 
>>>>>>> For addresses within the RFC1918 space, the translated address could be misrouted to an unintended host, diverging from the user's original intention. Nonetheless, it is worth noting that nothing stops the inclusion of RFC1918 addresses in DNS records. As a result, translated IPv6 addresses originating from RFC1918 space can still be acquired via DNS64. Given this, it may be counterintuitive to impose restrictions on such addresses in the Happy Eyeballs algorithm.
>>>>>> 
>>>>>> Another good point — we can add a mention of that. Want to file an issue?
>>>>>> 
>>>>>> Thanks,
>>>>>> Tommy
>>>>>>> 
>>>>>>> 
>>>>>>> Best,
>>>>>>> 
>>>>>>> Momoka 
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Oct 24, 2023 at 1:40 AM Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>> Hello v6ops,
>>>>>>>> 
>>>>>>>> We’ve just published a new draft for “Happy Eyeballs Version 3”, which is intended as a -bis document to RFC 8305 (which was developed in this WG). There are a few major points that needed updating:
>>>>>>>> 
>>>>>>>> - Describing how to incorporate SVCB / HTTPS RRs
>>>>>>>> 	- Priority
>>>>>>>> 	- v4/v6 hints
>>>>>>>> 	- Affect on various timers, etc
>>>>>>>> 	- ECH, ALPN, etc
>>>>>>>> - Describing how happy eyeballs applies to QUIC (and also TLS over TCP)
>>>>>>>> 
>>>>>>>> The bulk of the document is the same as RFC 8305, but updates the logic and algorithm for these changes.
>>>>>>>> 
>>>>>>>> Please take a look! We’d love to discuss at IETF 118 as time permits.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> Tommy
>>>>>>>> 
>>>>>>>>> Begin forwarded message:
>>>>>>>>> 
>>>>>>>>> From: [e-mail] <mailto:[e-mail]>
>>>>>>>>> Subject: New Version Notification for draft-pauly-v6ops-happy-eyeballs-v3-00.txt
>>>>>>>>> Date: October 23, 2023 at 9:34:00 AM PDT
>>>>>>>>> To: David Schinazi <[e-mail] <mailto:[e-mail]>>, Kenichi Ishibashi <[e-mail] <mailto:[e-mail]>>, Nidhi Jaju <[e-mail] <mailto:[e-mail]>>, Tommy Pauly <[e-mail] <mailto:[e-mail]>>
>>>>>>>>> 
>>>>>>>>> A new version of Internet-Draft draft-pauly-v6ops-happy-eyeballs-v3-00.txt has
>>>>>>>>> been successfully submitted by Tommy Pauly and posted to the
>>>>>>>>> IETF repository.
>>>>>>>>> 
>>>>>>>>> Name:     draft-pauly-v6ops-happy-eyeballs-v3
>>>>>>>>> Revision: 00
>>>>>>>>> Title:    Happy Eyeballs Version 3: Better Connectivity Using Concurrency
>>>>>>>>> Date:     2023-10-23
>>>>>>>>> Group:    Individual Submission
>>>>>>>>> Pages:    18
>>>>>>>>> URL:      https://www.ietf.org/archive/id/draft-pauly-v6ops-happy-eyeballs-v3-00.txt
>>>>>>>>> Status:   https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-v3/
>>>>>>>>> HTML:     https://www.ietf.org/archive/id/draft-pauly-v6ops-happy-eyeballs-v3-00.html
>>>>>>>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-pauly-v6ops-happy-eyeballs-v3
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Abstract:
>>>>>>>>> 
>>>>>>>>>   Many communication protocols operating over the modern Internet use
>>>>>>>>>   hostnames.  These often resolve to multiple IP addresses, each of
>>>>>>>>>   which may have different performance and connectivity
>>>>>>>>>   characteristics.  Since specific addresses or address families (IPv4
>>>>>>>>>   or IPv6) may be blocked, broken, or sub-optimal on a network, clients
>>>>>>>>>   that attempt multiple connections in parallel have a chance of
>>>>>>>>>   establishing a connection more quickly.  This document specifies
>>>>>>>>>   requirements for algorithms that reduce this user-visible delay and
>>>>>>>>>   provides an example algorithm, referred to as "Happy Eyeballs".  This
>>>>>>>>>   document updates the algorithm description in RFC 8305.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The IETF Secretariat
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> v6ops mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>> _______________________________________________
>>>>>>> v6ops mailing list
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>> 
>>>> 
>>