Yesterday's Windows update causes IPv4 to be default

[Christopher Palmer]

Lorenzo and I are having fantastic moment of togetherness right now.

Doug, I think it's a perfectly fair question. I think we have to disambiguate HE as a design for an operating system to implement, versus a browser.

As an OS, things like stability and predictability are especially important, both across apps and across time. This solution mitigates brokenness without robbing users of basic predictability. A ping of xbox.com at 6:30pm will be essentially identical to a ping of xbox.com at 6:35pm. The Netflix and Newegg apps operate similarly. 

Also, the network load implications of happy eyeballs are significant considering the high number of individual apps and services that may be connecting to Internet resources at any one time, and our fairly large install base. 

For these reasons, I doubt we'll implement something like happy eyeballs in Windows' connectbyname path. Maybe we'll provide more dynamic resolution of connectivity status and speed, but having a genuine race for every connection is not going to happen. 

As a browser vendor, we certainly reserve the right to do more in this space, and happy eyeballs isn't permanently off the table. If telemetry and other types of feedback indicate that the operating system intelligence isn't sufficient for user's modern standards of fast and ready web connectivity, then we'll have to consider a further improvement focused on Internet Explorer. That being said, I'm hopeful that our existing design is sufficient.

Let me further color that perspective : part of the experience issue with most IPv6 brokenness cases is that an end-user may encounter the problem before ISPs have prepared any sort of customer service response. A user calls customer service, and it can take a considerable amount of time before a resolution can be identified. The ISP's staff may have no idea what IPv6 even is. That sucks.

I worry less about slowness.

I believe the incidence and severity of chronic IPv6 slowness is negligible, at most. I do think that when it occurs, it's an issue I'm more comfortable leaving unfixed. An ISP that has IPv6 working, even slowly, has an obligation to its customers to work with them to deliver IPv6 performance that is reasonable. The same logic applies to temporary connectivity burps - ISPs should provide a reasonable quality of service, and I'm moderately fine with folks yelling at their ISP when stuff is actually broken. Customer service calls are expensive and they are one of the few ways to motivate forward progress.

There is a balance between delivering a good user-experience in the short-term, but also being honest about problems that have long-term implications. This might seem insensitive, but it's not - we really do care about users and making sure that they have the best possible Internet experience. We just have to chart a path between the short and long-term, and this is where we drew it, for now at least.

Best,
Chris

-----Original Message-----
From: Doug Barton [mailto:dougb at dougbarton.us] 
Sent: Tuesday, November 20, 2012 6:11 PM
To: Lorenzo Colitti
Cc: Christopher Palmer; ipv6-ops at lists.cluenet.de
Subject: Re: Yesterday's Windows update causes IPv4 to be default

On 11/20/2012 6:04 PM, Lorenzo Colitti wrote:
> On Wed, Nov 21, 2012 at 10:54 AM, Doug Barton <dougb at dougbarton.us 
> <mailto:dougb at dougbarton.us>> wrote:
>
>     Oh c'mon, that's just silly. The intermittent problems are almost
>     certainly not the fault of the content end of the system, they are
>     almost certainly on the user end, or somewhere in between.
>
>
> Correct. In case it wasn't clear, what I meant was:
>
>   * If you're an ISP, don't provision the user with an IPv6 address and
>     default route if you're not prepared to give them an appropriate
>     level of service.
>   * Similarly, if you're a website operator, don't give a website an
>     AAAA record if you're not prepared to make it sufficiently reliable.
>
> That is - if you're deploying IPv6, do it properly. Don't deploy 
> unreliable IPv6 "because it's the responsibility of the hosts to avoid 
> stuff that doesn't work".

Ok, on that much we agree. :)

>     We have to be able to deal rationally with the issue of the IPv4
>     network having a high degree of reliability and familiarity vs. the
>     IPv6 network which by comparison has neither. Otherwise we've
>     removed the motivation from both sides of the network to deploy it.
>
>
> I disagree. If we do this, we will be permanently increasing the 
> complexity of hosts just so we can work around a temporary problem 
> (immature IPv6 deployments and implementations).
>
> Happy eyeballs is a useful crutch to get us over the initial bump of
> IPv6 transition, but it's very much a double-edged sword. Relying on 
> it has long-term implementations for the complexity of the Internet 
> architecture, and that is IMO the wrong tradeoff..

... and with this perspective I sympathize, but I think the reality is that we are going to have wacky IPv6 connectivity problems well into the next decade, during the long ramp-up of knowledge and experience on both sides of the network. We are also going to continue to see reluctance on both sides if the hosts/apps are not robust enough to handle said wacky networks without significant degradation to the user experience.

Regardless of what we think it _should_ be, solving this problem is incredibly important to the long-term success of IPv6.

Doug