Subject: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC

From: Fred Baker <[email-masked]>
Date: Thu, 22 Sep 2011 22:18:41 -0700

This is to initiate a two week working group last call of draft-ietf-v6ops-happy-eyeballs. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 23 Sep 2011 12:01:58 +0200

I highly support the publication of this document. 

One note: Perhaps it is obvious, but I think there may be room for a sentence pointing out that network operators may need to be more diligent with IPv6 diagnostic and measurement on dual-stacked networks as HE-enabled applications and OSes appear. i.e., people with happy eyeballs are far less likely to alert an administrator if something is wrong with IPv6 (or IPv4 one day?)

Also, I wonder if the document should be a BCP given that we now have current practice, and that it is documented in the spec. 

Nits:

>   In order to use applications over IPv6, it is necessary that users enjoy nearly identical performance as compared to IPv4. 

s/identical identical or better

> This usually means giving preferring IPv6 over IPv4, although...

s/preferring/preference to

- Mark

On Sep 23, 2011, at 7:18 AM, Fred Baker wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Fri, 23 Sep 2011 09:11:15 -0700

> Also, I wonder if the document should be a BCP given that we now have current practice, and that it is documented in the spec. 

I would invite comment on that. It makes sense to me to make it BCP; do we as a group think that?

---

From: "George, Wes" <[email-masked]>
Date: Fri, 23 Sep 2011 14:28:44 -0400

I've reviewed the draft. Generally I'm pretty happy with it, but I have two main comments.

First for the Abstract/Introduction:
I'd rather this didn't focus exclusively on the v4 working/v6 broken permutation. Most of what I can see shows HE working in either direction, and as we move into a situation where IPv4 may be the more "broken" connectivity due to multiple layers of NAT, attempts to do on-demand IPv4 provisioning, etc, it may be that HE can be used to reduce the potential for IPv4 brokenness's impact on users. I realize that generally most OSes prefer IPv6 if given a AAAA today, but if we're implementing an algorithm to take some action based on information gathered about performance on which stack to use, sometimes maybe it's worth talking in more generic terms.

 I'd recommend rewording to discuss in slightly more agnostic terms - eg "in order to use applications in a dual-stack environment, it is necessary to enjoy proper technical performance (roughly equivalent to or better than today's IPv4 experience) on whichever address-family is used to reach the desired content and services. A combination of... and IPv4 extension techniques such as CGN, etc. all cause the user experience to suffer... Instead, applications can improve the user experience themselves, by more aggressively making connections on IPv6 or IPv4 depending on which provides the better service..."

You cover this in 4.1 and 4.2 but I don't see a need to be quite so version-specific in the intro/abstract. You also probably don't need to mention IPv6 in the title of 4.2. This algorithm can easily be stateful to remember that IPv4 is not working well and to prefer IPv6 if at all possible if there are scenarios where IPv6 is not actually the preferred address family.

Secondly:
I think that it probably makes some sense to discuss the fact that this is now implemented in several locations, perhaps along with a reference to the specifics, at least somewhere other than the acknowledgements section. I don't have a problem with it being changed to a BCP if everyone thinks that's the best course of action, but I think I'd rather see it remain a standards-track document with some implementation examples. Standards with multiple implementations are the goal, right?

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Friday, September 23, 2011 1:19 AM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC

This is to initiate a two week working group last call of draft-ietf-v6ops-happy-eyeballs.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Fred Baker <[email-masked]>
Date: Fri, 23 Sep 2011 12:37:54 -0700

> I think that it probably makes some sense to discuss the fact that this is now implemented in several locations, perhaps along with a reference to the specifics, at least somewhere other than the a…

A BCP (http://tools.ietf.org/html/rfc2026#section-5) is a standard, but a standard for a practice as opposed to an algorithm or protocol. The PS/DS/FS standards track (http://tools.ietf.org/html/rfc2026#section-4.1) is for "Internet specifications [that] go through stages of development, testing, and acceptance." 

BCP 38 (http://tools.ietf.org/html/bcp38), for example, is a recommended configuration of filters in routers. Although it specifically recommends the use of access lists (which it calls "filters" or "filtering rules"), it turns out that there is more than one way to implement it - we can discuss access lists or any of several variations on unicast reverse path forwarding. The important thing turns out to not be "how it is done" as much as "that it is done".

SNMP, on the other hand, has gone through three major revisions and PS/DS/FS in each revision. In each revision, the original specification came out at PS and only after wide testing, and then was taken to DS after wide interoperability testing.

In this case, the implementations that are out there are not all done the same way, but all have the intended effect with differences resulting from their algorithmic differences. There is no question of interoperability; if they don't successfully open TCP sessions, they don't work and are non-starters, and if they do open TCP sessions, the question is how long it takes for them to succeed in a given network scenario. We only implement happy eyeballs in the system that initiates a connection; in client/server applications (example HTTP), that's the client, and in peer-to-peer applications (example SMTP), the party that initiates the connection. In either case, the party accepting the connection - the server or the other peer - remains unchanged.

If I understand things correctly, one implementation is pretty similar to present behavior (which tries addresses serially to completion) except that it implements that for the set of IPv4 addresses, and in parallel implements it again for the set of IPv6 addresses. If the issue is between IPv4 and IPv6, this ensures that both are being tried early in the game. If I understand correctly, another implementation opens a single socket and opens connections using it in parallel (using the non-blocking mode of the socket), running down the getaddrinfo() list at some cadence, accepting the first that responds and discarding the rest. One implementation that I find as API code but don't know of an application that uses (http://www.v6address.com/node/16) opens them all at the same time. The latter two have the intended effect in any multihoming scenario including IPv4-only with multiple IPv4 addresses and IPv6-only with multiple IPv6 addresses. One concern: if the cadence is too quick (especially if the interval is zero), it can also have negative consequences on servers. I believe that there is at least one other implementation. 

If we were to recommend an algorithm, and therefore go Proposed/Draft/Full Standard or the currently-proposed two step procedure, I think we're getting into the specifics of the socket API on various operating systems. The idea of having multiple connections in the process of being attempted on the same socket (which I rather like, personally, for relative simplicity and generality) is specific to an OS that implements the “Liberal Behavior” of the connect() call; many OS's implement only the "rigid" behavior, which doesn't permit multiple connects in parallel on the same socket. (cf http://www.madore.org/~david/computers/connect-intr.html, http://www.v6address.com/node/16).

Also, lacking an interoperability component, I'm not sure what procedure I would use to go from PS to DS...

So I think we're better off taking the route that BCP 38 took, of saying *what* should be done without saying *how* to do it. That's the neighborhood of a BCP, not PS.

Obviously open to opinions.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 24 Sep 2011 08:22:47 +0200

In your letter dated Fri, 23 Sep 2011 14:28:44 -0400 you wrote:
>I'd rather this didn't focus exclusively on the v4 working/v6 broken permutati
>on. Most of what I can see shows HE working in either direction, and as we mov
>e into a situation where IPv4 may be the more "broken" connectivity due to mul
>tiple layers of NAT, attempts to do on-demand IPv4 provisioning, etc, it may b
>e that HE can be used to reduce the potential for IPv4 brokenness's impact on 
>users. I realize that generally most OSes prefer IPv6 if given a AAAA today, b
>ut if we're implementing an algorithm to take some action based on information
> gathered about performance on which stack to use, sometimes maybe it's worth 
>talking in more generic terms.

When I first started playing HE I had the same idea. Make it more symmetric.
But later I realized that we want to transition to IPv6. So it is inherently
asymmetric. We would like to use IPv6 as much as possible.

Also, keeping the document focused on IPv6 versus IPv4 keeps it simple. And
we want something now, not a fully general solution in 10 years time.

So I would prefer to keep it the way it is.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 26 Sep 2011 09:20:29 -0400

I believe you missed my point and we're actually in agreement for the most part.

Currently the section I mentioned discusses HE as a solution for *IPv6* brokenness (mainly by either falling back to IPv4 more quickly or by tracking state to determine which stack should be used for which destinations). I hope that IPv6 brokenness is a short-term problem and that as more people move to IPv6, *IPv4* may be the more broken item, and therefore we need a mechanism to ensure that IPv6 is preferred when it will provide the better user experience, even if there are some set of configurations or rules that would otherwise have the host prefer IPv4. I don't think that this moves away from the idea that preferring IPv6 whenever possible is the goal.

However, as important as I think IPv6 is, I should note that this isn't about preferring IPv6 as much as it is preferring the stack that works - hence "happy eyeballs." The assumption is that once IPv6's initial deployment teething problems are resolved in each network, and CGN becomes more prevalent in IPv4, IPv6 will be that "stack that works" more often than IPv4, rather than the other way around as it's currently presented.

Thanks,

Wes

---

From: Philip Homburg <[email-masked]>
Date: Mon, 26 Sep 2011 16:15:53 +0200

In your letter dated Mon, 26 Sep 2011 09:20:29 -0400 you wrote:
>even 
>if there are some set of configurations or rules that would otherwise have the
> host prefer IPv4. 

I think that's the important part.

I think the way forward is to make IPv6 preferred. The HE can switch to IPv4
if IPv6 doesn't work well enough.

The problem with making IPv4 preferred is that HE will mostly avoid using
IPv6 except when IPv4 is bad enough that IPv6 is really better.

I can imagine some sites having to prefer IPv4. And HE does work for that.
But I hope that is going to be a niche that we can hide somewhere in a corner.

>However, as important as I think IPv6 is, I should note that this isn't about 
>preferring IPv6 as much as it is preferring the stack that works - hence "happ
>y eyeballs." The assumption is that once IPv6's initial deployment teething pr
>oblems are resolved in each network, and CGN becomes more prevalent in IPv4, I
>Pv6 will be that "stack that works" more often than IPv4, rather than the othe
>r way around as it's currently presented.

The problem with preferring the stack that works is what do you do when IPv4
and IPv6 have parity? 

CGNs have to be good enough that from a performance point of view, a host
cannot easily tell that they are there. Otherwise, IPv4 would break too much.

What will happens in that case? Will the traffic be evenly distributed over
IPv4 and IPv6?

So, IMHO, the only way forward is to prefer IPv6 and then let HE fall back to
IPv4.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 26 Sep 2011 10:19:29 -0400

> So, IMHO, the only way forward is to prefer IPv6 and then let HE fall back to

I agree. My experience with one OS implementation that does similar to HE is that my computer no longer uses IPv6, because IPv4 almost always win, no matter what. Because IPv4 is where the money is currently. Therefore, if there is no pref for IPv6, then IPv6 will never happen, since no trafic, no eyeballs, ...

Marc.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 26 Sep 2011 16:23:15 +0200

Same for me Š the way is being implemented is not good at all. I was very
happy using IPv6 all the time, now is a problem even when there is native
IPv6 (because it may be slower than IPv4 some times) !

Regards,
Jordi

-----Mensaje original-----
De: Marc Blanchet <[email-masked]>
Responder a: <[email-masked]>
Fecha: Mon, 26 Sep 2011 10:19:29 -0400
Para: Philip Homburg <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Asunto: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC

>I agree. My experience with one OS implementation that does similar to HE
>is that my computer no longer uses IPv6, because IPv4 almost always win,
>no matter what. Because IPv4 is where the money is currently. Therefore,
>if there is no pref for IPv6, then IPv6 will never happen, since no
>trafic, no eyeballs, ...
>
>Marc.
>
>> 
>> 

**********************************************
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: Cameron Byrne <[email-masked]>
Date: Mon, 26 Sep 2011 07:40:01 -0700

> I agree. My experience with one OS implementation that does similar to HE
is that my computer no longer uses IPv6, because IPv4 almost always win, no
matter what. Because IPv4 is where the money is currently. Therefore, if
there is no pref for IPv6, then IPv6 will never happen, since no trafic, no
eyeballs, ...

+1

Cb

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 26 Sep 2011 10:53:04 -0500

> preferring IPv6 as much as it is preferring the stack that works -
hence
> "happy eyeballs." The assumption is that once IPv6's initial
deployment
> teething problems are resolved in each network, and CGN becomes more
prevalent
> in IPv4, IPv6 will be that "stack that works" more often than IPv4,
rather
> than the other way around as it's currently presented.

+1.

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> George, Wes
> Sent: Monday, September 26, 2011 9:20 AM
> To: Philip Homburg
> I believe you missed my point and we're actually in agreement for the
most
> part.
> 
> Currently the section I mentioned discusses HE as a solution for
*IPv6*
> brokenness (mainly by either falling back to IPv4 more quickly or by
tracking
> state to determine which stack should be used for which destinations).
I hope
> that IPv6 brokenness is a short-term problem and that as more people
move to
> IPv6, *IPv4* may be the more broken item, and therefore we need a
mechanism to
> ensure that IPv6 is preferred when it will provide the better user
experience,
> even if there are some set of configurations or rules that would
otherwise
> have the host prefer IPv4. I don't think that this moves away from the
idea
> that preferring IPv6 whenever possible is the goal.
> 
> preferring IPv6 as much as it is preferring the stack that works -
hence
> "happy eyeballs." The assumption is that once IPv6's initial
deployment
> teething problems are resolved in each network, and CGN becomes more
prevalent
> in IPv4, IPv6 will be that "stack that works" more often than IPv4,
rather
> than the other way around as it's currently presented.
> 
> Thanks,
> 
> Wes
> 
> 
> From: [email-masked]
[mailto:[email-masked]] On
> Behalf Of Philip Homburg
> >on. Most of what I can see shows HE working in either direction, and
as we
> mov
> >e into a situation where IPv4 may be the more "broken" connectivity
due to
> mul
> >tiple layers of NAT, attempts to do on-demand IPv4 provisioning, etc,
it may
> b
> >users. I realize that generally most OSes prefer IPv6 if given a AAAA
today,
> b
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
to
> copyright belonging to Time Warner Cable. This E-mail is intended
solely for
> the use of the individual or entity to which it is addressed. If you
are not
> the intended recipient of this E-mail, you are hereby notified that
any
> dissemination, distribution, copying, or action taken in relation to
the
> contents of and attachments to this E-mail is strictly prohibited and
may be
> unlawful. If you have received this E-mail in error, please notify the
sender
> immediately and permanently delete the original and any copy of this
E-mail
> and any printout.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 26 Sep 2011 12:10:26 -0400

>> than the other way around as it's currently presented.

disagree. that assumption is wrong. providers are pushing vendors as much as possible to provide CGN as transparent as possible as a router. There will always be a push to make CGN as good as routers. The possible limitation on the number of ports may or may not be detected by HE. Therefore, IPv4 will almost always win, because IPv4 is where the money is.

So I think the assumption that IPv6 will win using HE is not correct.

Marc.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 26 Sep 2011 11:27:10 -0500

Marc,

> So I think the assumption that IPv6 will win using HE is not correct.

Where do you see us making that assumption? 

In fact, we are all shying away from making that assumption, as much as we would wish for IPv6 to win.

> always be a push to make CGN as good as routers. The possible limitation on
> the number of ports may or may not be detected by HE. Therefore, IPv4 will
> almost always win, because IPv4 is where the money is.

Hmmm....if any sort of NAT(44) exhausts its (NAT) sessions capacity, then IPv4 connectivity would be broken for any new IP sessions relating to the hosts. Period. This should get detected by HE and declare IPv4 to loose. 

Cheers,
Rajiv

> From: Marc Blanchet [mailto:[email-masked]]
> Sent: Monday, September 26, 2011 12:10 PM
> To: Rajiv Asati (rajiva)
> Cc: George, Wes; Philip Homburg; [email-masked]; [email-masked]
> disagree. that assumption is wrong. providers are pushing vendors as much as
> possible to provide CGN as transparent as possible as a router. There will
> always be a push to make CGN as good as routers. The possible limitation on
> the number of ports may or may not be detected by HE. Therefore, IPv4 will
> almost always win, because IPv4 is where the money is.
>

---

From: james woodyatt <[email-masked]>
Date: Mon, 26 Sep 2011 10:29:54 -0700

> So I think the assumption that IPv6 will win using HE is not correct.

Absolutely correct.  That assumption is based on a myth that needs to die.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "George, Wes" <[email-masked]>
Date: Mon, 26 Sep 2011 14:36:28 -0400

-----Original Message-----
From: Marc Blanchet [mailto:[email-masked]]
Sent: Monday, September 26, 2011 12:10 PM
Subject: Re: [v6ops] draft-ietf-v6ops-happy-eyeballs WGLC

>The assumption is that once IPv6's initial
> deployment

Marc.

WEG] This seems to go the other direction - assuming that IPv6 will always be broken, which is also a faulty assumption. Second, history shows that no matter what providers push vendors to do, they'll be disappointed by what's actually delivered. I have no doubt that CGNs will continue to fix some of the things that are broken, but I do not for a second believe that they will get to the point where they are transparent (especially as transparent as a router) to all forms of user traffic, nor should we expend the effort to get them there. That amounts to defining and building an ALG for anything that doesn't behave like bog-standard traffic. At some point, we need to stop trying to "fix" IPv4, and I expect that point to happen long before we reach a "perfect" CGN, if it hasn't already occurred.
Lastly, whether or not each type of CGN failing is detected by HE and it makes the right decision really depends on the way that HE is implemented, but I'm not sure that's completely relevant to the point I was making originally about the way that the intro and abstract are currently worded to focus exclusively on IPv6 brokenness, when later in the document it becomes more agnostic.

Wes George

---

From: Philip Homburg <[email-masked]>
Date: Mon, 26 Sep 2011 20:52:17 +0200

In your letter dated Mon, 26 Sep 2011 14:36:28 -0400 you wrote:
>WEG] This seems to go the other direction - assuming that IPv6 will always =
>be broken, which is also a faulty assumption. Second, history shows that no=
> matter what providers push vendors to do, they'll be disappointed by what'=
>s actually delivered. I have no doubt that CGNs will continue to fix some o=
>f the things that are broken, but I do not for a second believe that they w=
>ill get to the point where they are transparent (especially as transparent =
>as a router) to all forms of user traffic, nor should we expend the effort =
>to get them there. That amounts to defining and building an ALG for anythin=
>g that doesn't behave like bog-standard traffic. At some point, we need to =
>stop trying to "fix" IPv4, and I expect that point to happen long before we=
> reach a "perfect" CGN, if it hasn't already occurred.
>Lastly, whether or not each type of CGN failing is detected by HE and it ma=
>kes the right decision really depends on the way that HE is implemented, bu=
>t I'm not sure that's completely relevant to the point I was making origina=
>lly about the way that the intro and abstract are currently worded to focus=
> exclusively on IPv6 brokenness, when later in the document it becomes more=
> agnostic.

I'm not quite sure about the point you are trying to make.

If IPv6 is better than IPv4, then just prefer IPv6 and be done with it.

If IPv6 sometimes or regularly performs worse than IPv4 then HE should be
able to switch back to IPv4 when that happens.

The other way around, preferring IPv4 when IPv6 actually performs better 
doesn't seem to make much sense to me (with some exceptions). 

So, yes, HE is for the time when IPv6 is worse than IPv4. By the time IPv6
becomes the norm, and IPv4 becomes legacy, the role of HE as described in this
document is essentially over. The same techniques may be used for a more 
general address selection algorithm. But let's do that we have plenty of
experience with HE.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 26 Sep 2011 15:05:39 -0400

I'm not quite sure about the point you are trying to make.
WEG] ok, I'll try again....

WEG] yes

WEG] yes

The other way around, preferring IPv4 when IPv6 actually performs better
doesn't seem to make much sense to me (with some exceptions).
WEG] I never suggested this, and I agree that's a bad idea.
What I was saying was- if *local address policy* (not HE) says "prefer IPv4", then there are circumstances where the user experience might suffer. HE can easily be extended to support those cases, override the local policy use IPv6 at least when it performs better. This results in a better user experience. I'm simply saying that the draft does not need to be written such that it eliminates the option of using HE in this fashion. It is an address-family selection algorithm, it's just that the primary use right now is to help with short-term IPv6 brokenness.

Wes George

---

From: Philip Homburg <[email-masked]>
Date: Mon, 26 Sep 2011 21:24:01 +0200

In your letter dated Mon, 26 Sep 2011 15:05:39 -0400 you wrote:
>What I was saying was- if *local address policy* (not HE) says "prefer IPv4=
>", then there are circumstances where the user experience might suffer. HE =
>can easily be extended to support those cases, override the local policy us=
>e IPv6 at least when it performs better. This results in a better user expe=
>rience. I'm simply saying that the draft does not need to be written such t=
>hat it eliminates the option of using HE in this fashion. It is an address-=
>family selection algorithm, it's just that the primary use right now is to =
>help with short-term IPv6 brokenness.

So we are talking about the, hopefully exceptional, case where some admin
sets the address selection policy for a host to prefer IPv4.

I would have to check the details, but I think for my own HE implementation,
it would require changes to fully support this case. It will work to some
extent, but not as well as the the way around. 

The main reason it doesn't work, is that the part of the kernel that implements
HE isn't aware of the address policy table. It doesn't have to, it only
has to probe IPv6 every once in a while. 

Making a switch to make it probe IPv4 instead is of course possible, but I 
would have to see a very good use case before I would consider doing that.

My impression is that you are making things needlessly complicated. Thinking
of HE as preferring IPv6 and then falling back to IPv4 is the right frame of 
mind. It is easy to explain.

Making it more symmetric leads to complications. You have to figure out from
the address policy table what protocol is preferred and then tell the HE
module to probe that protocol. In the other case, you can just hardcode 
probing IPv6.

And, most operators don't want admins to configure systems to prefer IPv4
because that just needlessly prolongs the life of IPv4.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 26 Sep 2011 15:36:39 -0400

Le 2011-09-26 à 14:36, George, Wes a écrit :

> WEG] This seems to go the other direction - assuming that IPv6 will always be broken, which is also a faulty assumption.

I'm not saying that IPv6 will always be broken. I'm just saying that IPv4 will be always better than IPv6 for quite a long time, since it is still IPv4 that brings money. 

So if HE does not give a pref to IPv6, then IPv4 will always win, and therefore does not help IPv6 deployment.

Marc.

> Second, history shows that no matter what providers push vendors to do, they'll be disappointed by what's actually delivered. I have no doubt that CGNs will continue to fix some of the things that are broken, but I do not for a second believe that they will get to the point where they are transparent (especially as transparent as a router) to all forms of user traffic, nor should we expend the effort to get them there. That amounts to defining and building an ALG for anything that doesn't behave like bog-standard traffic. At some point, we need to stop trying to "fix" IPv4, and I expect that point to happen long before we reach a "perfect" CGN, if it hasn't already occurred.

---

From: james woodyatt <[email-masked]>
Date: Mon, 26 Sep 2011 13:24:22 -0700

> So if HE does not give a pref to IPv6, then IPv4 will always win, and therefore does not help IPv6 deployment.

Well, that's not true either.  At this point, anything that permits IPv6 deployment without damaging coexistence with IPv4 would be a big help to the furtherance of IPv6.  HappyEyeballs, even if it does not give any preference to IPv6, would greatly improve coexistence with IPv4, and would therefore be a big help.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Sep 2011 09:34:53 +1300

> On Sep 26, 2011 7:19 AM, "Marc Blanchet" <[email-masked]> wrote:
...
>> there is no pref for IPv6, then IPv6 will never happen, since no trafic, no

Thus, IMHO there SHOULD be a tuning parameter of some kind,
whose default setting would be something like "prefer IPv6
unless it is 25% slower than IPv4".

On 2011-09-27 05:27, Rajiv Asati (rajiva) wrote:
...
> Hmmm....if any sort of NAT(44) exhausts its (NAT) sessions capacity, then IPv4 connectivity would be broken for any new IP sessions relating to the hosts. Period. This should get detected by HE and…

That seems a bit like magic. In any case it would need to
be predictive: "The NAPT44 is going to run out of port
numbers in 5 minutes, so prefer IPv6 even though it's slower".

Good luck with implementing that.

   Brian

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 26 Sep 2011 13:41:03 -0700

On 9/26/11 13:24 , james woodyatt wrote:
>> So if HE does not give a pref to IPv6, then IPv4 will always win,
>> and therefore does not help IPv6 deployment.
> 
> Well, that's not true either.  At this point, anything that permits
> IPv6 deployment without damaging coexistence with IPv4 would be a big
> help to the furtherance of IPv6.  HappyEyeballs, even if it does not
> give any preference to IPv6, would greatly improve coexistence with
> IPv4, and would therefore be a big help.

HE much like the reduction in use of 6to4, and to some extent AAAA
whitelisting (which I don't currently use) provide cover under which
people like me can convince our manangement that we can safely deploy
AAAA records for public facing services without impacting end-users.

Latency is a discussion point in virtually every public facing service
change here.

> 
> -- james woodyatt <[email-masked]> member of technical staff, core os
> networking
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Sep 2011 09:43:10 +1300

Unless I've missed it, the draft doesn't require that
an HE implementation MUST have a user-settable option to
disable it (and revert to the default prefer-IPv6 behaviour).

I think this needs to be added.

Regards
   Brian Carpenter

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 26 Sep 2011 22:48:39 +0200

> I think this needs to be added.

Strong voice for this from my side. And it does not have to be a UI
element (though that makes some people happy), just a sysctl knob or a
registry switch is just fine, as it is a setting that is likely only
needed by ops folks anyway.

Greets,
 Jeroen

--
jeroen@yomi:~$ cat .ssh/config
AddressFamily inet6

and on the verge of fakely inserting a few ms of extra latency into IPv4
to compensate for the minor but not really noticeable detour the
tunneled IPv6 packets take...

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 27 Sep 2011 00:49:26 +0300

There is a MAY under 5.3

> To assist in that regard, the implementations MAY also provide
> a mechanism to disable their Happy Eyeballs behavior via a user setting.

although changes through sysctl should probably go under 5.9.

--
Tassos

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Sep 2011 10:59:33 +1300

MAY isn't strong enough IMHO.

Regards
   Brian Carpenter

---

From: james woodyatt <[email-masked]>
Date: Mon, 26 Sep 2011 15:05:06 -0700

On Sep 26, 2011, at 13:34 , Brian E Carpenter wrote:
> 
> Thus, IMHO there SHOULD be a tuning parameter of some kind, whose default setting would be something like "prefer IPv6 unless it is 25% slower than IPv4".

I feel pretty comfortable making a prediction about how that would work out.

Pretty soon after such behavior were introduced in a forthcoming operating system release, it would be noticed by various commentators and contributors to user discussion forums on the web and elsewhere, who would complain loudly that this default parameter was poorly chosen, often in a pithy rant explaining in arrogant detail why it seems to its author to be such a bad idea.

In response to anyone posting a question to the effect of "why is my Internet download going so slow?" the reflexive answer given in response would be a citation for one of these rants along with instructions on how to set that tuning parameter to prefer IPv4 over IPv6.  A parade of follow-ups would appear overnight from people claiming that they did this and magically everything got better.  (Note: it's irrelevant to the discussion whether these claims could withstand any scientific examination.)

In short order, the complaints about the default setting and the advice to change it to something reasonable would reach a fever pitch, and whoever had the bright idea of following the recommendation from the IETF that such a preference for IPv6 be applied over IPv4 would be sent to a reeducation camp on the Moon.  A software update would be rushed out soon thereafter to ignore the preference setting and it would disappear in a future release.

The engineer sent to the Moon would likely never be heard from again.

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 26 Sep 2011 15:11:19 -0700

> although changes through sysctl should probably go under 5.9.

bearing in mind that some implementations are buried in applications and
not in kernels.

---

From: John Mann <[email-masked]>
Date: Tue, 27 Sep 2011 08:35:15 +1000

Hi,

On 27 September 2011 05:36, Marc Blanchet <[email-masked]> wrote:

> ...
> I'm not saying that IPv6 will always be broken. I'm just saying that IPv4
> will be always better than IPv6 for quite a long time, since it is still
> IPv4 that brings money.
>
> ...
> Marc.

IPv4 will not always be better.  For many sites IPv6 is already better.

For example http://ipv6monitor.comcast.net:8080/monitor/index.html
  For sites that do provide identical content over IPv4 and IPv6
  Figure-4.1 shows on 11-09-24, 45% of sites loaded faster over IPv6 than
over IPv4.
  Figure-4.2 shows "average of IPv4 download time minus IPv6 download time"
is +ve (i.e. IPv6 is faster)
  since June for "Top 1K" "Top 10K" and "Top 100K" sites

Sure, IPv4 is faster for 55% of sites, and sites not in "Top 100K" list on
average load 20msec slower,
but this is a long way from IPv4 will _always_ be better.

[ http://mnlab-ipv6.seas.upenn.edu/monitor isn't accessible to me at the
moment. ]

Also,
http://labs.ripe.net/Members/emileaben/measuring-world-ipv6-day-comparing-ipv4-and-ipv6-performance
 "Figure 1 shows a histogram of all relative IPv4/IPv6 performance data
points we collected during World IPv6 Day.
  ...
  On a dual-stack client that unconditionally prefers IPv6 over IPv4,
IPv4is more
often the faster protocol, but this is far from a universal truth.
  There is also a significant chance that IPv6 is faster, since the
"IPv6-is-faster"
part of the histogram also has a significant volume.
  ...
  Note that we measured ICMP/ICMPv6, not HTTP performance."

Thanks,
    John

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 11:14:27 +0200

On 2011-09-27 00:05 , james woodyatt wrote:
[..]
> In response to anyone posting a question to the effect of "why is my
> Internet download going so slow?" the reflexive answer given in
> response would be a citation for one of these rants along with
> instructions on how to set that tuning parameter to prefer IPv4 over
> IPv6.

That was not what was being asked for.

What was being asked for is a switch to turn off Happy Eyeballs.

Then the implementation follows the RFC3484 rules which causes a
predictable IPv6 first then IPv4 behavior.

That 'predictable' part is btw the biggest issue I have with the Happy
Eyeballs implementation

Yes, it is AWESOME for normal endusers who really can't care less as
long as it works (thus many thanks for solving that problem!), but for
people like most of the folks here on the IETF list and other such
ops/protocol people it is really annoying to not be able to know what
protocol is going to be selected.

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 Sep 2011 11:43:59 +0200

>protocol is going to be selected.

With round-robin DNS you never know which IPv4 address is going to be used.
That's just part of life.

If you look closer at root DNS servers, you never know which one is going
to be used, even if you know the IP address.

Yes, network debugging tools have to deal with that. 

Can't we just leave this to application writers? Section 5.3 seems more than
enough.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 11:52:29 +0200

> With round-robin DNS you never know which IPv4 address is going to be used.

But you do know if IPv4 or IPv6 is being used.

Note also that due to the rules the "longest prefix matching" RFC3484
rule, actually DNS round-robin does not exist any more as it then picks
the shorted prefix match, not the ordering in DNS.

> to be used, even if you know the IP address.

It also does not matter which is used. But you do know that IPv6 goes
first and then IPv4.

> Yes, network debugging tools have to deal with that. 

Having a consistent selection of a remote address is important.

Ignoring the fact that some hosts have multiple IPv4/IPv6 addresses and
just considering hosts that have 1x IPv4 and 1x IPv6 always using the
same protocol is a big plus already.

> Can't we just leave this to application writers? Section 5.3 seems more than

Application writers are exactly the ones that should not have to care
about Address Families or ordering or anything else.

The OS libraries should be taking care of this, or do you want a
different implementation per not only OS but per application (which is
what is mostly happening for web browsers anyway).

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 Sep 2011 12:02:37 +0200

>But you do know if IPv4 or IPv6 is being used.

Who cares? You care because you provide an IPv6 service. I don't really
care. Most of the problems I have to debug are not related to IPv4 or IPv6.

>the shorted prefix match, not the ordering in DNS.

That's not my experience. There are many cases where you get multiple addresses
in a single /24. Logest prefix matching doesn't do anything for that.

>It also does not matter which is used. But you do know that IPv6 goes

Because you only care about IPv6 versus IPv4. There is a lot more variation
than just that bit.

>Having a consistent selection of a remote address is important.

Most of the time, it isn't to me.

>same protocol is a big plus already.

Again, only if you are debugging network level problems.

>about Address Families or ordering or anything else.

They have to. Because the application has to provide a debugging interface.
There is (as far as I know) no fine grained control over DNS and related
services. And I'm not going to screw up and entire host by globally disabling
HE or something like that.

>what is mostly happening for web browsers anyway).

Well, talk to your OS vendor then. No point in putting that in an RFC. You
never know where HE functionality is actually implemented.

Yes, HE should be part of OS libraries, but that may take a while. So for the
near future I expect it to be in application.

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 27 Sep 2011 12:07:29 +0200 (CEST)

> the shorted prefix match, not the ordering in DNS.

Can you explain it more wtih example why DNS round-robin is not working?

> what is mostly happening for web browsers anyway).

Actually the standardised API (RFC 3493) is not dealing with multiple 
connections. It is dealing with getaddrinfo(). The actual applications are 
just trying to connect sequentially the addresses what getaddrinfo() 
returned.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 13:01:01 +0200

On 2011-09-27 12:02 , Philip Homburg wrote:
> Who cares? You care because you provide an IPv6 service.

Odd, I am participating in the IETF as me, not as any role or hat I
accidentally might have.

I care because of the consistency of address family selection which
makes debugging harder for hosts that only have a single IPv4 and IPv6
address (like general hosts have).

The ability to disable HE and thus make the results consistent is a
major pro for debugging and other general usage.

I wonder how you will like the confusion that about every other request,
because of minuscule changes, either IPv4 or IPv6 is selected.

Yes, quite a few tools have -4/-6 and -v alike options, but a lot of GUI
based tools unfortunately do not and will not retrofit this.

> I don't really care.

If you don't care then why are you involving yourself in this thread? :)

> Most of the problems I have to debug are not related to IPv4 or IPv6.

Ever considered that not everybody uses the Internet in the same way or
for the same purposes?

> in a single /24. Logest prefix matching doesn't do anything for that.

While that is quite true, if you do not stuff all your eggs in the same
basket (read: same prefix) then you will nicely always get a consistent
address order back from

Note also that various authoritative DNS servers like nsd don't do
address re-ordering and thus unless a intermediary cache is doing the
re-ordering for you, they will always be the same.

> Because you only care about IPv6 versus IPv4. There is a lot more variation

As this is the IPv6 list, what is the problem with caring about IPv6?

Also, if there is more variation, what would these be that we need to
consider?

> Most of the time, it isn't to me.

The whole idea behind this knob is that the default behavior is HE, as
this serves all the end-users who do not care about what is used the
best. (and using latency and other stats like Mac OS X does is a really
cool trick for this)

The knob thus allows people who do not want this behavior to turn it off.

> Again, only if you are debugging network level problems.

Which is why the knob is default set to 'use HE'.

What is the problem with this?

> They have to. Because the application has to provide a debugging interface.

What kind of debugging interface would that be?

Chrome has pretty neat internals under chrome:net-internals but even
that does not show any of the decisions made on the DNS or address
ordering level.

> HE or something like that.

You don't need to, just don't touch the knob. For the people who want
to, as you say 'screw up HE', let them.

Be Pro Choice! Freedom to the People (and other such slogans ;)

> never know where HE functionality is actually implemented.

The "SHOULD" is already in the document, there are several people who
would like that to be a MUST.

It does not break or change anything, it only expects the ability to
disable it.

> near future I expect it to be in application.

Mac OS X has had (a variation of) HE support since Lion.

A lot of applications (read browsers that are scared to be 'slow' versus
the competition) bypass OS libraries completely though.

Those applications tend to have a proper disable switch too.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 13:13:52 +0200

On 2011-09-27 12:07 , Mohacsi Janos wrote:
[..]
> Can you explain it more wtih example why DNS round-robin is not working?

There are two parts in this:
 1) some DNS authoritive servers (eg nsd) don't do DNS round-robin
 2) longest prefix matching

The first can be made even odder to determine if a DNS resolver in the
chain is a BIND, as that one will re-order for you, but if you have
unbound as caching/recursor, there won't be re-ordering at all.

The latter is simple, if I take:

$ dig +short www.sixxs.net aaaa
nginx.sixxs.net.
2001:838:2:1::30:67
2001:838:2:1:2a0:24ff:feab:3b53
2001:960:800::2
2001:1af8:4050::2
2620:0:6b0:a:250:56ff:fe99:78f7

(interestingly the results are hex-ordered)

Thus where the addresses are not at all in the same prefix, depending on
your source address you will pick, per the rule, the closest one.

We have noticed that for the www.sixxs.net that the majority of IPv6
clients are hitting the first address (2001:838:2:1::30:67), these tend
to be clients coming from source addresses from the APNIC region, as
there is a lot of 2001:2xx'ish address space there, thus the 'closest'
address space is the first one in that list.

The 2001:1af8:xxx host in the above list is getting the rest of the
'upper' traffic, while the 2620:xx host is getting everything close to that.

The two hosts in the 'middle' are not getting a lot of traffic in
comparison though, as the others are 'closer'.

To put it in a simpler example, if we have the following addresses:

2001:db8:1000::1
2001:db8:8000::2
2001:db8:a000::3
2001:db8:ffff::4

The first and last host will catch all the traffic, you have to be lucky
if the '2' and '3' get anything at all....

The 'good' thing about this though is that even though you have multiple
IP addresses at possibly completely separate hosts, they always end up
consistently at the same location.

In one of the setups I use this to my advantage as I am always hitting
the same host, I can edit stuff there and see it appear at a reload (as
the connection always end up on the same host), and then when done sync
it to the other ;)

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 13:20:25 +0200

[other comment answered in split-off message as I expect there to be
follow-ups to it that are not entirely related to this thread]

[..]
> connections. It is dealing with getaddrinfo(). The actual applications
> are just trying to connect sequentially the addresses what getaddrinfo()
> returned.

Indeed, but getaddrinfo() can already return addresses in an order that
it deems they should be tried at based on metrics (like the OSX Lion
implementation).

But this might just lead to a requirement for the IETF to finally create
a new set of APIs that support HE so that the application programmer can
ignore all of this, and just call a "connectit(<hostname>, <service>)"
alike function which does everything most users need?

Of course, quite a few frameworks have already implemented similar
functionality on their own, and their are myriads of locations where
that code exists, thus getting enough code to actually replace their
code would be a very long process.

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 Sep 2011 13:23:29 +0200

>Odd, I am participating in the IETF as me, not as any role or hat I

True, but what you do with a particular technology tends to shape how you
see it.

>address (like general hosts have).

Yes, running dual stack makes things harder. There is no way around it.

>major pro for debugging and other general usage.

Again, that's not my experience.

>because of minuscule changes, either IPv4 or IPv6 is selected.

I would shop for a better HE implementation then. This sounds like what Apple
is doing. There is no reason for HE to be that unstable.

>based tools unfortunately do not and will not retrofit this.

Well, talk to those people. 

>Ever considered that not everybody uses the Internet in the same way or

Yes, so why make the exception the rule?

>basket (read: same prefix) then you will nicely always get a consistent

Only upto the first bit that is different. 

The thing is, putting all the eggs in a single /24 is very common.

>re-ordering for you, they will always be the same.

Still, quite a bit of reordering is going on.

>As this is the IPv6 list, what is the problem with caring about IPv6?

Nothing. It works. My problem is more RFCs setting requirements for what kind
of debugging options have to be offered by applications and operating systems.

>Also, if there is more variation, what would these be that we need to

Root DNS Servers are anycast. And every instance can be different (due to
various kinds of problems).

>The knob thus allows people who do not want this behavior to turn it off.

So, talk to your OS/applications vendor.

>What is the problem with this?

The problem is an RFC requiring such a knob.

>What kind of debugging interface would that be?

Could be a simple as '-v'. Firefox has a very extensive control interface to
change all kinds of paramers. Asterisk has a CLI debugging/control interface.
Some library code can be controlled by setting environment variables.

Just a few examples.

>that does not show any of the decisions made on the DNS or address

Well, talk to the Crome people to add a debug console with debug output.

>Be Pro Choice! Freedom to the People (and other such slogans ;)

Well, my choice is to make such a knob optional :-)

>would like that to be a MUST.

I found a MAY, there is also a SHOULD? 

By the time the IETF is telling application vendors what kind of debug
interface they have to provide, it is time to just ignore the RFCs.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 Sep 2011 13:25:10 +0200

>just trying to connect sequentially the addresses what getaddrinfo() 

There is a bit more to that. A good HE implementation has to know when to
start connecting to the next address. You can't just wait for the OS to
time out. That takes too long.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 13:46:55 +0200

On 2011-09-27 13:23 , Philip Homburg wrote:
[..]
> Well, my choice is to make such a knob optional :-)

Good to read that you are not raising any arguments AGAINST this kind of
knob.

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 Sep 2011 14:04:21 +0200

>Good to read that you are not raising any arguments AGAINST this kind of

I fully support the current text in the draft:
"To assist in that regard, the implementations MAY also provide a mechanism
to disable their Happy Eyeballs behavior via a user setting."

An optional knob is fine with me.

---

From: <[email-masked]>
Date: Tue, 27 Sep 2011 10:13:36 +0200

> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von Jeroen Massar
> Gesendet: Montag, 26. September 2011 22:49
> An: Brian E Carpenter
> Cc: IPv6 Operations
> Betreff: Re: [v6ops] On/off switch
> [draft-ietf-v6ops-happy-eyeballs WGLC]
>

I would also prefer to have a more configurable / dynamic approach here and not just a simply "hard coded" one.
Cu
        Olaf

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Sep 2011 09:27:43 -0400

> I would also prefer to have a more configurable / dynamic approach here and not just a simply "hard coded" one.

me too. this is a minimum. Especially for "controlled deployments" (eg: enterprise, managed services, geeks, ...), where one knows and understand the consequences of running with or without HE.  

I would like to see a knob that would have the possible values as:
- default  (HE no pref between v4 or v6)
- v6 (HE does pref v6 by some minimal increment)
- off  (disable HE)

The way to implement this might be:
- off: value = 65535
- default: value = 0
- v6: value = number of ms "advantage for ipv6"

or any other variation thereof.

Marc.

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 27 Sep 2011 16:45:42 +0300

Marc Blanchet wrote on 27/09/2011 16:27:
> Le 2011-09-27 à 04:13,<[email-masked]>  a écrit :
>

What is the difference between "off" and "default"?

--
Tassos

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Sep 2011 09:47:49 -0400

> What is the difference between "off" and "default"?

(see above for the semantics)

default = HE enabled
off = HE disabled. 

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Sep 2011 09:53:19 -0400

> (see above for the semantics)

btw, I can provide text if there is support in wg for this idea.

Marc.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 27 Sep 2011 15:57:56 +0200

[..]

> btw, I can provide text if there is support in wg for this idea.

I would say that it is a great thing to add, but just an on/off is
already good enough from my POV.

The above proposal would give the advantage to be able to easily
distribute a site-wide (given that one control all the hosts involved)
bonus for IPv6 in case a site is connected over a tunnel or other
mechanism which causes a bit more latency on the IPv6 side.

The other way to counter that disadvantage is just delaying IPv4 packets
at the moment, but that is far from a proper solution.

Greets,
 Jeroen

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 27 Sep 2011 16:08:23 +0200 (CEST)

> time out. That takes too long.

We are speaking about the same problem. I was referring the current non HE 
applications - sequential try until success methods. The HE aware 
applications should use new API which is hiding the parallel connection 
attempts.... Or applications should be rewriten to use SCTP ;-) (and in 
the same time at the server side also)

Best Regards,
 	Janos Mohacsi

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Sep 2011 13:16:14 +1300

Marc,

> already good enough from my POV.

I agree; maybe on/off as a MUST and the ms of bias as a MAY?

I don't see anybody opposing the general idea, anyway.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 Sep 2011 13:57:26 -0700

On Thu, Sep 22, 2011 at 22:18, Fred Baker <[email-masked]> wrote:

> We are looking specifically for comments on the importance of the document
> as well as its content. If you have read the document and believe it to be
> of operational utility, that is also an important comment to make.
>

I support the publication of this document. A few comments:

1. The algorithm focuses on slow TCP connections. This is not the only cause
of slow performance of IPv6, DNS plays a part too. IPv6 responses may not be
cached or have low negative lifetimes; a broken DNS forwarder may be timing
out AAAA queries, or even returning them as A records with the first 32 bits
of the IPv6 address [1]; and so on. Some of this is documented in RFC 4074,
so you might want to cite it, even if only to claim that overcoming slowness
due to DNS queries is out of scope for this document.

2. You say that the recommended timeout is 150 to 250ms. FYI, Chrome uses
300ms. This is so much better than the default timeouts of 21s or 75s, and
the number of users with this problem is so low (approximately 0.1% in
today's Internet) that it seems to be a good compromise, especially since
only the first connection is really affected.

It also provides power users who would notice with a small (300ms) incentive
to get IPv6 working or disable it when it's broken. Finally, it reduces the
server load caused by stateless algorithms: in some regions of the world, an
RTT of over 150ms is very common.

3. Mozilla Firefox has disabled their happy eyeballs implementation because
it doesn't work. So I would avoid citing them here.

To those who say that the algorithm shouldn't prefer IPv6, I disagree. I
think we all agree that IPv6 is the right way forward in the long term. Our
problem now is that enabling IPv6 causes lots of pain to a small amount of
users, and we can't move forward. However, if the maximum impact is 300ms
additional latency on the first TCP connection to 0.1% of users, then a case
can be made that it's worth it.

As the draft correctly observes, it's hard to make IPv6 faster than IPv4 if
everything is running on the same infrastructure (which is the only sane way
to transition); if you do everything right, you'll get parity. So algorithms
that try to pick the fastest connection every time will just end up choosing
one or the other non-deterministically, or - worse - in the arbitrary order
that they end up doing DNS lookups.

Cheers,
Lorenzo

[1].
http://www.getipv6.info/index.php/Customer_problems_that_could_occur#D-Link

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 30 Sep 2011 19:25:07 -0700

> I don't see anybody opposing the general idea, anyway.

I don't think it's useful.

What would you need such a feature for? If IPv6 is as fast as IPv4, then the
implementation should just use IPv6 all the time. If IPv6 is broken,
wouldn't you as a user want to use IPv4 instead of using something that's
broken?

Personally, I think that if you want to find out if IPv6 is working, you
should use network monitoring. It's much more reliable than users with
browsers.

Also: I don't think that apps will pay much attention to what the IETF says
in regard to what settings they provide and expose to the user. Putting MUST
here could cause applications to be in violation of the RFC even if they're
perfectly in compliance with the actual technical requirements that matter.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Oct 2011 16:31:56 +1300

> wouldn't you as a user want to use IPv4 instead of using something that's

That's not for you to say. I might want to stand on my head all day, too.

Really - as someone else said, it might well be a useful tool for
certains types of diagnosis (e.g. a user who complains about poor
browsing response - let's switch off HE to see if that's relevant).
Or there might be other reasons that I'm not smart enough to think of
until the day comes.

It seems to me that making such a complex algorithm switch-offable
is just normal engineering.

> should use network monitoring. It's much more reliable than users with

That depends entirely on the problem you're faced with.

> perfectly in compliance with the actual technical requirements that matter.

And why would that be a problem for the IETF? It would be a problem for
the user, perhaps, but then they can switch to a browser that does provide
the switch.

    Brian