From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7DCB83CB37 for ; Sat, 2 May 2020 13:38:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1588441131; bh=v2BH94fM0b6+Q3oThv6ExqKHi7Y8/b0GkgW492TuiFg=; h=Date:Subject:From:To:From; b=gXyFhZvr1Cd7ywRmXng/rvp56e6eZtfMZKR4yGQUCthFpgGOtQD/t+UoHrIpT06sx K5UlQAJdnu0KYoEIdZsyhErpCN2JY4kkOtxu8d53ULC9MklCE12bxAEAqs1Abfpzns cCg1liH1ASsXEgVjZ3rZoAuYVyN0gEGaMGd60CEg= Received: from app46.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1AE2A459B; Sat, 2 May 2020 13:38:51 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app46.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sat, 02 May 2020 13:38:51 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app46.wa-webapps.iad3a (Postfix) with ESMTP id 604D9C0051; Sat, 2 May 2020 13:38:48 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sat, 2 May 2020 13:38:48 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Sat, 2 May 2020 13:38:48 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "Benjamin Cronce" , "Michael Richardson" , "Jannie Hanekom" , "bloat" , "Cake List" , "Sergey Fedorov" , "Make-Wifi-fast" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20200502133848000000_64882" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <05410663-5E50-4CF5-8ADE-3BBB985E32B1@gmx.de> <24457.1588370840@localhost> <013601d6201f$04c7db50$0e5791f0$@hanekom.net> Message-ID: <1588441128.39172345@apps.rackspace.com> X-Mailer: webmail/17.3.10-RC X-Classification-ID: b6309cc5-91d3-4b55-a0dd-8b2a21c027a9-1-1 Subject: Re: [Bloat] [Cake] [Make-wifi-fast] dslreports is no longer free X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 17:38:51 -0000 ------=_20200502133848000000_64882 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI am still a bit worried about properly defining "latency under load" fo= r a NAT routed situation. If the test is based on ICMP Ping packets *from t= he server*, it will NOT be measuring the full path latency, and if the pot= ential congestion is in the uplink path from the access provider's resident= ial box to the access provider's router/switch, it will NOT measure congest= ion caused by bufferbloat reliably on either side, since the bufferbloat wi= ll be outside the ICMP Ping path.=0A =0AI realize that a browser based spee= d test has to be basically run from the "server" end, because browsers are = not that good at time measurement on a packet basis. However, there are way= s to solve this and avoid the ICMP Ping issue, with a cooperative server.= =0A =0AI once built a test that fixed this issue reasonably well. It carefu= lly created a TCP based RTT measurement channel (over HTTP) that made the e= cho have to traverse the whole end-to-end path, which is the best and only = way to accurately define lag under load from the user's perspective. The cl= ient end of an unloaded TCP connection can depend on TCP (properly prepared= by getting it past slowstart) to generate a single packet response.=0A =0A= This "TCP ping" is thus compatible with getting the end-to-end measurement = on the server end of a true RTT.=0A =0AIt's like tcp-traceroute tool, in th= at it tricks anyone in the middle boxes into thinking this is a real, serio= us packet, not an optional low priority packet.=0A =0AThe same issue comes = up with non-browser-based techniques for measuring true lag-under-load.=0A = =0ANow as we move HTTP to QUIC, this actually gets easier to do.=0A =0AOne = other opportunity I haven't explored, but which is pregnant with potential = is the use of WebRTC, which runs over UDP internally. Since JavaScript has = direct access to create WebRTC connections (multiple ones), this makes deta= iled testing in the browser quite reasonable.=0A =0AAnd the time measuremen= ts can resolve well below 100 microseconds, if the JS is based on modern JI= T compilation (Chrome, Firefox, Edge all compile to machine code speed if t= he code is restricted and in a loop). Then again, there is Web Assembly if = you want to write C code that runs in the brower fast. WebAssembly is a low= level language that compiles to machine code in the browser execution, and= still has access to all the browser networking facilities.=0A =0AOn Saturd= ay, May 2, 2020 12:52pm, "Dave Taht" said:=0A=0A=0A= =0A> On Sat, May 2, 2020 at 9:37 AM Benjamin Cronce wro= te:=0A> >=0A> > > Fast.com reports my unloaded latency as 4ms, my loaded la= tency as ~7ms=0A> =0A> I guess one of my questions is that with a switch to= BBR netflix is=0A> going to do pretty well. If fast.com is using bbr, well= ... that=0A> excludes much of the current side of the internet.=0A> =0A> > = For download, I show 6ms unloaded and 6-7 loaded. But for upload the loaded= =0A> shows as 7-8 and I see it blip upwards of 12ms. But I am no longer usi= ng any=0A> traffic shaping. Any anti-bufferbloat is from my ISP. A graph of= the bloat would=0A> be nice.=0A> =0A> The tests do need to last a fairly l= ong time.=0A> =0A> > On Sat, May 2, 2020 at 9:51 AM Jannie Hanekom =0A> wrote:=0A> >>=0A> >> Michael Richardson = :=0A> >> > Does it find/use my nearest Netflix cache?=0A> >>=0A> >> Thankfu= lly, it appears so. The DSLReports bloat test was interesting,=0A> but=0A> = >> the jitter on the ~240ms base latency from South Africa (and other parts= =0A> of=0A> >> the world) was significant enough that the figures returned = were often=0A> >> unreliable and largely unusable - at least in my experien= ce.=0A> >>=0A> >> Fast.com reports my unloaded latency as 4ms, my loaded la= tency as ~7ms=0A> and=0A> >> mentions servers located in local cities. I fi= nally have a test I can=0A> share=0A> >> with local non-technical people!= =0A> >>=0A> >> (Agreed, upload test would be nice, but this is a huge step = forward from=0A> >> what I had access to before.)=0A> >>=0A> >> Jannie Hane= kom=0A> >>=0A> >> _______________________________________________=0A> >> Ca= ke mailing list=0A> >> Cake@lists.bufferbloat.net=0A> >> https://lists.buff= erbloat.net/listinfo/cake=0A> >=0A> > _____________________________________= __________=0A> > Cake mailing list=0A> > Cake@lists.bufferbloat.net=0A> > h= ttps://lists.bufferbloat.net/listinfo/cake=0A> =0A> =0A> =0A> --=0A> Make M= usic, Not War=0A> =0A> Dave T=C3=A4ht=0A> CTO, TekLibre, LLC=0A> http://www= .teklibre.com=0A> Tel: 1-831-435-0729=0A> _________________________________= ______________=0A> Cake mailing list=0A> Cake@lists.bufferbloat.net=0A> htt= ps://lists.bufferbloat.net/listinfo/cake=0A> ------=_20200502133848000000_64882 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am still a bit worri= ed about properly defining "latency under load" for a NAT routed situation.= If the test is based on ICMP Ping packets *from the server*,  it will= NOT be measuring the full path latency, and if the potential congestion is= in the uplink path from the access provider's residential box to the acces= s provider's router/switch, it will NOT measure congestion caused by buffer= bloat reliably on either side, since the bufferbloat will be outside the IC= MP Ping path.

=0A

 

=0A

= I realize that a browser based speed test has to be basically run from the = "server" end, because browsers are not that good at time measurement on a p= acket basis. However, there are ways to solve this and avoid the ICMP Ping = issue, with a cooperative server.

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 12pt; overflow= -wrap: break-word;">I once built a test that fixed this issue reasonably we= ll. It carefully created a TCP based RTT measurement channel (over HTTP) th= at made the echo have to traverse the whole end-to-end path, which is the b= est and only way to accurately define lag under load from the user's perspe= ctive. The client end of an unloaded TCP connection can depend on TCP (prop= erly prepared by getting it past slowstart) to generate a single packet res= ponse.

=0A

 

=0A

This "T= CP ping" is thus compatible with getting the end-to-end measurement on the = server end of a true RTT.

=0A

 

=0A

It's like tcp-traceroute tool, in that it tricks anyone in the= middle boxes into thinking this is a real, serious packet, not an optional= low priority packet.

=0A

 

=0A

The same issue comes up with non-browser-based techniques for measu= ring true lag-under-load.

=0A

 

=0A

Now as we move HTTP to QUIC, this actually gets easier to do.<= /p>=0A

 

=0A

One other oppo= rtunity I haven't explored, but which is pregnant with potential is the use= of WebRTC, which runs over UDP internally. Since JavaScript has direct acc= ess to create WebRTC connections (multiple ones), this makes detailed testi= ng in the browser quite reasonable.

=0A

 

= =0A

And the time measurements can resolve well below 10= 0 microseconds, if the JS is based on modern JIT compilation (Chrome, Firef= ox, Edge all compile to machine code speed if the code is restricted and in= a loop). Then again, there is Web Assembly if you want to write C code tha= t runs in the brower fast. WebAssembly is a low level language that compile= s to machine code in the browser execution, and still has access to all the= browser networking facilities.

=0A

 

=0A

On Saturday, May 2, 2020 12:52pm, "Dave Taht" <dave.ta= ht@gmail.com> said:

=0A
= =0A

> On Sat, May 2, 2020 at 9:37 AM Benjamin Cronce= <bcronce@gmail.com> wrote:
> >
> > > Fast.c= om reports my unloaded latency as 4ms, my loaded latency as ~7ms
> =
> I guess one of my questions is that with a switch to BBR netflix= is
> going to do pretty well. If fast.com is using bbr, well... th= at
> excludes much of the current side of the internet.
> <= br />> > For download, I show 6ms unloaded and 6-7 loaded. But for up= load the loaded
> shows as 7-8 and I see it blip upwards of 12ms. B= ut I am no longer using any
> traffic shaping. Any anti-bufferbloat= is from my ISP. A graph of the bloat would
> be nice.
> > The tests do need to last a fairly long time.
>
>= > On Sat, May 2, 2020 at 9:51 AM Jannie Hanekom <jannie@hanekom.net&= gt;
> wrote:
> >>
> >> Michael Richards= on <mcr@sandelman.ca>:
> >> > Does it find/use my ne= arest Netflix cache?
> >>
> >> Thankfully, it a= ppears so. The DSLReports bloat test was interesting,
> but
&g= t; >> the jitter on the ~240ms base latency from South Africa (and ot= her parts
> of
> >> the world) was significant enough= that the figures returned were often
> >> unreliable and lar= gely unusable - at least in my experience.
> >>
> >= ;> Fast.com reports my unloaded latency as 4ms, my loaded latency as ~7m= s
> and
> >> mentions servers located in local cities= . I finally have a test I can
> share
> >> with local= non-technical people!
> >>
> >> (Agreed, uploa= d test would be nice, but this is a huge step forward from
> >&g= t; what I had access to before.)
> >>
> >> Jann= ie Hanekom
> >>
> >> __________________________= _____________________
> >> Cake mailing list
> >&g= t; Cake@lists.bufferbloat.net
> >> https://lists.bufferbloat.= net/listinfo/cake
> >
> > ___________________________= ____________________
> > Cake mailing list
> > Cake@l= ists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/= cake
>
>
>
> --
> Make Music, No= t 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/li= stinfo/cake
>

=0A
 ------=_20200502133848000000_64882--