From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3B17D3CB39 for ; Fri, 1 May 2020 17:37:47 -0400 (EDT) Received: by mail-il1-x12f.google.com with SMTP id w6so5691200ilg.1 for ; Fri, 01 May 2020 14:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AUqe/6cKTVMhFmKvfCYtchvuJ6ej7FdefGRGErYQZYA=; b=AoOw7EKE/cXeQEdugzN9JFgI/IDscKIH4nIvlY5wicCDijdNvYgMv3ILj1NM1ANK7Y 0tyWqkv757rocSspmRJ4zjtwujsMJxiYPceRufsO0MgFThBJG11NCTjO0ADH4ZK5DsCX RDU/4+sUWJsZMXStBMvP2prPsUW4K7lYs9jtY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AUqe/6cKTVMhFmKvfCYtchvuJ6ej7FdefGRGErYQZYA=; b=NKi4l8KOl7XHPHcUiLaNT5+rwDqDhcMSktVvVmnpPkn2MD9Ia2bQI9mvQRszDzsSCU bcGDYfPdCkHt09HR9t+ZwdAMtCnh2NE8md9PmVwn4P8LIBW533w1rnW9uap6JL77j8Vb PisU/Pvuo6GHC5zOKmtf7wEAW9fCqwL8BswNcr1TPRsb4jDzcLKUq8DwJqwO8SP/pEjA TByW6n1yGJNEetM5ldD31bbKLUoH4npHIvS0P05IWcEPJjx/LhepIBB9Wcvsn3pTzWIT 5MH+j8/ejKfhZAxgYPVCG4ucaDftVs9XkTRchBkpgFlFd1OAppkqYQFiBSdMXhfsQ+IF xASA== X-Gm-Message-State: AGi0PuY9ro5zF/icOEL0YH2Eb376Pc1TeTUMck4zQDuWfQtsym3gY/ah HE84MoX5ZmpU2WD/6DBnms4fff2wyMh0x5Kp9JGcOQ== X-Google-Smtp-Source: APiQypISsIbHBnqkS18K9jfKwtHal1F7X2praA60XKWShMkJ1+QZ7Fcd6yKhALflz5pAJaDyL+PC2cTgI8UZzJ4NAk8= X-Received: by 2002:a05:6e02:60a:: with SMTP id t10mr5681889ils.302.1588369066575; Fri, 01 May 2020 14:37:46 -0700 (PDT) MIME-Version: 1.0 References: <05410663-5E50-4CF5-8ADE-3BBB985E32B1@gmx.de> <8F8579BB-3B58-4E20-8827-3F09506E0D74@gmx.de> In-Reply-To: <8F8579BB-3B58-4E20-8827-3F09506E0D74@gmx.de> From: Sergey Fedorov Date: Fri, 1 May 2020 14:37:10 -0700 Message-ID: Subject: Re: [Bloat] [Cake] dslreports is no longer free To: Sebastian Moeller Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , Cake List , Make-Wifi-fast , cerowrt-devel , bloat Content-Type: multipart/alternative; boundary="000000000000fc8a1305a49cfd52" X-List-Received-Date: Fri, 01 May 2020 21:37:47 -0000 --000000000000fc8a1305a49cfd52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the kind words, Sebastian! +1; for normal users that is already bliss. For de-bloating a link however > a bit more time resolution generally makes things a bit easier to reason > about ;) Apologies, I misunderstood your original statement. I interpreted it as a vote to keep a single bufferbloat metric (vs loaded/unloaded latency). Agreed on time resolution and its value. No question it's useful for diagnostics. Open question is to what extent browser-based tools should be used for detailed troubleshooting (due to sandboxing limitations), and when is the time for the big guns (like flent) to enter the scene. I like to talk about the latency-under-load-increase when helping people > to debloat their links, but that also is a tad on the long side. Fully agree on length, don't like the verboseness as well. Still looking for a term that is shorter and yet generic enough that I can explain to my mom. Ah, I might have tried too hard at understatement, this was the only > back-end worth mentioning in the "pros" section... Got it. The breitbandmessung case is indeed interesting. SERGEY FEDOROV Director of Engineering sfedorov@netflix.com 121 Albright Way | Los Gatos, CA 95032 On Fri, May 1, 2020 at 2:11 PM Sebastian Moeller wrote: > Hi Sergey, > > > > > On May 1, 2020, at 22:09, Sergey Fedorov wrote: > > > > Great review, Sebastian! > > > > NETFLIX: fast.com. > > Pros: allows selection of upload testing, supposedly decent > back-end, duration configurable > > allows unloaded, loaded download and loaded upload RTT > measurements (but reports sinlge numbers for loaded and unloaded RTT, tha= t > are not the max) > > Cons: RTT report as two numbers one for the loaded and one for > unloaded RTT, time-course of RTTs missing > > BUFFERBLOAT verdict: incomplete, but oh, so close... > > Just a note that I have a plan to separate the loaded latency into > upload/download. It's not great UX now they way it's implemented. > > Great! I really appreciate the way fast.com evolves carefully to > not confuse the intended users and to stay true to its core mission while > it still gaining additional features that are not directly part of Netfli= x > business case to operate that test in the first place. Don't get me wrong= , > I absolutely love that I can easily understand why you should be interest= ed > in getting reliable robust speedtests from all existing or potential > customers to your back-end; and unlike an ISP's internal speedtest, you a= re > not likely to sugar coat things ;) as your goal and the end-user's goal a= re > fully aligned. > > > The timeline view is a bit more nuanced, in the spirit of the simplisti= c > UX, but I've been thinking on a good way to show that for super users as > well. > > Great again! I see the beauty of keeping things simple while mayb= e > hiding optional information behind an additional "click". > > > Two latency numbers - that's more user friendly, we want the general > user to understand the meaning. > > +1; for normal users that is already bliss. For de-bloating a lin= k > however a bit more time resolution generally makes things a bit easier to > reason about ;) > > > And latency under load is much easier than bufferbloat. > > +1; as far as I can tell that term sort of was a decent > description of the observed phenomenon that then got a life of its own; i= n > retrospect it was not the most self explanatory term. I like to talk abou= t > the latency-under-load-increase when helping people to debloat their link= s, > but that also is a tad on the long side. > > > > > As a side note, if our backend is decent, I'm curious what are the > backends for the speed tests that exist that are great :) > > Ah, I might have tried too hard at understatement, this was the > only back-end worth mentioning in the "pros" section... > (well, I also like how breitbandmessung.de deals with their purposefully > limited backend (all located in a single" data center in Germany located = in > an AS that is not directly owned by any ISP, it's the german regulators > official speedtest for germany against which we can effectively measure a= nd > get an early exit from contracts if the ISPs can not deliver the contract= ed > rates (with a bit of slack))) > > Best Regards > Sebastian > > > > > SERGEY FEDOROV > > Director of Engineering > > sfedorov@netflix.com > > 121 Albright Way | Los Gatos, CA 95032 > > > > > > > > On Fri, May 1, 2020 at 12:48 PM Sebastian Moeller > wrote: > > Hi Dave, > > > > well, it was a free service and it lasted a long time. I want to raise = a > toast to Justin and convey my sincere thanks for years of investing into > the "good" of the internet. > > > > Now, the question is which test is going to be the rightful successor? > > > > Short of running netperf/irtt/iper2/iperf3 on a hosted server, I see > lots of potential but none of the tests are really there yet (grievances = in > now particular order): > > > > OOKLA: speedtest.net. > > Pros: ubiquitious, allows selection of single flow versus > multi-flow test, allows server selection > > Cons: only IPv4, only static unloaded RTT measurement, no > control over measurement duration > > BUFFERBLOAT verdict: incomplete, maybe usable as load generator > > > > > > NETFLIX: fast.com. > > Pros: allows selection of upload testing, supposedly decent > back-end, duration configurable > > allows unloaded, loaded download and loaded upload RTT > measurements (but reports sinlge numbers for loaded and unloaded RTT, tha= t > are not the max) > > Cons: RTT report as two numbers one for the loaded and one for > unloaded RTT, time-course of RTTs missing > > BUFFERBLOAT verdict: incomplete, but oh, so close... > > > > > > NPERF: nperf.com > > Pros: allows server selection, RTT measurement and report as > time course, also reports average rates and static RTT/jitter for Up- and > Download > > Cons: RTT measurement for unloaded only, reported RTT static > only , no control over measurement duration > > BUFFERBLOAT verdict: incomplete, > > > > > > THINKBROADBAND: www.thinkbroadband.com/speedtest > > Pros: IPv6, reports coarse RTT time courses for all three > measurement phases > > Cons: only static unloaded RTT report in final results, time > courses only visible immediately after testing, no control over measureme= nt > duration > > BUFFERBLOAT verdict: a bit coarse, might work for users within = a > reasonable distance to the UK for acute de-bloating sessions (history > reporting is bad though) > > > > > > honorable mentioning: > > BREITBANDMESSUNG: breitbandmessung.de > > Pros: query of contracted internet access speed before > measurement, with a scheduler that will only start a test when the backen= d > has sufficient capacity to saturate the user-supplied contracted rates, > IPv6 (happy-eyeballs) > > Cons: only static unloaded RTT measurement, no control over > measurement duration > > BUFFERBLOAT verdict: unsuitable, exceot as load generator, but > the bandwidth reservation feature is quite nice. > > > > Best Regards > > Sebastian > > > > > > > On May 1, 2020, at 18:44, Dave Taht wrote: > > > > > > > https://www.reddit.com/r/HomeNetworking/comments/gbd6g0/dsl_reports_speed= _test_no_longer_free/ > > > > > > They ran out of bandwidth. > > > > > > Message to users here: > > > > > > http://www.dslreports.com/speedtest > > > > > > > > > -- > > > Make Music, Not War > > > > > > Dave T=C3=A4ht > > > CTO, TekLibre, LLC > > > http://www.teklibre.com > > > Tel: 1-831-435-0729 > > > _______________________________________________ > > > Cake mailing list > > > Cake@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/cake > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > --000000000000fc8a1305a49cfd52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the kind words, Sebastian!

=C2=A0+1; for normal users that= is already bliss. For de-bloating a link however a bit more time resolutio= n generally makes things a bit easier to reason about ;)
A= pologies, I misunderstood your original statement. I interpreted it as a vo= te to keep a single bufferbloat metric (vs loaded/unloaded latency).
<= div>Agreed on time resolution and its value. No question it's useful fo= r diagnostics. Open question is to what extent browser-based tools should b= e used for detailed troubleshooting (due to sandboxing limitations), and wh= en is the time for the big guns (like flent) to enter the scene.
=
=C2=A0I like to= talk about the latency-under-load-increase when helping people to debloat = their links, but that also is a tad on the long side.
Full= y agree on length, don't like the verboseness as well. Still looking fo= r a term that is shorter and yet generic enough that I can explain to my mo= m.=C2=A0

Ah, I might have tried too hard at understatement, this was the only ba= ck-end worth mentioning in the "pros" section...
Got it. The=C2=A0breitbandmessung case is indeed interesting.

SERGEY FEDOROV

Director of Engineering

sfedorov@netflix.com=

121 Albright Way | Los Gatos, CA 95032




On Fri, May 1, 2020 at 2:11 PM Sebastian Moeller <moeller0@gmx.de> wrote:
Hi Sergey,



> On May 1, 2020, at 22:09, Sergey Fedorov <sfedorov@netflix.com> wrote:
>
> Great review, Sebastian!
>=C2=A0
> NETFLIX: fast.com.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: allows selection of upload test= ing, supposedly decent back-end, duration configurable
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allows un= loaded, loaded download and loaded upload RTT measurements (but reports sin= lge numbers for loaded and unloaded RTT, that are not the max)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cons: RTT report as two numbers one f= or the loaded and one for unloaded RTT, time-course of RTTs missing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BUFFERBLOAT verdict: incomplete, but = oh, so close...
> Just a note that I have a plan to separate the loaded latency into upl= oad/download. It's not great UX now they way it's implemented.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Great! I really appreciate the way fast.com evolves c= arefully to not confuse the intended users and to stay true to its core mis= sion while it still gaining additional features that are not directly part = of Netflix business case to operate that test in the first place. Don't= get me wrong, I absolutely love that I can easily understand why you shoul= d be interested in getting reliable robust speedtests from all existing or = potential customers to your back-end; and unlike an ISP's internal spee= dtest, you are not likely to sugar coat things ;) as your goal and the end-= user's goal are fully aligned.

> The timeline view is a bit more nuanced, in the spirit of the simplist= ic UX, but I've been thinking on a good way to show that for super user= s as well.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Great again! I see the beauty of keeping things= simple while maybe hiding optional information behind an additional "= click".

> Two latency numbers - that's more user friendly, we want the gener= al user to understand the meaning.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 +1; for normal users that is already bliss. For= de-bloating a link however a bit more time resolution generally makes thin= gs a bit easier to reason about ;)

> And latency under load is much easier than bufferbloat.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 +1; as far as I can tell that term sort of was = a decent description of the observed phenomenon that then got a life of its= own; in retrospect it was not the most self explanatory term. I like to ta= lk about the latency-under-load-increase when helping people to debloat the= ir links, but that also is a tad on the long side.

>
> As a side note, if our backend is decent, I'm curious what are the= backends for the speed tests that exist that are great :)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ah, I might have tried too hard at understateme= nt, this was the only back-end worth mentioning in the "pros" sec= tion...
(well, I also like how breitbandmessung.de deals with their purposeful= ly limited backend (all located in a single" data center in Germany lo= cated in an AS that is not directly owned by any ISP, it's the german r= egulators official speedtest for germany against which we can effectively m= easure and get an early exit from contracts if the ISPs can not deliver the= contracted rates (with a bit of slack)))

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian

>=C2=A0
> SERGEY FEDOROV
> Director of Engineering
> sfedorov@net= flix.com
> 121 Albright Way=C2=A0 |=C2=A0 Los Gatos, CA 95032
>
>
>
> On Fri, May 1, 2020 at 12:48 PM Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> well, it was a free service and it lasted a long time. I want to raise= a toast to Justin and convey my sincere thanks for years of investing into= the "good" of the internet.
>
> Now, the question is which test is going to be the rightful successor?=
>
> Short of running netperf/irtt/iper2/iperf3 on a hosted server, I see l= ots of potential but none of the tests are really there yet (grievances in = now particular order):
>
> OOKLA: speedtest.net.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: ubiquitious, allows selection o= f single flow versus multi-flow test, allows server selection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cons: only IPv4, only static unloaded= RTT measurement, no control over measurement duration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BUFFERBLOAT verdict: incomplete, mayb= e usable as load generator
>
>
> NETFLIX: fast.com.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: allows selection of upload test= ing, supposedly decent back-end, duration configurable
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allows un= loaded, loaded download and loaded upload RTT measurements (but reports sin= lge numbers for loaded and unloaded RTT, that are not the max)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cons: RTT report as two numbers one f= or the loaded and one for unloaded RTT, time-course of RTTs missing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BUFFERBLOAT verdict: incomplete, but = oh, so close...
>
>
> NPERF: nperf.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: allows server selection, RTT me= asurement and report as time course, also reports average rates and static = RTT/jitter for Up- and Download
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cons: RTT measurement for unloaded on= ly, reported RTT static only , no control over measurement duration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BUFFERBLOAT verdict: incomplete,
>
>
> THINKBROADBAND: www.thinkbroadband.com/speedtest
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: IPv6, reports coarse RTT time c= ourses for all three measurement phases
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cons: only static unloaded RTT report= in final results, time courses only visible immediately after testing, no = control over measurement duration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BUFFERBLOAT verdict: a bit coarse, mi= ght work for users within a reasonable distance to the UK for acute de-bloa= ting sessions (history reporting is bad though)
>
>
> honorable mentioning:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BREITBANDMESSUNG: breitbandmessung.d= e
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pros: query of contracted internet ac= cess speed before measurement, with a scheduler that will only start a test= when the backend has sufficient capacity to saturate the user-supplied con= tracted rates, IPv6 (happy-eyeballs)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cons: only static unloaded RTT measur= ement, no control over measurement duration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BUFFERBLOAT verdict: unsuitable, exce= ot as load generator, but the bandwidth reservation feature is quite nice.<= br> >
> Best Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian
>
>
> > On May 1, 2020, at 18:44, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > https://www.reddit.com/r/HomeNetworking/comments/gbd6g0/dsl_reports_spe= ed_test_no_longer_free/
> >
> > They ran out of bandwidth.
> >
> > Message to users here:
> >
> > http://www.dslreports.com/speedtest
> >
> >
> > --
> > Make Music, Not War
> >
> > Dave T=C3=A4ht
> > CTO, TekLibre, LLC
> > http://www.teklibre.com
> > Tel: 1-831-435-0729
> > _______________________________________________
> > Cake mailing list
> > C= ake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake=
>
> _______________________________________________
> Bloat mailing list
> Bloat= @lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--000000000000fc8a1305a49cfd52--