IPv6 client loss measurements, now on the web

Tore Anderson tore.anderson at redpill-linpro.com
Wed Apr 28 14:51:08 CEST 2010


* Matthew Ford

>> This really is excellent work, thanks!

I'm glad you like it!  :-)

>> Of course there's always room for improvement ;) - one thing I'd
>> like to see would be a version of the no-known-brokenness-historic
>> graph *with* timeout, to get a sense of the impact of the state of
>> the IPv6 inter-network on connectivity and latency in the absence
>> of other bigger problems.
>> 
> Gah. There's certainly room for improvement in my observational
> skills. It's not graphed, but the numbers are there.

Actually, it's graphed too:

http://fud.no/ipv6/gnuplot/no-known-brokenness-t10.png
http://fud.no/ipv6/gnuplot/no-known-brokenness-t10-historic.png

Same goes for the "noosx" and "nobuggyopera" variants.  I just took them
out of the page since I got feedback that they just made the the page
too cluttered with graphs.  After all, they're not graphs of real user
behaviour, they're just illustrating a «wishful thinking» scenario, so
he thought the no-timeout variant made the point well enough and that
the timeout one was therefore redundant.  But I'll put them back in as
text links instead, hopefully that'll satisfy you both.  :-)  Better now?

> So, client loss of 0.01% with a 10s timeout. Is that acceptable to
> your customers (both the loss rate and the timeout)? How does this
> change with, say a 5s or a 1s timeout?

I think 0.01% would be acceptable, yes.  I haven't given up on trying to
convince them to go for it at this point either, but it certainly
requires some nagging!

It would take me quite a few hours to run the parsing scripts again with
a modified timeout on all the logs, so I'd rather not start that right
now since I'm doing some calculations on the impact of a certain
6to4-filtering end-user network here in Norway at the moment.

However Steinar has also been looking into my logs to see how long the
delays are, and he found that many are clustered around 75 seconds. That
appears to be how long it takes Safari (possibly other Mac OS X-based
browsers too?) to recover from a failed initial IPv6 connection attempt.
 This behaviour has been observed by others, too, see:

http://www.potaroo.net/ispcol/2009-01/mtu6.html

So 10s should be sufficient to weed out those false positives, at least.

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


More information about the ipv6-ops mailing list