From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 0F1043B29D; Sun, 3 May 2020 11:37:55 -0400 (EDT) Received: by mail-il1-x12a.google.com with SMTP id i16so8956811ils.12; Sun, 03 May 2020 08:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dUeh69W8PzT95cF/kN1HLTH2/NNMRlJvNIPzLcO632c=; b=oHEU5oUxH7LR3qooRSiWkcC/e2CWdukrp8Kiw8ZwJn6kUcoRJBK1eY2lbv+vpWcC3D /NjkPrFCFx1oKYggwPQkZGbOj2hvBPlMtw5E44WqshkjV+9TC4+1+9wcT6pBFVDF6xJ3 o+ApVV9/YPMQY2t/9ihhg0AWPj7Aiq5D4uptVy1ia8BT2klK7jGdnX6zztzciJLGqH4a Rq7Jgsa9nm/sHVGIZr3K8ll2SuVyJ522A5voa6xp8fIMNz1SWjAOPE+Nebt63jvtkc3B WYaYQM5E0/G5n7kWQgqLN3Urz1vuekaX1YDnbCBoMs5jA56wVZlLZBNfZ5uc0Py77+fK jnsg== 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:content-transfer-encoding; bh=dUeh69W8PzT95cF/kN1HLTH2/NNMRlJvNIPzLcO632c=; b=mYMwh+MT37Svlg4DqBCzaDbTTClhH7q7lGXRzk6OLE6gOGWzUH4sJ9nTvLt0HE933/ D3CRFXqxr98MCYXlJiy3dvhzoylnXVYLBMAHXG0LmXAPHSaUDXQbROR7dWt3/sYSLXge vf+wztKXQ4vERQW3S55GdkQrq068JUHU+tcNte1/JMgyc7R6jTh0OtxgXiO57ZiOmLun vmrLFI3N0Mxr1iThsLy17XYHJOt2SAEQ71wpQG33av4hF9zE9pHnYjPio/p9txw4kQ01 WlL/eBoKIL1z+MY8S6hOwfV3+VN0yHvEMS++lGy269qrdmAz4UaldqaiFVXfTPLVIACo FfFQ== X-Gm-Message-State: AGi0PuZs/1T6lDPBt3C5THWtlYK4y36HbJf51RN+153otK/9cY8V+Y6X EptvMp6CIrYwEjudYZtLgyym421+/nUe016/Umk= X-Google-Smtp-Source: APiQypLag5QlZ9/jgL0Lcsi10rf8yk016xaEbN6ceGREto9k25gJzzMFw7QT0FmgxWp2OZf+2iwm8eD3JLyQmSILO+M= X-Received: by 2002:a92:c7a9:: with SMTP id f9mr13167881ilk.0.1588520274475; Sun, 03 May 2020 08:37:54 -0700 (PDT) MIME-Version: 1.0 References: <05410663-5E50-4CF5-8ADE-3BBB985E32B1@gmx.de> <24457.1588370840@localhost> <013601d6201f$04c7db50$0e5791f0$@hanekom.net> <1588441128.39172345@apps.rackspace.com> <1588519912.070420298@apps.rackspace.com> In-Reply-To: <1588519912.070420298@apps.rackspace.com> From: Dave Taht Date: Sun, 3 May 2020 08:37:43 -0700 Message-ID: To: "David P. Reed" Cc: Sergey Fedorov , Benjamin Cronce , Michael Richardson , Jannie Hanekom , bloat , Cake List , Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] fast.com quality X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 15:37:55 -0000 turn off cake, do it over wired. :) TAKE a packet cap of before and after.T= hx. On Sun, May 3, 2020 at 8:31 AM David P. Reed wrote: > > Sergey - > > > > I am very happy to report that fast.com reports the following from my ine= xpensive Chromebook, over 802.11ac, my Linux-on-Celeron cake entry router s= etup, through RCN's "Gigabit service". It's a little surprising, only in ho= w good it is. > > > > 460 Mbps down/17 Mbps up, 11 ms. unloaded, 18 ms. loaded. > > > > I'm a little bit curious about the extra 7 ms. due to load. I'm wondering= if it is in my WiFi path, or whether Cake is building a queue. > > > > The 11 ms. to South Boston from my Needham home seems a bit high. I used = to be about 7 msec. away from that switch. But I'm not complaiing. > > On Saturday, May 2, 2020 3:00pm, "Sergey Fedorov" = said: > > Dave, thanks for sharing interesting thoughts and context. >> >> I 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. >> >> I realize that a browser based speed test has to be basically run from t= he "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 Pi= ng issue, with a cooperative server. > > This erroneously assumes that fast.com measures latency from the server s= ide. It does not. The measurements are done from the client, over http, wit= h a parallel connection(s) to the same or similar set of servers, by sendin= g empty requests over a previously established connection (you can see that= in the browser web inspector). > It should be noted that the value is not precisely the "RTT on a TCP/UDP = flow that is loaded with traffic", but "user delay given the presence of he= avy parallel flows". With that, some of the challenges you mentioned do not= apply. > In line with another point I've shared earlier - the goal is to measure a= nd explain the user experience, not to be a diagnostic tool showing interna= l transport metrics. > > SERGEY FEDOROV > > Director of Engineering > > sfedorov@netflix.com > > 121 Albright Way | Los Gatos, CA 95032 > > > On Sat, May 2, 2020 at 10:38 AM David P. Reed wrote= : >> >> I 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. >> >> >> >> I realize that a browser based speed test has to be basically run from t= he "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 Pi= ng issue, with a cooperative server. >> >> >> >> 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. >> >> >> >> This "TCP ping" is thus compatible with getting the end-to-end measureme= nt on the server end of a true RTT. >> >> >> >> It's like tcp-traceroute tool, in that it tricks anyone in the middle bo= xes into thinking this is a real, serious packet, not an optional low prior= ity packet. >> >> >> >> The same issue comes up with non-browser-based techniques for measuring = true lag-under-load. >> >> >> >> Now as we move HTTP to QUIC, this actually gets easier to do. >> >> >> >> One other opportunity I haven't explored, but which is pregnant with pot= ential is the use of WebRTC, which runs over UDP internally. Since JavaScri= pt has direct access to create WebRTC connections (multiple ones), this mak= es detailed testing in the browser quite reasonable. >> >> >> >> And the time measurements can resolve well below 100 microseconds, if th= e 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 f= acilities. >> >> >> >> On Saturday, May 2, 2020 12:52pm, "Dave Taht" said= : >> >> > On Sat, May 2, 2020 at 9:37 AM Benjamin Cronce wro= te: >> > > >> > > > Fast.com 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... that >> > excludes much of the current side of the internet. >> > >> > > 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 usi= ng any >> > traffic shaping. Any anti-bufferbloat is from my ISP. A graph of the b= loat would >> > be nice. >> > >> > The tests do need to last a fairly long time. >> > >> > > 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 interestin= g, >> > 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 of= ten >> > >> 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 c= an >> > 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 >> > >> > >> > >> > -- >> > 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 >> > --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729