Re: [v6ops] Happy Eyeballs, v3!

[Momoka Yamamoto <[e-mail]>]

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?)

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