Tore,
First of all, I'd like to say thank you for this data, it is
*extremely* useful! So, we now that we have 2 different tests that show
the same ballpark of breakage. Some questions in-line...
On Thu, 1 Apr 2010, Tore Anderson wrote:
:: To that end, I've been running my own measurement for quite some time
:: now. It's very regional in scope (Norwegian end users mostly), so it is
:: very likely that Yahoo, with their global audience, are observing
:: problems that I do not, but I'll try to make a summary of my conclusions
:: from March:
::
:: - Total client loss to the dualstacked host is at 0.074%.
:: - (At least) 95% of the client loss is due to clients choosing to use
:: inherently unreliable transitional IPv6 (6to4/Teredo) instead of IPv4.
:: - I've identifed three groups of clients that behave in this way:
:: 1) Users of Opera <10.50, which did not use the RFC 3484-compliant
:: getaddrinfo() call, at least on Windows. It would prefer any form
:: of IPv6 connectivity above IPv4. This is especially a problem on
:: Windows Vista and 7, where 6to4 and/or Teredo are enabled by
:: default. This accounts for about half of the 95%.
:: 2) Dualstacked Mac OS X users with RFC 1918 IPv4 addresses (using
:: NAT) and transitional IPv6 addresses. In this case, getaddrinfo()
:: will sort the IPv6 address above the IPv4 address, causing the
:: transitional connectivity to be used. This accounts for the other
:: half of the 95%.
:: 3) Dualstacked Linux users with RFC 1918 IPv4 addresses and
:: transitional IPv6 addresses, as GNU libc's getaddrinfo()
:: implementation behaves exactly like the one in Mac OS X. However,
:: the overall client loss caused by this is miniscule compared to
:: #1 and #2 (I have problems measuring any at all).
One question on this awesome data -- if the browser gets AAAA, hangs on
connecting to it, then goes into a time-out retry state, gets the A, and
hits the site over ipv4, say, 75 seconds later, does your method still
concider that connect successfull, or have you controlled for that via
time-outs in javascript or something? If you concider that to be
successful, do you have any way of re-doing the calculation to say "if it
took you longer then 10 seconds to connect, you are also broken"?
:: - When disregarding all hits from users in problem groups #1 and #2,
:: the total client loss is at 0.003% - this is, in my opinion, low
:: enough to accept. (Of course, other content providers might feel
:: differently.)
Honestly, I'd prefer the loss to be 0.001% to be comfortable with it, but
I have a feeling that you are right, and 0.003% will have to be
sufficient, provided that those numbers include the unacceptable latency
people.
:: In that regard I hope you have found my measurements useful. To the
:: Yahoo people: The sooner we know what the problems are, the sooner we
:: can start to fix them. Could you provide us with some preliminary
:: results from your measurements before June?
When we have some preliminary data to share, we will absolutely do so..
Thank you again for your data, extremely useful!
-igor
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
