Hi Igor, * Igor Gashinsky
> 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... I'm glad you find it interesting! > 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"? There's no timeout with the current numbers, no. The methology is as follows (I've anonymised the hostnames to prevent spiders and such from skewing my results): - There's a (hidden) IFRAME with src=http://exp.foo.no/linkgen.php in the HTML of the web site the end user is visiting. - The linkgen.php script spits out two IMG links: a) http://ds.foo.no/1x1,png?uuid=<random>:<unixtime>&src=<v4 src addr> b) http://v4.foo.no/1x1.png?uuid=<random>:<unixtime>&src=<v4 src addr> The ordering of the links in the generated HTML is random. - All of the hostnames mentioned point to different IPv4 addresses, and the "ds" one to a IPv6 address also. However they're all found on the same test server, served by the same Apache process. (There's only one copy of 1x1.png on the sever.) - The DNS TTL for all hostnames are 5 seconds. So basically what I do is to parse the logs, and count the following (numbers in parenthesis are from yesterday, April 1st): * N - number of hits to linkgen.php 1986244 * Ns - number of hits to 1x1.png via the v4 virtual host 1971340 * Nd - number of hits to 1x1.png via the ds virtual host 1970605 = Client loss: 100 / N * (Ns - Nd) 0.037% There's no timeout of any sort, the only hits I discard are duplicates, that is any 1x1.png request that comes in with an UUID I've already seen on that virtual host. But it would absolutesly be interesting to see how a timeout would affect the numbers, thanks for the suggestion! Since the time when the linkgen script ran in is embedded in the 1x1.png link, that was trivial to implement, and I've just run the numbers for March with a timeout of ten seconds, like you suggested. Results for VG: - Overall client loss: 0.122% - With Opera <10.50 on Windows and Mac OS X excluded: 0.015% - IOW, Opera/Mac OS X accounts for 88.056% of the client loss. So the root cause is for client loss is still overwhelmingly unnecessary use of transitional IPv6 connectivity. I will attempt to look more into the set of hits that arrive more than 10 seconds late on the dualstack host to see if I can uncover any other sources of client loss there, other than the ones I already know about. By the way, it would be fantastic if you/Yahoo would (in addition to pursuing the proposed DNS solution) help make an effort to help get rid off the known problems, by for example talking to Apple about their getaddrinfo() implementation, and warning users with old versions of Opera to upgrade - at least if you measure bad IPv6 connectivity from them. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
