Re: [v6ops] Happy Eyeballs, v3!

[Momoka Yamamoto <[e-mail]>]

>
> - 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.

Best,
Momoka Y

On Mon, Nov 6, 2023 at 11:21 AM Tommy Pauly <[e-mail]> wrote:

>
>
> On Nov 6, 2023, at 11:13 AM, Momoka Yamamoto <[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]> wrote:
>
>>
>>
>> On Oct 30, 2023, at 4:58 PM, Momoka Yamamoto <[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]> wrote:
>>
>>> Hi Momoka,
>>>
>>> Thanks for reviewing! Some comments inline.
>>>
>>> On Oct 26, 2023, at 1:16 AM, Momoka Yamamoto <[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? Maybe we
>>> should discuss if these address spaces should NOT be translated.
>>>
>>> For the loopback address range (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]> 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]
>>>> *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]>, Kenichi Ishibashi <
>>>> [e-mail]>, Nidhi Jaju <[e-mail]>, Tommy Pauly <
>>>> [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]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>>
>>
>