Proving Gig Speed

Wed Jul 18 13:48:32 UTC 2018

https://isp.google.com

Thought I think this is only for when you have peering, someone can correct me if that's incorrect.

ns

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of K. Scott Helms
Sent: Wednesday, July 18, 2018 8:45 AM
To: Mike Hammett
Cc: NANOG list
Subject: Re: Proving Gig Speed

Mike,

What portal would that be?  Do you have a URL?

On Wed, Jul 18, 2018 at 9:25 AM Mike Hammett <nanog at ics-il.net> wrote:

> Check your Google portal for more information as to what Google can do
> with BGP Communities related to reporting.
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ----- Original Message -----
>
> From: "K. Scott Helms" <kscott.helms at gmail.com>
> To: "mark tinka" <mark.tinka at seacom.mu>
> Cc: "NANOG list" <nanog at nanog.org>
> Sent: Wednesday, July 18, 2018 7:40:31 AM
> Subject: Re: Proving Gig Speed
>
> Agreed, and it's one of the fundamental problems that a speed test is
> (and can only) measure the speeds from point A to point B (often both
> inside the service provider's network) when the customer is concerned
> with traffic to and from point C off in someone else's network
> altogether. It's one of the reasons that I think we have to get more
> comfortable and more collaborative with the CDN providers as well as
> the large sources of traffic. Netflix, Youtube, and I'm sure others
> have their own consumer facing performance testing that is _much_ more
> applicable to most consumers as compared to the "normal" technician
> test and measurement approach or even the service assurance that you
> get from normal performance monitoring. What I'd really like to see is
> a way to measure network performance from the CO/head end/PoP and also
> get consumer level reporting from these kinds of services. If
> Google/Netflix/Amazon Video/$others would get on board with this idea
> it would make all our lives simpler.
>
> Providing individual users stats is nice, but if these guys really
> want to improve service it would be great to get aggregate reporting
> by ASN. You can get a rough idea by looking at your overall graph from
> Google, but it's lacking a lot of detail and there's no simple way to
> compare that to a head end/CO test versus specific end users.
>
> https://www.google.com/get/videoqualityreport/
> https://fast.com/#
>
>
>
> On Wed, Jul 18, 2018 at 8:27 AM Mark Tinka <mark.tinka at seacom.mu> wrote:
>
> >
> >
> > On 18/Jul/18 14:00, K. Scott Helms wrote:
> >
> >
> > That's absolutely a concern Mark, but most of the CPE vendors that
> support
> > doing this are providing enough juice to keep up with their max
> > forwarding/routing data rates. I don't see 10 Gbps in residential
> Internet
> > service being normal for quite a long time off even if the port
> > itself
> is
> > capable of 10Gbps. We have this issue today with commercial
> > customers,
> but
> > it's generally not as a much of a problem because the commercial CPE
> > get their usage graphed and the commercial CPE have more
> > capabilities for testing.
> >
> >
> > I suppose the point I was trying to make is when does it stop being
> > feasible to test each and every piece of bandwidth you deliver to a
> > customer? It may very well not be 10Gbps... perhaps it's 2Gbps, or
> 3.2Gbps,
> > or 5.1Gbps... basically, the rabbit hole.
> >
> > Like Saku, I am more interested in other fundamental metrics that
> > could impact throughput such as latency, packet loss and jitter.
> > Bandwidth, itself, is easy to measure with your choice of SNMP poller + 5 minutes.
> But
> > when you're trying to explain to a simple customer buying 100Mbps
> > that a break in your Skype video cannot be diagnosed with a
> > throughput speed
> test,
> > they don't/won't get it.
> >
> > In Africa, for example, customers in only one of our markets are so
> > obsessed with speed tests. But not to speed test servers that are
> > in-country... they want to test servers that sit in Europe, North
> America,
> > South America and Asia-Pac. With the latency averaging between 140ms
> > - 400ms across all of those regions from source, the amount of
> > energy
> spent
> > explaining to customers that there is no way you can saturate your
> > delivered capacity beyond a couple of Mbps using Ookla and friends
> > is energy I could spend drinking wine and having a medium-rare
> > steak,
> instead.
> >
> > For us, at least, aside from going on a mass education drive in this
> > particular market, the ultimate solution is just getting all that
> content
> > localized in-country or in-region. Once that latency comes down and
> > the resources are available locally, the whole speed test debacle
> > will
> easily
> > fall away, because the source of these speed tests is simply how
> physically
> > far the content is. Is this an easy task - hell no; but slamming
> > your
> head
> > against a wall over and over is no fun either.
> >
> > Mark.
> >
>
>