[v6test] 2008-02-11 status update

[Kevin - Your.Org]

Quick update on what's been going on behind the scenes:


** Two NSPs in our area have made generous donations of bandwidth,  
just waiting for the crossconnects to be completed to bring those up.  
More details about how you can peer with us, or peer with them will be  
announced as soon as everything's ready.

** I'm working with two content providers to borrow some of their  
"completely safe for work" videos for this experiment. The premise  
being that when a user first visits the site, they're given two  
choices. "Click here for a completely work-safe version of this site,  
with some funny videos to watch that won't get you fired." and "Click  
here to view the adult stuff that we know you really came here  
for. :)" This was one of the biggest things people had been asking me  
for, so I'm glad I've finally been able to find some materials that  
would work for this.

** A web based discussion forum for end users, network operators and  
anyone else interested in the experiment has been installed, and will  
be launched before the actual experiment begins.

** One of the goals of this experiment is to instrument the  
performance differences for the same user between v4 and v6, as well  
as determining what the average end-user visible penalty for various  
transition methods (Teredo, 6to4, tunnels, etc). To accomplish this,  
I've written a kernel and web server patch to document the following  
metrics on every download:

Average download speed
Peak download speed
Average round trip time (as measured by TCP ACKs)
Best round trip time
Worst round trip time
Round trip time jitter
Window size
Maximum segment size
Retransmits / packet loss rate
SACK initiated retransmits
Duplicate acks (may indicate packets being duplicated somewhere on the  
network)
Duplicate data packets (not likely to be seen because of the one-way  
nature of the expected traffic flow)
Out of order data packets (also not likely to be seen)
Received TTL
PMTU occurrences (number of times MSS shrinks during a download)

This kernel patch has been running on an unrelated high traffic site  
for the last 48 hours with no problems, and appears to be generating  
valid data. With this patch, we can get an accurate idea of a user's  
v4 performance, recognize them when they come back to the site on v6  
by use of a randomized cookie, and make direct user-by-user  
comparisons on v4 v.s. v6 performance.

Other data points that we're collecting that don't require such kernel  
hackery:

Browser / Browser version
OS / OS Version
v4 source ASN
v6 source ASN
v6 address type (regular unicast, 6to4, teredo, etc)
What percentage of users who visit the site who don't have v4 to start  
with end up getting v6 working?
What percentage of v4 users are unable to access a site that has both  
A and AAAA records when first visiting (broken v6 stack/connectivity)?
What percentage of those users have fixed that problem somehow and  
returned?
What percentage of users have reported problems with each transition  
method? What percentage of those were eventually resolved?

Is there any other data that anyone here is interested in having me  
try to collect?



-- Kevin