Subject: [v6ops] An Update to Happy Eyeballs

From: David Schinazi <[email-masked]>
Date: Wed, 08 Mar 2017 11:25:29 -0800

Hi v6ops,

Tommy Pauly and myself have written up what we've learned
in the past few years maintaining and improving Apple's Happy Eyeballs stack,
and submitted it as draft-pauly-v6ops-happy-eyeballs-update.

You'd love to hear your feedback!

Thanks,
David Schinazi

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pauly-v6ops-happy-eyeballs-update-00.txt
> Date: March 8, 2017 at 10:43:20 PST
> To: Tommy Pauly <[email-masked]>, David Schinazi <[email-masked]>
> 
> 
> A new version of I-D, draft-pauly-v6ops-happy-eyeballs-update-00.txt
> has been successfully submitted by David Schinazi and posted to the
> IETF repository.
> 
> Name:		draft-pauly-v6ops-happy-eyeballs-update
> Revision:	00
> Title:		An Update to Happy Eyeballs
> Document date:	2017-03-08
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyeballs-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-update/
> Htmlized:       https://tools.ietf.org/html/draft-pauly-v6ops-happy-eyeballs-update-00
> 
> 
> Abstract:
>   "Happy Eyeballs" (RFC6555) is the name for a technique of reducing
>   user-visible delays on dual-stack hosts.  Since one address family
>   (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network,
>   clients that attempt connections for both address families in
>   parallel have a higher chance of establishing a connection sooner.
>   Now that this approach has been deployed at scale and measured for
>   several years, the algorithm specification can be refined to improve
>   its reliability and generalization.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Mar 2017 11:51:48 +0100

>and submitted it as draft-pauly-v6ops-happy-eyeballs-update.

The draft says: Intended status: Standards Track

With that in mind I would prefer splitting the DNS and the connection
parts over two different drafts.

The reason is two fold:
1) The only API that we standardized (getaddrinfo) cannot support the required
   behavior. So an application would have to choose between using a standard
   API or implementing happy eyeballs.
2) In my experience, AAAA hardly ever times out. (I wanted to write 'fail',
   but failure, as in not returning the correct AAAA can be close to 1%. But
   as long as there is no delay, it doesn't matter for happy eyeballs).

I think setting up tcp connections in staggered fashion is highly useful. 
Writing code that gets triggered by DNS responses coming is not supported by
standard APIs and may make code needlessly complex. So we should not require
such behavior.

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Mar 2017 08:56:00 -0800

Hi Philip,

Just a friendly correction. A nit, really.

>   API or implementing happy eyeballs.

This wasn’t us. It was the Open Group. We have no standard API of our own.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Nick Chettle <[email-masked]>
Date: Thu, 9 Mar 2017 17:22:54 +0000

Hi David,

It looks good, thanks for sharing what you've learnt.

I just have one question, when talking about the DNS query in section 2 you say:

Both queries SHOULD be sent on the wire as
   close together as possible, with the ordering being dictated by the
   system's host address preference policy.

Then when talking about DNS server selection in Section 2.1 you mention that:

In keeping with the Happy Eyeballs approach,
   queries SHOULD be sent over IPv6 first.

Are these statements slightly contradictory or should DNS queries relate to the host policy while DNS server selection always uses IPv6 first?

Thanks, Nick

________________________________________
From: v6ops <[email-masked]> on behalf of David Schinazi <[email-masked]>
Sent: 08 March 2017 19:25:29
To: IPv6 Operations
Subject: [v6ops] An Update to Happy Eyeballs

Hi v6ops,

Thanks,
David Schinazi

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-pauly-v6ops-happy-eyeballs-update-00.txt
Date: March 8, 2017 at 10:43:20 PST
To: Tommy Pauly <[email-masked]<mailto:[email-masked]>>, David Schinazi <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 09 Mar 2017 09:31:22 -0800

Hi Nick,

We can clarify the text to make the distinction clearer.

>   queries SHOULD be sent over IPv6 first.

So, to summarize:
- Choose which DNS server to talk to first if you have multiple; prefer IPv6 if you have no better information that's what your system prefers
- When you send queries to that server, send both A and AAAA close together, and if your system prefers IPv6, send the AAAA first.

Thanks,
Tommy 

> On Mar 9, 2017, at 9:22 AM, Nick Chettle <[email-masked]> wrote:
> 
> Hi David,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Mar 2017 18:40:34 +0100

>    On Mar 9, 2017, at 02:51, Philip Homburg <[1][email-masked]>
>    wrote:
> 
>    This wasnt us. It was the Open Group. We have no standard API
>    of our own.  --james woodyatt <[2][email-masked]>

Yes, you are correct. I never noticed that it originate there.

---

From: Joe Touch <[email-masked]>
Date: Thu, 9 Mar 2017 10:33:53 -0800

>    system's host address preference policy.
With one or more layers (link, tunnel, etc.), and possibly one or more
"wires", the end system might not have any control over this requirement.

Why is it needed?

(if it applies ONLY if the queries end up on the same "wire", how would
an end system even detect that?)

Joe

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 10 Mar 2017 09:29:55 -0800

Hi Philip,

As James mentioned, getaddrinfo isn't technically an IETF standardized API. There are many networking APIs that are based on asynchronously handling DNS responses. We can certainly soften some of the language to make it clear that if your system has no such option, you are not necessarily out of spec, but if such an option is available, we believe that it SHOULD indeed be used. This fits with the Happy Eyeballs paradigm: if I am waiting for one of the DNS responses to come back, I could have already made my connection in that time, getting the user the resource loaded more quickly.

To the point of how often this situation occurs, we have done a lot of measurements in our stack. The approach documented in this document is essentially the algorithm that we have implemented for Apple devices. We do observe that fairly often, when DNS results are not already cached, one result (AAAA) may be returned asynchronously, and the TCP connection can be fully established before the other result (A) is returned. Using this algorithm, even if it only helps in a small percentage of overall connections, is a big win.

For those who are interested, I'd like to also point to some work going on in TAPS that build upon Happy Eyeballs to do connection racing and use asynchronous APIs to get wins not just in IPv4-vs-IPv6, but between paths, interfaces, and other protocols (and hopefully make it easier to application developers to write their networking code in the process):
https://tools.ietf.org/html/draft-pauly-taps-guidelines-00
https://tools.ietf.org/html/draft-trammell-taps-post-sockets-00

Thanks,
Tommy

> On Mar 9, 2017, at 2:51 AM, Philip Homburg <[email-masked]> wrote:
>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Mar 2017 23:54:22 +0100

In your letter dated Fri, 10 Mar 2017 09:29:55 -0800 you wrote:
>We can certainly soften some of the language to make it clear that if 
>your system has no such option, you are not necessarily out of spec, but if su
>ch an option is available, we believe that it SHOULD indeed be used. This fits
> with the Happy Eyeballs paradigm: if I am waiting for one of the DNS response
>s to come back, I could have already made my connection in that time, getting 
>the user the resource loaded more quickly.

If the DNS requirements can be toned down to the point that an application
can use getaddrinfo if that fits the application, then that's fine
with me.

---

From: David Schinazi <[email-masked]>
Date: Sun, 12 Mar 2017 20:53:13 -0700

Hi everyone,

Thanks a lot for the comments and feedback.
We've incorporated them into -01, please let us know if they were properly addressed.
https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyeballs-update-01.txt <https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyeballs-update-01.txt>

Regards,
David Schinazi

> On Mar 10, 2017, at 14:54, Philip Homburg <[email-masked]> wrote:
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Mar 2017 13:49:16 +0100

>    We've incorporated them into -01, please let us know if they

In my opinion, there is no justification for declaring a single threaded
C application that uses getaddrinfo non-compliant.

So this draft doesn't address my concerns. Just calling getaddrinfo should
be enough.

---

From: David Schinazi <[email-masked]>
Date: Mon, 13 Mar 2017 11:13:51 -0700

Phillip,

By design, Happy Eyeballs cannot be implemented using blocking
networking calls in a single-threaded C program, as it involves
racing parallel operations. DNS is no different than TCP in this regard.

If an implementation wants to be compliant with this specification,
they'll need to support asynchronous networking. If an implementation
has limitations that prevent it from being compliant, that is fine,
you don't need to support all RFCs to connect your code to the Internet.

If there is consensus in the working group to relax the requirements
language in this document, we're absolutely open to that. But I don't
believe we should restrict ourselves to getaddrinfo() or any API for
that matter.

David

> On Mar 13, 2017, at 05:49, Philip Homburg <[email-masked]> wrote:
> 
>>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Mar 2017 08:04:16 +1100

This is also a area where fastest is the enemy of faster.

There is zero reason for making async DNS a MUST.  A MAY would be
fine for the DNS lookups.  AAAA lookups vary rarely fail to resolve
these days which was the original reason for splitting the two
lookups.  It also adds a lot of complication for very little gain.
It also doesn't preserve a preference to IPv6 as it depends on cache
content not transport reachability, 50ms is not enough time to take
cache contents out of the equation if A is cached and AAAA isn't.

nodes are supposed to impliment destination address selection policy
rules and that includes deciding whether to talk IPv4 or IPv6 first.
This document breaks that for no good reason.

Mark

In message <[email-masked]>, David Schinazi wri
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Nygren <[email-masked]>
Date: Mon, 13 Mar 2017 22:02:46 -0400

It's great to see an updated version of this guidance!

> There is zero reason for making async DNS a MUST.

The bare minimum is that revolvers must do A and AAAA lookups in parallel.
The current behavior of some stacks is to do the AAAA and A lookups in
series.
This means effectively means that adding IPv6 connectivity to a client adds
an
extra RTT in for almost all DNS lookups.
For example, see section 5 in:
https://www.akamai.com/us/en/multimedia/documents/technical-publication/a-case-for-faster-mobile-web-in-cellular-ipv6-networks.pdf
For clients such as mobile device visiting sites with lots of hostnames,
this can have a very substantial performance hit.  This also shows up
in some RUM-based measurement reports making IPv6 look slower
(due to clients with IPv6 spending more time doing DNS lookups before
doing page loads).

Doing the lookups in parallel but not waiting for both responses is better
than serial,
but still has a perf hit (whatever the recovery time plus an RTT) when
the A or AAAA lookup packet is lost.

Some additional comments/thoughts after reading through the -01 version:

* It would be good to add a section on failure cases NOT detected/mitigated
by this form of Happy Eyeballs.
   Even if not covering mitigations, it would still be good to discuss them
for awareness.

    - In particular, PMTUD seems to be the most common.  ie, if there is a
PMTUD issue between
      the client and server, then the connect will often succeed but the
connection will fail to function.
      I think most large-scale IPv6 server operators (plus many of small
ones) have broken this at least once.
      One client-side mitigation for TCP might be for the client to offer
progressively smaller MSS
      as it retries different IPs within a protocol family.
      (I don't know if anyone does or has tried this?  There is the
server-side pmtud probing feature.)
      For UDP protocols, using full-frame packets for the SYN and the
SYN-ACK (as QUIC does) seems
      like one approach to at least detect breakage early, although QUIC
doesn't key have a PMTUD
      mitigation solution AFAIK.

    -  Servers that return different content for IPv6 vs IPv4 (eg, "404 not
found" due to an unconfigured server on the IPv6 side).
       "Don't do this" as advice to server operators is likely the best way
to fix it as hacking around it on the client side is unhelpful.

* It may make sense to recommend some form of back-off in the retry
timing.  Rather than a fixed value (eg, 250ms), adding
  an increasing time value with some jitter into each retry may be safer in
the cases of overloaded servers
  or a network connection that is borderline near the retry time.  I've
seen congestive failure and lack-of-progress
  scenarios from having a fixed retry timer.  For example, with servers
that do FIFO queueing of connections to accept,
  if the queue becomes longer than the retry period then all clients fail
to make forward progress and you reach
  congestive collapse.  The same can happen with links that become
high-latency, however.

* It may be worth adding some guidance into reporting and visibility.  I'm
not sure how?
  One of the big complaints against Happy Eyeballs is that it masks
brokenness (latency spikes
  but things keep working so no one complains enough to fix the root cause).
  Having a recommendation that stacks or applications at least keep
counters and telemetry
  on failures may at least make it more viable to debug?

* It would be good to provide guidance or a reminder around protocols that
send data along with a SYN
  or an initial flight  (eg, TCP Fast Open / TFO and TLS 1.3 0RTT).  In
particular, you likely
  want to send this ONLY on one connection attempt (eg, the IPv6 attempt?)
as otherwise
  the operation may be executed twice by the server.  This may cause undue
server load
  and for apps/clients incorrectly using TFO or 0RTT for non-idempotent
operations
  it could cause duplicate actions.

Thanks!  Erik

On Sun, Mar 12, 2017 at 11:53 PM, David Schinazi <[email-masked]>
wrote:

> https://www.ietf.org/internet-drafts/draft-pauly-v6ops-
> happy-eyeballs-update-01.txt
>
> Regards,
> David Schinazi
>
>

---

From: David Schinazi <[email-masked]>
Date: Tue, 14 Mar 2017 19:54:00 -0700

Mark,

We have operational data proving that asynchronous DNS is not "for no good reason".
DNS queries fail rarely (it still happens) but they often can take several hundreds of milliseconds longer.
The user shouldn't have to wait that delay for their webpage to load, and our data shows that this timer
fires regularly in the field indicating that users would have been needlessly waiting for their content.
Why should we artificially delay the user's experience for an A response if we already have the AAAA?

Erik,

Thanks for the suggestions!
- we'll add a section about problems that Happy Eyeballs do not solve
- regarding the increased retry timer, this is somewhat covered by historical RTT information.
    I don't think failures to reach the first address should harm the next ones, as that defeats redundancy
- I do agree that the main downside of Happy Eyeballs is hiding failures,
    but enforcing clients have a reporting system seems uncommon for IETF protocols, do you know of any?
- Regarding TFO / TLS 1.3 0RTT I think the requirement is that you MUST NOT use those
    if your data isn't idempotent, as packets could be duplicated in the network. This is orthogonal to Happy Eyeballs.

Thanks,
David Schinazi

> On Mar 13, 2017, at 19:02, Erik Nygren <[email-masked]> wrote:
> 
> The current behavior of some stacks is to do the AAAA and A lookups in series. 
> This means effectively means that adding IPv6 connectivity to a client adds an 
> For example, see section 5 in:  https://www.akamai.com/us/en/multimedia/documents/technical-publication/a-case-for-faster-mobile-web-in-cellular-ipv6-networks.pdf <https://www.akamai.com/us/en/multimedia/documents/technical-publication/a-case-for-faster-mobile-web-in-cellular-ipv6-networks.pdf>
> Doing the lookups in parallel but not waiting for both responses is better than serial,
> * It would be good to add a section on failure cases NOT detected/mitigated by this form of Happy Eyeballs.
>    Even if not covering mitigations, it would still be good to discuss them for awareness.
> 
>     - In particular, PMTUD seems to be the most common.  ie, if there is a PMTUD issue between
>       the client and server, then the connect will often succeed but the connection will fail to function.
>       I think most large-scale IPv6 server operators (plus many of small ones) have broken this at least once.
>       One client-side mitigation for TCP might be for the client to offer progressively smaller MSS 
>       (I don't know if anyone does or has tried this?  There is the server-side pmtud probing feature.)
>       For UDP protocols, using full-frame packets for the SYN and the SYN-ACK (as QUIC does) seems
>       like one approach to at least detect breakage early, although QUIC doesn't key have a PMTUD 
>     -  Servers that return different content for IPv6 vs IPv4 (eg, "404 not found" due to an unconfigured server on the IPv6 side).
>        "Don't do this" as advice to server operators is likely the best way to fix it as hacking around it on the client side is unhelpful.
> 
> * It may make sense to recommend some form of back-off in the retry timing.  Rather than a fixed value (eg, 250ms), adding
>   an increasing time value with some jitter into each retry may be safer in the cases of overloaded servers
>   or a network connection that is borderline near the retry time.  I've seen congestive failure and lack-of-progress
>   scenarios from having a fixed retry timer.  For example, with servers that do FIFO queueing of connections to accept,
>   if the queue becomes longer than the retry period then all clients fail to make forward progress and you reach 
>   congestive collapse.  The same can happen with links that become high-latency, however.
> 
> * It may be worth adding some guidance into reporting and visibility.  I'm not sure how?  
>   One of the big complaints against Happy Eyeballs is that it masks brokenness (latency spikes
>   Having a recommendation that stacks or applications at least keep counters and telemetry
> * It would be good to provide guidance or a reminder around protocols that send data along with a SYN
>   or an initial flight  (eg, TCP Fast Open / TFO and TLS 1.3 0RTT).  In particular, you likely
>   want to send this ONLY on one connection attempt (eg, the IPv6 attempt?) as otherwise 
>   the operation may be executed twice by the server.  This may cause undue server load
>   and for apps/clients incorrectly using TFO or 0RTT for non-idempotent operations 
> On Sun, Mar 12, 2017 at 11:53 PM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi everyone,
> 
>> On Mar 10, 2017, at 14:54, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Mar 2017 14:46:21 +1100

In message <[email-masked]>, David Schinazi wri
tes:
> Mark,
> 
> We have operational data proving that asynchronous DNS is not "for no
> good reason".  DNS queries fail rarely (it still happens) but they often
> can take several hundreds of milliseconds longer.
> The user shouldn't have to wait that delay for their webpage to load,
> and our data shows that this timer fires regularly in the field 
> indicating that users would have been needlessly waiting for their content.

So you now want Happy Eyeballs, which was designed to remove delays
of 10's - 100's of seconds before failover, to now override address
selection policies because the DNS's cache has one address type
present and not the other.  That is what the 50ms timer achieves.
It takes ~200ms to get a answer from the other side of the world
with terrestial links.

Happy Eyeballs was never about having the absolute fastest time to
connect.  It was about establishing a connection in a reasonable
amount of time in presence of network / server failures without
having ridiciously long failover delays.

Mark

> - Regarding TFO / TLS 1.3 0RTT I think the requirement is that you MUST
>   NOT use those if your data isn't idempotent, as packets could be
>   duplicated in the network. This is orthogonal to Happy Eyeballs.
> 
> Thanks,
> David Schinazi
> 
> 
> > For example, see section 5 in:  https://www.akamai.com/us/en/multimedia/doc
> uments/technical-publication/a-case-for-faster-mobile-web-in-cellular-ipv6-ne
> tworks.pdf <https://www.akamai.com/us/en/multimedia/documents/technical-publi
> cation/a-case-for-faster-mobile-web-in-cellular-ipv6-networks.pdf>
> > * It may make sense to recommend some form of back-off in the retry timing.
>   Rather than a fixed value (eg, 250ms), adding
> >   or a network connection that is borderline near the retry time.  I've see
> n congestive failure and lack-of-progress
> >   scenarios from having a fixed retry timer.  For example, with servers tha
> t do FIFO queueing of connections to accept,
> > https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyeballs-updat
> e-01.txt <https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyebal
> ls-update-01.txt>
> > 
> > Regards,
> > David Schinazi
> > 
> > 
> --Boundary_(ID_F8KG9fRFqYtBb8MnlxB0dw)
> Content-type: text/html; CHARSET=US-ASCII
> Content-transfer-encoding: quoted-printable
> 
> <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
> charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
> class=3D""><div class=3D"">Mark,</div><div class=3D""><br =
> class=3D""></div><div class=3D"">We have operational data proving that =
> asynchronous DNS is not "for no good reason".</div><div class=3D"">DNS =
> queries fail rarely (it still happens) but they often can take several =
> hundreds of milliseconds longer.</div><div class=3D"">The user shouldn't =
> have to wait that delay for their webpage to load, and our data shows =
> that this timer</div><div class=3D"">fires regularly in the field =
> indicating that users would have been needlessly waiting for their =
> content.</div><div class=3D"">Why should we artificially delay the =
> user's experience for an A response if we already have the =
> AAAA?</div><div class=3D""><br class=3D""></div><div =
> class=3D"">Erik,</div><div class=3D""><br class=3D""></div><div =
> class=3D"">Thanks for the suggestions!</div><div class=3D"">- we'll add =
> a section about problems that Happy Eyeballs do not solve</div><div =
> class=3D"">- regarding the increased retry timer, this is somewhat =
> covered by historical RTT information.</div><div class=3D"">&nbsp; =
> &nbsp; I don't think failures to reach the first address should harm the =
> next ones, as that defeats redundancy</div><div class=3D"">- I do agree =
> that the main downside of Happy Eyeballs is hiding failures,</div><div =
> class=3D"">&nbsp; &nbsp; but enforcing clients have a reporting system =
> seems uncommon for IETF protocols, do you know of any?</div><div =
> class=3D"">- Regarding TFO / TLS 1.3 0RTT I think the requirement is =
> that you MUST NOT use those</div><div class=3D"">&nbsp; &nbsp; if your =
> data isn't idempotent, as packets could be duplicated in the network. =
> This is orthogonal to Happy Eyeballs.</div><div class=3D""><br =
> class=3D""></div><div class=3D"">Thanks,</div><div class=3D"">David =
> Schinazi</div><div class=3D""><br class=3D""></div><br =
> class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
> Mar 13, 2017, at 19:02, Erik Nygren &lt;<a =
> href=3D"mailto:[email-masked]" =
> class=3D"">[email-masked]</a>&gt; wrote:</div><br =
> class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
> class=3D""><div class=3D""><div class=3D""><div class=3D""><div =
> class=3D""><div class=3D""><div class=3D""><div class=3D""><div =
> class=3D""><div class=3D"">It's great to see an updated version of this =
> guidance!<br class=3D""><br class=3D"">&gt; There is zero reason for =
> making async DNS a MUST.&nbsp; <br class=3D""><br class=3D""></div><div =
> class=3D"">The bare minimum is that revolvers must do A and AAAA lookups =
> in parallel.<br class=3D""></div><div class=3D"">The current behavior of =
> some stacks is to do the AAAA and A lookups in series. <br class=3D"">This=
>  means effectively means that adding IPv6 connectivity to a client adds =
> an <br class=3D""></div><div class=3D"">extra RTT in for almost all DNS =
> lookups.&nbsp; <br class=3D""></div><div class=3D"">For example, see =
> section 5 in:&nbsp; <a =
> href=3D"https://www.akamai.com/us/en/multimedia/documents/technical-public=
> ation/a-case-for-faster-mobile-web-in-cellular-ipv6-networks.pdf" =
> class=3D"">https://www.akamai.com/us/en/multimedia/documents/technical-pub=
> lication/a-case-for-faster-mobile-web-in-cellular-ipv6-networks.pdf</a><br=
>  class=3D""></div><div class=3D"">For clients such as mobile device =
> visiting sites with lots of hostnames,<br class=3D""></div><div =
> class=3D"">this can have a very substantial performance hit.&nbsp; This =
> also shows up<br class=3D""></div><div class=3D"">in some RUM-based =
> measurement reports making IPv6 look slower <br class=3D""></div><div =
> class=3D"">(due to clients with IPv6 spending more time doing DNS =
> lookups before <br class=3D""></div><div class=3D"">doing page loads). =
> <br class=3D""><br class=3D"">Doing the lookups in parallel but not =
> waiting for both responses is better than serial,<br class=3D""></div><div=
>  class=3D"">but still has a perf hit (whatever the recovery time plus an =
> RTT) when <br class=3D"">the A or AAAA lookup packet is lost.<br =
> class=3D""></div><div class=3D""><br class=3D""></div>Some additional =
> comments/thoughts after reading through the -01 version:<br class=3D""><br=
>  class=3D""></div>* It would be good to add a section on failure cases =
> NOT detected/mitigated by this form of Happy Eyeballs.<br =
> class=3D""></div><div class=3D"">&nbsp;&nbsp; Even if not covering =
> mitigations, it would still be good to discuss them for awareness.<br =
> class=3D""></div><br class=3D"">&nbsp;&nbsp;&nbsp; - In particular, =
> PMTUD seems to be the most common.&nbsp; ie, if there is a PMTUD issue =
> between<br class=3D""></div>&nbsp; &nbsp; &nbsp; the client and server, =
> then the connect will often succeed but the connection will fail to =
> function.<br class=3D""></div><div =
> class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think most large-scale IPv6 =
> server operators (plus many of small ones) have broken this at least =
> once.<br class=3D""></div>&nbsp;&nbsp; &nbsp;&nbsp; One client-side =
> mitigation for TCP might be for the client to offer progressively =
> smaller MSS <br class=3D"">&nbsp;&nbsp; &nbsp;&nbsp; as it retries =
> different IPs within a protocol family.<br =
> class=3D""></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (I don't know if anyone =
> does or has tried this?&nbsp; There is the server-side pmtud probing =
> feature.)<br class=3D""></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For UDP =
> protocols, using full-frame packets for the SYN and the SYN-ACK (as QUIC =
> does) seems<br class=3D""></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; like one =
> approach to at least detect breakage early, although QUIC doesn't key =
> have a PMTUD <br class=3D""></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> mitigation solution AFAIK.<br class=3D""><div class=3D""><div =
> class=3D""><div class=3D""><div class=3D""><div class=3D""><div =
> class=3D""><div class=3D""><div class=3D""><br class=3D""><div =
> class=3D"">&nbsp;&nbsp;&nbsp; -&nbsp; Servers that return different =
> content for IPv6 vs IPv4 (eg, "404 not found" due to an unconfigured =
> server on the IPv6 side).<br class=3D""></div><div =
> class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Don't do this" as =
> advice to server operators is likely the best way to fix it as hacking =
> around it on the client side is unhelpful.<br class=3D""></div><div =
> class=3D""><br class=3D""></div><div class=3D"">* It may make sense to =
> recommend some form of back-off in the retry timing.&nbsp; Rather than a =
> fixed value (eg, 250ms), adding<br class=3D""></div><div class=3D"">&nbsp;=
>  an increasing time value with some jitter into each retry may be safer =
> in the cases of overloaded servers<br class=3D""></div><div =
> class=3D"">&nbsp; or a network connection that is borderline near the =
> retry time.&nbsp; I've seen congestive failure and lack-of-progress<br =
> class=3D""></div><div class=3D"">&nbsp; scenarios from having a fixed =
> retry timer.&nbsp; For example, with servers that do FIFO queueing of =
> connections to accept,<br class=3D""></div><div class=3D"">&nbsp; if the =
> queue becomes longer than the retry period then all clients fail to make =
> forward progress and you reach <br class=3D""></div><div class=3D"">&nbsp;=
>  congestive collapse.&nbsp; The same can happen with links that become =
> high-latency, however.<br class=3D""></div><div class=3D""><br =
> class=3D""></div><div class=3D"">* It may be worth adding some guidance =
> into reporting and visibility.&nbsp; I'm not sure how?&nbsp; <br =
> class=3D""></div><div class=3D"">&nbsp; One of the big complaints =
> against Happy Eyeballs is that it masks brokenness (latency spikes<br =
> class=3D""></div><div class=3D"">&nbsp; but things keep working so no =
> one complains enough to fix the root cause).<br class=3D""></div><div =
> class=3D"">&nbsp; Having a recommendation that stacks or applications at =
> least keep counters and telemetry<br class=3D""></div><div =
> class=3D"">&nbsp; on failures may at least make it more viable to =
> debug?<br class=3D""><br class=3D""></div><div class=3D"">* It would be =
> good to provide guidance or a reminder around protocols that send data =
> along with a SYN<br class=3D"">&nbsp; or an initial flight&nbsp; (eg, =
> TCP Fast Open / TFO and TLS 1.3 0RTT).&nbsp; In particular, you =
> likely<br class=3D"">&nbsp; want to send this ONLY on one connection =
> attempt (eg, the IPv6 attempt?) as otherwise <br class=3D""></div><div =
> class=3D"">&nbsp; the operation may be executed twice by the =
> server.&nbsp; This may cause undue server load<br class=3D""></div><div =
> class=3D"">&nbsp; and for apps/clients incorrectly using TFO or 0RTT for =
> non-idempotent operations <br class=3D""></div><div class=3D"">&nbsp; it =
> could cause duplicate actions. <br class=3D""></div><div class=3D""><br =
> class=3D""></div><div class=3D"">Thanks!&nbsp; Erik<br class=3D""><br =
> class=3D""></div><div class=3D""><br class=3D""><br class=3D""><br =
> class=3D""><br =
> class=3D""></div></div></div></div></div></div></div></div></div></div><di=
> v class=3D"gmail_extra"><br class=3D""><div class=3D"gmail_quote">On =
> Sun, Mar 12, 2017 at 11:53 PM, David Schinazi <span dir=3D"ltr" =
> class=3D"">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank" =
> class=3D"">[email-masked]</a>&gt;</span> wrote:<br =
> class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
> .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
> style=3D"word-wrap:break-word" class=3D"">Hi everyone,<div class=3D""><br =
> class=3D""></div><div class=3D"">Thanks a lot for the comments and =
> feedback.</div><div class=3D"">We've incorporated them into -01, please =
> let us know if they were properly addressed.</div><div class=3D""><a =
> href=3D"https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyeba=
> lls-update-01.txt" target=3D"_blank" =
> class=3D"">https://www.ietf.org/internet-<wbr =
> class=3D"">drafts/draft-pauly-v6ops-<wbr =
> class=3D"">happy-eyeballs-update-01.txt</a></div><div class=3D""><br =
> class=3D""></div><div class=3D"">Regards,</div><div class=3D"">David =
> Schinazi</div><div class=3D""><div class=3D"h5"><div class=3D""><br =
> class=3D""></div><div class=3D""><br class=3D""><div =
> class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Mar =
> 10, 2017, at 14:54, Philip Homburg &lt;<a =
> href=3D"mailto:[email-masked]" target=3D"_blank" =
> class=3D"">[email-masked]</a>&gt; wrote:</div><br =
> class=3D"m_5032583941560406556Apple-interchange-newline"><div =
> class=3D""><div class=3D"">In your letter dated Fri, 10 Mar 2017 =
> 09:29:55 -0800 you wrote:<br class=3D""><blockquote type=3D"cite" =
> class=3D"">We can certainly soften some of the language to make it clear =
> that if <br class=3D"">your system has no such option, you are not =
> necessarily out of spec, but if su<br class=3D"">ch an option is =
> available, we believe that it SHOULD indeed be used. This fits<br =
> class=3D"">with the Happy Eyeballs paradigm: if I am waiting for one of =
> the DNS response<br class=3D"">s to come back, I could have already made =
> my connection in that time, getting <br class=3D"">the user the resource =
> loaded more quickly.<br class=3D""></blockquote><br class=3D"">If the =
> DNS requirements can be toned down to the point that an application<br =
> class=3D"">can use getaddrinfo if that fits the application, then that's =
> fine<br class=3D"">with me.<br class=3D""><br class=3D""><br =
> class=3D"">______________________________<wbr =
> class=3D"">_________________<br class=3D"">v6ops mailing list<br =
> class=3D""><a href=3D"mailto:[email-masked]" target=3D"_blank" =
> class=3D"">[email-masked]</a><br class=3D""><a =
> href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank" =
> class=3D"">https://www.ietf.org/mailman/<wbr =
> class=3D"">listinfo/v6ops</a><br =
> class=3D""></div></div></blockquote></div><br =
> class=3D""></div></div></div></div><br =
> class=3D"">______________________________<wbr =
> class=3D"">_________________<br class=3D"">
> v6ops mailing list<br class=3D"">
> <a href=3D"mailto:[email-masked]" class=3D"">[email-masked]</a><br =
> class=3D"">
> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer"=
>  target=3D"_blank" class=3D"">https://www.ietf.org/mailman/<wbr =
> class=3D"">listinfo/v6ops</a><br class=3D"">
> <br class=3D""></blockquote></div><br class=3D""></div>
> </div></blockquote></div><br class=3D""></body></html>=
> 
> --Boundary_(ID_F8KG9fRFqYtBb8MnlxB0dw)--
> 
> 
> --===============7303905125349802389==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============7303905125349802389==--
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 15 Mar 2017 17:00:47 -0700

On Sun, Mar 12, 2017 at 8:53 PM, David Schinazi <[email-masked]> wrote:

> https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyeballs-update-01.txt

I have one quick (and minor) question about the 01 version: in Section
6 it states

   If, during the course of connection establishment, the DNS answers
   change either by adding resolved addresses, or removing previously
   resolved addresses (for example, due to expiry of the TTL on that DNS
   record), the client should react based on its current progress.

Specifically what kind of scenario does this intend to imply?  For
example, consider the following scenario:

1. start a AAAA query for a destination name
2. start an A query for the same name almost at the same time
3. get a response to the AAAA query (set of IPv6 addresses)
4. start establishing a connection for one of the IPv6 addresses
5. get a response to the A query (set of IPv4 addresses)

At step 5, DNS resolution is fully completed.  But the response to the
A query is quite unlikely to affect "previously resolved (IPv6 in this
case) addresses".  At least it shouldn't add any IPv6 address.  The
only possible corner case I can think of is to get an NXDOMAIN to the
A query, which could effectively mean "removing" the IPv6 addresses.
Does the above text specifically mean this case?  Are there other
cases under consideration?  Or is this about the case where multiple
DNS servers are used?

--
JINMEI, Tatuya

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 16 Mar 2017 13:05:56 -0700

> having ridiciously long failover delays.

What an utterly absurd statement, to claim to speak for the authors “Happy Eyeballs”, and tell us what our invention was or was not designed to do.

Back in 2007 and 2008 at Apple we started to get real-world bug reports about web sites being unusable. These were major web sites, whose DNS servers simply failed to answer AAAA queries, causing unusably long timeouts before getaddrinfo() completed. I won’t name names, because incredibly, some of these major web sites still have broken DNS servers. Some fixed their DNS servers, only then later to break them again.

Without some workaround in place, any ISP attempting to turn on IPv6 support would have caused client devices to start doing AAAA queries, which time out, which make web sites unusable, which results in complaints from customers, which results in the ISP turning off IPv6 support. So it was vital that we work out how to allow an ISP to enable IPv6 without enraging their customers.

In July 2008 I gave a presentation at the Technical Plenary at IETF 72 in Dublin about how Apple fixed this problem, recommending that others do the same. If you haven’t watched the presentation, please do, before telling us what our invention was designed to do. It’s not very long.

<http://www.stuartcheshire.org/IETF72/>

Dan Wing and Andrew Yiurtchenko decided to write up a subset of my recommendations as RFC 6555. Inexplicably they decided to document the asynchronous TCP connection racing, but not the asynchronous DNS query racing, which is odd, given that, at the time, DNS failure to answer AAAA queries was the dominant problem.

Still, Dan Wing and Andrew Yiurtchenko wrote a good, if incomplete, RFC.

Now, nine years later, Tommy Pauly and David Schinazi thought it was about time we shared the remainder of the relevant information with the community.

Like it or not, this is in fact what Apple networking products do, and have done for many years, and, regardless of what you think, it does provide a better user experience than a synchronous blocking call to getaddrinfo().

Stuart Cheshire

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 16 Mar 2017 13:07:50 -0700

On 13 Mar 2017, at 05:49, Philip Homburg <[email-masked]> wrote:

> In my opinion, there is no justification for declaring a single threaded C application that uses getaddrinfo non-compliant.
> 
> So this draft doesn't address my concerns. Just calling getaddrinfo should be enough.

You might think just calling getaddrinfo() should be enough, but it’s not.

You are free to write a single-threaded C application that uses synchronous blocking calls if you like, and it might work okay on Ethernet, but it would give a horrible user-experience on a mobile device with wireless networking (and for that reason your app would fail Apple app review and it would not be allowed on the iPhone, for failing to achieve even minimal usability standards).

We’re not telling you how you should write your app.

But we are publishing a specification that gives guidance about how to write a good app, that gives a good user experience. (You’re not forced to follow that guidance, and you don’t have to if you don’t want to.)

Stuart Cheshire

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 16 Mar 2017 13:09:57 -0700

On 15 Mar 2017, at 17:00, 神明達哉 <[email-masked]> wrote:

> At step 5, DNS resolution is fully completed.

No, DNS resolution is not fully completed at step 5. In this asynchronous model (as used in Apple products for many years) DNS resolution is an ongoing process, which continues until the client has successfully made a connection, and only stops when the client tells the DNS engine that it can stop.

Many web sites use DNS records with fairly short TTLs, which allows them to update answers fairly rapidly.

If a server is down or overloaded, they can remove that address from the answer set, and substitute another. Thus the set of answers changes over time. The Apple DNS APIs take this passage of time into account, and notify clients as the set of answers changes, via “add” and “remove” events. If a client has been trying to connect for some time, unsuccessfully, and then another IP address becomes available, that address is added to the set of candidates, and may be the one that actually works.

You can easily see this for yourself, e.g., using www.google.com, or www.microsoft.com.

Here are two examples (using IPv4 only, for readability).

You will see that at 12:47:10 the IP address 172.217.6.68 for Google was withdrawn, and replaced by 216.58.194.164.

At 12:47:16 the IP address 104.82.49.139 for Microsoft was withdrawn, and replaced by 173.222.250.151.

% dns-sd -G v4 www.google.com
DATE: ---Thu 16 Mar 2017---
12:47:02.843  ...STARTING...
Timestamp     A/R Flags if Hostname                     Address
12:47:02.845  Add     2  0 www.google.com.              172.217.6.68
12:47:10.854  Rmv     1  0 www.google.com.              172.217.6.68
12:47:10.855  Add     2  0 www.google.com.              216.58.194.164

% dns-sd -G v4 www.microsoft.com
DATE: ---Thu 16 Mar 2017---
12:46:41.253  ...STARTING...
Timestamp     A/R Flags if Hostname                     Address
12:46:41.256  Add     2  0 e1863.dspb.akamaiedge.net.   104.82.49.139
12:47:16.139  Rmv     1  0 e1863.dspb.akamaiedge.net.   104.82.49.139
12:47:16.139  Add     2  0 e1863.dspb.akamaiedge.net.   173.222.250.151

Stuart Cheshire

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Mar 2017 08:11:23 +1100

In message <[email-masked]>, Stuart Cheshire wr
ites:
> What an utterly absurd statement, to claim to speak for the authors
> “Happy Eyeballs”, and tell us what our invention was or was not designed
> to do.

Happy Eyeballs is working group consensus.  It's a product of the
working group.

> Back in 2007 and 2008 at Apple we started to get real-world bug reports
> about web sites being unusable. These were major web sites, whose DNS
> servers simply failed to answer AAAA queries, causing unusably long
> timeouts before getaddrinfo() completed. I won’t name names, because
> incredibly, some of these major web sites still have broken DNS servers.
> Some fixed their DNS servers, only then later to break them again.

And that isn't a server failure?  https://www.kb.cert.org/vuls/id/714121
was issued in 2003 about this.  We have similar issues with TLSA
today.

> Without some workaround in place, any ISP attempting to turn on IPv6
> support would have caused client devices to start doing AAAA queries,
> which time out, which make web sites unusable, which results in
> complaints from customers, which results in the ISP turning off IPv6
> support. So it was vital that we work out how to allow an ISP to enable
> IPv6 without enraging their customers.

Actually most AAAA queries have always worked.  The ones that failed
were those directed at load balancers.

> In July 2008 I gave a presentation at the Technical Plenary at IETF 72 in
> Dublin about how Apple fixed this problem, recommending that others do
> the same. If you haven’t watched the presentation, please do, before
> telling us what our invention was designed to do. It’s not very long.
>
> Dan Wing and Andrew Yiurtchenko decided to write up a subset of my
> recommendations as RFC 6555. Inexplicably they decided to document the
> asynchronous TCP connection racing, but not the asynchronous DNS query
> racing, which is odd, given that, at the time, DNS failure to answer AAAA
> queries was the dominant problem.
>

Which is Happy Eyeballs.  Just because HE isn't what Apple experimented
with doesn't make my statement was wrong.  Apple has never implemented
HE.  It's implemented something that is HE like but not HE.  Apple
actually got complaints about that.

A bit like the load balancers implemented something that was like
a DNS server but wasn't actually a DNS server. They implements a A
record server and failed to handle all the other types as required
by RFC 1034.

> Now, nine years later, Tommy Pauly and David Schinazi thought it was
> about time we shared the remainder of the relevant information with the
> community.

And we are pushing back because it goes too far.

> Like it or not, this is in fact what Apple networking products do, and
> have done for many years, and, regardless of what you think, it does
> provide a better user experience than a synchronous blocking call to
> getaddrinfo().
>
> Stuart Cheshire

---

From: Philip Homburg <[email-masked]>
Date: Fri, 17 Mar 2017 11:49:06 +0100

> Were not telling you how you should write your app.
> 
> But we are publishing a specification that gives guidance about
> how to write a good app, that gives a good user experience. (Youre
> not forced to follow that guidance, and you dont have to if you
> dont want to.)

If you proposed an informational RFC published through the ISE 'This
how we do Happy Eyeballs at Apple' then it would be perfectly fine with me.

However, this is proposed as a BCP, which has the same status as standard.
So if you write a BCP with MUSTs, etc. then you are telling people how
they should write their apps. That the purpose of a BCP.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Mar 2017 14:22:41 -0700

At Thu, 16 Mar 2017 13:09:57 -0700,
Stuart Cheshire <[email-masked]> wrote:

> No, DNS resolution is not fully completed at step 5. In this
> asynchronous model (as used in Apple products for many years) DNS
> resolution is an ongoing process, which continues until the client
> has successfully made a connection, and only stops when the client
> tells the DNS engine that it can stop.

I guess there's something (undocumented yet and) very specific to the
Apple implementation details of the "asynchronous model", then.  In
the above example steps, we've received an answer to both AAAA and A
queries at step 5.  Whether the resolution is asynchronous or
synchronous, why can't we "tell the DNS engine to stop"?  Does the
"DNS engine" still expect more responses even after getting both AAAA
and A responses?  Perhaps it keeps sending the same queries to see
whether there's a change?  At least it's not clear to me from Section
3 of the draft.

> them to update answers fairly rapidly.

I know all this.  But I don't think it relevant to the point of my
question.

--
JINMEI, Tatuya

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 17 Mar 2017 16:46:35 -0700

> whether there's a change?  At least it's not clear to me from Section

If you want to learn more about this, the asynchronous model is explained in “Zero Configuration Networking: The Definitive Guide”

<https://www.amazon.com/Zero-Configuration-Networking-Definitive-Guide-ebook/dp/B0043M4Z9I/>

If you’re going to be in Chicago for IETF 98 I can bring a copy for you.

Stuart Cheshire

---

From: Benno Overeinder <[email-masked]>
Date: Wed, 22 Mar 2017 14:55:31 +0100

Hi all,

A bit late to chime in, but maybe still a useful and relevant contribution to the discussion.

> On 16 Mar 2017, at 21:07, Stuart Cheshire <[email-masked]> wrote:
> 

Thanks, I can second this as one of the partners in the getdns API project [1].  

First I like to mention that getdns API provides a modern *asynchronous* DNS API.  And although the getdns API is not a standard, the design process of the getdns API specification [2] has similarities with a standardisation process.  In the specification [2] you can also read what the design considerations were.  Talking with a handful of application developers about the requirements of a modern API, a first version of the API was published.  Public feedback was provided (during presentations, email list, etc.) and incorporated, and implementers of the API also contributed feedback and improvements.

The goals and results of the getdns API and library are similar to what Stuart mentioned above: the API (hopefully) provides a means to write a good application, i.e. using a high-level DNS resolution API with much functionality and good user experience.

— Benno

[1] https://getdnsapi.net
[2] https://getdnsapi.net/documentation/spec/

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Mar 2017 23:56:21 +0900

> having ridiciously long failover delays.

I think this is just a naming issue. Happy Eyeballs was about avoiding
broken IPv6 connections. Period. In fact, the very first words in RFC 6555
are "When a server's IPv4 path and protocol are working, but the server's
IPv6 path and protocol are not working...".

What is written in this draft does much more than that, and calling it
"happy eyeballs" is sort of insultingly simplistic. Perhaps just drop the
words "happy eyeballs" and reposition the draft as a best current practice
to provide a good user experience in a dual-stack Internet?

I think it's extremely hard to argue that waiting for an A query when you
have an AAAA in cache (or vice versa) is going to reduce latency or improve
user experience. You can use getaddrinfo if you want, but you're going to
pay the price in terms of latency. I wouldn't call that a best practice.

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Mar 2017 08:04:17 -0700

> On Mar 22, 2017, at 7:56 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> I think it's extremely hard to argue that waiting for an A query when you have an AAAA in cache (or vice versa) is going to reduce latency or improve user experience. You can use getaddrinfo if you want, but you're going to pay the price in terms of latency. I wouldn't call that a best practice.

I must be missing something. If you already know the AAAA, fine. If you're using the resolver's cache, what API gets you an IPv6 address other than getaddrinfo?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Mar 2017 00:15:16 +0900

On Thu, Mar 23, 2017 at 12:04 AM, Fred Baker <[email-masked]>
wrote:

> > I think it's extremely hard to argue that waiting for an A query when
> you have an AAAA in cache (or vice versa) is going to reduce latency or
> improve user experience. You can use getaddrinfo if you want, but you're
> going to pay the price in terms of latency. I wouldn't call that a best
> practice.
>
> I must be missing something. If you already know the AAAA, fine. If you're
> using the resolver's cache, what API gets you an IPv6 address other than
> getaddrinfo?
>

You don't have to use getaddrinfo to do AAAA lookups. You can use your own
code, or even pass binary blobs to res_send if you want.

getaddrinfo is not very smart. It keeps trying until it has answers for
everything you asked it to do, and then it returns everything. That means
that if the A query is in cache and the AAAA query is not, then you have to
wait for the AAAA query to succeed.

I think the key point here is that integrating the DNS resolver retry loops
with the connection attempts provide latency savings.

---

From: Job Snijders <[email-masked]>
Date: Wed, 22 Mar 2017 16:18:49 +0100

Perhaps of interest to this group:

https://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/

Kind regards,

Job

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Mar 2017 16:26:13 +0100 (CET)

> https://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/

There is work going on coming up with better APIs than the 90ties socket 
ones and getaddrinfo.

If this is of interest, TAPS WG has presentation from other efforts as 
well.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Mar 2017 11:22:15 +1300

> https://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/

What a bizarre idea to use getaddrinfo() for format conversion, when inet_pton() and inet_ntop() exist.

My sympathy is limited.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 22 Mar 2017 23:22:38 +0100

>with the connection attempts provide latency savings.

What is next? Is this working group going to specify how SMTP clients should
do MX lookups?

Why is how to do DNS lookups suddenly something v6ops has to write a BCP
about?

Next question. If an A record happens to be cached and an operator wants
to keep traffic out of expensive CGNAT routers. Do we really want to 
encourage hosts to connect over IPv4 just because an A record was cached
and the AAAA record wasn't? Is that really best current practice?

---

From: Gert Doering <[email-masked]>
Date: Thu, 23 Mar 2017 13:07:04 +0100

Hi,

> What a bizarre idea to use getaddrinfo() for format conversion, when inet_pton() and inet_ntop() exist.

Well, whoever designed that API obviously thought it would be something
clever.  Otherwise, how do you explain AI_NUMERICHOST?

                    AI_NUMERICHOST  If the AI_NUMERICHOST bit is set, it indi-
                                    cates that hostname should be treated as a
                                    numeric string defining an IPv4 or IPv6
                                    address and no name resolution should be
                                    attempted.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279