Ryan Mounce <r...@mounce.com.au> writes: > For convenience > > https://www.scribd.com/document/396733989/Low-Latency-DOCSIS-Draft
That was very helpful, thank you. I read up to page 106, and I'm sure there's stuff in the annex worth reading. It is seemingly impossible to copy and paste from this version, though... Overall comment: Cable modems make fiber and ethernet technololgy look simple. WiFi is still worse, however, as is LTE. For those familiar with wifi or non-switched ethernet, the contention window backoff (sec 7.2.1.1) might be of interest, as well as the wire encodings... Overall it looks like a bunch of needed clarifications to the docsis 3.1 standard with a couple fixes for docsis 3.0 They changed the notion of a "primary service flow" (pg 23) They added a definition for LLSF (low latency service flow) and a PGS (proactive grant service), and SCN (service class name), and WRR (weighted round robin). DOCSIS 3.1 has a "downstream convergence layer", (see section 5) where MPEG-2 is no longer the convergence layer between the mac and phy. this is something I didn't understand before now, (and still might not!) and I think in part a driving factor behind the dual-q aqm system, so that video traffic always gains priority, and they free up more channels for transmitting data rather than video, in general. Pg 40: "this additional set of features comprised of proactive scheduling, dual-q coupled aqm and queue protection, significantly decreases the latency of packets as they traverse the..." Pg 41 goes into QoS and diffserv field treatments. Nothing new here, it's an underused/undertested facility that has always been there, aside from comcast rewriting every diffserv mark it doesn't recognize as CS1. (this was my main driver to introduce diffserv washing into cake. It's extremely annoying to have so much traffic fall into wifi's background queue all the time otherwise, and I do hope more third party qos and hw makers start washing at least some diffserv bits out on entrance to the customer domain if they detect it happening. Hmm... we could use a test for this. irtt can do it easily, so can netperf.) Section 5.2.4.3 (pg 43) defines the new L4S stuff. Section 6.2.4.5 appears redacted or missing. Sec 7.2.1.1: I like that they are aiming for a 1ms request/grant interval with the OFDM encoding, and hope it's feasible. Sec 7.2.1.5*: Backward compatability is a bitch. The cable operators of the world would do well to just upgrade everybody to 3.0 or later modems. It would pay off in increased customer satisfaction and capacity... in weeks. Sec 7.2.3 has a gem for "proactive scheduling" - I don't feel like retyping it (pg 68) - It starts with "The CMTS can schedule grants proactively"... and concludes with "the algorithm by which the by which the CMTS estimates bandwidth demand and proactively schedules is vendor specific". Also on page 68 is a promising new bit signaling when the local CM buffer is overfull. There's a lot of good stuff in section 7.2.3.8 for "proactive granting". It's not really clear how this conflicts with/works with powersave, but anything that keeps the modem more awake helps with many flow types. Section 7.7.3.9 punts this configuration making to the operator. There's stuff here to disable aqm, and enable "classic" aqm with a 10ms default latency target. Fragmentation is also (finally) deprecated... Section 7.7 (pg 97) goes into the dual-q design. All packets with ECN enablement and also those with the EF bit set, go into the new low latency queue. It handwaves as to what other diffserv bits might imply low latency non-queue-building. Packets without ECN or the right diffserv bits, go into the "classic" queue, which drops. there's a handwave for a "queue protection function", which "protects the low latency service flow from be-ing overwhelmed by mismarked traffic". Maybe I missed where it got defined... They use WRR between the two queues that has to be aware of mini-slots (so this is the rough equivalent of what we did for wifi airtime) ... I'll read more later. ... The dualQ stuff has been baking in the ietf for quite some time. After the AQM group folded up shop it moved to tsvwg - see dualq, l4s, etc. https://datatracker.ietf.org/group/tsvwg/documents/ I've made the occasional pithy comments, but I was more focused on fixing wifi than caring. I've always had a half dozen major problems with the concept of using up the last ECT(1) bit for a specialized purpose. The spec (so far! 100s of pages to go) does not actually fully indicate how the "low latency" and "classic" queues will be used, or even expressed. * The latest internet draft deprecates "classic" traffic to 1/4th the total bandwidth. Classic is of course everything not using the newfangled congestion control bit, things like normal TCP, BBR, dns, gaming, voip, etc - or for all we know only used within an operator's DC for specialized traffic, like video streaming, and washed clean elsewhere, or subject to admission control (in fact, I don't see how dual-q can work at all correctly unless it's admissioned controlled) * FRAND There is a core patent as part of that RFC attempt ( https://datatracker.ietf.org/ipr/2952/ ) I asked for what it would cost to produce a free and open source version of this algorithm a while back and never got a reply. FRAND in my mind has always been code for "there will never be a FOSS version". Not ever having had viable code to use on our tests for going on 5 years now, and having made requests for someone on that side to actually try a suite of our tests to no avail, I've ignored it, but it now looks like it's got traction in the cable industry so... * DualQ in general There's no real outside analysis of this set of algorithms - in part due to the frand problem, and a lot of political support from the patent owners, and political hoopla and marketing. "Low Latency for All" was one that stuck in my craw, given that the "all" implied everyone adopting dctcp like congestion management for all flows. Another one that really bugs me is a benchmark going around that claims to show how this stuff meets operator needs, that synthesizes traffic that claims to look like "chat"... but it's all greedy flows underneath... All that said, I'd welcome *anything* that promises to reduce latency from the CMTS to the CM - even this. Even if it requires mass adoption of the ECT(1) bit to utilize. My guess is marking DNS traffic ECT(1) ought to be "interesting". I am sad that AQM technlogies and techniques has become a battleground over the corpse of net neutrality, and still wish that Arris had somehow followed up on their initial very promising SFQ based results in 2013. _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat