[ipv6-wg] v4 versus v6 -- who connects faster?

Dear Tore,

> On 23 May 2016, at 09:47, Tore Anderson <tore at fud.no> wrote:
> 
> * Vaibhav Bajpai <vaibhavbajpai at me.com>
> 
>> Here [a] is a toy v6 service I came up with during the RIPE 
>> Atlas hackathon over this weekend. Thought I share this along:
>> 
>> [a] http://goo.gl/hbzbwD <http://goo.gl/hbzbwD>
>> 
>> [...]
> 
> Very cool, thanks for sharing!
> 
> Unfortunately though, th websites mentioned in websites.txt that I host
> on my network and thus am the most interested in (www.e24.no, www.vg.no,
> www.news247.gr, www.sport24.gr, www.contra.gr) doesn't actually yield
> any useful graphs. www.vg.no shows the diagram and the map, but they're
> empty. The others just say «Oops! No data».

The measurements for all these websites failed. Note, this is a 
TLS measurement to port 443 over v4 and v6. 

For www.e24.no and www.vg.no, the TCP connection gets established
but the TLS handshake fails. Note, the test does not like to report 
anything if the TLS handshake fails, so I lose the TCP report from the 
test, and therefore the webpage has nothing to show.

Here is a single one-off happy measurement [a] my laptop:
[a] http://happy.vaibhavbajpai.com

-----------------------
% happy -cp 443 www.e24.no
 2001:67c:21e0::e24                          30.632   27.497   32.613
 195.88.55.47                                35.660   30.441   31.260

% happy -cp 443 www.vg.no
www.vg.no:443
 2001:67c:21e0::16                             *        *        *   
 195.88.54.16                                65.549  109.074  127.143
 195.88.55.16                                45.398   85.099  104.523
-----------------------

For www.news247.gr, www.sport24.gr, www.contra.gr, the situation is 
worse. The server-side is not listening on port 443. Most likely 
these websites do not support TLS.

Here is a single one-off happy measurement [a] my laptop:

-----------------------
% happy -cp 443 www.news247.gr
www.news247.gr:443
 2a02:c0:208::36                               *        *        *   
 2a02:c0:208::37                               *        *        *   
 87.238.36.37                                  *        *        *   
 87.238.36.36                                  *        *        * 

% happy -cp 443 www.sport24.gr
www.sport24.gr:443
 2a02:c0:208::36                               *        *        *   
 2a02:c0:208::37                               *        *        *   
 87.238.36.37                                  *        *        *   
 87.238.36.36                                  *        *        * 

% happy -cp 443 www.contra.gr
www.contra.gr:443
 2a02:c0:208::37                               *        *        *   
 2a02:c0:208::36                               *        *        *   
 87.238.36.36                                  *        *        *   
 87.238.36.37                                  *        *        *  
-----------------------

Here are the raw RIPE Atlas measurements for ^ websites:

www.e24.no
https://atlas.ripe.net/measurements/3808293/#!probes
https://atlas.ripe.net/measurements/3808294/#!probes

www.vg.no
https://atlas.ripe.net/measurements/3807048/#!probes
https://atlas.ripe.net/measurements/3807049/#!probes

www.news247.gr
https://atlas.ripe.net/measurements/3807426/#!probes
https://atlas.ripe.net/measurements/3807425/#!probes

www.sport24.gr
https://atlas.ripe.net/measurements/3807288/#!probes
https://atlas.ripe.net/measurements/3807289/#!probes

www.contra.gr
https://atlas.ripe.net/measurements/3807583/#!probes
https://atlas.ripe.net/measurements/3807584/#!probes


Background
----------

Even though I am only interested in TCP connect times, there is no
TCP-layer test available on RIPE Atlas. Therefore, I leverage
TLS and then look at the underlying metrics reported for TCP.

Moreover, I cannot do TLS measurement to port 80 because the test
does not like to report TCP layer metrics in situations where the
TLS handshake fails. I did discuss this with Philip Homburg at
the hackathon. One possibility is to either a) refactor the TCP 
metrics into a specific TCP test or b) make the TLS test report 
TCP metrics even in situations where TLS handshake fails. I 
personally prefer b).

> Another suggestion: allow GET requests (/result?website=foo&asn=bar) to
> allow for direct linking and bookmarking.

Yes, good suggestion.

> Tore

Best, Vaibhav

===================================