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

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

+1 for Happy Eyeballs.

Not convinced about giving IPv6 a 100mS head start as standard. 
Especially for web pages / applications that trigger many sessions.

I really really do like the fact that the authors have not attempted to 
second guess operational people's requirements and have given network 
managers the tools they need so that they can manage their own networks 
and their own migrations (in this case via DHCPv6 or the prefix policy 
table).

Sensible defaults are fine, so we can debate if the +100mS is correct. 
I'd personally like to see somewhere nearer 0mS as default. Why handicap 
a working service?

I do think it's sensible to take the lead from a well defined parameter 
e.g. the preference RFC3484 policy table in all cases to set the sign of 
the offset. IPv4 works just fine today actually, even if RFC3484 
defaults think otherwise. If the network manager has gone to the trouble 
of over-riding the default in RFC3484 to prefer IPv4 over IPv6 then that 
should be respected.

But I'd like to go one stage further and define an explicit DHCPv6 
mechanism/ named parameter to be able to set the value of IH as well as 
the sign (+ve or -ve). Maybe not IETF style I know.

Please forgive any apparent frustration in the following text. 
Operations people will know when it's the correct time to prefer IPv6 or 
IPv4 for their own particular network for their own particular 
migration, and by how much. One size does not fit all. At the moment, 
ironically enough, "zero configuration" seems to mean a lot more work, 
because not all implementations are following the same lead for what 
features to implement, or set of default behaviors, or end node 
configuration/ signaling mechanisms. [If you have a mixed network of 
thousands of Linux and Windows and OS X and iOS devices today (plus 
"legacy" OS), you have to locally reconfigure at least one set of 
machines to make them behave consistently. For one you even have to 
compile in DHCPv6 yourself, and for another that's pretty much impossible.]

regards,
RayH

> 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

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 27 May 2011 13:47:44 +0200

On Thu, May 26, 2011 at 08:44:32AM +0200, Ray Hunter wrote:
> Sensible defaults are fine, so we can debate if the +100mS is correct. I'd 
> personally like to see somewhere nearer 0mS as default. Why handicap a 
> working service?

Because cost of providing this service will explode in the future (LSN),
and "working" will certainly undergo significant redefinitions.

Don't continue riding dead horses more than absolutely required.

Best regards,
Daniel

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