Subject: [v6ops] WGLC for RFC6555bis

From: Fred Baker <[email-masked]>
Date: Thu, 3 Aug 2017 19:55:32 -0700

As discussed in Prague, this opens a two week WGLC on this draft. This will end on 18 August. Please read the draft now and comment on it. The chairs are interested to know about experiments using the old and modified behaviors, and a quantification of the improvement (or lack thereof) if such exists. We are also interested in the clarity and utility of the proposal.

Sent using a machine that autocorrects in interesting ways...

> On Aug 3, 2017, at 7:50 PM, Fred Baker <[email-masked]> wrote:
> 
> Thanks
> 
> Sent using a machine that autocorrects in interesting ways...
> 
>> On Aug 2, 2017, at 7:41 PM, David Schinazi <[email-masked]> wrote:
>> 
>> Hi v6ops chairs,
>> 
>> As discussed in Prague, we have published a minor revision to RFC655bis:
>> https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-03
>> 
>> I think the document is ready to start Working Group Last Call.
>> 
>> Thanks,
>> David Schinazi

---

From: Philip Homburg <[email-masked]>
Date: Sun, 06 Aug 2017 17:38:29 +0200

I still disagree with Section 3. In particular the use of MUST and MUST NOT
in that section.

It is fine if an implementation want to go the extra mile and do asynch DNS.
But happy eyeballs has a lot of benefits without asynch DNS.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 8 Aug 2017 09:26:35 -0700

At Thu, 3 Aug 2017 19:55:32 -0700,
Fred Baker <[email-masked]> wrote:

> As discussed in Prague, this opens a two week WGLC on this
> draft. This will end on 18 August. Please read the draft now and
> comment on it. The chairs are interested to know about experiments
> using the old and modified behaviors, and a quantification of the
> improvement (or lack thereof) if such exists. We are also interested
> in the clarity and utility of the proposal.

I've just taken a quick look at draft-ietf-v6ops-rfc6555bis-03.  I
don't think it even ready for a WGLC.

As far as I can see the 03 version doesn't address any of my previous
comments https://www.ietf.org/mail-archive/web/v6ops/current/msg26611.html,
not even a quite trivial editorial glitch.  Actually I've not even
seen any followup discussion on the comments in the list.

I'm not saying these comments are necessarily addressed.  Some of them
may turn out to be invalid or too minor and dismissed.  That's totally
fine, but from the fact there's not even been a discussion seems to
suggest the authors have not really checked all feedback yet.  I'd
suggest the authors do it first, discuss those in this list, make a
decision on how/whether to address these points, get rough consensus,
and then ask for a WGLC.

--
JINMEI, Tatuya

---

From: David Schinazi <[email-masked]>
Date: Tue, 08 Aug 2017 10:06:12 -0700

Hi Jinmei,

We have read the feedback and addressed the ones we thought relevant.
It does appear that I did not respond to the email you linked, and failed to
take into account your editorial comment. For both of these I apologize.

Most of your comments were regarding asynchronous DNS, which I believe
the working group has reached rough consensus on. While there is still a
vocal minority advocating that asynchronous DNS is "too hard", those
implementations are free to only implement Happy Eyeballs v1. The chairs
should correct me if they disagree, but I feel the working group overall
agrees that the benefits of asynchronous DNS are worth it.

Thanks,
David Schinazi

> On Aug 8, 2017, at 09:26, 神明達哉 <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ca By <[email-masked]>
Date: Tue, 08 Aug 2017 19:27:45 +0000

On Thu, Aug 3, 2017 at 7:55 PM Fred Baker <[email-masked]> wrote:

> As discussed in Prague, this opens a two week WGLC on this draft. This
> will end on 18 August. Please read the draft now and comment on it. The
> chairs are interested to know about experiments using the old and modified
> behaviors, and a quantification of the improvement (or lack thereof) if
> such exists. We are also interested in the clarity and utility of the
> proposal.
>

I have read the i-d.

I believe the I-D is clear, provides a high level of utility, and is ready
to move forward.

Section 7 for handling ipv6-only networks is especially helpful

Regards,
Cameron

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 9 Aug 2017 06:08:48 +0200 (CEST)

On Thu, 3 Aug 2017, Fred Baker wrote:

> chairs are interested to know about experiments using the old and 
> modified behaviors, and a quantification of the improvement (or lack 
> thereof) if such exists. We are also interested in the clarity and 
> utility of the proposal.

I have re-read this i-d in its entirety. It's clear, useful, and I support 
it being moved towards publication.

As a side note, we might sometime in the future want to bis this document 
with source address selection as well (to try with multiple source 
addresses if the inital attempts do not work). Currently in 4, it only 
deals with destination address selection.

Actually, thinking of it, this draft doesn't say anything about source 
address selection. It just says:

"First, the client MUST sort the addresses using Destination Address
    Selection ([RFC6724], Section 6)."

Is the presumtion that RFC6724 section 5 (source address selection) is 
already being performed one by one on all destination addresses being 
processed, and that the source address selection is out of scope for this 
document? Do we need this to be explicitly stated? This is not a show 
stopper for me, I don't have a strong opinion on the matter.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 9 Aug 2017 14:05:00 -0700

I could be wrong, and in any event this is "no hats".

My perception is that the application (which is to say, the code that calls the socket API) selects the destination, tells the socket API, and the OS then selects the source address. If I were allowed to specify that interface, I would have the application give an ASCII literal string (which might contain an encoded address, a DNS name, or something else specific to the OS) to the API, which would select both the source and destination addresses on the OS side of the API. If the socket API worked that way, we wouldn't have to change applications to deploy IPv6, which would be a huge win. 

If we're not allowed to change the API, I don't think we're in a position to discuss source address selection in this document. The code that selects the destination doesn't (at least usually) also select the source.

Happy to be corrected.

> On Aug 8, 2017, at 9:08 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I have re-read this i-d in its entirety. It's clear, useful, and I support it being moved towards publication.
> 
> As a side note, we might sometime in the future want to bis this document with source address selection as well (to try with multiple source addresses if the inital attempts do not work). Currently in 4, it only deals with destination address selection.
> 
> Actually, thinking of it, this draft doesn't say anything about source address selection. It just says:
> 
> Is the presumtion that RFC6724 section 5 (source address selection) is already being performed one by one on all destination addresses being processed, and that the source address selection is out of scope for this document? Do we need this to be explicitly stated? This is not a show stopper for me, I don't have a strong opinion on the matter.
> 
> --

---

From: David Schinazi <[email-masked]>
Date: Wed, 09 Aug 2017 17:26:17 -0700

I agree with Fred. As currently specified, Happy Eyeballs (both v1 and v2) only discuss destination addresses.
For each destination address that Happy Eyeballs wants to connect to, the OS picks a corresponding source address via RFC 6724.
I believe source address selection is out of scope of RFC 6555bis and already well documented in RFC 6724.
We could however explicitly say the above in the document.

Regarding Mikael's proposal of trying multiple source addresses for one given destination, this would be a non-trivial amount of work to specify,
as doing it "wrong" can cause serious issues (e.g. a server can trick you into leaking your stable address), so I'll consider it future work.

David Schinazi

> On Aug 9, 2017, at 14:05, Fred Baker <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 10 Aug 2017 07:47:05 +0200 (CEST)

On Wed, 9 Aug 2017, David Schinazi wrote:

> Regarding Mikael's proposal of trying multiple source addresses for one 
> given destination, this would be a non-trivial amount of work to 
> specify, as doing it "wrong" can cause serious issues (e.g. a server can 
> trick you into leaking your stable address), so I'll consider it future 
> work.

That's a good point. I still think we need to do this at some point in the 
future, but I agree that it's out of scope for this document.

Thanks!

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Aug 2017 11:13:48 -0700

At Tue, 08 Aug 2017 10:06:12 -0700,

> agrees that the benefits of asynchronous DNS are worth it.

Hmm, if the wg has reached consensus on the use of a MUST for
asynchronous DNS, I'm not opposed to it myself.  I thought it was
still open: as far as I remember I've not seen a declaration of the
consensus in this list, and I can't see it in the Prague minutes:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6ops
(and I wasn't there or didn't participate in it remotely).  And, while
I personally don't have a strong opinion on the matter itself, I tend
to agree with those opposing to it in that a MUST sounds too strong.
But, again, if we've already reached a consensus on it that I have
simply overlooked, that's fine.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Thu, 10 Aug 2017 12:50:37 -0700

To my knowledge, the chairs have not asserted a consensus.

> On Aug 10, 2017, at 11:13 AM, 神明達哉 <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Aug 2017 11:42:29 +1000

It breaks address selection rules (RFC  6724) as they require that
A and AAAA lookups succeeding and are intended to move traffic to
using IPv6 as a transport if it is available.

50ms is doesn't even allow for speed-of-light responses from the
other side of the world to arrive or is the IETF demanding that
every zone be served by commercial DNS hosters that have multiple
points of presence on every continent on the planet.  At the moment
you are measuring if there is a cached A/AAAA response or not.

It's not that asynchronous is too hard.  It's that it results in
bad behaviour with the timers presented here.  Its speed vs correctness
with no reasonable delay to allow for a correct response to arrive.

Do we want traffic to move to IPv6 by default or the absolute fastest
connections possible?  You can't have both.

Mark

In message <[email-masked]>, Fred Baker writes:
> > On Aug 10, 2017, at 11:13 AM,  <[email-masked]> wrote:
> >

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 10 Aug 2017 21:16:34 -0700

Hi Mark,

I'd like to clarify the role of the 50ms delay. This is not a delay from the beginning of the DNS query, but a delay from when the A record returns, and when the AAAA record later comes back. There should not be a significant difference in the query response time between A and AAAA generally, which is why the delay is short. The only time cached results would come into play is if only one family is cached, and not the other.

There are essentially three options with regards to when you start a TCP connection after sending the DNS queries:

1. Start the first TCP connection immediately upon receiving the first DNS response. Downside here is that if A comes back 2 milliseconds or so before the AAAA, you've biased towards IPv4 for no good reason.
2. Start the first TCP connection after a grace period delay after receiving the first DNS response (we recommend 50 ms). This guarantees that you never wait beyond the delay before trying some connection, but you also won't bias towards IPv4 for just a couple milliseconds.
3. Start the first TCP connection after receiving both A and AAAA always. This is the synchronous DNS option that was used previously, which means that if there is an error with one response, you have the penalty of waiting a very long time.

I think that (2) is the best option both for user experience and for the promotion of IPv6. We can certainly try to have both, at least! The timer values may need to be tuned in the future, but in our measurements, the 50ms window is the right tradeoff on the current Internet.

Thanks,
Tommy

> On Aug 10, 2017, at 6:42 PM, Mark Andrews <[email-masked]> wrote:
> 
> 
> In message <[email-masked] <mailto:[email-masked]>>, Fred Baker writes:
>>> On Aug 10, 2017, at 11:13 AM,  <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked] <mailto:[email-masked]>
> 
> [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: Fri, 11 Aug 2017 15:57:35 +1000

In message <[email-masked]>, Tommy Pauly writes
:
> 
> Hi Mark,
> 
> I'd like to clarify the role of the 50ms delay. This is not a delay from
> the beginning of the DNS query, but a delay from when the A record returns,
> and when the AAAA record later comes back. There should not be a significant
> difference in the query response time between A and AAAA generally, which
> is why the delay is short. The only time cached results would come into
> play is if only one family is cached, and not the other.

Which happens all the time.  Negative responses have different TTLs
to positive responses almost all the time so they leave the cache
at different times.  Also if you have a mix of IPv4 only clients
and dual stack clients talking to a common resolver the A/AAAA
records when both are present become unsyncronised even if they are
published with the same TTL.

With lossless DNS we should be picking IPv6 connections all the
time.  50 ms won't achieve that.  Somewhere up around 250ms might.
Really small amounts of IPv4 traffic will stop people turning off
IPv4.  They won't investigate to see if the IPv4 traffic could have
been served by IPv6.

Picking IPv4 when there is IPv6 because a DNS transaction was lost
is acceptable.  It shouldn't happen if the wasn't a lost transaction.

> There are essentially three options with regards to when you start a TCP
> connection after sending the DNS queries:
> 
> 1. Start the first TCP connection immediately upon receiving the first
> DNS response. Downside here is that if A comes back 2 milliseconds or
> so before the AAAA, you've biased towards IPv4 for no good reason.
> 2. Start the first TCP connection after a grace period delay after
> receiving the first DNS response (we recommend 50 ms). This guarantees
> that you never wait beyond the delay before trying some connection, but
> you also won't bias towards IPv4 for just a couple milliseconds.
> 3. Start the first TCP connection after receiving both A and AAAA always.
> This is the synchronous DNS option that was used previously, which means
> that if there is an error with one response, you have the penalty of
> waiting a very long time.
> 
> I think that (2) is the best option both for user experience and for
> the promotion of IPv6. We can certainly try to have both, at least! The
> timer values may need to be tuned in the future, but in our measurements,
> the 50ms window is the right tradeoff on the current Internet.
> 
> Thanks,
> Tommy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 11 Aug 2017 08:22:55 +0200 (CEST)

On Fri, 11 Aug 2017, Mark Andrews wrote:

> With lossless DNS we should be picking IPv6 connections all the time. 
> 50 ms won't achieve that.  Somewhere up around 250ms might. Really small 
> amounts of IPv4 traffic will stop people turning off IPv4.  They won't 
> investigate to see if the IPv4 traffic could have been served by IPv6.
>
> Picking IPv4 when there is IPv6 because a DNS transaction was lost is 
> acceptable.  It shouldn't happen if the wasn't a lost transaction.

I think this is premature. Apple started with 0ms IPv6 head start, then 
from what I understand, gathered data, then decided 50ms would not hurt 
customer experience.

I would fully expect that in 3-5 years we will have a new document that 
says "look, now there is so much IPv6 out there and it works so well, that 
250ms is a great value". It could even be 500ms. Or 2 seconds, using the 
6555bis value for "Last Resort Local Synthesis Delay".

But doing 250ms today is premature in my opinion. 50ms will give IPv6 
enough of a head start for now. There is enough broken AAAA pointers out 
there still yet.

People won't turn off IPv4 for services in the next 3-5 years anyway.

I believe I saw numbers before that with 50ms head start for IPv6, the 
connection rate over IPv6 was in the 95% or more range? I can't find it 
now however.

---

From: Tim Chown <[email-masked]>
Date: Fri, 11 Aug 2017 13:41:54 +0000

Hi,

> On 11 Aug 2017, at 05:16, Tommy Pauly <[email-masked]> wrote:
> 
> Hi Mark,
> 

I agree (2) seems reasonable.

It’s a hack, but as elegant/good a one that we could reasonably use right now.  It improves on the current RFC6555 behaviour.

On clarifying the relationship to RFC6724, section 4 does already mention it, but perhaps the scope of HE2 can be clearer in the introduction.  Also, using the word ‘destination’ more in the abstract and introduction may help too.

It was good to see presentations at Prague on the impact of timers, and/or suggested changes for them.

I support its publication.

Tim

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 11 Aug 2017 10:19:23 -0700

Hi Mark,

The case in which one query (A) is cached locally, while the other (AAAA) needs to be fetched, should only affect a particular device's connection to a host once. 

Before our device makes any queries, it will either be the case that:
	a) No other device on the local network has made any queries for that hostname, so no answers are cached.
	b) A single-stack device on the local network has made an A query, so only the A answer is cached.
	c) A dual-stack device on the local network has made both A and AAAA queries, so both answers are cached.

In cases (a) and (c), there shouldn't be any significant difference between the response times when our device makes its A and AAAA queries. The case you're concerned about is (b). While it may have been common 10 years ago have most devices on a network be single-stack, almost all consumer operating systems in recent years are dual-stack by default, so we are very rarely in case (b). If you have measured data to show otherwise, I'd love to see it! We've been running metrics for over a year on Happy Eyeballs behavior, and we see good behavior with this algorithm.

When our device sends out its A and AAAA queries, even if we had fallen into the bad case of (b), the caches on the local resolver and the on-device cache will be populated with both answers once both returns. An IPv4 connection may have been established during that time, but any subsequent connections to the same hostname will benefit by the caching, and will choose IPv6 in the future.

I'd like to also emphasize that the spec does say that these delay values are expected to change and be extended beyond current values in the future: 
"For that reason, it is expected that these values will change over time.
   Implementors should feel welcome to use different values without
   changing this specification."
The main point is that the ability to have this logic, and not block on waiting for both answers, is key. If you'd like to set your implementation to use 250ms, that's fine!

Thanks,
Tommy

> On Aug 10, 2017, at 10:57 PM, Mark Andrews <[email-masked]> wrote:
> 
> 
> In message <[email-masked] <mailto:[email-masked]>>, Tommy Pauly writes
> :
>> 
>> Hi Mark,
>>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Aug 2017 11:08:22 -0700

At Fri, 11 Aug 2017 10:19:23 -0700,
Tommy Pauly <[email-masked]> wrote:

> In cases (a) and (c), there shouldn't be any significant difference
> between the response times when our device makes its A and AAAA
> queries. The case you're concerned about is (b). While it may have
> been common 10 years ago have most devices on a network be
> single-stack, almost all consumer operating systems in recent years
> are dual-stack by default, so we are very rarely in case (b). If you
> have measured data to show otherwise, I'd love to see it! We've been
> running metrics for over a year on Happy Eyeballs behavior, and we
> see good behavior with this algorithm.

Regarding measurement, I'd be curious whether you have collected
statistics on ios devices to show if there's any significant
difference between the AAAA TTL and the A TTL of received RRsets.  If
you have actual data that prove these are largely identical most of
the time, it would be more convincing.

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Mon, 14 Aug 2017 09:31:41 +1000

In message <[email-masked]>, Tommy Pauly writes:
> Hi Mark,
>
> The case in which one query (A) is cached locally, while the other (AAAA)
> needs to be fetched, should only affect a particular device's connection
> to a host once.

Whether they will remain unsynchronised or not depends on what
queries arriving when around the ttl expiry period.  Yes, this will
happen again and again and again.  We regularly see cases where
your have sets of records that you know originally arrived with the
same TTL value in the same response packet ending up with different
TTL values over time.  That's just how DNS caches work.

I've looks at thousands of cache dumps over the years.  Seen it
happen lots of the time.

> 	c) A dual-stack device on the local network has made both A and
> AAAA queries, so both answers are cached.
>
> between the response times when our device makes its A and AAAA queries.
> The case you're concerned about is (b). While it may have been common 10
> years ago have most devices on a network be single-stack, almost all
> consumer operating systems in recent years are dual-stack by default,
> so we are very rarely in case (b). If you have measured data to show
> otherwise, I'd love to see it! We've been running metrics for over a
> year on Happy Eyeballs behavior, and we see good behavior with this algorithm.

There is still a lot of equipement being shipped today which is IPv4 only.
Caches don't keep TTLs of different RRsets synchronised.

> When our device sends out its A and AAAA queries, even if we had fallen
> into the bad case of (b), the caches on the local resolver and the
> on-device cache will be populated with both answers once both returns.

Which will have different TTL values.  

> An IPv4 connection may have been established during that time, but any
> subsequent connections to the same hostname will benefit by the caching,
> and will choose IPv6 in the future.

Until the AAAA record expires from the cache and need to be refreshed
at which time there will be a A record in the cache and you get a
cache miss on the AAAA record resulting in IPv4 traffic.  This is
assuming that there was a lookup of the A (and possibly AAAA) record
between when the A record expires and the AAAA record expires.

> I'd like to also emphasize that the spec does say that these delay values
> are expected to change and be extended beyond current values in the future:
> The main point is that the ability to have this logic, and not block on
> waiting for both answers, is key. If you'd like to set your implementation
> to use 250ms, that's fine!

What I do, doesn't have statistical impact, in a world following
this document.  As for changing in the future, all that is doing
is leaving a long tail of devices with bad timer values that have
to be dealt with.

ISP's and providers need to know when to switch off IPv4.  To do
that they will look at the amount of IPv4 traffic they are getting.
Devices that initiate IPv4 connections when there is a full working
IPv6 path just because there was a DNS cache miss don't help anyone
make that decision.  50ms is measuring cache misses not broken /
misconfigure authoritative servers and turning them into IPv4
traffic.  250ms is less so.  500ms is more less so.  This is just
with plain DNS.  Add DNSSEC into the mix where a cache miss may
well require multiple queries as DNSKEY and DS RRsets have also
expired 250ms is becoming too small.

Mark

> > In message <[email-masked]
> <mailto:4CEEB2DC-CF09-45B4
> [email-masked]>>, Tommy Pauly writes
> > :
> >>
> >> Hi Mark,
> >>
> <mailto:[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 Aug 2017 08:51:37 +0200 (CEST)

> expired 250ms is becoming too small.

You are correct, however, this problem should be solved in DNS land, not 
in setting a really high advantage for IPv6 over IPv4 (at this point in 
time).

So while everything you say is correct, I do not agree with your 
prioritization of "avoid long tail IPv4 usage" as opposed to "if IPv6 is 
broken, the user will turn off IPv6 (forever) because it slows down the 
user experience once".

I also think that the caching resolver should refresh soon-to-be-expired 
RRs that are getting close to their TTL=0. For instance, if someone is 
asking for an RR and it has less than 5% of its TTL left, then just 
refresh it.

I believe there are drafts regarding this in DNSOP?

https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 
is one. I thought there was another one, but I can't find it right now.

---

From: Stephen Strowes <[email-masked]>
Date: Mon, 14 Aug 2017 10:44:50 +0200

On 14/08/2017 01:31, Mark Andrews wrote:
> 50ms is measuring cache misses not broken /
> traffic.  250ms is less so.  500ms is more less so.

Regarding bounds for delays and the eyeballs we aim to make happy:

Your comment triggered an old memory. ITU-T G.114 [1], fig. 1, looks at 
human tolerance of one-way delay for real-time comms. Modelling a web 
session against the tolerances they describe implies a 
click-to-seeing-a-page-load delay of <= 290ms for eyeballs to be 
satisfied, and <= 200ms to be practically ecstatic.

So in terms of human-level responsiveness, perhaps the time taken to 
resolve the A record plus, say, 200ms is usually within the bounds of 
acceptability even on the long-end of that timer. This would suggest 
that the timer after the A record is received doesn't have to be as 
tight as 50ms.

Since measurements have been done and 6555bis recommends timers for the 
first time, I'd love to see more data! I'd love to know if people get 
real mad with a 100ms failover.

The most recent public study on happy eyeballs that comes to mind -- 
which doesn't factor in DNS resolution times -- is probably [2]; lots of 
HTTP content is within a few milliseconds on either side.

S.

[1] 
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.114-200305-I!!PDF-E&type=items
[2] 
http://vaibhavbajpai.com/documents/papers/proceedings/dualstack-he-anrw-2016.pdf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 14 Aug 2017 18:51:12 +1000

In message <[email-masked]>, Mikael Abraha
> in setting a really high advantage for IPv6 over IPv4 (at this point in 

The document fails to account for cache misses.  It assumes that
there will be *no* A or AAAA records present or that both A and
AAAA records will be present in the cache.  In both those caches
~50ms is fine as it accounts for variance in the lookups.

When only one of A or AAAA RRsets is present in the cache you have
lookup times < 10ms for the RRset that is present in the cache and
~200ms for the RRset that isn't in the cache but the nameserver
information is present.  Waiting a realistic period for the cache
miss to be filled is not "setting a really high advantage for IPv6
over IPv4".  It's giving them equal standing.

Another way to express this would be to require that the AAAA lookup
has a minimum amount of time to succeed before failing over to IPv4
which is of the order of the time of a cache refresh.

Below is a example of a cache miss for bbc.co.uk/A where the answer
is fetched from the other side of the world.  Thats one UDP there
and one UDP packet back.

[rock:~/git/bind9] marka% dig a bbc.co.uk
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> a bbc.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38363
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d3a9ce37593e504dfd7a68a45991596c1a2a6c63bc284349 (good)
;; QUESTION SECTION:
;bbc.co.uk.			IN	A

;; ANSWER SECTION:
bbc.co.uk.		300	IN	A	212.58.246.79
bbc.co.uk.		300	IN	A	212.58.244.23
bbc.co.uk.		300	IN	A	212.58.244.22
bbc.co.uk.		300	IN	A	212.58.246.78

;; Query time: 206 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 14 18:03:56 AEST 2017
;; MSG SIZE  rcvd: 130

[rock:~/git/bind9] marka% 

> broken, the user will turn off IPv6 (forever) because it slows down the 

When IPv6 lookups are broken they usually take significantly longer
than a additional 200ms to complete as you end up with multiple
queries being made.

> asking for an RR and it has less than 5% of its TTL left, then just 

Which hides some cache misses from the client but not all of them.
Been there, done that.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 Aug 2017 12:00:22 +0200 (CEST)

> over IPv4".  It's giving them equal standing.

Yes, but most of the requests will not have this problem, but you want to 
set the time to take into account this edge case to slow down all 
fall-back cases to IPv4?

Also, I already said you were correct in your analysis, but I just don't 
agree that we need to bring up the wait period for IPv4 to handle the 
problem you're describing. Yes it happens, I am not disputing that. I just 
don't see the huge disadvantage you seem to be seeing in doing a few IPv4 
accesses when it could eventually had been used over IPv6 instead. At 
least not at this point in time.

> When IPv6 lookups are broken they usually take significantly longer than 
> a additional 200ms to complete as you end up with multiple queries being 
> made.

So your proposal is to wait for the AAAA lookup to complete, even if this 
takes several seconds? Just to make sure we might get an answer, 
eventually?

> Which hides some cache misses from the client but not all of them. Been 
> there, done that.

Happy Eyeballs is all about compromise between user experience and "use 
IPv6 at all cost". 50ms seems like a good value at this point in time.

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Aug 2017 20:05:37 +1000

On 14 August 2017 at 18:44, Stephen Strowes <[email-masked]> wrote:
> click-to-seeing-a-page-load delay of <= 290ms for eyeballs to be satisfied,
> and <= 200ms to be practically ecstatic.
>

The ITU's values might be worst case values, rather than ideals.

"Response Times: The 3 Important Limits"
https://www.nngroup.com/articles/response-times-3-important-limits/

"The basic advice regarding response times has been about the same for
thirty years [Miller 1968; Card et al. 1991]:

0.1 second is about the limit for having the user feel that the system
is reacting instantaneously, meaning that no special feedback is
necessary except to display the result.

1.0 second is about the limit for the user's flow of thought to stay
uninterrupted, even though the user will notice the delay. Normally,
no special feedback is necessary during delays of more than 0.1 but
less than 1.0 second, but the user does lose the feeling of operating
directly on the data.

...

"

So I think the ideal to aim for would be for DNS resolution, TCP
connection establishment and web page rendering to start within that
100ms time period.

"Powers of 10: Time Scales in User Experience"
https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/

is another related article.

Regards,
Mark.

> So in terms of human-level responsiveness, perhaps the time taken to resolve
> the A record plus, say, 200ms is usually within the bounds of acceptability
> even on the long-end of that timer. This would suggest that the timer after
> the A record is received doesn't have to be as tight as 50ms.
>
> first time, I'd love to see more data! I'd love to know if people get real
> mad with a 100ms failover.
>
> The most recent public study on happy eyeballs that comes to mind -- which
> doesn't factor in DNS resolution times -- is probably [2]; lots of HTTP
> content is within a few milliseconds on either side.
>
> S.
>
>
> [1]
>>>>> I'd like to clarify the role of the 50ms delay. This is not a delay
>>>
>>> from
>>>>>
>>>>> the beginning of the DNS query, but a delay from when the A record
>>>
>>> returns,
>>>>>
>>>>> and when the AAAA record later comes back. There should not be a
>>>
>>> significant
>>>>>
>>>>> difference in the query response time between A and AAAA generally,
>>>
>>> which
>>>>>
>>>>> There are essentially three options with regards to when you start a
>>>
>>> TCP
>>>>>
>>>>> 3. Start the first TCP connection after receiving both A and AAAA
>>>
>>> always.
>>>>>
>>>>> This is the synchronous DNS option that was used previously, which
>>>
>>> means
>>>>>
>>>>> timer values may need to be tuned in the future, but in our
>>>
>>> measurements,
>>>>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 14 Aug 2017 12:45:41 +0200

Looking at the latest work from Vaibhav, which was presented at the last v6ops meeting:

https://datatracker.ietf.org/meeting/99/materials/slides-99-v6ops-sessa-a-longitudinal-view-of-dual-stacked-websites-failures-latency-and-happy-eyeballs

It looks like the correct value, instead of 50ms will be 150.

I will be in favor of a higher default value, something around 250ms maybe, in order to, not damage “too much” the user experience, but 1) ensure that IPv6 get as much preference as possible and, 2) if something is broken, users complain and operators realize that HE is hiding some problem in their networks.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mark Smith <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 14 de agosto de 2017, 12:06
Para: Stephen Strowes <[email-masked]>
CC: "[email-masked]" <[email-masked]>, 神明達哉 <[email-masked]>
Asunto: Re: [v6ops] WGLC for RFC6555bis

    

    
    
    ...
    
    "

    

    Regards,
    Mark.

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Stephen Strowes <[email-masked]>
Date: Mon, 14 Aug 2017 13:43:12 +0200

> The ITU's values might be worst case values, rather than ideals.

You're right, those values are at the tail ends of their categories in 
the graph in the document. And real-time comms is different from web 
responsiveness, of course, but it's an interesting limit. And happy 
eyeballs is directly about not-displeasing users.

> [...]

Notably the worst case, as recommended, is 300ms after the first DNS 
answers arrive (50ms AAAA grace period + 250ms connect() failover): a 
similar range as I understand Chrome's behaviour.

300ms is, as above, on the long end of when users will reach for their 
pitchforks, so that's probably a good ceiling. If there were data to 
support, say, a 100ms/200ms balance to help satisfy DNS caching 
concerns, that'd be neat.

S.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 14 Aug 2017 14:08:32 +0200

> I will be in favor of a higher default value, something around
> 250ms maybe, in order to, not damage too much the user experience,
> but 1) ensure that IPv6 get as much preference as possible and, 2)
> if something is broken, users complain and operators realize that
> HE is hiding some problem in their networks.

As far as I know, it is extremely rare that an AAAA query will timeout where
an A query succeeds. (Not impossible, just very rare).

So this whole async DNS business is just an attempt to benefit from cached
A records at the expense of having more IPv4 connections go through CGN boxes.

---

From: james woodyatt <[email-masked]>
Date: Mon, 14 Aug 2017 11:46:01 -0700

On Aug 13, 2017, at 23:51, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I also think that the caching resolver should refresh soon-to-be-expired RRs that are getting close to their TTL=0. For instance, if someone is asking for an RR and it has less than 5% of its TTL left, then just refresh it.
> 

You know what would be really terrible? If caching resolvers did this for A records without also doing it for corresponding AAAA records.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Aug 2017 10:25:53 +1000

In message <[email-masked]>, Mikael Abraha
> set the time to take into account this edge case to slow down all 

You obviously do not understand the message you replied to if that is
the message you took out of it.  Please go bag and re-read it.  No I'm
not asking to slow down all fall-back cases to IPv4.

> least not at this point in time.

I design software so that it will be behaving well in 10, 15 years
time.  I do this because I know people are still running the software
I released 20 years ago.  I was also doing this 20 years ago.

The way RFC6555bis is at the moment the timers are such that you
do not even wait for a reply from a single authoritative server.
Now if I was trying to do the absolute fastest connection that would
be the strategy I would be using but that strategy does not match
IETF consensus that IPv6 should be tried before IPv4.  Just waiting 50ms
doesn't come close to meeting that consensus.

> takes several seconds?

I don't know where you are getting this several seconds from.  If
we have a cache hit and a cache miss the server will usually have
NS and associated address records for the zone so you are looking
at a single packet exchange most of the time which was the timer
value I was talking about.  That's all 200ms gives you.  I'm not
asking to wait for the AAAA lookup to always complete.  I'm just
asking for it to have a fair chance to succeed rather than having
almost no chance of succeeding.

50ms give 1% of IPv4 traffic if I'm correctly understanding what
was presented in the video from Prague.  Why are we happy with a
1% error rate?  Why not 0.1% or 0.01%?

> Just to make sure we might get an answer, eventually?

I also don't know where you are getting the "eventually" from but
AAAA lookups succeed (NOERROR/NXDOMAIN) 99.78% (0.22% failure) of
the time over the Alexa top 1 Million for names where A lookups
succeed (0.28% failure rate).  It's companies that decide to use
load balancers and then misconfigure them (they have the wrong
backing zone behind the load balancer) that see AAAA lookups fail
or those that host parked zones and instead of configuring a
individual zone configure a .com or root zone with a wildcard record
resulting in the wrong SOA record being returned.  These misconfigurations
cause the recursive server to try all of the authoritative servers
for a answer before returning SERVFAIL.

---

From: David Schinazi <[email-masked]>
Date: Mon, 14 Aug 2017 19:25:38 -0700

Mark,

Most general-purpose consumer operating systems have been dual-stack for a while now. On dual-stack networks, when modern devices make DNS queries, they'll almost always ask for both A and AAAA. This means that in most cases the cache at the recursive resolver will either contain both or neither response. In that case the time to get either response is roughly the same. So 50ms is a generous time to account for many standard deviations between both responses.

Better yet, we've deployed this to over a billion devices for several years now, and we have collected data from networks worldwide indicating that we do indeed prefer IPv6, and your edge-cases are negligible in practice. The 50ms timer optimizes user experience will ensuring that the overwhelming majority of connections (>99%) go over IPv6.

If we assume that the average packet loss rate of the internet is 1%, then you have roughly a 1.95% chance of having either the AAAA query or response lost with neither the A request nor response lost. In that case it will only be retransmitted 1s later so any timer value less than 1s will not be able to catch that. They just waste the user's time.

So, while I understand your concerns, data shows they are theoretical and impractical. You can set 200ms on your own devices and still be compliant with RFC6555bis.

David Schinazi

> On Aug 14, 2017, at 17:25, Mark Andrews <[email-masked]> wrote:
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Aug 2017 13:45:39 +1000

In message <[email-masked]>, David Schinazi wri
tes:
> Mark,
> 
> Most general-purpose consumer operating systems have been dual-stack
> for a while now. On dual-stack networks, when modern devices make DNS
> queries, they'll almost always ask for both A and AAAA. This means that
> in most cases the cache at the recursive resolver will either contain
> both or neither response. In that case the time to get either response
> is roughly the same. So 50ms is a generous time to account for many
> standard deviations between both responses.
> 
> Better yet, we've deployed this to over a billion devices for several
> years now, and we have collected data from networks worldwide indicating
> that we do indeed prefer IPv6, and your edge-cases are negligible in
> practice. The 50ms timer optimizes user experience will ensuring that
> the overwhelming majority of connections (>99%) go over IPv6.
>
> If we assume that the average packet loss rate of the internet is 1%,
> then you have roughly a 1.95% chance of having either the AAAA query
> or response lost with neither the A request nor response lost. In that
> case it will only be retransmitted 1s later so any timer value less
> than 1s will not be able to catch that. They just waste the user's time.

Does it hurt to have a 300ms timer that starts when the AAAA query
is issued which stops the A RRset being used until that timer clears
unless there has been a reply to the AAAA lookup?  I'm asking for
there being a chance that a cache miss on the AAAA lookup can succeed
in getting a AAAA RRset returned.  Today there is almost no chance.
This does not slow down queries where both A and AAAA responses are
cached (as you should get both answers in well under that time) or
neither are cached.  If there ttls remain sychronised this degenerates
to what you already have and if they don't it allows for a single
refresh to succeed.  It isn't waiting for packet loss retransmission
except for authoritative servers that are known to be topologicaly
close based on their previous response times.  Yes, recursive servers
use sub-second retransmission timers.

e.g.
		max(50, (300 - elasped-time-ms))

Mark

> So, while I understand your concerns, data shows they are theoretical
> and impractical. You can set 200ms on your own devices and still be
> compliant with RFC6555bis.

Don't insult my intelligence by repeating this again. What I do has
no statistical signicicance.  Whats in the document does.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 07:17:25 +0200 (CEST)

> value I was talking about.  That's all 200ms gives you.  I'm not

200ms doesn't give you a response if the authoritative server is on the 
other side of the world. Australia is 350ms or more away from me. I've 
regularily seen 450ms RTT to places. Where did this 200ms figure come 
from? This is why I am referring to "seconds", because if you want to make 
sure to get any available A and AAAA for a lot of different corner cases, 
then you soon end up with very big numbers.

Also, what about James Woodyatts idea of having the resolver sync AAAA and 
A queries so that if there is A or AAAA query and there is an impending 
TTL expire of any of them, this should fire up a refresh of the 
soon-to-be-expired information in the caching resolver? This would mean 
that the caching resolver would "always" have information in its cache for 
both A and AAAA records.

I think this is a better place to solve your concern than to increase the 
timers in the HE implementation. However...

Tommy/David, do you have numbers on how often the problem Mark is talking 
about, actually occurs? Ie lookup times for A and AAAA, and when the IPv4 
goes into "Start TCP" in 
https://www.ietf.org/proceedings/99/slides/slides-99-v6ops-sessa-happy-eyeballs-v2-00.pdf 
slide 4, and IPv6 didn't even start because the AAAA response arrived much 
later? Or are the DNS lookup time and TCP established time lumped together 
in your data (which was my takeaway when I saw the presentation).

I have no idea what the packet loss rate are for resolver lookups (traffic 
between client and resolver). Do we have data on that? Because if the 
packet loss rate is very low then what I feared wouldn't be a problem.

Right now it seems DNSresolve+TCP is 50ms head start for IPv6, right? To 
solve what Mark wants to solve (if I understand it correctly), this would 
have to be bumped up to 200ms, BUT, to solve your (and mine) TCP 
establishment concerns, as soon as the IPv6 DNS+TCP subflow goes into TCP 
SYN, it should send a signal to the IPv4 subflow to say "I'm going into 
TCP syn now, you can decrease your timer to 50ms if it's higher than 
50ms".

This would mean that any DNS induced delay would be 200ms max, but any TCP 
induced delay would be max 50ms.

Mark, would this solve most of your concerns?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Aug 2017 16:36:23 +1000

In message <[email-masked]>, Mikael Abraha
> then you soon end up with very big numbers.

The UK is ~200ms from here in Sydney, Australia.  The example I
posted up thread was 206ms.  Yes, I was only allowing for a single
query to the other side of the world.  Most of the time that is all
that is needed as the recursive server will still have the NS records
and associated adddress records.  Whether the time is 200ms or 400ms
is negotiable.  The current 50ms makes most of the world unreachable.

> that the caching resolver would "always" have information in its cache for 

Actually it wont and it wouldn't fix this issue where there is a
cache miss on the AAAA and a cache hit on the A record.  What we
are designing should work when A records have TTLs of 3600 and AAAA
records have 0 and 1 second TTLs.  As it currently is designed it
won't work (produce IPv6 connections most of the time) and it should.
The design is wrong if it doesn't.  It shouldn't depend on authoritative
server operators having equal value TTLs for A and AAAA RRsets for
it to work regardles of how common that is.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 08:51:11 +0200 (CEST)

> is negotiable.  The current 50ms makes most of the world unreachable.

200ms RTT? What path do you take then? That seems very low.

> Actually it wont and it wouldn't fix this issue where there is a cache 
> miss on the AAAA and a cache hit on the A record.  What we are designing 
> should work when A records have TTLs of 3600 and AAAA records have 0 and 
> 1 second TTLs.  As it currently is designed it won't work (produce IPv6 
> connections most of the time) and it should. The design is wrong if it 
> doesn't.  It shouldn't depend on authoritative server operators having 
> equal value TTLs for A and AAAA RRsets for it to work regardles of how 
> common that is.

As I said, I have 350ms RTT to Australia. So in the above example, 200ms 
won't be enough. We need it to be at least 500ms to solve the problem you 
describe above. I think that's too much. What if the authoritiative 
nameserver is two satellite hops away, then we need 2 seconds?

Also it doesn't depend on them having equal values, it depends on them 
having a value that is more than 5-10 seconds TTL and there are frequent 
queries.

Putting in a 500ms (or more) delay just because someone might set a 1 
second TTL, that seems extreme to me. Because there are other failure 
scenarios where 500ms delay will cause a severe customer experience 
degradation, where it's completely unneccesary to wait that long.

---

From: Stephen Strowes <[email-masked]>
Date: Tue, 15 Aug 2017 09:29:16 +0200

> Most general-purpose consumer operating systems have been dual-stack for a while now. On dual-stack networks, when modern devices make DNS queries, they'll almost always ask for both A and AAAA. Th…

Got numbers? What are the tail-end p-tiles for some of these? How do 
those compare per-region, per-country?

I mean, I believe you. The world didn't burn down a couple years back 
when some of these changes started popping up, and I was watching. But 
data is useful, both here and in the draft.

S.

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Aug 2017 13:39:41 -0700

When David and Jinmei started using the word "consensus" and asked what the chairs thought, the chairs went off in a huddle. This is us coming back.

If the working group has a consensus regarding this draft, we think the consensus is that it likes the direction the draft is going. Interpreting that as a consensus around an individual point in the draft contains, I think, an instance of a fallacy - it deserves careful consideration before making vast pronouncements. That's why we're having a WGLC - to test the consensus.

Our perception is that very few issues have been raised in the draft; the working group appears to have consensus around most of what it contains. One question the chairs have is "what are we missing?" If our perception is not true, we're looking for comments on the list.

Regarding Asynchronous DNS resolution, the statement in the draft is that 

   Implementations MUST NOT wait for both families of answers to return
   before attempting connection establishment. 

Our perception of the difference between David and Jinmei here surrounds getaddrinfo(); David wants all implementations to use the AAAA record the instant it comes back, and the A record only if the AAAA record is significantly delayed, while Jinmei wants to grandfather implementations using existing APIs that insist on having both or seeing a timeout. We (the chairs) have sympathy in both directions, but suspect that Jinmei's is more realistic. From a strategic perspective, we want all applications to do this; making it harder reduces the probability of it happening, and making it easy makes it more likely. Not all OS's (think IOT RTOS's) have threads, and not all have asynchronous DNS resolution. Practically, we suspect that implementors will do what is straightforward, and not do the rest - HEv1.5, if you will. In addition, at least the way I use "MUST" in an RFC, when I say something MUST (or MUST NOT) be done, failing on the point results in something dramatic. If I say that a TCP implementation MUST eventually acknowledge every segment it correctly receives in sequence, and someone doesn't, the result is a perpetual TCP session transmitting and retransmitting the same data. That's pretty fundamental. I don't see an interoperability failure if an implementation doesn't resolve DNS asynchronously; I do see a delay, and a reason that an asynchronous implementation might be preferred in the market. So to me, this sounds more like "SHOULD/SHOULD NOT" - we would like folks to do this, and if they don't they should understand the implications of not doing so, but it doesn't break in any fundamental way.

So, question for the WG: do we agree with the statement in the draft, or would we grandfather existing APIs (which HE 1.0 does).

---

From: Sander Steffann <[email-masked]>
Date: Tue, 15 Aug 2017 22:58:13 +0200

Hi Fred,

> I don't see an interoperability failure if an implementation doesn't resolve DNS asynchronously; I do see a delay, and a reason that an asynchronous implementation might be preferred in the market. So to me, this sounds more like "SHOULD/SHOULD NOT" - we would like folks to do this, and if they don't they should understand the implications of not doing so, but it doesn't break in any fundamental way.

This reasoning sounds good. I think "SHOULD/SHOULD NOT" is the best choice here. We definitely would strongly like asynchronous DNS, but a well-informed decision not to doesn't make the HE implementation completely useless.

Cheers,
Sander

---

From: Stephen Strowes <[email-masked]>
Date: Wed, 16 Aug 2017 09:36:35 +0200

On 15/08/2017 22:39, Fred Baker wrote:
> Practically, we suspect that implementors will do what is straightforward, and not do the rest - HEv1.5, if you will. In addition, at least the way I use "MUST" in an RFC, when I say something MUST (or MUST NOT) be done, failing on the point results in something dramatic. If I say that a TCP implementation MUST eventually acknowledge every segment it correctly receives in sequence, and someone doesn't, the result is a perpetual TCP session transmitting and retransmitting the same data. That's pretty fundamental. I don't see an interoperability failure if an implementation doesn't resolve DNS asynchronously; I do see a delay, and a reason that an asynchronous implementation might be preferred in the market. So to me, this sounds more like "SHOULD/SHOULD NOT" - we would like folks to do this, and if they don't they should understand the implications of not doing so, but it doesn't break in any fundamental way.

I agree with SHOULD/SHOULD NOT.

Sections 4 and 5 already read linearly and are not at all confusing if 
the DNS resolution is synchronous. Modifying section 3 should allow it 
to become an optional part of the algorithm with very little wordsmithing.

S.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 16 Aug 2017 11:17:54 -0700

At Tue, 15 Aug 2017 13:39:41 -0700,
Fred Baker <[email-masked]> wrote:

> When David and Jinmei started using the word "consensus" and asked
> what the chairs thought, the chairs went off in a huddle. This is us
> coming back.
[...]
> Our perception of the difference between David and Jinmei here
> surrounds getaddrinfo(); David wants all implementations to use the
> AAAA record the instant it comes back, and the A record only if the
> AAAA record is significantly delayed, while Jinmei wants to
> grandfather implementations using existing APIs that insist on
> having both or seeing a timeout.

To be clear, I personally don't have a *strong* opinion on the choice.
If the wg without me decides a MUST is more appropriate, that's fine.
I raised this point in my review comment just in case it's an
oversight since I've observed this has been a controversial point and
I don't think I saw an explicit wg consensus about that.

But, if what I feel matters, I actually think a MUST is too strong,
exactly for the reason you explained below, that is, I just don't see
why this requirement must inevitably be a MUST.  I also agree
SHOULD/SHOULD NOT is more suitable in cases like this.

> We (the chairs) have sympathy in both directions, but suspect that
> Jinmei's is more realistic. From a strategic perspective, we want
> all applications to do this; making it harder reduces the
> probability of it happening, and making it easy makes it more
> likely. Not all OS's (think IOT RTOS's) have threads, and not all
> have asynchronous DNS resolution. Practically, we suspect that
> implementors will do what is straightforward, and not do the rest -
> HEv1.5, if you will. In addition, at least the way I use "MUST" in
> an RFC, when I say something MUST (or MUST NOT) be done, failing on
> the point results in something dramatic. If I say that a TCP
> implementation MUST eventually acknowledge every segment it
> correctly receives in sequence, and someone doesn't, the result is a
> perpetual TCP session transmitting and retransmitting the same
> data. That's pretty fundamental. I don't see an interoperability
> failure if an implementation doesn't resolve DNS asynchronously; I
> do see a delay, and a reason that an asynchronous implementation
> might be preferred in the market. So to me, this sounds more like
> "SHOULD/SHOULD NOT" - we would like folks to do this, and if they
> don't they should understand the implications of not doing so, but
> it doesn't break in any fundamental way.

--
JINMEI, Tatuya

---

From: David Schinazi <[email-masked]>
Date: Fri, 18 Aug 2017 13:58:49 -0700

Thanks everyone for the feedback provided during WGLC. The authors accept the group's consensus that asynchronous DNS should be a SHOULD rather than a MUST, and we have updated the document accordingly. Starting with version -04, the "Hostname Resolution Query Handling" section does not contain any MUSTs. We have also made editorial changes, clarifications, and addressed other comments received in the past few weeks.

The latest version can be found here:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-04

To everyone who send feedback during WGLC, please let us know whether version -04 addresses your comments.

Thanks,
David Schinazi

> On Aug 16, 2017, at 11:17, 神明達哉 <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Aug 2017 11:05:33 +1000

In message <[email-masked]>, David Schinazi writes:
> Thanks everyone for the feedback provided during WGLC. The authors accept
> the group's consensus that asynchronous DNS should be a SHOULD rather
> than a MUST, and we have updated the document accordingly. Starting with
> version -04, the "Hostname Resolution Query Handling" section does not
> contain any MUSTs. We have also made editorial changes, clarifications,
> and addressed other comments received in the past few weeks.
>

I still think the 50ms wait is too simplistic and fails to account
for DNS cache misses.  HE should result is IPv6 being used most of
the time even if the zone administrator has a zero TTL set on the
AAAA RRset and a non zero TTL on the A RRset.  It is possible to
achieve this but not how the document is currently written.  It
requires waiting enough time for a cache refresh attempt to complete.
This time starts when the AAAA lookup is made and is enough time
for a single query to be answered from the other side of the planet
O(250ms). Both this time and the 50ms wait from the A lookup
succeeding must complete before the IPv4 connect attempt starts if
there is no response to the AAAA lookup.

At the moment we have a tail wagging the dog senario where host
operators are going to have to keep AAAA RRsets TTL with similar
or larger than A RRset TTLs to avoid hosts using HE2 using IPv4 as
the primary transport.