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

Hello Vaibhav,

The map with blue/red is really a nice one :-)

May I dare to propose some improvements?

  *   on the blue/red map, be sure to have blue meaning all the time that IPv6 is faster (the legend is unclear and by using those tools, I know that this is not trivial to do)
  *   State the date of the 'scan'
  *   Some web sites are in the top 10K of Alexa but are not in: www.iet.org, www.lesoir.be, .... (Even www.ripe.net is not in the data :-) but RIPE is only 25.000th so out of your data set)

Again, nice visualisation!

-éric


From: ipv6-wg <ipv6-wg-bounces at ripe.net<mailto:ipv6-wg-bounces at ripe.net>> on behalf of "Bajpai, Vaibhav" <v.bajpai at jacobs-university.de<mailto:v.bajpai at jacobs-university.de>>
Date: Monday 23 May 2016 at 08:08
To: "ipv6-wg at ripe.net<mailto:ipv6-wg at ripe.net> IPv6" <ipv6-wg at ripe.net<mailto:ipv6-wg at ripe.net>>
Subject: [ipv6-wg] v4 versus v6 -- who connects faster?

Dear v6 WG,

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

You enter a dual-stacked website (ALEXA top 10K) and it shows
you the difference in TCP connect times over v4 and v6 as seen
by all dual-stacked RIPE Atlas probes (~1.3K probes). You can
also filter the visualisation from a specific origin-AS. This
additional filter can be useful to view performance towards a
website from a specific origin-AS (say 3320).

Disclaimer: This is an outcome of a 1.5d long hackathon project.
As such, the codebase is possibly inundated with bugs. Please
don’t see it as a production service :-)

Best, Vaibhav

===================================
Vaibhav Bajpai
www.vaibhavbajpai.com<http://www.vaibhavbajpai.com>

Room 91, Research I
School of Engineering and Sciences
Jacobs University Bremen, Germany
===================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ipv6-wg/attachments/20160523/439d446d/attachment.html>