* Re: [Bloat] DOCSIS Low Latency Spec Details
2019-01-03 13:28 ` Ryan Mounce
@ 2019-01-03 21:42 ` Dave Taht
0 siblings, 0 replies; 4+ messages in thread
From: Dave Taht @ 2019-01-03 21:42 UTC (permalink / raw)
To: Ryan Mounce; +Cc: Dave Taht, bloat
Ryan Mounce <ryan@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.
^ permalink raw reply [flat|nested] 4+ messages in thread