Mailing List Archive

Very nice. I wonder why www.facebook.com shows much better IPv4 latency?

On Mon, May 23, 2016 at 11:30 PM, Bajpai, Vaibhav <
v.bajpai@jacobs-university.de> wrote:

> Dear v6-ops,
>
> 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 :-)
>
> Feedback most welcome!
>
> Best, Vaibhav
>
> ===================================
> Vaibhav Bajpai
> www.vaibhavbajpai.com
>
> Room 91, Research I
> School of Engineering and Sciences
> Jacobs University Bremen, Germany
> ===================================
>

> On May 23, 2016, at 8:16 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> Very nice. I wonder why www.facebook.com <http://www.facebook.com/> shows much better IPv4 latency?

First guess is something about data center location. IPv6 works well for them on the UA west coast and measurement points in Australia and SE Asia, but IPv4 is better in Europe and the US east coast. Now look at LinkedIn.

> On Mon, May 23, 2016 at 11:30 PM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de <mailto:v.bajpai@jacobs-university.de>> wrote:
> Dear v6-ops,
>
> 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 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 :-)
>
> Feedback most welcome!
>
> Best, Vaibhav
>
> ===================================
> Vaibhav Bajpai
> www.vaibhavbajpai.com <http://www.vaibhavbajpai.com/>
>
> Room 91, Research I
> School of Engineering and Sciences
> Jacobs University Bremen, Germany
> ===================================
>

> On 23 May 2016, at 22:44, Fred Baker (fred) <fred@cisco.com> wrote:
>
>> On May 23, 2016, at 8:16 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>>
>> Very nice. I wonder why www.facebook.com shows much better IPv4 latency?
>
> First guess is something about data center location. IPv6 works well for them
> on the UA west coast and measurement points in Australia and SE Asia, but IPv4
> is better in Europe and the US east coast. Now look at LinkedIn.

Let me stress this again. This is a toy! Not only because the web
interface is crappy, but also because the dataset is miniscule.
Although the dataset has a very good coverage of dual-stacked
vantage points, the sample size is very small (1 sample / probe).
This provides a very small peak into the performance of a website.

As you know, I have been doing long-term v6 performance measurements
from (although a smaller set of) 80 SamKnows probes. The 3-year
long trend shows that performance towards www.facebook.com has
dramatically improved over time. Using this sample (as of today),
I don’t see www.facebook.com to be slower over IPv6.

I created this toy to show that RIPE Atlas can be used to provide
such a service. I decided to showcase to you because I wanted to
learn if there is interest in having such a service.

With the amount of positive feedback I have received in a single
day, I’ll be happy to spend cycles to run this measurement for
a longer duration. This will require also blessing from the RIPE NCC
because the project will cross all sorts of rate thresholds :-)

With permission from RIPE NCC, let me run this every hour from all
probes for at least a week and then we should look at the results.
At this point, just play with it, but please don’t use it to declare
any website faster or slower.

Best, Vaibhav


>> On Mon, May 23, 2016 at 11:30 PM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> wrote:
>> Dear v6-ops,
>>
>> 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 :-)
>>
>> Feedback most welcome!
>>
>> Best, Vaibhav

===================================
Vaibhav Bajpai
www.vaibhavbajpai.com

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

Vaibhav,

> On May 24, 2016, at 3:51 AM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> wrote:
> Let me stress this again. This is a toy! Not only because the web
> interface is crappy, but also because the dataset is miniscule.
> Although the dataset has a very good coverage of dual-stacked
> vantage points, the sample size is very small (1 sample / probe).
> This provides a very small peak into the performance of a website.

Welcome to the “if it links, ship it” aspect of releasing tools
on the internet.

> As you know, I have been doing long-term v6 performance measurements
> from (although a smaller set of) 80 SamKnows probes. The 3-year
> long trend shows that performance towards www.facebook.com has
> dramatically improved over time. Using this sample (as of today),
> I don’t see www.facebook.com to be slower over IPv6.
>
> I created this toy to show that RIPE Atlas can be used to provide
> such a service. I decided to showcase to you because I wanted to
> learn if there is interest in having such a service.
>
> With the amount of positive feedback I have received in a single
> day, I’ll be happy to spend cycles to run this measurement for
> a longer duration. This will require also blessing from the RIPE NCC
> because the project will cross all sorts of rate thresholds :-)

I’m happy to support you on the atlas lists and such. Will you be
presenting at the MAT WG as well this week?

> With permission from RIPE NCC, let me run this every hour from all
> probes for at least a week and then we should look at the results.
> At this point, just play with it, but please don’t use it to declare
> any website faster or slower.

I’ve sent you some credits to get you started on some longer term
measurements. I’d be interested in finding some way to filter out
things like google.com vs google.co.uk etc as you are likely measuring
the same sites and hosts.

- Jared

> On 24 May 2016, at 09:56, Jared Mauch <jared@puck.nether.net> wrote:
>
> Vaibhav,
>
>> On May 24, 2016, at 3:51 AM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> wrote:
>> Let me stress this again. This is a toy! Not only because the web
>> interface is crappy, but also because the dataset is miniscule.
>> Although the dataset has a very good coverage of dual-stacked
>> vantage points, the sample size is very small (1 sample / probe).
>> This provides a very small peak into the performance of a website.
>
> Welcome to the “if it links, ship it” aspect of releasing tools
> on the internet.
>
>> As you know, I have been doing long-term v6 performance measurements
>> from (although a smaller set of) 80 SamKnows probes. The 3-year
>> long trend shows that performance towards www.facebook.com has
>> dramatically improved over time. Using this sample (as of today),
>> I don’t see www.facebook.com to be slower over IPv6.
>>
>> I created this toy to show that RIPE Atlas can be used to provide
>> such a service. I decided to showcase to you because I wanted to
>> learn if there is interest in having such a service.
>>
>> With the amount of positive feedback I have received in a single
>> day, I’ll be happy to spend cycles to run this measurement for
>> a longer duration. This will require also blessing from the RIPE NCC
>> because the project will cross all sorts of rate thresholds :-)
>
> I’m happy to support you on the atlas lists and such. Will you be
> presenting at the MAT WG as well this week?

Thanks!

Yes: https://ripe72.ripe.net/programme/meeting-plan/mat-wg

>> With permission from RIPE NCC, let me run this every hour from all
>> probes for at least a week and then we should look at the results.
>> At this point, just play with it, but please don’t use it to declare
>> any website faster or slower.
>
> I’ve sent you some credits to get you started on some longer term
> measurements. I’d be interested in finding some way to filter out
> things like google.com vs google.co.uk etc as you are likely measuring
> the same sites and hosts.

Thanks!

Yes, SamKnows measurements show that www.google.* and www.blogspot.*
usually tends to hit the same CDN or a web cache. It should suffice to
run against one member of each set alone.

> - Jared

Best, Vaibhav

===================================
Vaibhav Bajpai
www.vaibhavbajpai.com

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

On May 24, 2016, at 12:56 AM, Jared Mauch <jared@puck.Nether.net> wrote:
> I’ve sent you some credits to get you started on some longer term
> measurements. I’d be interested in finding some way to filter out
> things like google.com vs google.co.uk etc as you are likely measuring
> the same sites and hosts.

I might suggest two steps in selecting targets. When I wonder about such things, I start with either the Alexa or the Quantcast list and "dig" for a AAAA record (or CNAME that has a AAAA record), and ping or curl it. As a next step, what if we add "and has a unique IPv6 address among addresses found so far"?

Dear v6-ops,

> On 23 May 2016, at 16:30, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> 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 3320).

FYI:

In 20 minutes from now, I’ll be giving a talk at RIPE 72
describing how these dual stacked RIPE Atlas vantage points were
selected and what is the region-based and network-based
bias associated with using these vantage points.

It will be live streamed:
https://ripe72.ripe.net/programme/meeting-plan/mat-wg

Best, Vaibhav

> 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 :-)
>
> Feedback most welcome!
>
> Best, Vaibhav

===================================
Vaibhav Bajpai
www.vaibhavbajpai.com

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

> On 25 May 2016, at 13:56, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> wrote:
>
> Dear v6-ops,
>
>> On 23 May 2016, at 16:30, Bajpai, Vaibhav <v.bajpai@jacobs-university.de> 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 3320).
>
> FYI:
>
> In 20 minutes from now, I’ll be giving a talk at RIPE 72
> describing how these dual stacked RIPE Atlas vantage points were
> selected and what is the region-based and network-based
> bias associated with using these vantage points.
>
> It will be live streamed:
> https://ripe72.ripe.net/programme/meeting-plan/mat-wg

Here is the video / slides:
https://ripe72.ripe.net/archives/video/167

Best, Vaibhav

===================================
Vaibhav Bajpai
www.vaibhavbajpai.com

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