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 <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 DTAG). 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 ===================================
* Vaibhav Bajpai <vaibhavbajpai@me.com>
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 <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 DTAG).
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». Another suggestion: allow GET requests (/result?website=foo&asn=bar) to allow for direct linking and bookmarking. Tore
Dear Tore,
On 23 May 2016, at 09:47, Tore Anderson <tore@fud.no> wrote:
* Vaibhav Bajpai <vaibhavbajpai@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 ===================================
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).
This not correct/complete. The Atlas traceroute measurement supports TCP. There is no reason to assume that this will not result in valid connect times. Just use a high enough starting ttl and only the target system will see the SYN packets. Philip
Hi Vaibhav, On 23 May 2016 at 08:51:27, Vaibhav Bajpai (vaibhavbajpai@me.com) wrote: 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 DTAG). 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 :-) Nice job, congratulations. Out of curiosity, I tried accessing it from the NAT64 Wifi network at RIPE72, and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some reason. Thoughts? Cheers, -- Nico
On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON <nicolas@ncartron.org> wrote:
Here [a] is a toy v6 service I came up with during the RIPE Atlas hackathon over this weekend. Thought I share this along:
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 DTAG).
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 :-)
Nice job, congratulations.
Out of curiosity, I tried accessing it from the NAT64 Wifi network at RIPE72, and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some reason. Thoughts?
1) Does it work from the dual-stacked network? I'm seeing significant packet loss on wireless right now, on both dual-stacked and v6-only network, so it might the reason 2) how exactly does it fail? DNS resolution/connection timeout? -- SY, Jen Linkova aka Furry
On 23 May 2016 at 14:24:55, Jen Linkova (furry13@gmail.com) wrote: On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON <nicolas@ncartron.org> wrote:
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 DTAG). 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 :-) Nice job, congratulations. Out of curiosity, I tried accessing it from the NAT64 Wifi network at RIPE72, and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some reason. Thoughts?
1) Does it work from the dual-stacked network? Yes it does. I'm seeing significant packet loss on wireless right now, on both dual-stacked and v6-only network, so it might the reason Possibly. 2) how exactly does it fail? DNS resolution/connection timeout? Nope, DNS resolution works fine: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2934 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;dragon.eecs.jacobs-university.de. IN A ;; ANSWER SECTION: dragon.eecs.jacobs-university.de. 277 IN A 212.201.49.38 Could it be related to the special port (5000) you’re using?
On 23 May 2016 at 14:32:59, Nico CARTRON (nicolas@ncartron.org) wrote: On 23 May 2016 at 14:24:55, Jen Linkova (furry13@gmail.com) wrote: On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON <nicolas@ncartron.org> wrote:
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 DTAG). 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 :-) Nice job, congratulations. Out of curiosity, I tried accessing it from the NAT64 Wifi network at RIPE72, and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some reason. Thoughts?
1) Does it work from the dual-stacked network? Yes it does. I'm seeing significant packet loss on wireless right now, on both dual-stacked and v6-only network, so it might the reason Possibly. 2) how exactly does it fail? DNS resolution/connection timeout? Nope, DNS resolution works fine: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2934 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;dragon.eecs.jacobs-university.de. IN A ;; ANSWER SECTION: dragon.eecs.jacobs-university.de. 277 IN A 212.201.49.38 My mistake, with AAA it’s better: ;; QUESTION SECTION: ;dragon.eecs.jacobs-university.de. IN AAAA ;; ANSWER SECTION: dragon.eecs.jacobs-university.de. 107 IN AAAA 2001:638:709:3000::3a Could it be related to the special port (5000) you’re using? I confirm what Jen said, there’s noting listening on 5000 over IPv6.
On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON <nicolas@ncartron.org> wrote:
Out of curiosity, I tried accessing it from the NAT64 Wifi network at RIPE72, and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some reason. Thoughts?
furry@Wintermute:~>dig dragon.eecs.jacobs-university.de aaaa +short 2001:638:709:3000::3a furry@Wintermute:~>telnet -6 dragon.eecs.jacobs-university.de 5000 Trying 2001:638:709:3000::3a... telnet: connect to address 2001:638:709:3000::3a: Connection refused telnet: Unable to connect to remote host That host does have IPv6 address in DNS (so no NAT64 is involved) but nothing is listening on tcp/5000 on that IPv6 address. -- SY, Jen Linkova aka Furry
On Mon, May 23, 2016 at 2:29 PM, Jen Linkova <furry13@gmail.com> wrote:
On Mon, May 23, 2016 at 2:15 PM, Nico CARTRON <nicolas@ncartron.org> wrote:
Out of curiosity, I tried accessing it from the NAT64 Wifi network at RIPE72, and http://dragon.eecs.jacobs-university.de:5000 seems not to work for some reason. Thoughts?
furry@Wintermute:~>dig dragon.eecs.jacobs-university.de aaaa +short 2001:638:709:3000::3a furry@Wintermute:~>telnet -6 dragon.eecs.jacobs-university.de 5000 Trying 2001:638:709:3000::3a... telnet: connect to address 2001:638:709:3000::3a: Connection refused telnet: Unable to connect to remote host
That host does have IPv6 address in DNS (so no NAT64 is involved) but nothing is listening on tcp/5000 on that IPv6 address.
...or there is a firewall on the path blocking connections and sending RST back... -- SY, Jen Linkova aka Furry
On 23 May 2016, at 14:29, Jen Linkova <furry13@gmail.com> wrote:
furry@Wintermute:~>dig dragon.eecs.jacobs-university.de aaaa +short 2001:638:709:3000::3a furry@Wintermute:~>telnet -6 dragon.eecs.jacobs-university.de 5000 Trying 2001:638:709:3000::3a... telnet: connect to address 2001:638:709:3000::3a: Connection refused telnet: Unable to connect to remote host
That host does have IPv6 address in DNS (so no NAT64 is involved) but nothing is listening on tcp/5000 on that IPv6 address.
Fixed. Now it’s listening on both v4 and v6.
-- SY, Jen Linkova aka Furry
Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================
On 23 May 2016 at 14:40:00, Bajpai, Vaibhav (v.bajpai@jacobs-university.de) wrote:
On 23 May 2016, at 14:29, Jen Linkova <furry13@gmail.com> wrote: furry@Wintermute:~>dig dragon.eecs.jacobs-university.de aaaa +short 2001:638:709:3000::3a furry@Wintermute:~>telnet -6 dragon.eecs.jacobs-university.de 5000 Trying 2001:638:709:3000::3a... telnet: connect to address 2001:638:709:3000::3a: Connection refused telnet: Unable to connect to remote host That host does have IPv6 address in DNS (so no NAT64 is involved) but nothing is listening on tcp/5000 on that IPv6 address.
Fixed. Now it’s listening on both v4 and v6. And works perfectly now, thanks! -- Nico
participants (6)
-
Bajpai, Vaibhav -
Jen Linkova -
Nico CARTRON -
Philip Homburg -
Tore Anderson -
Vaibhav Bajpai