Re: [Bloat] [Cake] dslreports is no longer free

[Sergey Fedorov <sfedorov@netflix.com>]

[-- Attachment #1: Type: text/plain, Size: 8302 bytes --]

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 <moeller0@gmx.de> wrote:

> Hi Sergey,
>
>
>
> > On May 1, 2020, at 22:09, Sergey Fedorov <sfedorov@netflix.com> 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, that
> 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 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 should be interested
> in getting reliable robust speedtests from all existing or potential
> customers to your back-end; and unlike an ISP's internal speedtest, 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 simplistic
> 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 maybe
> 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 link
> 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; in
> retrospect it was not the most self explanatory term. 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.
>
> >
> > 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 and
> get an early exit from contracts if the ISPs can not deliver the contracted
> 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 <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
> 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, that
> 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 measurement
> 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 backend
> 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 <dave.taht@gmail.com> 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äht
> > > 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
>
>

[-- Attachment #2: Type: text/html, Size: 12423 bytes --]