Subject: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 May 2011 17:25:40 -0700

This has been a long time coming -- sorry about that.

This new version incorporates almost all of the feedback we received from
the working group -- support for per-prefix "P", IPv6 head start, fully
describing "Smoothed P".  This also added complexity.  There are some ideas
Andrew is kicking around to reduce the complexity, but we wanted people to
take a look at this document and see how it feels.  There is a tradeoff in
complexity with being gentle to the network -- which is desirable if only
certain servers or certain IPv6 prefixes are failing (but others are
working), and we don't want to abuse the network by attempting IPv4
connections whenever IPv6 has a small hiccup.

Reading this update will require a holistic view, so please fill your coffee
mug before diving into the document.

new version:
  http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02	
side-by-side differences:
  http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-happy-eyeballs-02.txt

Changes are in Appendix A.1, and are also copied below for reference.

-Dan and Andrew

-----

   o  Now honors host's address preference (RFC3484 and friends)

   o  No longer requires thread-safe DNS library.  It uses getaddrinfo()

   o  No longer describes threading.

   o  IPv6 is given a 200ms head start (Initial Headstart variable).

   o  If the IPv6 and IPv4 connection attempts were made at nearly the
      same time, wait Tolerance Interval milliseconds for both to
      complete before deciding which one wins. 

   o  Renamed "global P" to "Smoothed P", and better described how it is
      calculated.

   o  introduced the exception cache.  This contains the set of networks
      that only work with IPv4 (or only with IPv6), so that subsequent
      connection attempts use that address family without them causing
      serious affect to Smoothed P.

   o  encourages that every 10 minutes the exception cache and Smoothed
      P be reset.  This allows IPv6 to be attempted again, so we don't
      get 'stuck' on IPv4.

   o  If we didn't get both A and AAAA, abandon all Happy Eyeballs
      processing (thanks to Simon Perreault).

   o  added discussion of Same Origin Policy

   o  Removed discussion of NAT-PT and address learning; those are only
      used with IPv6-only hosts whereas this document is about dual-
      stack hosts contacting dual-stack servers.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 25 May 2011 13:49:28 +0200

In your letter dated Tue, 24 May 2011 17:25:40 -0700 you wrote:
>describing "Smoothed P".  

Two comments.

It looks like a naive implementation would take at least Tolerance Interval
(20ms) when both an A and AAAA are present. I wonder if that is really a
good idea. I would be prefer a connection to be available to the application
as soon as possible. Optionally without updating the SP value.

The draft is biased towards IPv6. I wonder if that is a good idea. In the past,
a bias towards IPv6 led to all kinds of problems. If IPv6 is better, let
that be shown in the connection setup times. Maybe for small values of P,
the algorithm should use the address in the order in which they were found
in the getaddrinfo results.

---

From: <[email-masked]>
Date: Wed, 25 May 2011 16:23:06 +0200

I disagree with Philips opinion.

I think we have to prefer IPv6 since we simply want to push back IPv4 in the case that IPv4 and IPv6 connectivity are equal in quality. Otherwise we would never get rid of IPv4 since nobody will switch of IPv4 servers when he sees incoming IPv4 connections.
That's why I also like the 200 ms head start for IPv6 since this seems to come close to an (IPv4) exit strategy I requested a few discussion cycles before.

Regards
        Olaf

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von Philip Homburg
> Gesendet: Mittwoch, 25. Mai 2011 13:49
> An: Dan Wing
> Cc: [email-masked]
> Betreff: Re: [v6ops] Happy eyeballs update,
> draft-ietf-v6ops-happy-eyeballs-02
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tim Chown <[email-masked]>
Date: Wed, 25 May 2011 15:49:10 +0100

> That's why I also like the 200 ms head start for IPv6 since this seems to come close to an (IPv4) exit strategy I requested a few discussion cycles before.

I agree.

I notice the latest Chrome now has IPv4 fallback code in it, which gives IPv6 a 300ms head start.  Not a pure Happy Eyeballs implementation, but a very nice start, and much better than a 21 second fallback.

See http://googlechromereleases.blogspot.com/2011/05/stable-channel-update_24.html
and more specifically the tail of http://code.google.com/p/chromium/issues/detail?id=81686

Kudos to Lorenzo and those involved to get this out in time for IPv6 Day; if you have issues on the 8th just get Chrome :)

Also worth noting that in some cases you can predict the page fetch so the content is coming in before the user hits their enter key or clicks somewhere.

Tim

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 25 May 2011 09:01:43 -0700

On May 25, 2011 7:49 AM, "Tim Chown" <[email-masked]> wrote:
> > I think we have to prefer IPv6 since we simply want to push back IPv4 in
the case that IPv4 and IPv6 connectivity are equal in quality. Otherwise we
would never get rid of IPv4 since nobody will switch of IPv4 servers when he
sees incoming IPv4 connections.
> > That's why I also like the 200 ms head start for IPv6 since this seems
to come close to an (IPv4) exit strategy I requested a few discussion cycles
before.
> I agree.

+1 for v6 head start

Cb

> I notice the latest Chrome now has IPv4 fallback code in it, which gives
IPv6 a 300ms head start.  Not a pure Happy Eyeballs implementation, but a
very nice start, and much better than a 21 second fallback.
> See
http://googlechromereleases.blogspot.com/2011/05/stable-channel-update_24.html
> and more specifically the tail of
http://code.google.com/p/chromium/issues/detail?id=81686
>
> Kudos to Lorenzo and those involved to get this out in time for IPv6 Day;
if you have issues on the 8th just get Chrome :)
>
> Also worth noting that in some cases you can predict the page fetch so the
content is coming in before the user hits their enter key or clicks
somewhere.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 May 2011 09:13:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:pch-b2B3A6689@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: Wednesday, May 25, 2011 4:49 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-
> eyeballs-02
> 
> as soon as possible. 

Then Tolerance Interval is set to 0ms.

> Optionally without updating the SP value.

If SP isn't adjusted, we'll blindly beat the network and server.  This
is certainly easiest to implement.  It also creates the most impact to
the network and the server.

> The draft is biased towards IPv6. I wonder if that is a good idea. In
> the past, a bias towards IPv6 led to all kinds of problems. 

> If IPv6 is better, let
> that be shown in the connection setup times. Maybe for small values of
> P, the algorithm should use the address in the order in which they were
> found in the getaddrinfo results.

Yes, there is a slight IPv6 bias when IPv4 and IPv6 are both connecting 
quickly.  

My own testing shows variance in IPv4 and IPv6 connection setup times
to the same hosts.  For that reason, using Tolerance Interval allows
improving upon a "first connection wins" algorithm.  I want to prefer
IPv6 because the IPv4 path is more likely to have NATs (home NAT or
carrier NAT) which will prevent deployment of new transports (e.g.,
SCTP), have designed or enforced port limits, and all the other
evils of IPv4 address sharing.

-d

---

From: Doug Barton <[email-masked]>
Date: Wed, 25 May 2011 10:25:55 -0700

> That's why I also like the 200 ms head start for IPv6 since this seems to come close to an (IPv4) exit strategy I requested a few discussion cycles before.

+1 on both purpose and reasoning.

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 May 2011 11:15:13 -0700

On May 25, 2011, at 04:49 , Philip Homburg wrote:
> 
> The draft is biased towards IPv6. I wonder if that is a good idea. In the past, a bias towards IPv6 led to all kinds of problems. If IPv6 is better, let that be shown in the connection setup times.

I have to break from the majority on this and concur with Mr. Homburg.  These little 200 milliseconds delays will add up quickly with repetition.

Picture in your mind a user interface for letting a human configure the bias between IPv4 and IPv6.  The proper way to present this would be a slider, where the middle position means without any bias between IPv4 and IPv6, and the distance from the middle position, in either direction, corresponds to the amount of time a user is willing to wait for a connection over a specific network layer protocol when the other one would give them service sooner.

Can anyone here imagine a reasonable situation where an ordinary user would want to position that slider anywhere other than the middle position?

I can imagine situations where a certain class of advanced user might want, for troubleshooting purposes, to disable one or the other network layer entirely, but I can't see why I should be required by standards action to set a default for that conceptual slider on the vast majority of ordinary users to anywhere but the exact middle.

Why, oh why, would we ever think it was smart to force these delays in a standards track document?

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 May 2011 14:30:36 -0400

On 2011-05-25 14:15, james woodyatt wrote:
> Can anyone here imagine a reasonable situation where an ordinary user
> would want to position that slider anywhere other than the middle
> position?

IPv6 is less likely to have a NAT in the path, so an ordinary user is
better off preferring IPv6. (No NAT means less breakage.)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 May 2011 11:38:53 -0700

On May 25, 2011, at 11:30 , Simon Perreault wrote:
> 
> IPv6 is less likely to have a NAT in the path, so an ordinary user is better off preferring IPv6. (No NAT means less breakage.)

Nonsense.  Happy Eyeballs chooses another path when it encounters breakage due to a NAT barrier.  The ordinary users with which I'm most acquainted will all be better off with IPv4/NAT connections that complete 200 ms sooner than otherwise functionally equivalent IPv6 connections.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 May 2011 14:45:04 -0400

On 2011-05-25 14:38, james woodyatt wrote:
>> IPv6 is less likely to have a NAT in the path, so an ordinary user
>> is better off preferring IPv6. (No NAT means less breakage.)
> 
> Nonsense.  Happy Eyeballs chooses another path when it encounters
> breakage due to a NAT barrier.

I'm not following you.

Happy eyeballs chooses another path when it is unable to establish  an
outbound connection (e.g. when contacting a rendez-vous server). That's
not the kind of breakage I'm talking about.

The NAT breakage I'm talking about occurs after the initial connection,
when the app tries to receive a new connection from a peer (e.g. after
having published its IP address on the rendez-vous server). Happy
eyeballs is not in the picture at this stage.

If happy eyeballs chooses IPv6 in the first place, it is less likely
that there will be a NAT, and the peer-to-peer connection in the second
step is more likely to work.

Simon

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 25 May 2011 11:54:42 -0700

> Nonsense.  Happy Eyeballs chooses another path when it encounters breakage due to a NAT barrier.  The ordinary users with which I'm most acquainted will all be better off with IPv4/NAT connections…

James, i completely understand, we are suggesting giving the user a
possibly slightly worse experience by default.  I struggle with this
myself.

As i have stated on the list before, if we keep pushing IPv4 at the
browser level (aka not pushing IPv6), the network operators have to
keep investing in more IPv4 peering, NATs, and other IPv4 technologies
since that is where the traffic is at.  Without IPv6 traffic volumes,
there will be no investment to fix IPv6 latency, peering, and other
investments.... wait and it will come is not sufficient.... we have
learned that over the last 10 years of stalemate in IPv6 adoption. It
will be yet another chicken and egg ... people have IPv6 addresses but
the browser does not use it... because the peering on IPv6 is not
robust ...because there is no traffic ...and there is no traffic
because users use NAT444 instead because its faster... so the browers
use IPv4 and not IPv6... so the network operator does not invest in
IPv6 improvements...so ipv6 is slower, so the browser choose ipv4 ...
and that logic loops around indefinitely.

We (the IETF) need to see the big picture and bypass the obvious
chicken and egg issue that happy eyeballs may cause.  We need to
change that chicken and egg stalemate and turn it into fortuitous
cycle of increasing IPv6 traffic volumes and investment that will lead
us out of this IPv4 NAT mess.

IPv6 investments will not happen because people are "doing the right
thing" or taking the "high road"... IPv6 investments and improvements
will happen when the traffic makes it happen, and that starts at the
user.

Cameron

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 May 2011 12:23:09 -0700

On May 25, 2011, at 11:54 , Cameron Byrne wrote:
> 
> We need to change that chicken and egg stalemate and turn it into fortuitous cycle of increasing IPv6 traffic volumes and investment that will lead us out of this IPv4 NAT mess.

With all due respect, no... no, we [the IETF] do not.

The IETF needs to preserve the utility of the Internet and the welfare of its users during the transition of the Internet to a dual-stack IPv4/IPv6 phase of operations.  The IETF must resist the urge to use the dubious power of standards documentation to serve the parochial interests of the network operator community in a misguided drive to seek yet another externality to exploit at the significant cost to the welfare of all Internet users.

If network operators and content providers want their subscribers and correspondents to prefer IPv6 over IPv4, then let happy eyeballs have no bias between the two, and let the Mystic Knights of Traffic Engineering make it so.  To preserve the welfare of the Internet user community, IETF must allow the invisible brass knuckles of The Market to sort out which network layer shall win in the end.

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 25 May 2011 21:23:13 +0200

On Wed, May 25, 2011 at 04:23:06PM +0200, [email-masked] wrote:
> I think we have to prefer IPv6 since we simply want to push back IPv4
> in the case that IPv4 and IPv6 connectivity are equal in quality.

+1 from another operator.

A bias towards IPv6 is absolutely imperative to get rid of the LSNs
(at least dampen the scaling required) which will be widely deployed
to continue riding the dead horse IPv4.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 25 May 2011 14:46:03 -0500

> to continue riding the dead horse IPv4.

+1 from yet another.

We must balance both sides of the issue, making the user experience
acceptable while clearly rigging the election.

Dale

---

From: Philip Homburg <[email-masked]>
Date: Thu, 26 May 2011 00:15:05 +0200

>the network and the server.

In trying figure out what value of SP I would want, and also how that relates
to the 'SP=SP/2' in the draft I came up with the following algorithm, which
in part may be easier to analyse.

The main goal is that I want to try the best protocol first, and that I also
want to avoid trying two protocols as much as possible. Certainly when IPv4
is behind CGN, we have to avoid placing unnecessary load on those devices as
much as possible.

So the basic idea is that SP should big enough that almost all (i.e. mean
plus a few times sigma) connections will complete in less the SP time.

Assuming SP>0 then we start with the IPv6 address. If that connection
completes in less than SP time, don't update SP because it is already big
enough.

If it takes longer than SP, start IPv4. If the IPv6 connection completes 
first then don't wait for the IPv4 connection but increase SP by some amount.
If on the other hand, IP4 completes first then decrease SP by some (possibly
different) amount.

What will happen is the following. Suppose x% of the IPv6 destinations
is bad, either because the connection will not complete at all, or because it
takes much longer than using IPv4 then in x% of the cases SP will be decreased.
If we assume the amount to increase and decrease of SP is equal, then it needs 
another x% or the connections to keep SP stable. In other words, SP will end
up a value such that x% of the properly working IPv6 connections are taking
longer than SP.

We can now easily see that the overhead is 100%: of each IPv4 connection 
that is actually required (the first x% above) there is another x% started to
keep SP balanced. 

If we now change the ratio between the values we use for increasing and
decreasing SP then we can reduce that overhead: if the increment is 10x less
than the decrement then the overhead will be 10%.

(Alternatively, if IPv4 is cheap, you can also invert the ratio and decrease
the latency in case an IPv6 address is not working)

For cached values, you just use the smallest absolute value you find in the
case (or if you find only one, then that address family).

The algorithm sofar ensures that if either IPv6 or IPv4 is working, you end up
with the right one. But if both work, you have to do something extra to
find the fastest one.

For cache values it is easy: every once in a while, say in 1% of the cases,
you just start both at the same time. If, according to the cache IPv6 was
preferred and IPv6 was also the fasted then you don't do anything. Otherwise,
you update the IPv4 value with what you found (there should no need to update
the IPv6 value because that should already be higher than the time it takes
to connect).

You can do the same thing for SP, but that is a bit tricky. In 1% of the
cases start both at the same time. Still assuming SP>0 then if IPv6 connects
first, you don't do anything. If IPv4 connects first then the next time
you also start both connections at the same time. If again IPv4 wins, you
flip the sign of SP (no need to adjust the absolute value).

This should ensure that when IPv4 is faster then IPv6 in 50% of the cases,
IPv4 is preferred. And the same goes vice versa for IPv6.

(Some changes would be required to prefer IPv6 over IPv4, but that should be
doable).

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 May 2011 13:11:50 +1000

> acceptable while clearly rigging the election.

Or we can define methods to inform hosts when they are behind a LSN
and let them use that information to depreference external IPv4
addresses.  Now is the time to do this before there is a large
installed base of CPE dual stack routers that don't pass the
information though to the hosts.

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

---

From: <[email-masked]>
Date: Thu, 26 May 2011 08:14:17 +0200

Hmm, strange discussion. Do you really propose that network operators use TE to delay IPv4 packets? I can't follow you how this would "preserve the welfare of the Internet user community" when most of the traffic (IPv4) is slowed down by network operators. How do you think about net neutrality?

No sorry, IMHO you are wrong this time, James.
If we want to make IPv6 happen, than we have to prefere its usage starting with the connection initiation.
Don't put double load to networks and servers and this will make the Eyeballs more happy.

Regards
        Olaf
>
> If network operators and content providers want their
> subscribers and correspondents to prefer IPv6 over IPv4, then
> let happy eyeballs have no bias between the two, and let the
> Mystic Knights of Traffic Engineering make it so.  To
> preserve the welfare of the Internet user community, IETF
> must allow the invisible brass knuckles of The Market to sort
> out which network layer shall win in the end.
>
>
> --

---

From: Philip Homburg <[email-masked]>
Date: Thu, 26 May 2011 11:26:25 +0200

In your letter dated Thu, 26 May 2011 08:14:17 +0200 you wrote:
>Hmm, strange discussion. Do you really propose that network operators use TE t
>o delay IPv4 packets? I can't follow you how this would "preserve the welfare 
>of the Internet user community" when most of the traffic (IPv4) is slowed down
> by network operators. How do you think about net neutrality?
>

For many years now, people have been trying to get networks with good IPv4 
connectivity to add IPv6 support. This mostly failed. ISPs mostly didn't do 
anything. There are a few big content providers have IPv6 but many don't.

So the whole idea of getting people to prefer IPv6 over IPv4 is an illusion,
because on average nobody has IPv6 and there is no IPv6 content.

You can think about switching off IPv4 when essentially the whole world
has IPv6. We are so far from that, it is not even funny. So what's the
point of setting protocol parameters now for something that is likely
to happen a couple of decades from now?

What will happen in some places in the Internet is that various NAT boxes
will slow things down. This will automatically get the algorithm to prefer
IPv6. A similar thing may happen at content providers: if they upgrade
IPv6 support first, or ensure that the IPv6 are slightly less loaded, then
traffic will switch to IPv6. 

That way, IPv6 will be used when it actually gives better performance.

---

From: <[email-masked]>
Date: Thu, 26 May 2011 13:56:09 +0200

Please see my remarks in line.

> anything. There are a few big content providers have IPv6 but

O.k. so far, but the times are changing now. More and more content becomes available via IPv6.

> because on average nobody has IPv6 and there is no IPv6 content.

If IPv6 is not enabled than HE wouldn't start. The same if there is no AAAA. Don't understand you here.

> to happen a couple of decades from now?

IMHO to pessimistic but this is not very relevant for the discussion.

> That way, IPv6 will be used when it actually gives better performance.

I don't buy this approach "the network will solve the problem itself" or "the content provider will push IPv6 and neglect IPv4".

>From my point of view I like this HE I-D as it is and think that this is a viable approach to solve the existing problem _and_ make IPv6 happen.
Just my 2 cent.
        Olaf

---

From: Philip Homburg <[email-masked]>
Date: Thu, 26 May 2011 15:56:31 +0200

In your letter dated Thu, 26 May 2011 13:56:09 +0200 you wrote:
>From my point of view I like this HE I-D as it is and think that this is a 
>viable approach to solve the existing problem _and_ make IPv6 happen.

One thing I forgot to mention. At the moment not having IPv6 connectivity
is perfectly possible. 

It is possible that in a few years time, some people will have to have 
IPv6 connectivity, even if it is relatively poor.

Poor IPv6 connectivity for connecting to IPv6-only sites is better than
nothing. But it would be really bad if then most of the other traffic would
take the same route, just because 'we' decided that we have to promote IPv6.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 May 2011 10:02:02 -0400

> Don't put double load to networks and servers and this will make the Eyeballs more happy.

Sorry, what?   Happy Eyeballs does not fetch the same data twice through different connections, so it's not even remotely accurate to say that it doubles the load on networks and servers.  Indeed, it goes to what I think are unnecessary extremes to avoid creating any extra traffic at all.

One thing I like about the 100ms delay is that it encourages operators to optimize their networks--it astonishes me that my current ISP has such congested border routers that the RTT to my server in California is >100ms.

---

From: <[email-masked]>
Date: Thu, 26 May 2011 16:15:40 +0200

Hi Philip, in principle I see your point, but don't forget that HE is a very adaptive mechanism that recognises very fast (anf reacts accordingly) when IPv6 connectivity is broken.
So drawing a picture in black that all the Internet connections will be slowed down just because IPv6 is a little bit prefered for the connection initiation phase is a bit FUD. Hence please do not generalize this.

Thx and ciao
        Olaf

> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Philip Homburg
> Gesendet: Donnerstag, 26. Mai 2011 15:57
> An: Bonneß, Olaf
> Cc: [email-masked]
> Betreff: Re: AW: [v6ops] Happy eyeballs update,

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 May 2011 10:23:38 -0400

> So drawing a picture in black that all the Internet connections will be slowed down just because IPv6 is a little bit prefered for the connection initiation phase is a bit FUD. Hence please do not…

It's possible that some people who have studied this draft may have missed the point that Happy Eyeballs is adaptive.   If IPv6 fails as a transport the first time it's attempted, it won't be preferred the next time the application tries to connect.   So e.g. if your web browser implements Happy Eyeballs, you will see that 100ms delay on the first web page you load, but not on any subsequent web pages.

So the 100ms delay really does provide a relatively cost-free preference for IPv6: the only way that it will keep preferring IPv6 is if in fact IPv6 works at least as well as IPv4.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 May 2011 10:39:41 -0400

Le May 26, 2011 à 10:28 AM, <[email-masked]>
 <[email-masked]> a écrit :
> The "double load" was meant for the case where the delay tolerance has been chosen to small and the host tries an IPvX connection before a successful IPvY connection can return.

But this is completely inaccurate.   Properly implemented, only one connection will get to the point where the server process wakes up.   Even if both server processes wake up, data will only ever flow over one of the two connections.   So if every connection were SYN,SYN+ACK,ACK,DATA,ACK,FIN,FIN+ACK, the increased traffic would be minimal.   But in reality, most web connections transfer a great deal more data than that, so the total added network load for Happy Eyeballs even in the case where we don't get an ACK from the remote end in time is negligible.

Furthermore, this only ever happens on the first connect; subsequent connects are optimized based on the result of the first connect.  Even if every connect were an even race, the additional load would be small.   But since HE optimizes according to network conditions, very few connections will be races, and none of the races will be even, so the additional load is really tiny.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 26 May 2011 08:13:07 -0700

On May 26, 2011 2:26 AM, "Philip Homburg" <[email-masked]> wrote:
> >If we want to make IPv6 happen, than we have to prefere its usage
starting wit
> >h the connection initiation.
> >Don't put double load to networks and servers and this will make the
Eyeballs
> >more happy.

Heads up, APNIC and IANA are already out of ipv4 addresses.

Also, those few big content folks that are doing v6day  account for 50+% of
the be on my network (Mobile)

Ipv6 must be now.

> IPv6. A similar thing may happen at content providers: if they upgrade

CGN and most other types of NAT do not have a material impact on latency,
your assertion is false.

Cb

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 May 2011 08:30:43 -0700

On May 25, 2011, at 11:14 PM, [email-masked] wrote:
> 
>  Do you really propose that network operators use TE to delay IPv4 packets?

No, I'm proposing that network operators who want users to prefer IPv6 over IPv4 should use TE to make sure that IPv6 paths are less congested than IPv4 paths.

> If we want to make IPv6 happen, than we have to prefere its usage starting with the connection initiation.

That's what you wrote, but I what I'm reading is this: "Before we network operators can make IPv6 happen, you host system implementors must cripple IPv4 for your users."

Not. Going. To. Happen.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 26 May 2011 17:41:04 +0200

In your letter dated Thu, 26 May 2011 10:23:38 -0400 you wrote:
>It's possible that some people who have studied this draft may have =
>missed the point that Happy Eyeballs is adaptive.   If IPv6 fails as a =
>transport the first time it's attempted, it won't be preferred the next =
>time the application tries to connect.   So e.g. if your web browser =
>implements Happy Eyeballs, you will see that 100ms delay on the first =
>web page you load, but not on any subsequent web pages.
>
>So the 100ms delay really does provide a relatively cost-free preference =
>for IPv6: the only way that it will keep preferring IPv6 is if in fact =
>IPv6 works at least as well as IPv4.

The case where IPv6 fails consistently is the easy case. Yes, HE will start
preferring IPv4 quickly. No problem.

But if IPv6 is on the order of 50ms slower than IPv4. Are you sure that the
current HE draft is also going to prefer IPv4 in that case? Or will users just
have to live with the additional latency?

---

From: <[email-masked]>
Date: Thu, 26 May 2011 17:46:19 +0200

>
> > If we want to make IPv6 happen, than we have to prefere its
> usage starting with the connection initiation.
>
>
> That's what you wrote, but I what I'm reading is this:
> "Before we network operators can make IPv6 happen, you host
> system implementors must cripple IPv4 for your users."
>
> Not. Going. To. Happen.
>
Hi James, sorry, I'm not a native English speaking person, but I'm absolutely sure that your reading does not correpsond to my (may be bad) English writing. Its simply a targeted misinterpretation.

Nothing. to. add.

Olaf

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 26 May 2011 09:03:34 -0700

> That's what you wrote, but I what I'm reading is this: "Before we network operators can make IPv6 happen, you host system implementors must cripple IPv4 for your users."

It already happened.

"When a hostname has both IPv6 and IPv4 addresses, and the IPv6
address is listed first, we start a timer (300ms) (deliberately chosen
to be different from the backup connect job). If the timer fires, that
means the IPv6 connect() hasn't completed yet, and we start a second
socket connect() where we give it the same AddressList, except we move
all IPv6 addresses that are in front of the first IPv4 address to the
end. That way, we will use the first IPv4 address. We will race these
two connect()s and pass the first one to complete to
ConnectJob::set_socket()."

Obviously this is not HE, but ... it did already happen. I am running
it now, as are thousands of others who don't know what IPv6 is.  It
works well, kudos to the Chrome crew on  release 11.0.696.71

 http://googlechromereleases.blogspot.com/

 Cameron

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 May 2011 09:22:15 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of james woodyatt
> Sent: Wednesday, May 25, 2011 11:15 AM
> To: [email-masked] WG
> the past, a bias towards IPv6 led to all kinds of problems. If IPv6 is
> better, let that be shown in the connection setup times.
> 
> I have to break from the majority on this and concur with Mr. Homburg.
> These little 200 milliseconds delays will add up quickly with
> repetition.

The draft does not propose a fixed 200ms headstart for IPv6.

Rather, when a host first connects to a network (e.g., it boots up), 
IPv6 will have a head start.

Then, if IPv6 shows itself worthy (IPv6 connections succeed), IPv6 will 
get even longer headstart (SP is increased).  If IPv6 shows itself 
unworthy (IPv6 connections fail), IPv6's initial headstart is reduced 
by half (SP is halved).  So, on initial connection to a network where
IPv6 connectivity is broken, IPv6 will have a 200ms, 100ms, 50ms, 
25ms, 12ms, 6ms, 3ms, 2ms, 1ms headstart for each connection.  That
is 9 connections before it becomes 0ms headstart.  If this is a 
web browser, then according to 
http://code.google.com/speed/articles/web-metrics.html, we are going
to hit about 8 hosts to render an average web page (42/5=8).

(Due to Tolerance Interval, there is an additional 20ms delay for
each connection while we're waiting for our preferred connection
(IPv6) to complete.  This would be 20ms*9=180ms.  Once IPv6 has
proven itself unworthy (connections fail), we no longer wait for
IPv6 to complete, so after 10 IPv6 connection failures, this
20ms tolerance interval goes away.)

> Picture in your mind a user interface for letting a human configure the
> bias between IPv4 and IPv6.  The proper way to present this would be a
> slider, where the middle position means without any bias between IPv4
> and IPv6, and the distance from the middle position, in either
> direction, corresponds to the amount of time a user is willing to wait
> for a connection over a specific network layer protocol when the other
> one would give them service sooner.
> 

If user is behind an IPv4 NAT (and everybody is), they have a port
limit and they can only use UDP and TCP.  These are not problems
right now for many (too slow?  upgrade your home NAT to a $150 box
that supports 802.11n with some magic speed booster technology!).  
But will become a problem going forward with CGNs, where the ISP's
incentives are not aligned with the user's incentives.

> I can imagine situations where a certain class of advanced user might
> want, for troubleshooting purposes, to disable one or the other network
> layer entirely, but I can't see why I should be required by standards
> action to set a default for that conceptual slider on the vast majority
> of ordinary users to anywhere but the exact middle.
> 

1. We're trying to improve the situation today that occurs with IPv6
timeouts, slide 3 of 
http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf 

2. Naive solutions to this problem can flood the network, servers,
and NAT devices with connection attempts on both address families.  
Once widely deployed, the fear is such solutions could cause 
additional cost to users (e.g., on networks with per-packet
billing models), network operators, and server operators.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 May 2011 09:24:10 -0700

> information though to the hosts.

draft-ietf-6man-addr-select-opt can do that.

-d

---

From: Tore Anderson <[email-masked]>
Date: Thu, 26 May 2011 18:36:06 +0200

* james woodyatt

> That's what you wrote, but I what I'm reading is this: "Before we
> network operators can make IPv6 happen, you host system implementors
> must cripple IPv4 for your users."
> 
> Not. Going. To. Happen.

Modern operating systems are already giving IPv6 a head start over IPv4
of anywhere from 20 to 190 seconds. So isn't this «crippling» already
happening, and in a *way* more unequal manner than the 100ms we're
talking about now?

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 May 2011 12:54:47 -0400

> That's what you wrote, but I what I'm reading is this: "Before we network operators can make IPv6 happen, you host system implementors must cripple IPv4 for your users."

In what sense do you believe the current HE proposal cripples IPv4?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 May 2011 13:01:38 -0400

> have to live with the additional latency?

Before I answer that question, can you prove to me that 50ms of additional latency is going to have a noticeable effect on users?   Because right now I have 100ms of latency on my IPv4 link to most machines on the Internet, and it seems to be working okay.   I think it's because 100ms is about the shortest interval anyone is likely to perceive that it's been chosen as the cutoff.   It's important to make the distinction between things that will actually affect the user experience, and things that will not, when deciding what sort of tradeoffs to make.

Remember that web browsers connect in parallel, not in series, up to a point, and that web sites typically already game their secondary downloads to take advantage of the browser cache.   So the only delay that's additive is DNS latency with latency on the initial connect.   We don't have to worry that a web page that loads 40 scripts and css files is going to take two additional seconds to download because of that additional 50ms of latency.

How many times can you tap your foot impatiently in 50ms?

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 May 2011 12:17:21 -0700

On May 26, 2011, at 09:36 , Tore Anderson wrote:
> 
> Modern operating systems are already giving IPv6 a head start over IPv4 of anywhere from 20 to 190 seconds.

I'm absolutely certain there aren't any standards track IETF documents that RECOMMEND such behavior.

> In what sense do you believe the current HE proposal cripples IPv4?

I see that I-D.ietf-v6ops-happy-eyeballs-02 specifies an Initial Headstart of 100 milliseconds.  I think that unnecessarily places a delay on IPv4 connectivity at initial conditions.  It should be sufficient for hosts that serialize any concurrent flow initiations over a short time interval to sort their destination addresses using the RFC3484bis default policy.  I'd leave out the Initial Headstart state variable.

I'll admit that I don't have much hope that Happy Eyeballs will work very well-- I think a more advanced heuristic will turn out to be required.  However, the specification of the Initial Headstart is especially difficult for me to accept.  That just looks to me like it flies in the face of the name of the draft.  Maybe we should call it, "Mostly Happy Eyeballs, *After* The Initial Headstart Period" or something like that.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 May 2011 18:45:30 -0400

Le May 26, 2011 à 3:17 PM, james woodyatt a écrit :
> I see that I-D.ietf-v6ops-happy-eyeballs-02 specifies an Initial Headstart of 100 milliseconds.  I think that unnecessarily places a delay on IPv4 connectivity at initial conditions.

It's not unnecessary, in the sense that there is no identified need to do it.   The need has been stated.   You may disagree that the need exists, but that's a separate question.

Moreover, you seem to have some instinctive belief that any price is too high a price to pay to address this need.   But you haven't said what you think the actual cost of that 100ms delay is.   What bad thing happens because of that delay?   The delay itself is just a delay. Until you identify a bad outcome that results from that delay, the delay itself is value-neutral.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 May 2011 21:56:44 +0200

In your letter dated Thu, 26 May 2011 13:01:38 -0400 you wrote:
>Le May 26, 2011 =E0 11:41 AM, Philip Homburg a =E9crit :
>> But if IPv6 is on the order of 50ms slower than IPv4. Are you sure =
>that the
>> current HE draft is also going to prefer IPv4 in that case? Or will =
>users just
>Before I answer that question, can you prove to me that 50ms of =
>additional latency is going to have a noticeable effect on users?   =
>Because right now I have 100ms of latency on my IPv4 link to most =
>machines on the Internet, and it seems to be working okay.   I think =
>it's because 100ms is about the shortest interval anyone is likely to =
>perceive that it's been chosen as the cutoff.   It's important to make =
>the distinction between things that will actually affect the user =
>experience, and things that will not, when deciding what sort of =
>tradeoffs to make.

I'm not a human-computer-interface expert, so I can only guess. There is 
difference between users noticing a difference, and users complaining. 

My latency to a lot of nearby sites is 20ms. And my guess is that I would
notice if there would be another 50ms.

>Remember that web browsers connect in parallel, not in series, up to a =
>point, and that web sites typically already game their secondary =
>downloads to take advantage of the browser cache.   So the only delay =
>that's additive is DNS latency with latency on the initial connect.   We =
>don't have to worry that a web page that loads 40 scripts and css files =
>is going to take two additional seconds to download because of that =
>additional 50ms of latency.

I think you may be a bit too optimistic. There are plenty of pages that are
way more complex than that.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 May 2011 16:02:07 -0400

> difference between users noticing a difference, and users complaining. 

If you can only guess, doesn't that mean that you don't know?   If you don't know the answer to a question, how does it help anyone for you to guess?

(BTW, you definitely will notice a 50ms increase in latency if it happens for every packet in a lockstep protocol.   But we're talking about TCP here, and TCP is a sliding-window protocol.)

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 28 May 2011 01:00:14 -0700

> One thing I like about the 100ms delay is that it encourages operators to optimize their networks--it astonishes me that my current ISP has such congested border routers that the RTT to my server i…

Delay is delay, the happy eyeballs approach is considered saluribious, because it is better than what happens today rather than because adding overhead on connect is considered a generally good idea.

joel

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 28 May 2011 19:00:16 +0200

> Why, oh why, would we ever think it was smart to force these delays in a standards track document?

I really really would like everyone to be forced over to IPv6, I
really do. I could accept a breakage on IPv4 just to get it done.

But... I do not think IETF can prefer IPv6 over IPv4 yet, it's too
soon. We should not be biased toward any right now.

We should instead give three suggested "values", and suggest people
should consider the future and recommend people to prefer IPv6.
1.) prefer IPv4 over IPv6 use this value
2.) do not prefer any, use this value
3.) prefer IPv6 over IPv4, use this value

If IPv6 is better it will "win" the race anyway in the end. And I
belive it will.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sun, 29 May 2011 11:26:07 +1000

In message <[email-masked]>, =?ISO-8859-1?Q?Roger_J=F8rgensen?= writes:
> >> The draft is biased towards IPv6. I wonder if that is a good idea. In th=
> e past, a bias towards IPv6 led to all kinds of problems. If IPv6 is better=
> , let that be shown in the connection setup times.
> >
> > I have to break from the majority on this and concur with Mr. Homburg. =
> =A0These little 200 milliseconds delays will add up quickly with repetition.
> >
> > Picture in your mind a user interface for letting a human configure the b=
> ias between IPv4 and IPv6. =A0The proper way to present this would be a sli=
> der, where the middle position means without any bias between IPv4 and IPv6=
> , and the distance from the middle position, in either direction, correspon=
> ds to the amount of time a user is willing to wait for a connection over a =
> specific network layer protocol when the other one would give them service =
> sooner.
> >
> > Can anyone here imagine a reasonable situation where an ordinary user wou=
> ld want to position that slider anywhere other than the middle position?
> >
> > I can imagine situations where a certain class of advanced user might wan=
> t, for troubleshooting purposes, to disable one or the other network layer =
> entirely, but I can't see why I should be required by standards action to s=
> et a default for that conceptual slider on the vast majority of ordinary us=
> ers to anywhere but the exact middle.
> >
> > Why, oh why, would we ever think it was smart to force these delays in a =
> standards track document?

What delay?  Native vs native is equal.
 
> soon. We should not be biased toward any right now.

The problem is that if there isn't a connection bias that we won't
know when it is safe to turn off IPv4.  Without a bias you will
have a 50/50 split in traffic.  Tunneling of IPv6 will mostly
disappear in a couple of years time as ISPs bring up native IPv6,
you can see the trend happening today.  ISP's really don't want to
be running transitioning technology or CGN's.  Both are overhead
on top of native.

If using a transition technology to get IPv6 gives you unacceptable
performance for what you are doing then turn it off and wait until
you can get native or switch providers to get native.

Remember for most applications marginal difference in rtt cause by
using transition technology is not noticible.  Additionally a 100ms
bias will stop you using really bad tunnel end point w.r.t. to where
you are connecting to so it puts a upper bound on the extra rtt,
(100ms + IPv4 rtt).

I'm in Sydney, Australia and the tunnel end point is in California.
The following is with a 100 ms bias.

e.g.
[drugs:~] marka% ./a.out www.aarnet.edu.au
trying 2001:388:1:4041::800
trying 202.158.201.38
connected 202.158.201.38
connect_to_host(www.aarnet.edu.au) -> 5 in 122 ms
[drugs:~] marka% ping www.aarnet.edu.au
PING www.aarnet.edu.au (202.158.201.38): 56 data bytes
64 bytes from 202.158.201.38: icmp_seq=0 ttl=116 time=18.556 ms
64 bytes from 202.158.201.38: icmp_seq=1 ttl=116 time=20.606 ms
^C
--- www.aarnet.edu.au ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.556/19.581/20.606/1.025 ms
[drugs:~] marka% ping6 www.aarnet.edu.au
PING6(56=40+8+8 bytes) 2001:470:1f00:820:6233:4bff:fe01:7585 --> 2001:388:1:4041::800
16 bytes from 2001:388:1:4041::800, icmp_seq=0 hlim=56 time=406.336 ms
^C
--- www.aarnet.edu.au ping6 statistics ---
2 packets transmitted, 1 packets received, 50.0% packet loss
round-trip min/avg/max/std-dev = 406.336/406.336/406.336/0.000 ms

[drugs:~] marka% 

For Europe and America using tunneled IPv6 has no negative impact
for me.  Connecting to Australian sites it will have a negative
impact but a 100 ms bias will remove it.  Connecting to most of
Asia there is no negative impact from the tunnel.

Mark

> -- =
> Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 |
> [email-masked]=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key!
> http://www.jorgensen.no=A0=A0 | [email-masked]