From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 226E63B29D; Fri, 24 Jan 2020 07:08:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579867701; bh=mw5QQqsnYBGCZmm9NuqT59vPIQj6XRSebzxEkWRbgXY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=gD4e6nkoDUFvM4sGZGWaoM8Iok+q6d2hGgzpn1I9YZOFo8k33sBleSvdwDeCTVLqN 2INeZdQpFpernu6K+BukW2DoAekP0JKSOWBuiv6Go8bumreYAAJIEuKM22ICbM//te 5bE0irwHdwMJSo0rPr1haO8FDWvqicS9GO/Kg5Jk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MSKu0-1j1WHN1ruC-00Sf7x; Fri, 24 Jan 2020 13:08:21 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 24 Jan 2020 13:08:20 +0100 Cc: Jonathan Morton , ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <0081A6FD-97D0-4610-B9C2-D054BC5488C3@gmx.de> References: <95CC814B-9F95-4C79-BF47-ABB551B50429@gmail.com> <3D7A8E2C-5A8F-4FBB-89B0-9711E46CD560@gmx.de> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:p2ibfSt0O0PJGz2BpabQHkDfm/aTzhI9GjdNLLAU++L6qRsKmVX 7ukiKxkKGnQ4tH66WqPgA2IHxtABYj3ZRc2ro3yTk6ZLrrFOD8m3wLUheoCLe8rukzOIWMB vM6GaHLG/Kq1PQ4Xx2r8ek+dmoDEkMAw7S+pjsfGpD29AfDDrHRAY31Rdlk5AgMnR9iUJKB 0SOgu8kCGmekkTwAz+woA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:QOVrnxaOeFo=:Kka8rv9U8uHZTqADm/dfJ0 cOnkB5WcboQF25yP0BQE10oZ6fsOwgw7l3BOpd1iSaZyAyuQl5HutoqbJoyma2iM9o2oJD/09 PxhEeFEdcySewA/kMrYBJJBgjBT4uSkz8UEfVKiPQcYvHLKWoC+B8yl+NbvIvEQiyfHFCIy+O Gqf1bd0VHGSt06cnDieDDFUfPM50F1qOvkPhnxvT9lvhNY6qqEoCU+8KLvpXrjwB1VAU7be6l AuxI8pUANolHv0MaJ/DJa6CHlfvSSp29o6T86mk8wIc0xQUCTvQN9KmuIePN/MHSUKLCSKWaX Q1F/FjvtViEDC64loGwRatXs0QsAXzJbg0XfkdPxIEevDDjTX9oC5hrLV6YC7I3ehfGI7McAd 2fOi81x469CdAqv2UGapnN1CZnUUxUFFOpTXnWREbej+8PxTYriwscGGzjCiqtZemEy40LtbC yMkGhYjQafFE1V8GdbAngDWHznOjmJveLzjIv+qsmwyaiGZD86/7WG/Q+7XiDvXd/WnlUlfFd oXTpWr/OAlQJG+6bo4QqfSxabwmZai82gOpgjy++UQ+gbWN8HafpKfZw0zegVvhC4JEZLWi+a HNLimT8wPi0st/Vn4SvkiJIV6PWGDU2SPmYlbu8eMQ7JWAYPGrrZBGZu5l2QsBMdUW8xVDOzD Pz7kVJV06XhNbwYUun8cuzPagyA6y9WsemwMw0p87xSu0zR85W3WA67bSi5+RCPansvq1o/wE 840kSLwbSb4psw8yUX0bZ6dYyybGoNUnxVC2SLx5uPUm4c0fsAchTcb6fr/cy0tMrjBE9eNXm We8G9VoWPL8fU1yAPyzABG+irKPVWjRYX7L0Klv/Y8yXu6U0n+BaOBwd1gwHwHe3YpqEIL2PZ ArAjikyiGelKXVBd7NwEg9bUkhfpLjwFkSkRejm8pVdxBF702XvUZ48fvEX/agLdPa9L/iy8X NaxHaBk4zORuZgzqUIk69gcMLwgSttbSk+RfsmQlKMAxl/nlBpEKwabZ9vXK+sR+m9dhJXBX8 K/U11eRBw+OpFl+O6xJAfe/3rvWHWbWhy3/g2KmctN9atfUIIIWYpR3GNXMozNyzshkQovLla 2kiSkzuFSDqOY0nDXey185hQ185Is8AzyayCxwu9R3yuBb/HmDMOfH+eP7KHtsVrwGvJTC6JZ Yq7P7IEFtWjc1uOZq5woaWKIP7de8iMctTrgy+XNbXFOnxM6qhwvN8Pctm/RqtpgsEe17Ryze Aw7grfnanD7jzCoZ0 Subject: Re: [Ecn-sane] 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: Fri, 24 Jan 2020 12:08:23 -0000 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)? >=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. > 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).=20 > 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.=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.. > 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-ta= le-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