From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2F6CF3B2A4; Sat, 2 May 2020 16:20:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588450801; bh=59FPaJ6WZioP8WJG2BpD5UDo/gnHsuDLBlyIIiIG7NY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=NkEKmgPMeX4kmDEgqGLhrlU8tHK9tKm7m/cBK85+LcQGcHdZLb4zsnFG3ozogPKsv th7nrnXmmbevnLwtjADtcg8G66vo8qHjfUvW6CJIPDh+qwfEbpGW/etiqqTaELMgEV PlNAHnFfDovuid+Jcb/DoiicCxCpOwROZL8OnZ6A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.42.222] ([77.8.225.157]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MpDJX-1ioErn4BB9-00qlvu; Sat, 02 May 2020 22:20:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller X-Priority: 3 (Normal) In-Reply-To: <1588441128.39172345@apps.rackspace.com> Date: Sat, 2 May 2020 22:19:57 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Michael Richardson , Make-Wifi-fast , Jannie Hanekom , Cake List , Sergey Fedorov , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <216F9474-51C1-40F2-BF1A-230B6A85D3DA@gmx.de> References: <05410663-5E50-4CF5-8ADE-3BBB985E32B1@gmx.de> <24457.1588370840@localhost> <013601d6201f$04c7db50$0e5791f0$@hanekom.net> <1588441128.39172345@apps.rackspace.com> To: "David P. Reed" X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:cTNAKODOhGOUlPvPAJfexEMpoFkSv+N//MBoYeYIjuVDbYanseD u1pYq73PHHo4cBTkXJiDDPxmD9YghQ2gzkdOqlZOR0mlOPPJ87y12okiEOuEJAJG9tOxUTC CtdDKzi4xgUvAOVKHXBg8Llw5a3Lj9dtCp/h1RVlJ2fMrXRkMDx5WczISU1b/Px9TvovZgn Kv5sk5eMWL18tjNk8NPzw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:8NYazXDfevk=:RNheFd+n9usOo/pAAFRiH6 Sn5qTVpD/gpVp+fPTSkUpxGnDtbnZNN/dsH7L1BoD3kp8b/4MD8WNIdVWyAPxCgEHlI/TjHod VIV/kF2Ra0aOoBrHXROJ+9KYXKBdCFMWNESwlIu4gzW8tyh2INp7KnMXiasHUaUH0QlsQZvvr d7VJevjtkIimziJqGQLS92YkEzs/Lju6gZCilfzV/u5mkfgoFpP3q9pk3Fxq3m31Poklewap7 jvGFwMIQBqp5R325Jhulm3FzOpKSVRPQee/zxf1XL7lYkWefP3wfE3pX0lxYZEXCWDjoLweg8 +64vRi2IYbSx/LrtR85IROeX/IhVD5yaMXaLaSPLCan3khnC0AVuE6Tr93G+w1kQLW2GZ3TcX y8zukfO1D4FMGF5drq1NcojcCPhh+BX4Z82ry5FhLKby6v3i0inGh2JIsY9D/11oK1JkdVl2K XoaJhiDTBQq1CKd/dtVM0Phj1Thgqq6MfkYQV8HhoBJbJ2NPZpCYHJk6eIMx00zMM4lnnBgBm pxdruxm3ogUNRDKoa2np+SWNyKnDD3o7yLez7S3p229e2IV9Ceuy8YlObWOxr+v0MA8AvkCs1 javo70/L9TZFsa+Eg2w0g6VOkT8Zg4LrHSL115sLEwHqBAEVwPDVRxhjHkSkpHEYdewpAqL5Q cXeJpWtsCzyb8md/8C33/g5F8z3hLshEytY9V67s3o6vdboF+c3ldPttp8h0sFA1FEjoo+/g4 68hKunwIQD/gpweCMYUZTQadAHxYSkf+ps//OvE9RXXQ4UPvVmXnIKp4Z0W32aP3qNHHJNUNH 3SFEnBBxI77ES595oDPv9h4BCTYLjjQnOTryHwaygLC8j3Rbe4FwUXcTFLcL7/qVO9NSt8zf6 CJfuWi3K/34FPuB/gCpNKkGnbw0Y/BUM3lsInCizJ+HO5Z1E81UFekBw6oMz+sLdobuQWF0AI I/Cor3f+czecQ5gaR1emzDG2VQgULOu6tgadFRkmpo01WGEY7YkSZ42R1k9VlXJYe14kzhR6K Mz70MrRPPdo1fr94II0niNpOKJhjBE88STFx4G2bmxUTnv7eNJ6T/jdQTvOMaoXyBe/AkZSbZ zYit/9v5mijAA2ANGiIsDKT9r+Uak44UWHnhj0xZhVkVrmEH5WPdVDhpo7j1uX8T+WQeyvemv U627Frd9zWEhX2BswGlgFumXPO3JcC5HDM/hWZl0hiGzNaL7EnmGeDGnjBJGvNWjbN1POEGW9 xfTjCiJunqr6hBkws Subject: Re: [Make-wifi-fast] [Cake] [Bloat] dslreports is no longer free X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 20:20:12 -0000 Hi David, in principle I agree, a NATed IPv4 ICMP probe will be at best reflected = at the NAT router (CPE) (some commercial home gateways do not respond = to ICMP echo requests in the name of security theatre). So it is pretty = hard to measure the full end to end path in that configuration. I = believe that IPv6 should make that easier/simpler in that NAT hopefully = will be out of the path (but let's see what ingenuity ISPs will come up = with). Then again, traditionally the relevant bottlenecks often are a) the = internet access link itself and there the CPE is in a reasonable = position as a reflector on the other side of the bottleneck as seen from = an internet server, b) the home network between CPE and end-host, often = with variable rate wifi, here I agree reflecting echos at the CPE hides = part of the issue. > On May 2, 2020, at 19:38, David P. Reed wrote: >=20 > I am still a bit worried 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 access provider's router/switch, it = will NOT measure congestion caused by bufferbloat reliably on either = side, since the bufferbloat will be outside the ICMP Ping path. Puzzled, as i believe it is going to be the residential box that = will respond here, or will it be the AFTRs for CG-NAT that reflect the = ICMP echo requests? > =20 > 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 packet basis. However, there are ways to solve this and avoid the = ICMP Ping issue, with a cooperative server. > =20 > I once built a test that fixed this issue reasonably well. It = carefully created a TCP based RTT measurement channel (over HTTP) that = made the echo 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 client end of an unloaded TCP connection can depend on = TCP (properly prepared by getting it past slowstart) to generate a = single packet response. > =20 > This "TCP ping" is thus compatible with getting the end-to-end = measurement on the server end of a true RTT. > =20 > 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. > =20 > The same issue comes up with non-browser-based techniques for = measuring true lag-under-load. > =20 > Now as we move HTTP to QUIC, this actually gets easier to do. > =20 > One 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 detailed testing in the browser quite reasonable. > =20 > And the time measurements can resolve well below 100 microseconds, if = the JS is based on modern JIT compilation (Chrome, Firefox, 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 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. Mmmh, according to https://github.com/w3c/hr-time/issues/56 due = to spectre side-channel vulnerabilities many browsers seemed to have = lowered the timer resolution, but even the ~1ms resolution should be = fine for typical RTTs. Best Regards Sebastian P.S.: I assume that I simply do not see/understand the full scope of the = issue at hand yet. > =20 > On Saturday, May 2, 2020 12:52pm, "Dave Taht" = said: >=20 > > On Sat, May 2, 2020 at 9:37 AM Benjamin Cronce = wrote: > > > > > > > Fast.com reports my unloaded latency as 4ms, my loaded latency = as ~7ms > >=20 > > 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... that > > excludes much of the current side of the internet. > >=20 > > > For download, I show 6ms unloaded and 6-7 loaded. But for upload = the loaded > > shows as 7-8 and I see it blip upwards of 12ms. But I am no longer = using any > > traffic shaping. Any anti-bufferbloat is from my ISP. A graph of the = bloat would > > be nice. > >=20 > > The tests do need to last a fairly long time. > >=20 > > > On Sat, May 2, 2020 at 9:51 AM Jannie Hanekom > > wrote: > > >> > > >> Michael Richardson : > > >> > Does it find/use my nearest Netflix cache? > > >> > > >> Thankfully, it appears so. The DSLReports bloat test was = interesting, > > but > > >> the jitter on the ~240ms base latency from South Africa (and = other parts > > of > > >> the world) was significant enough that the figures returned were = often > > >> unreliable and largely unusable - at least in my experience. > > >> > > >> Fast.com reports my unloaded latency as 4ms, my loaded latency as = ~7ms > > and > > >> mentions servers located in local cities. I finally have a test I = can > > share > > >> with local non-technical people! > > >> > > >> (Agreed, upload test would be nice, but this is a huge step = forward from > > >> what I had access to before.) > > >> > > >> Jannie Hanekom > > >> > > >> _______________________________________________ > > >> Cake mailing list > > >> Cake@lists.bufferbloat.net > > >> https://lists.bufferbloat.net/listinfo/cake > > > > > > _______________________________________________ > > > Cake mailing list > > > Cake@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/cake > >=20 > >=20 > >=20 > > -- > > Make Music, Not War > >=20 > > 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 > >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake