On killing IPv6 transition mechanisms
ek at google.com
Tue Mar 16 10:38:24 CET 2010
On 16 March 2010 18:28, Gert Doering <gert at space.net> wrote:
> On Tue, Mar 16, 2010 at 10:13:18AM +0100, Tore Anderson wrote:
>> on and on. Network latency is without question on that list. While
>> nothing can be done about a user's high-latency connection, 150ms of
>> additional client-server latency due to IPv6 being used will quickly add
>> up to seconds in terms of overall page load time for a complex web site,
> I keep wondering about those 150ms. I seem to remember that Google saw
> *few users* that had a much higher IPv6 latency - but at the same time
> they also saw users with a *lower* latency via IPv6 (due to different
> network paths being taken).
> For me, the v4/v6 latency is very similar - I use v6 all day, many of
> the sites I connect to (including google) have v6, and I do not see any
> adverse effects (nor any positive effects - it's just IP, after all).
> So I'd like to see these 150ms qualified - in this discussion, it seems
> to be the assumption that "IPv6 will *always* be 150ms slower", which
> is most definitely not the case.
Things definitely improved a bit (brought the average extra latency
down to between 50 and 100 msec) when we started getting a different
2002::/16 at one point, IIRC. There is indeed a list of caveats
w.r.t. these latency numbers: they are only Google's observations
based on the state of everyone else's 22.214.171.124/24 and whatever
2002::/16 we were being advertised during the measurement period.
Clearly that means the observations were temporally relevant to mostly
But that's not the point. The point is more the massive indeterminacy
in the full pairwise mesh of <ISP network, content network> ugliness
and whether or not "polishing the turd" is worth one's time. Clearly
that's going to be a decision each person will have to make for
More information about the ipv6-ops