From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 91EDE3B2A4; Sat, 25 Jan 2020 11:21:24 -0500 (EST) Received: from dancer.taht.net (unknown [IPv6:2601:646:8301:676f:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id CE03F2296C; Sat, 25 Jan 2020 16:21:22 +0000 (UTC) From: Dave Taht To: Sebastian Moeller Cc: Dave =?utf-8?Q?T=C3=A4ht?= , Jonathan Morton , ECN-Sane , bloat References: <95CC814B-9F95-4C79-BF47-ABB551B50429@gmail.com> <3D7A8E2C-5A8F-4FBB-89B0-9711E46CD560@gmx.de> <0081A6FD-97D0-4610-B9C2-D054BC5488C3@gmx.de> Date: Sat, 25 Jan 2020 08:21:21 -0800 In-Reply-To: <0081A6FD-97D0-4610-B9C2-D054BC5488C3@gmx.de> (Sebastian Moeller's message of "Fri, 24 Jan 2020 13:08:20 +0100") Message-ID: <87pnf7zev2.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecn-sane] [Bloat] 2019-12-31 docsis strict priority dual queue patent granted X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 16:21:24 -0000 Sebastian Moeller writes: > Hi Dave, > > >> On Jan 24, 2020, at 09:59, Dave Taht wrote: >>=20 >> To be deliberately contrarian - (I do try to only pay attention to >> this a few days a month) - after also re-reading >> https://www.cablelabs.com/technologies/low-latency-docsis and the >> associated white papers (yes, 24 hours on a plane can do this to >> you) >>=20 >> 1) I've never been able to figure out where the 99 percentile >> latency >> figure so often cited came from. on the upstream which typically >> runs >> well below 20Mbit, a single IW10 burst at 10Mbit is 1.3ms, so I've >> generally figured it was either a long term figure, or calculated >> from >> a much higher (100mbit? 1gbit?) downstream rate against some load >> that's never been documented. (that I know of, please note that I >> don't >> read much of the traffic about this stuff) > > Thinn air and/or tests with DCTCP, probably (or paced > fixed-rate flows)? Well, I really would like a repeatable benchmark to address this particular claim. > > >>=20 >> 2) There is a lot of valuable looking stuff in the lower level >> aspects >> of the docsis LL standard. > > I agree, they propose a nice mid-life MAC do-over, but I am > not sure whether ISPs/Manufacturers will follow as IIRC some of that > stuff is either not mandatory to implement and/or to activate. In markets where docsis is competing with fiber, I would suspect folk might try. > >> I'd noted it when I first read it, but >> achieving .9ms baseline a/g latency finally does make it competitive >> with fiber with whatever the heck "pgm" is. So far as I knew, the >> overlapping grant request and estimator functions > > I initially thought that is going to be tricky, but > realistically if there is traffic on a link (immediate) history > probably is a decent predictor of (immediate) future traffic need, so > a bit of temporal prediction can go a long way there to lessen the > impact of the grant request cycle on average latency (one could even > think about not only tracking past traffic speed but also > acceleration). Sure. The part that I don't really get is how often actual contention for grants happens in docsis today. It's one thing to request a grant, even one that is speculative, but as in wifi - actually getting one strikes me as increasingly hard. Asking for a grant when you end up needing it not, hmm. > > >> documented in the >> patent are already present in most cablemodems already, and not >> really >> tied to the ll spec... but that data would be interesting to get out >> of the modem itself, somehow. The histogram is made available via a >> MIB to the operator. It would be nice if those MIBs were also >> visible >> to the user somehow. >>=20 >> 3) >>=20 >> In the docsis-ll white paper and spec it lays out cmts requirements >> also. With the cmtses currently exhibiting 500+ms of latency at >> 100Mbit loaded, from a mere "solving bufferbloat" perspective - >> getting just pie there to work would be *marvelous* - it would be >> superior to any of the fiber deployments I know of. dualpi, even if >> not configured for l4s ecn support, > > Well, especially if not configured for l4s ECN, as dualpi is > misdesigned in giving the L4S queue dominance over the non-L4S > queue... Ironic giving all the prose about dualpi not being a priority > based AQM (and driven by the IMHO faulty assumption that rate and > delay are fully orthogonal). And that failure to do the one job it was > designed for has been documented (or shall I say buried) in the L4S > measurement papers since early on, and yet no-one bothered to actually > go fix this. RTT unfairness seems to be a highly desirable feature for the vertically oriented ISP. Convincing anybody else using the internet for real traffic to multiple destinations that this is a "good thing" seems to be an increasingly difficult uphill slog thanks to your work and the work of others appearing.=20 > But to your point, sure, if used as a single queue AQM it will > give us a PIE variant with a reference delay of 15ms (which according > to theory should be good up to a RTT of ~300ms) at the head-end, a > significant improvement on the status quo, albeit only for docsis > users.. I'm happy to see postive movement on the uploads. I have a slide from 2017 somewhere that I should probably animate into this plot. (anybody else have screenshots of this over time?) http://www.dslreports.com/speedtest/results/bufferbloat?up=3D1 There used to be a group of docsis 3.0 modems that is now nearly gone from = the statistics now here. While the dslreports dataset is polluted by folk actively fixing their bufferbloat, the tremendous improvement in docsis upstream latency observed since 2017 probably comes down to 4 factors - doubling or more the upstream bandwidth while holding buffersizes constant, ISPs also cutting the buffersizes down, and the docsis-pie deployment, and sqm. As to which of those factors was the greatest... not a clue! There's been very little movement in the dsl world, in comparison, and seeing a range of fiber nodes at 100mbit on the wrong side of the black line is worrisome. I have less screen caps of this. http://www.dslreports.com/speedtest/results/bufferbloat > > >> would be a godsend. The ECO for >> cablemodems at least, went out over a year ago. >>=20 >> some aqm tech becoming common on these head ends would also spur >> deployment of aqm (or fq + aqm) tech on fiber also. But I've seen no >> info as to what's going into cmtses today. Haven't seen any >> announcements... >>=20 >> I still have no idea what is going to happen on 5G. >>=20 >> My initial experiments with the intel ax200 wifi card have been >> dismal. >>=20 >> On Fri, Jan 24, 2020 at 12:24 AM Dave Taht >> wrote: >>>=20 >>> Jeeze, you guys are up early. I read this stuff on the plane home >>> from >>> australia, and am still a bit under the weather. >>>=20 >>> On Fri, Jan 24, 2020 at 12:01 AM Sebastian Moeller >>> wrote: >>>>=20 >>>> Hi Jonathan, >>>>=20 >>>>=20 >>>>> On Jan 24, 2020, at 08:44, Jonathan Morton >>>>> wrote: >>>>>=20 >>>>>> On 24 Jan, 2020, at 7:37 am, Dave Taht >>>>>> wrote: >>>>>>=20 >>>>>> "Otherwise, this exemplary embodiment enables system >>>>>> configuration to >>>>>> discard the low-priority packet tail, and transmit the >>>>>> high-priority >>>>>> packet instead, without waiting." >>>>>=20 >>>>> So this really *is* a "fast lane" enabling technology. Just as >>>>> we suspected. >>>=20 >>> Well, there are weasel words elsewhere in the patent, and the dualq >>> code for linux merely cleared a lane for L4S traffic and hardcoded >>> the >>> ect(1) as an identifier. It would be good to have more data on >>> rtt-fairness, and on CE reordering of rfc3168 ecn packets. >>>=20 >>> I spent time dreaming up also all the ways "queue protection" could >>> be >>> used against the user. Given the rigor of the l4s spec required, >>> and >>> how one misbehaving application can screw it all up, I could see >>> queue protection of unknown sources that can be squelched on demand >>> being a desirable "feature". This can be used to stop >>> "unauthorized" >>> mac addresses from participating in this design as one example. >>>=20 >>> I like the idea of queue protection - there is a lot of malicious >>> traffic worth throttling - but without a reporting scheme to the >>> user, >>> nor a means for the user to set it up, and the mechanism under the >>> sole control of the ISP - not so much. >>>=20 >>> My other in-flight entertainment was cory doctorow's latest piece, >>> which was so good I submitted it to slashdot. ( >>> https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future= -tale-of-refugees-and-sinister-iot-appliances/ >>> ) >>>=20 >>>=20 >>>> They seem to be setting their customers up for a head-on >>>> collision with the European Union's net neutrality rules, >>>> according to which "special services/fast lanes" are permissible >>>> under the condition thay they are realized with completely >>>> dedicated addition bandwidth. Just looking at their patent diagram >>>> there is one common input path to the classifier. So either that >>>> fast lane is not going to be a paid for fast lane, or the ISPs >>>> rolling this out will be in hot water with the respective national >>>> regulators (at least in the EU). The one chance would be to give >>>> the end-user control over the classification engine, or if the >>>> strict priority path is only used for ISP originated VoIP traffic >>>> (I seem to recall there are weasel words in the EU rules that >>>> would allow that and ISPs are doing something like that already, >>>> and I agree that it is nice to be able to field an emergency call >>>> independent of access link load). >>>=20 >>> Well, one country at a time. NN is currently quite dead in the USA, >>> and only a change in regime might change that, and it's unclear if >>> any >>> of the candiates understand the issues. Certainly with twin >>> subsidies >>> being aimed at 5G and broadband deployment in pending legislation, >>> I >>> have no idea what will happen here next. I view 5G with fear, >>> watching >>> frontier file for bankruptcy, also... I really wish all the fiber >>> being run for 5G was being run into the home instead. >>>=20 >>>=20 >>>>=20 >>>> Best Regards >>>> Sebastian >>>>=20 >>>>=20 >>>>>=20 >>>>> - Jonathan Morton >>>>> _______________________________________________ >>>>> Ecn-sane mailing list >>>>> Ecn-sane@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/ecn-sane >>>>=20 >>> -- >>> Make Music, Not War >>>=20 >>> Dave T=C3=A4ht >>> CTO, TekLibre, LLC >>> http://www.teklibre.com >>> Tel: 1-831-435-0729 >>=20 >>=20 >>=20 >> --=20 >> Make Music, Not War >>=20 >> Dave T=C3=A4ht >> CTO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-831-435-0729 > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat