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

From: Ray Hunter <[email-masked]>
Date: Thu, 26 May 2011 18:30:33 +0200

Whilst I like the concept of Happy Eyeballs, I humbly suggest that the 
WG needs to be a bit careful here in its assumptions on the use-cases.

I realize Happy Eyeballs is intended for addressing the issue of slow 
web browsing, and for Internet, and it's adaptive.

It looks like a really good solution for that problem.

But it is suggested in the draft that Happy Eyeballs could be applicable 
to other interactive applications too. And it could unintentionally 
affect other services.

 > While the application recommendations in this document are described 
in the context of HTTP clients ("web browsers") and SRV clients (e.g., 
XMPP clients) the procedure is also useful and applicable to other 
interactive applications.

Bear in mind that the adaption of the timers restarts from default every 
time a machine reboots, or reconnects to a network, or roams, or the 
cache is flushed..... they are not at all persistent by design.

I'd be delighted if IPv6 devices had the same performance as IPv4 
devices (think lack of IPv6 hardware acceleration on firewalls)

100mS latency may be very significant for a number of applications 
(especially in enterprise networks).

The use-case also makes the assumption that sessions are short lived, 
and each transaction results in a new session, hence the adaption of 
preference of IPv6 v IPv4 can have a positive effect.

For longer longer-lived sessions, the latency doesn't go away. That 
would probably not result in happy eyeballs.

How about X windows, or IP-HTTPS, or CIFS mounts, or Skype voice 
tunneling over port 80, or a whole load of other applications that are 
latency sensitive and hence which do not generally run over the Internet 
but do often run in enterprise networks?

There are also use cases where holes are punched in security devices 
based on web authentication. I can imagine that in most cases this is 
done based on source IP address. If that address alters over time ....

ISP's may also pay different traffic tariffs for upstream IPv6 and IPv4 
connectivity.

I'm OK with "Internet browsing as a default use case", but please don't 
forget to let people easily set their own preferences and tuning 
parameters on a per network basis for the use-cases that the IETF WG 
discounts today, or just haven't thought of right now. One size does not 
fit all. It's going to be a very long period of coexistence.

regards,
RayH

 >
 > Subject:
 > Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
 > From:
 > <[email-masked]>
 > Date:
 > Thu, 26 May 2011 16:15:40 +0200
 > To:
 > <[email-masked]>
 >
 >
 > 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

---

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

Le May 26, 2011 à 12:30 PM, Ray Hunter a écrit :
> How about X windows, or IP-HTTPS, or CIFS mounts, or Skype voice tunneling over port 80, or a whole load of other applications that are latency sensitive and hence which do not generally run over the Internet but do often run in enterprise networks?

The only one of these things that anybody actually does (rounded to the nearest hundred thousand) is Skype.   X windows over the Internet is, de facto, obsolete, whether we like it or not.   Furthermore, X was designed to deal with much worse latency.   The most commonly-used application that falls into the class you're talking about is online gaming.   I would expect that online gaming systems would use a much fancier adaptive algorithm than Happy Eyeballs to solve this problem, for just the reason you state.   Since these protocols are typically proprietary, we don't really have to worry about them--our defining Happy Eyeballs, unless it's implemented in the kernel (which I think is a tremendously bad idea) is not going to have any effect on them.

Skype spits in the eye of 50ms latency.   Also, Skype doesn't support IPv6, unless that's changed recently.

> There are also use cases where holes are punched in security devices based on web authentication. I can imagine that in most cases this is done based on source IP address. If that address alters over time ....

From that middlebox's perspective, the two addresses are two different devices.   So, in the vanishingly unlikely situation that the middlebox even *supports* IPv6, it's just going to punch two holes.   This is not rocket science.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 26 May 2011 20:33:41 +0200

Sorry Ted, all due respect but you appear to be making assumptions and 
statements about technical requirements on stuff you possibly haven't 
even seen.

Please don't try to convince me that enterprise customers are running 
"de facto obsolete" code, and that they don't have strict latency 
requirements, because they do.

Just because an application is not "a mass market 100K user application" 
doesn't mean to say they aren't financially significant to the IT industry.

X windows is alive and well in enterprise networks and designing for 
example the very latest products as I type, (together with a requirement 
of 35mS round trip network latency for a designer to be fully 
productive). This latency requirement figure was not plucked out of thin 
air and was the result of extensive user acceptability testing. FYI 
there is also a requirement in many CAD areas to be able to maintain 
these designs for 7 - 40 years or even indefinitely (automotive to 
nuclear). These software licenses also cost $25K to $100K per seat. 
Which is an awful lot of World of Warcraft subscribers.

That's just one example of something that you will not find running much 
on the Internet, and is in danger of slipping under the radar in such 
generalized discussions focused purely on requirements for browsing the web.

If enterprises didn't have these sort of latency and availability 
requirements, enterprise networks wouldn't exist, and every single 
device would just connect to the Internet. CFO's aren't daft.

So if Happy Eyeballs does have the ambition to be a more generic 
solution to the address family selection problem, it should allow tuning 
of the end node protocol selection parameters by the network manager, as 
Philip Homburg and Marc Andrews have already suggested. Otherwise make 
it a standard for Internet web browsers by all means.

regards,
RayH

---

From: Tim Chown <[email-masked]>
Date: Thu, 26 May 2011 19:45:49 +0100

On 26 May 2011, at 19:33, Ray Hunter wrote:

> 
> So if Happy Eyeballs does have the ambition to be a more generic solution to the address family selection problem, it should allow tuning of the end node protocol selection parameters by the network manager, as Philip Homburg and Marc Andrews have already suggested. Otherwise make it a standard for Internet web browsers by all means.

I'm a bit confused.

There's a suggestion that apps in enterprises may see 100ms latency.  HE is an adaptive system, but it won't be used at all if there is no AAAA record published for a service.  If an enterprise is publishing AAAA records for services that are not IPv6-enabled, and thus seeing (some) HE delays, there's something more fundamentally wrong (which is why per-service IPv6 addresses are handy, as mentioned in another discussion).

I see HE as a means to dramatically reduce the 21+ second timeouts that are seen for IPv6 accesses to sites/services outside your own control.  In that respect, it's a significant help, and I assume that's why Google have put similar behaviour into Chrome.

Tim

---

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

Le May 26, 2011 à 2:33 PM, Ray Hunter a écrit :
> Sorry Ted, all due respect but you appear to be making assumptions and statements about technical requirements on stuff you possibly haven't even seen.

You appear to have missed my point that custom applications probably won't do Happy Eyeballs.   Just because we publish a spec saying how to do it doesn't mean everyone will do it, or that they will do it that specific way.

Having said that, you posit a corporate environment where (a) IPv6 is configured; (b) the operators of the network can't afford to make it perform well, and (c) they *can* afford to spend $25k/seat on CAD software.   I can imagine an environment where any two of these conditions are true, but not all three.

The fact that you make these points as if they mean that Happy Eyeballs is a bad idea suggests to me that you haven't read the spec, or haven't understood it.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 26 May 2011 22:08:22 +0200

Ted Lemon wrote:
> my point that custom appl
I'm tempted to just let your reaction go without comment.

I have taken the time to read the spec carefully and provided positive 
feedback on how IMHO you could improve a very good draft even more so 
that it is applicable to a larger set of use-cases driven by an 
alternate view of end users' requirements.

If you read my previous posts you will see that:

1) I am very positive about Happy Eyeballs.

2) I think that the coexistence period of IPv4 and IPv6 is going to be 
very long. Perhaps 10 years or even more.

IPv6 will not get turned on instantly in an enterprise with a complex IT 
service stack and 100K desktops in 50+ countries.

Enterprises are going to run quickly to turn on IPv6 on the Internet 
facing edge systems, but internal systems will take far longer to 
migrate, especially in factory environments where downtime is limited.

As I'm sure you are aware, Windows is already running IPv6 by default, 
and is today setting up 6to4 connections over an IPv4 network by 
default. It's not a question of IPv6 being configured. Sometimes it's on 
by default.

Who knows what applications and latency requirements will pop up in the 
coming 10 years?

Where's the experimental evidence that an additional arbitrary 100mS or 
50mS or even 10mS is acceptable to users?

If you look at ping pong protocols like CIFS, we all know they're bad, 
we all know the throughput is proportional to the inverse of the 
latency, and yet they are still found in all sorts of modern 
implementations. 50mS versus 10mS latency reduces throughput by a factor 
of 5.

3) Roll out on Intercontinental enterprise networks is provider dependent.

Some customers have 4 or 5 different MPLS providers. Intercontinental 
networks are also limited by speed of light delay. It is likely during 
the transition that IPv6 transits may have less direct physical routes 
than the current IPv4 network. Maybe the undersea fibers haven't even 
been lit up yet for IPv6. No amount of money may be able to tune IPv6 
adequately for all providers simultaneously.

4) Custom apps do not mean custom stacks.

The CAD server software and user license is expensive, but the server OS 
is standard Linux, the PC client OS it runs on is standard Windows or 
Linux, as is the X windows product running on the client and server.

Any underlying commercial product in that software stack may make 
assumptions and implement Happy Eyeballs without knowing that the custom 
CAD application even exists.

Telnet is another simple example. 150-200mS is the accepted round trip 
delay for usable character echo. If you add on to inter-continental 
speed of light delays, an additional max of say 100mS for Happy 
Eyeballs, (if it is the first session to be established after Happy 
Eyeballs clears it's cache) could tip the user-acceptability for remote 
(global) applications. And please don't suggest local echo. That would 
not pass all user-acceptability tests.

Now I'm sure you'll accept that telnet is not a $100K app, but which may 
well be something that people consider "generic" and implement Happy 
Eyeballs in, not considering that telnet may be running over 
inter-continental links and have a character echo delay limit on user 
acceptability in certain environments and certain apps.

Happy Eyeballs currently claims to work for "interactive applications" 
and yet possibly introduces additional latency to an existing working 
service that has been tuned for user acceptance. Maybe it needs a health 
warning before people implement it? I sincerely hope not. I'd rather 
avoid that and improve the draft right now, so that it can be tuned to 
match the individual end users' requirements, and so that it is 
future-proof for use-cases that the original designers either haven't 
considered or which don't match the assumptions they made about user 
acceptability.

regards,
RayH

---

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

Le May 26, 2011 à 4:08 PM, Ray Hunter a écrit :
> I have taken the time to read the spec carefully and provided positive feedback on how IMHO you could improve a very good draft even more so that it is applicable to a larger set of use-cases driven by an alternate view of end users' requirements.

I think we are talking past each other.   In order for there to be latency resulting from happy eyeballs with the 100ms headstart, the following conditions must apply:

- You must set up AAAA records in the DNS for the server that provides the service for which latency is an issue.
- The software that talks to that server must implement happy eyeballs, even though it has constraints that make implementing happy eyeballs a bad idea.
- IPv6 connectivity from some client to that host must have latency that is sufficient to impact performance, yet still less than 100ms more than the latency on the IPv4 network.

This is an extremely constrained set of conditions.   Which, according to you, applies to about 100k devices.   All of which are managed by professional, yet apparently incompetent, IT departments.

So I'm really having trouble imagining a scenario in which the problem you are concerned about will occur.   And you seem to be proposing that we change the spec to accommodate these 100k mismanaged hosts.

Just to be clear here, I personally think that the right thing to do is simply launch both connections at the same time, and take the one that connects first.   However, there's been substantial pushback on this proposal because people think it will create too much extra load.   So we have this compromise of introducing some latency, and we can either do it to IPv6, or to IPv4.   If we do it to IPv6, it will mean that traffic that could quite successfully go over IPv6 will go over IPv4 instead; indeed, if we prefer IPv4 to IPv6, the same problem you are concerned about could easily occur.

So are you in fact proposing that we run a fair race, or that we run an unfair race with IPv4 being given the advantage?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 May 2011 09:41:24 +1000

In message <[email-masked]>, Ted Lemon writes:
> Le May 26, 2011 =E0 4:08 PM, Ray Hunter a =E9crit :
> > I have taken the time to read the spec carefully and provided positive fe=
> edback on how IMHO you could improve a very good draft even more so that it=
>  is applicable to a larger set of use-cases driven by an alternate view of =
> end users' requirements.
> 
> I think we are talking past each other.   In order for there to be latency =
> resulting from happy eyeballs with the 100ms headstart, the following condi=
> tions must apply:
> 
> - You must set up AAAA records in the DNS for the server that provides the =
> service for which latency is an issue.
> - The software that talks to that server must implement happy eyeballs, eve=
> n though it has constraints that make implementing happy eyeballs a bad ide=
> a.
> - IPv6 connectivity from some client to that host must have latency that is=
>  sufficient to impact performance, yet still less than 100ms more than the =
> latency on the IPv4 network.
> 
> This is an extremely constrained set of conditions.   Which, according to y=
> ou, applies to about 100k devices.   All of which are managed by profession=
> al, yet apparently incompetent, IT departments.
> 
> So I'm really having trouble imagining a scenario in which the problem you =
> are concerned about will occur.   And you seem to be proposing that we chan=
> ge the spec to accommodate these 100k mismanaged hosts.
> 
> Just to be clear here, I personally think that the right thing to do is sim=
> ply launch both connections at the same time, and take the one that connect=
> s first.   However, there's been substantial pushback on this proposal beca=
> use people think it will create too much extra load.   So we have this comp=
> romise of introducing some latency, and we can either do it to IPv6, or to =
> IPv4.   If we do it to IPv6, it will mean that traffic that could quite suc=
> cessfully go over IPv6 will go over IPv4 instead; indeed, if we prefer IPv4=
>  to IPv6, the same problem you are concerned about could easily occur.
> 
> So are you in fact proposing that we run a fair race, or that we run an unf=
> air race with IPv4 being given the advantage?

Ted go try the code available at my blog, referenced in happy-eyeballs.
It does a 200ms delay, then 100, 50, 25 ... for subseqent connection
attempts.  We don't need dual connection attempts for what should
be very low failure rates once the broken 6to4 connections are
essentially removed from the equation which will be well before
code with this "fix" in it is replaced.

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 May 2011 17:57:00 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ray Hunter
> Sent: Thursday, May 26, 2011 11:34 AM
> To: Ted Lemon
> Cc: [email-masked] WG
> Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-
> v6ops-happy-eyeballs-02
> 
> Just because an application is not "a mass market 100K user
> application" doesn't mean to say they aren't financially significant to
> the IT industry.
> 
> example the very latest products as I type, (together with a
> requirement of 35mS round trip network latency for a designer to be
> fully productive). This latency requirement figure was not plucked out
> of thin air and was the result of extensive user acceptability testing.
> FYI there is also a requirement in many CAD areas to be able to
> maintain these designs for 7 - 40 years or even indefinitely
> (automotive to nuclear). These software licenses also cost $25K to
> $100K per seat. Which is an awful lot of World of Warcraft subscribers.
> 
> That's just one example of something that you will not find running
> much on the Internet, and is in danger of slipping under the radar in
> such generalized discussions focused purely on requirements for
> browsing the web.

It is for these reasons that Happy Eyeballs supports different behavior
for different IPv6 prefixes.  

Happy Eyeballs has more than just its "IPv6 is working" or "IPv6 
is failing" variable (called Smoothed P).  Happy Eyeballs also 
includes a per-prefix exception cache, which can handle cases 
where IPv6 is working well within the enterprise but failing to 
the Internet.  The exception cache described in the I-D can 
be improved.  For example, the exception cache could be pre-populated
with information that is useful (e.g., based on information from
draft-ietf-6man-addr-select-opt could cause Happy Eyeballs to
give a *very* strong preference to an enterprise's own internal
IPv6 prefix).

> solution to the address family selection problem, it should allow
> tuning of the end node protocol selection parameters by the network
> manager, as Philip Homburg and Marc Andrews have already suggested.

Such ability is suggested in the I-D, and could be gleaned from
existing DHCPv6 parameters.  Or we may decide to define new DHCPv6
parameters for such tuning.

-d

> Otherwise make it a standard for Internet web browsers by all means.
> 
> regards,
> RayH
> 
> 
> Ted Lemon wrote:
> 
> 		How about X windows, or IP-HTTPS, or CIFS mounts, or Skype
> voice tunneling over port 80, or a whole load of other applications
> that are latency sensitive and hence which do not generally run over
> the Internet but do often run in enterprise networks?
> 
> 
> 
> 	The only one of these things that anybody actually does (rounded
> to the nearest hundred thousand) is Skype.   X windows over the
> Internet is, de facto, obsolete, whether we like it or not.
> Furthermore, X was designed to deal with much worse latency.   The most
> commonly-used application that falls into the class you're talking
> about is online gaming.   I would expect that online gaming systems
> would use a much fancier adaptive algorithm than Happy Eyeballs to
> solve this problem, for just the reason you state.   Since these
> protocols are typically proprietary, we don't really have to worry
> about them--our defining Happy Eyeballs, unless it's implemented in the
> kernel (which I think is a tremendously bad idea) is not going to have
> any effect on them.
> 
> 	Skype spits in the eye of 50ms latency.   Also, Skype doesn't
> support IPv6, unless that's changed recently.
> 
> 
> 
> 		There are also use cases where holes are punched in
> security devices based on web authentication. I can imagine that in
> most cases this is done based on source IP address. If that address
> alters over time ....
> 
> 
> 
> 	From that middlebox's perspective, the two addresses are two
> different devices.   So, in the vanishingly unlikely situation that the
> middlebox even *supports* IPv6, it's just going to punch two holes.
> This is not rocket science.
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 May 2011 14:20:09 +1000

> not pass all user-acceptability tests.

Native/6rd/local tunnel to Native/6rd/local tunnel is approximately
equal in performance to IPv4.  When *one* end of the connection is
6to4 *and* there isn't local relays (which any ISP which offers IPv6
should be running for reverse traffic generated by their customers)
you get a small additional latency.

Even with non-local tunnel end points it is still often comparible.
(www.ipv6.ripe.net appears to not be setting hlim correctly when
generating replies)

[drugs:~/cvs/9.4.x] marka% traceroute -I www.ripe.net
traceroute to www.ripe.net (193.0.6.139), 64 hops max, 72 byte packets
 1  bsdi (192.168.191.233)  63.925 ms  1.391 ms  0.982 ms
 2  10.72.0.1 (10.72.0.1)  7.900 ms  9.012 ms  8.173 ms
 3  bla2-ge0-0-1.gw.optusnet.com.au (198.142.160.185)  11.673 ms  11.412 ms  8.519 ms
 4  bla5-ge13-0.gw.optusnet.com.au (211.29.125.249)  7.910 ms  8.584 ms  8.309 ms
 5  203.208.191.5 (203.208.191.5)  158.422 ms  157.694 ms  157.606 ms
 6  cw.com.any2ix.coresite.com (206.223.143.96)  169.433 ms  159.543 ms  157.109 ms
 7  xe-7-2-0-xcr1.ash.cw.net (195.2.28.1)  409.945 ms  402.041 ms  413.517 ms
 8  xe-11-1-0-xcr1.nyk.cw.net (195.2.21.181)  409.958 ms  407.851 ms  404.836 ms
 9  xe-3-1-0-xcr1.lnd.cw.net (195.2.25.198)  409.894 ms  412.656 ms  409.774 ms
10  xe-7-3-0-xcr1.lsw.cw.net (195.2.25.134)  407.561 ms  404.797 ms  314.972 ms
11  xe-9-3-0-xcr1.amd.cw.net (195.2.25.202)  401.322 ms  407.849 ms  409.888 ms
12  * * *
13  www.ripe.net (193.0.6.139)  359.622 ms  400.558 ms  409.767 ms
[drugs:~/cvs/9.4.x] marka% traceroute6 -l -I www.ripe.net
traceroute6 to www.ripe.net (2001:67c:2e8:22::c100:68b) from 2001:470:1f00:820:6233:4bff:fe01:7585, 64 hops max, 16 byte packets
 1  bsdi (2001:470:1f00:820:2e0:29ff:fe19:c02d)  19.152 ms  1.248 ms  1.149 ms
 2  dviscorg.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1f00:ffff::5a0)  166.151 ms  166.802 ms  169.871 ms
 3  v702.core1.fmt1.he.net (2001:470:0:1f::1)  169.598 ms  177.313 ms  182.231 ms
 4  10gigabitethernet1-2.core1.sjc2.he.net (2001:470:0:2f::2)  167.109 ms  171.035 ms  168.418 ms
 5  10gigabitethernet3-3.core1.den1.he.net (2001:470:0:1b4::2)  196.435 ms  192.550 ms  198.616 ms
 6  10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1)  217.557 ms  291.472 ms  302.521 ms
 7  10gigabitethernet7-2.core1.nyc4.he.net (2001:470:0:1c6::1)  307.526 ms  345.985 ms  302.500 ms
 8  10gigabitethernet3-3.core1.lon1.he.net (2001:470:0:128::2)  406.787 ms  341.936 ms  396.796 ms
 9  10gigabitethernet1-1.core1.ams1.he.net (2001:470:0:3f::2)  326.308 ms  329.117 ms  406.218 ms
10  amsix-501.xe-0-0-0.jun1.bit-1.network.bit.nl (2001:7f8:1::a501:2859:2)  408.763 ms  401.435 ms  408.666 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  www.ipv6.ripe.net (2001:67c:2e8:22::c100:68b)  402.841 ms !  405.661 ms !  410.330 ms !
[drugs:~/cvs/9.4.x] marka% 

I will admit that having a not local tunnel end point will introduce
big delays.

[drugs:~/cvs/9.4.x] marka% traceroute6 -Il www.aarnet.edu.au
traceroute6 to www.aarnet.edu.au (2001:388:1:4041::800) from 2001:470:1f00:820:6233:4bff:fe01:7585, 64 hops max, 16 byte packets
 1  bsdi (2001:470:1f00:820:2e0:29ff:fe19:c02d)  7.626 ms  1.240 ms  1.164 ms
 2  dviscorg.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1f00:ffff::5a0)  166.750 ms  167.300 ms  167.445 ms
 3  v702.core1.fmt1.he.net (2001:470:0:1f::1)  166.078 ms  165.613 ms  172.338 ms
 4  10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2e::2)  172.103 ms  172.361 ms  206.173 ms
 5  xe-0-0-0.bb1.a.pao.aarnet.net.au (2001:504:d::b1)  167.818 ms  166.810 ms  166.644 ms
 6  so-3-1-0.bb1.a.syd.aarnet.net.au (2001:388:1:14::1)  330.779 ms  404.319 ms  413.099 ms
 7  so-0-1-0.bb1.a.cbr.aarnet.net.au (2001:388:1:c::1)  404.547 ms  407.836 ms  409.120 ms
 8  2001:388:1:4030:5675:d0ff:fea6:7880 (2001:388:1:4030:5675:d0ff:fea6:7880)  413.582 ms  406.345 ms  407.862 ms
 9  www.ipv6.aarnet.edu.au (2001:388:1:4041::800)  329.204 ms  389.227 ms  404.533 ms
[drugs:~/cvs/9.4.x] marka% traceroute -I www.aarnet.edu.au
traceroute to www.aarnet.edu.au (202.158.201.38), 64 hops max, 72 byte packets
 1  bsdi (192.168.191.233)  1.421 ms  2.327 ms  1.009 ms
 2  10.72.0.1 (10.72.0.1)  8.832 ms  27.643 ms  9.822 ms
 3  bla1-ge13-1.gw.optusnet.com.au (198.142.163.49)  9.628 ms  8.141 ms  9.247 ms
 4  xe-3-1-0.sd22.optus.net.au (119.225.9.253)  18.363 ms  10.113 ms  9.615 ms
 5  * * *
 6  bundle-ether15.ken39.sydney.telstra.net (165.228.132.205)  17.820 ms  11.391 ms  9.451 ms
 7  bundle-ether6.ken-core4.sydney.telstra.net (203.50.6.145)  24.087 ms  10.645 ms  12.256 ms
 8  tengigabitethernet4-1.ken37.sydney.telstra.net (203.50.20.52)  10.499 ms  9.987 ms  9.536 ms
 9  aarnet6.lnk.telstra.net (139.130.0.78)  11.534 ms  12.515 ms  14.519 ms
10  ge-6-0-0.bb1.a.syd.aarnet.net.au (202.158.202.17)  10.187 ms  11.035 ms  12.468 ms
11  so-0-1-0.bb1.a.cbr.aarnet.net.au (202.158.194.41)  13.722 ms  16.148 ms  16.010 ms
12  webmail.aarnet.edu.au (202.158.201.18)  14.758 ms  20.644 ms  14.402 ms
13  aarnet.biz (202.158.201.38)  15.945 ms  14.884 ms  17.338 ms
[drugs:~/cvs/9.4.x] marka% 

However even this this need not be problematic for most applications.

> acceptability in certain environments and certain apps.

And thoses that have those limits will fix things.  The home user
*can* turn off 6to4 or they *can* ask their ISP to run a 6to4 relay
for them.  Enterprises *can* get native ipv6 and/or local tunnel
end points.  It's not like good IPv6 is impossible to get if you
need interactive performance.  There really is enough interconnects
these days.  Strange routings are almost a thing of the past.
It's just getting your local link to support ipv6 that is the problem.

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

---

From: Ray Hunter <[email-masked]>
Date: Fri, 27 May 2011 07:47:03 +0200

Mark Andrews wrote:
> In message<[email-masked]>, Ray Hunter writes:
>    
> <snip>
"Most applications" is not good enough for some end users of IPv4 and IPv6.

> It's just getting your local link to support ipv6 that is the problem.
More assumptions about what is acceptable to an end user, what services 
are globally available, what standards have been implemented in existing 
products, what migration path people will take to IPv6, and what power 
an end user has to fix things when using pre-compiled or older or 
off-the-self products.

Where's the experimental evidence that the Internet represents the only 
valid set of end user requirements for IETF standards? Existence of 
networks other than the Internet that also run IP point in the opposite 
direction.

Tight control of latency is a hot issue in the SLA for many end users of 
IETF protocols, and this is not currently addressed by the public 
Internet or the current draft.

AFAIK The IETF has never ever made a statement saying that IPv6 needs to 
be faster than IPv4 (by handicapping IPv4) in order to promote IPv6 
adoption, nor should it IMHO.

All I'm saying is that if there is an address family priority preference 
parameter in a protocol, then the IETF should give network managers the 
tools they need to be able tune their own networks to match their own 
end user requirements during a long period of coexistence, and 
preferably on a per link basis (e.g. via DHCPv6).

I personally would prefer if the default was neutral bias, so that the 
"best address family" with the lowest latency was selected. I could live 
with another default, provided it was easy to override by a standard 
mechanism. I'm pretty sure ISPs could live with another set of default 
tuning parameters for AF selection if they could easily tune the 
protocol to their apparent requirement to promote IPv6 over IPv4 (to 
avoid overloading expensive CGN devices or whatever else), although I'll 
let them represent their own views and requirements.

Is it really such a big deal to give network managers some knobs to 
turn, together with an easy and standard communication mechanism to do 
this? The existing mechanism that covered AF preference selection 
(RFC3484) recognised this requirement for a need to implement different 
policies for different networks at different times during the transition 
(although IMHO the standardized tuning tools and communication methods 
are rather lacking at this time).

regards,
RayH

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 May 2011 09:40:45 -0400

Le May 27, 2011 à 1:47 AM, Ray Hunter a écrit :
> Is it really such a big deal to give network managers some knobs to turn, together with an easy and standard communication mechanism to do this? The existing mechanism that covered AF preference selection (RFC3484) recognised this requirement for a need to implement different policies for different networks at different times during the transition (although IMHO the standardized tuning tools and communication methods are rather lacking at this time).

Not only is it not a big deal, but as several people have explained to you, there exist mechanisms already that we think are adequate.   But you insist that those mechanisms aren't adequate.   You haven't actually made any argument as to why they are inadequate; although you seem certain that they are not.

It would be awfully nice if we could actually identify what it is about the existing methods doesn't work for you.   If you think there is some new mechanism that is needed, it would be helpful if you could describe such a mechanism.   It would also help if you could explain why it is better than the mechanisms we've already described.  Then we could have a discussion about whether that mechanism is easier or harder to implement than existing mechanisms, and whether it would be more or less effective.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 May 2011 07:18:55 -0700

Hi,

If I set address selection policy rules that de-prefer
certain IPv6 prefixes (e.g., 2001:db8:0:1::/64) and makes
them to be of lesser priority than IPv4, will HE respect
that and use IPv4?

Thanks - Fred

---

From: Ray Hunter <[email-masked]>
Date: Fri, 27 May 2011 16:52:07 +0200

Interesting concept of engineering: there are solutions and they are all 
just fine, but why do you insist on coming with that daft requirement 
after we've already designed? ;)

See existing thread on RFC3484 bis 
http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html for my 
input to how RFC3484 address family selection does not meet my 
customer's requirements today to be able to prefer IPv4 in an 
operational network to avoid excessive latency for interactive 
applications in the presence of IPv6 over tunnels but still allowing 
them to roll out IPv6 native, and a suggestion to improve this by 
codifying address selection policy of RFC3484 bis into DHCPv6.

And also a suggestion of adding one or more separate tables to the 
prefix policy table to be able to codify rules in policy, rather than 
these being hard coded into operating systems or applications. e.g. 
whether RFC1918 addresses should be considered global (in the presence 
of IPv4 NAT) or truly local (isolated IPv4 RFC1918 islands once IPv6 
becomes ubiquitous and the IPv4 Internet is becoming fragmented for CGN 
or whatever other reason)

The basic point is that one size does not fit all. Otherwise the 
Internet would be the only IP network in the World. And it clearly isn't.

The IPv6 end node implementations today do not have standardized default 
behavior.

One vendor will turn on DHCPv6. Another vendor hates the whole concept 
of DHCPv6 and will possibly implement DHCPv6, but not enable it.

One vendor will turn on temporary addresses by default. Another will not 
because they hate the idea.

Today's infrastructures are multi-vendor. To achieve consistent behavior 
a network manager has to manually override default settings on every 
single machine of the flavor they don't like, no matter whether you are 
a fan of SLAAC or DHCPv6. You can't win. Yes they will work together on 
the wire, but is it easy to operate and manage?Just ask any real busy 
network administrator today who performs daily operations in a large 
commercial environment and has to trace problems what he/she thinks 
about that and whether today's tools help them do their job.

One vendor will turn on Happy Eyeballs on one application. Another will 
not. One person wants IPv6 preferred today. Another doesn't.

The IPv6 end node implementations today do not have standard ways of 
being able to over ride those defaults (which have anyway not been 
coordinated across the industry).

So over riding of any defaults that are not appropriate for a particular 
end users' requirements relies on operating system specific / 
proprietary management techniques such as Microsoft Active Directory.

However, in these days of the exploding numbers of devices, Internet of 
Everything, highly mobile devices, devices running multiple interfaces 
and technologies, and Bring Your Own Device, these assumptions of host 
management control being equal to network management control are 
breaking down.

The IPv6 set of standards does not have a standard way of communicating 
or signaling appropriate behavior from a network device to an end node. 
DHCPv6 might grow to become that standard, but there is certainly no 
consensus at this time. DHCPv6 today isn't even backwards compatible 
with all of DHCPv4 e.g. all of the vendor extensions.

If you compare that situation to say 3G or GSM mobile telephone 
networks, you will see that these standards do exist in that World for 
similar functions (although obviously using different protocols). And 
for a good reason. These standards are needed when devices are produced 
by different vendors, are highly mobile, some devices are rapidly turned 
over whilst others have long operational lifetimes, and they are all 
managed by different entities.

There are standards for network equipment behavior (including backwards 
compatibility and release management). There are standards for end node 
behavior (again including release management). There are standards for 
signaling between a network operators device and an end terminal to 
ensure that the end node behaves in a manner appropriate for that 
operators network.

I'm not saying the Internet should go as far as those ITU style 
standards, as they also have their downsides. But I am flagging up that 
existing assumptions about how defaults and settings on IT and Internet 
systems are expected to be managed should be challenged. Hard coding 
settings is not the way to make this transition/ deployment a success. IMHO

If you need further evidence that people need more control of how the 
end nodes behave on their networks today, I suggest the WG casts its net 
wider to attempt to quantify all end user requirements and Service Level 
Agreements that exist for all systems running IPv4 operationally today, 
and how each one will translate into IPv6 in the future.

Everything from light bulbs to web surfing to stock trading systems to 
electricity network control systems to spacecraft control systems to 
nuclear power plants.
[Many of which also include standard off the shelf operating systems and 
applications and IETF defined standard protocols in some part of their 
operations]

This has been addressed before in the v6ops list, so is nothing new, but 
it did not seem to gain traction there for whatever reason.

See http://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00

Regards,
RayH

Ted Lemon wrote:
>> turn, together with an easy and standard communication mechanism to 
>> do this? The existing mechanism that covered AF preference selection 
>> (RFC3484) recognised this requirement for a need to implement 
>> different policies for different networks at different times during 
>> the transition (although IMHO the standardized tuning tools and 
>> communication methods are rather lacking at this time).
>
> Not only is it not a big deal, but as several people have explained to 
> you, there exist mechanisms already that we think are adequate.   But 
> you insist that those mechanisms aren't adequate.   You haven't 
> actually made any argument as to why they are inadequate; although you 
> seem certain that they are not.
>
> It would be awfully nice if we could actually identify what it is 
> about the existing methods doesn't work for you.   If you think there 
> is some new mechanism that is needed, it would be helpful if you could 
> describe such a mechanism.   It would also help if you could explain 
> why it is better than the mechanisms we've already described.  Then we 
> could have a discussion about whether that mechanism is easier or 
> harder to implement than existing mechanisms, and whether it would be 
> more or less effective.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 May 2011 08:48:54 -0700

Ray,

Based on your link to the RFC3484 thread, you seem to be still
concerned about ISATAP. Please have a look at the latest draft
to see if it satisfies the concerns:

http://www.ietf.org/id/draft-templin-v6ops-isops-07.txt

Thanks - Fred

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Friday, May 27, 2011 7:52 AM
To: Ted Lemon
Cc: [email-masked] WG
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-happy-eyeballs-02

Interesting concept of engineering: there are solutions and they are all just fine, but why do you insist on coming with that daft requirement after we've already designed? ;)

See existing thread on RFC3484 bis http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html for my input to how RFC3484 address family selection does not meet my customer's requirements today to be able to prefer IPv4 in an operational network to avoid excessive latency for interactive applications in the presence of IPv6 over tunnels but still allowing them to roll out IPv6 native, and a suggestion to improve this by codifying address selection policy of RFC3484 bis into DHCPv6.

And also a suggestion of adding one or more separate tables to the prefix policy table to be able to codify rules in policy, rather than these being hard coded into operating systems or applications. e.g. whether RFC1918 addresses should be considered global (in the presence of IPv4 NAT) or truly local (isolated IPv4 RFC1918 islands once IPv6 becomes ubiquitous and the IPv4 Internet is becoming fragmented for CGN or whatever other reason)

The basic point is that one size does not fit all. Otherwise the Internet would be the only IP network in the World. And it clearly isn't.

The IPv6 end node implementations today do not have standardized default behavior.

One vendor will turn on DHCPv6. Another vendor hates the whole concept of DHCPv6 and will possibly implement DHCPv6, but not enable it.

One vendor will turn on temporary addresses by default. Another will not because they hate the idea.

Today's infrastructures are multi-vendor. To achieve consistent behavior a network manager has to manually override default settings on every single machine of the flavor they don't like, no matter whether you are a fan of SLAAC or DHCPv6. You can't win. Yes they will work together on the wire, but is it easy to operate and manage?Just ask any real busy network administrator today who performs daily operations in a large commercial environment and has to trace problems what he/she thinks about that and whether today's tools help them do their job.

One vendor will turn on Happy Eyeballs on one application. Another will not. One person wants IPv6 preferred today. Another doesn't.

The IPv6 end node implementations today do not have standard ways of being able to over ride those defaults (which have anyway not been coordinated across the industry).

So over riding of any defaults that are not appropriate for a particular end users' requirements relies on operating system specific / proprietary management techniques such as Microsoft Active Directory.

However, in these days of the exploding numbers of devices, Internet of Everything, highly mobile devices, devices running multiple interfaces and technologies, and Bring Your Own Device, these assumptions of host management control being equal to network management control are breaking down.

The IPv6 set of standards does not have a standard way of communicating or signaling appropriate behavior from a network device to an end node. DHCPv6 might grow to become that standard, but there is certainly no consensus at this time. DHCPv6 today isn't even backwards compatible with all of DHCPv4 e.g. all of the vendor extensions.

If you compare that situation to say 3G or GSM mobile telephone networks, you will see that these standards do exist in that World for similar functions (although obviously using different protocols). And for a good reason. These standards are needed when devices are produced by different vendors, are highly mobile, some devices are rapidly turned over whilst others have long operational lifetimes, and they are all managed by different entities.

There are standards for network equipment behavior (including backwards compatibility and release management). There are standards for end node behavior (again including release management). There are standards for signaling between a network operators device and an end terminal to ensure that the end node behaves in a manner appropriate for that operators network.

I'm not saying the Internet should go as far as those ITU style standards, as they also have their downsides. But I am flagging up that existing assumptions about how defaults and settings on IT and Internet systems are expected to be managed should be challenged. Hard coding settings is not the way to make this transition/ deployment a success. IMHO

If you need further evidence that people need more control of how the end nodes behave on their networks today, I suggest the WG casts its net wider to attempt to quantify all end user requirements and Service Level Agreements that exist for all systems running IPv4 operationally today, and how each one will translate into IPv6 in the future.

Everything from light bulbs to web surfing to stock trading systems to electricity network control systems to spacecraft control systems to nuclear power plants.
[Many of which also include standard off the shelf operating systems and applications and IETF defined standard protocols in some part of their operations]

This has been addressed before in the v6ops list, so is nothing new, but it did not seem to gain traction there for whatever reason.

Regards,
RayH

Ted Lemon wrote:

---

From: Ray Hunter <[email-masked]>
Date: Sat, 28 May 2011 16:30:30 +0200

I would hope people reading the v6ops list just recognize someone 
applying ITIL principles and processes to the discussion, no matter what 
the technology. Please rest assured that I also pose similar questions 
and follow similar steps when introducing any new service, or provider, 
or indeed anything else significantly new to the operational environment 
that has potential to affect the SLA, but of course that doesn't get 
posted to this list.

best regards,
RayH

Templin, Fred L wrote:
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Ray Hunter
>     *Sent:* Friday, May 27, 2011 7:52 AM
>     *To:* Ted Lemon
>     *Cc:* [email-masked] WG
>     *Subject:* Re: [v6ops] Subject: Re: Happy eyeballs
>     update,draft-ietf-v6ops-happy-eyeballs-02
>
>     Interesting concept of engineering: there are solutions and they
>     are all just fine, but why do you insist on coming with that daft
>     requirement after we've already designed? ;)
>
>     http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html
>     for my input to how RFC3484 address family selection does not meet
>     my customer's requirements today to be able to prefer IPv4 in an
>     applications in the presence of IPv6 over tunnels but still
>     allowing them to roll out IPv6 native, and a suggestion to improve
>     this by codifying address selection policy of RFC3484 bis into DHCPv6.
>
>     prefix policy table to be able to codify rules in policy, rather
>     than these being hard coded into operating systems or
>     applications. e.g. whether RFC1918 addresses should be considered
>     global (in the presence of IPv4 NAT) or truly local (isolated IPv4
>     RFC1918 islands once IPv6 becomes ubiquitous and the IPv4 Internet
>     is becoming fragmented for CGN or whatever other reason)
>
>     One vendor will turn on DHCPv6. Another vendor hates the whole
>     concept of DHCPv6 and will possibly implement DHCPv6, but not
>     enable it.
>
>     Today's infrastructures are multi-vendor. To achieve consistent
>     behavior a network manager has to manually override default
>     settings on every single machine of the flavor they don't like, no
>     matter whether you are a fan of SLAAC or DHCPv6. You can't win.
>     Yes they will work together on the wire, but is it easy to operate
>     and manage?Just ask any real busy network administrator today who
>     performs daily operations in a large commercial environment and
>     has to trace problems what he/she thinks about that and whether
>     today's tools help them do their job.
>
>     One vendor will turn on Happy Eyeballs on one application. Another
>     will not. One person wants IPv6 preferred today. Another doesn't.
>
>     The IPv6 end node implementations today do not have standard ways
>     of being able to over ride those defaults (which have anyway not
>     been coordinated across the industry).
>
>     So over riding of any defaults that are not appropriate for a
>     particular end users' requirements relies on operating system
>     specific / proprietary management techniques such as Microsoft
>     Active Directory.
>
>     However, in these days of the exploding numbers of devices,
>     Internet of Everything, highly mobile devices, devices running
>     multiple interfaces and technologies, and Bring Your Own Device,
>     these assumptions of host management control being equal to
>     network management control are breaking down.
>
>     The IPv6 set of standards does not have a standard way of
>     communicating or signaling appropriate behavior from a network
>     device to an end node. DHCPv6 might grow to become that standard,
>     but there is certainly no consensus at this time. DHCPv6 today
>     isn't even backwards compatible with all of DHCPv4 e.g. all of the
>     vendor extensions.
>
>     networks, you will see that these standards do exist in that World
>     for similar functions (although obviously using different
>     protocols). And for a good reason. These standards are needed when
>     devices are produced by different vendors, are highly mobile, some
>     devices are rapidly turned over whilst others have long
>     operational lifetimes, and they are all managed by different entities.
>
>     There are standards for network equipment behavior (including
>     backwards compatibility and release management). There are
>     standards for end node behavior (again including release
>     management). There are standards for signaling between a network
>     operators device and an end terminal to ensure that the end node
>     behaves in a manner appropriate for that operators network.
>
>     standards, as they also have their downsides. But I am flagging up
>     that existing assumptions about how defaults and settings on IT
>     and Internet systems are expected to be managed should be
>     challenged. Hard coding settings is not the way to make this
>     transition/ deployment a success. IMHO
>
>     If you need further evidence that people need more control of how
>     the end nodes behave on their networks today, I suggest the WG
>     casts its net wider to attempt to quantify all end user
>     requirements and Service Level Agreements that exist for all
>     systems running IPv4 operationally today, and how each one will
>     translate into IPv6 in the future.
>
>     Everything from light bulbs to web surfing to stock trading
>     systems to electricity network control systems to spacecraft
>     control systems to nuclear power plants.
>     [Many of which also include standard off the shelf operating
>     systems and applications and IETF defined standard protocols in
>     some part of their operations]
>
>     This has been addressed before in the v6ops list, so is nothing
>     new, but it did not seem to gain traction there for whatever reason.
>
>>>     Is it really such a big deal to give network managers some knobs
>>>     to turn, together with an easy and standard communication
>>>     mechanism to do this? The existing mechanism that covered AF
>>>     preference selection (RFC3484) recognised this requirement for a
>>>     need to implement different policies for different networks at
>>>     different times during the transition (although IMHO the
>>>     standardized tuning tools and communication methods are rather
>>>     lacking at this time).
>>
>>     Not only is it not a big deal, but as several people have
>>     explained to you, there exist mechanisms already that we think
>>     are adequate.   But you insist that those mechanisms aren't
>>     adequate.   You haven't actually made any argument as to why they
>>     are inadequate; although you seem certain that they are not.
>>
>>     about the existing methods doesn't work for you.   If you think
>>     there is some new mechanism that is needed, it would be helpful
>>     if you could describe such a mechanism.   It would also help if
>>     you could explain why it is better than the mechanisms we've
>>     already described.  Then we could have a discussion about whether
>>     that mechanism is easier or harder to implement than existing
>>     mechanisms, and whether it would be more or less effective.
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 May 2011 08:16:04 -0700

Hi Ray,

Have you read RFC1687? The document is 17yrs old and may have some
dated concepts, but it covers a number of concerns that are similar to the
ones you have raised. Here is the conclusion, which to a certain extent
still rings true today:

Conclusion

   In summary, the key factor which will determine whether -- and to
   what extent -- IPng will be deployed by large end users is whether
   IPng will become an essential element for the construction of
   applications which are critically needed by our businesses.  If IPng
   is bundled with applications which satisfy critical business needs,
   it will be deployed.  If it isn't, it is of little relevance to the
   large end user.  Regardless of what happens to IPng, the large mass
   of IPv4 devices will ensure that IPv4 will remain an important
   protocol for the foreseeable future and that continued development of
   IPv4 products is advisable.

Thanks - Fred
[email-masked]<mailto:[email-masked]>
________________________________
From: Ray Hunter [mailto:[email-masked]]
Sent: Saturday, May 28, 2011 7:31 AM
To: Templin, Fred L
Cc: [email-masked] WG
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-happy-eyeballs-02

I would hope people reading the v6ops list just recognize someone applying ITIL principles and processes to the discussion, no matter what the technology. Please rest assured that I also pose similar questions and follow similar steps when introducing any new service, or provider, or indeed anything else significantly new to the operational environment that has potential to affect the SLA, but of course that doesn't get posted to this list.

best regards,
RayH

Templin, Fred L wrote:
Ray,

Thanks - Fred

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Friday, May 27, 2011 7:52 AM
To: Ted Lemon
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-happy-eyeballs-02

Regards,
RayH

Ted Lemon wrote:

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 May 2011 18:11:58 -0700

> them to be of lesser priority than IPv4, will HE respect

Not as currently written, no.  The steps are 
described in
http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02#section-5.3

An algorithm that uses the host's address selection rules
is easy:  getaddrinfo(), then attempt to connect to each 
address in the order returned, delaying NNNN milliseconds
between connection attempts.

What Happy Eyeballs is trying to accomplish is not simply
walking the host's address selection table quickly; Happy
Eyeballs is trying to react to the success (or failure)
of IPv6 or IPv4, with the idea that (a) the address 
selection table is incorrect or (b) there is a problem with
the network path.  (b) cannot be fixed by the address
selection table.

There might be some way to get Happy Eyeballs to accomplish
its goal while still honoring the host's address selection
policy rule better.  I don't know how to do that, though.
Ideas welcome.

-d

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Jun 2011 12:55:12 +1000

> policy rule better.  I don't know how to do that, though.

I don't think HE needs to go this far.  Truly, fast recovery will
be enough with the application re-using the working address for the
same host.  We have over-reacted.

Mark

---

From: Jason Lin <[email-masked]>
Date: Wed, 1 Jun 2011 12:22:13 +0800

I think the objective of the Initial Headstart (IH) is good. But it is hard
to say whether 100ms has bad influence to dual-stack users, we need more
experimental statistics. If the influence is obviously, user will change
their browser to another which has set IH=0.

So I think this value will adapt the market needs. Software companies will
change the value by providing updates.

- Jinyan Lin