[Ecn-sane] [tsvwg] Comments on L4S drafts

[Dave Taht]

"De Schepper, Koen (Nokia - BE/Antwerp)"
<koen.de_schepper at nokia-bell-labs.com> writes:

> Hi Sebastian,
>
> To avoid people to read through the long mail, I think the main point I want to make is:
>  "Indeed, having common-Qs supported is one of my requirements. That's

It's the common-q with AQM **+ ECN** that's the sticking point. I'm
perfectly satisfied with the behavior of every ietf approved single
queued AQM without ecn enabled. Let's deploy more of those!

> why I want to keep the discussion on that level: is there consensus
> that low latency is only needed for a per flow FQ system with an AQM
> per flow?"

Your problem statement elides the ECN bit.

If there is any one point that I'd like to see resolved about L4S
vs SCE, it's having a vote on its the use of ECT(1) as an e2e
identifier.

The poll I took in my communities (after trying really hard for years to
get folk to take a look at the architecture without bias), ran about
98% against the L4S usage of ect(1), in the lwn article and in every
private conversation since.

The SCE proposal for this half a bit as an additional congestion
signal supplied by the aqm, is vastly superior.

If we could somehow create a neutral poll in the general networking
community outside the ietf (nanog, bsd, linux, dcs, bigcos, routercos,
ISPs small and large) , and do it much like your classic "vote for a
political measure" thing, with a single point/counterpoint section,
maybe we'd get somewhere.

>
> If there is this consensus, this means that we can use SCE and that
> from now on, all network nodes have to implement per flow queuing with
> an AQM per flow.

There is no "we" here, and this is not a binary set of choices.

In particular conflating "low latency" really confounds the subject
matter, and has for years. FQ gives "low latency" for the vast
majority of flows running below their fair share. L4S promises "low
latency" for a rigidly defined set of congestion controls in a
specialized queue, and otherwise tosses all flows into a higher latency
queue when one flow is greedy.

The "ultra low queuing latency *for all*" marketing claptrap that l4S
had at one point really stuck in my craw.

0) There is a "we" that likes L4S in all its complexity and missing
integrated running code that demands total ECN deployment on one
physical medium (so far), a change to the definition of ECN itself, and
uses up ect(1) e2e instead of a dscp.

1) There is a "we" that has a highly deployed fq+aqm that happens to
have an ECN response, that is providing some of the lowest latencies
ever seen, live on the internet, across multiple physical mediums.

With a backward compatible proposal to do better, that uses up ect(1) as
an additional congestion notifier by the AQM.

2) There is a VERY large (silent) majority that wants nothing to do with
ECN at all and long ago fled the ietf, and works on things like RTT and
other metrics that don't need anything extra at the IP layer.

3) There is a vastly larger majority that has never even heard of AQM,
much less ECN, and doesn't care.

> If there is no consensus, we cannot use SCE and need to use L4S.

No.

If there is no consensus, we just keep motoring on with the existing
pie (with drop) deployments, and fq_codel/fq_pie/sch_cake more or less
as is... and continued refinement of transports and more research.

We've got a few billion devices that could use just what we got to get
orders of magnitude improvements in network delay.

And:

If there is consensus on fq+aqm+sce - ECN remains *optional*
which is an outcome I massively support, also.

So repeating this:

> If there is this consensus, this means that we can use SCE and that
> from now on, all network nodes have to implement per flow queuing with
> an AQM per flow.

It's not a binary choice as you lay it out.

1) Just getting FIFO queue sizes down to something reasonable - would be
GREAT. It still blows my mind that CMTSes still have 700ms of buffering at
100Mbit, 8 years into this debate.

2) only the network nodes most regularly experiencing human visible
congestive events truly need any form of AQM or FQ. In terms of what I
observe, thats:

ISP uplinks
Wifi (at ISP downlink speeds > 40Mbit)
345G 
ISP downlinks
Other in-home devices like ethernet over powerline

I'm sure others in the DC and interconnects see things differently.

I know I'm weird, but I'd like to eliminate congestion *humans* see,
rather than what skynet sees. Am I the only one that thinks this way?

3) we currently have a choice between multiple single queue, *non ECN*
enabled aqms that DO indeed work - pretty well - without any ECN support
enabled - pie, red, dualpi without using the ect identifier, cake
(cobalt). We never got around to making codel work better on a single
queue because we didn't see the point, but what's in cobalt could go
there if anyone cares.

We have a couple very successful fq+aqm combinations, *also*, that
happen to have an RFC3168 ECN response.

4) as for ECN enabled AQMs - single queued, dual q'd, or FQ'd, there's
plenty of problems remaining with all of them and their transports, that
make me very dubious about internet-wide deployment. Period. No matter
what happens here, I am going to keep discouraging the linux distros as
a whole to turn it on without first addressing the long list of items in
the ecn-sane design group's work list.

...

So to me, it goes back to slamming the door shut, or not, on L4S's usage
of ect(1) as a too easily gamed e2e identifier. As I don't think it and
all the dependent code and algorithms can possibly scale past a single
physical layer tech, I'd like to see it move to a DSCP codepoint, worst
case... and certainly remain "experimental" in scope until anyone
independent can attempt to evaluate it. 

second door I'd like to slam shut is redefining CE to be a weaker signal
of congestion as L4S does. I'm willing to write a whole bunch of
standards track RFCs obsoleting the experimental RFCs allowing this, if
that's what it takes. Bufferbloat is still a huge problem! Can we keep
working on fixing that?

third door I'd like to see open is the possibilities behind SCE.

Lastly:

I'd really all the tcp-go-fast-at-any-cost people to take a year off to
dogfood their designs, and go live somewhere with a congested network to
deal with daily, like a railway or airport, or on 3G network on a
sailboat or beach somewhere. It's not a bad life... REALLY.

In fact, it's WAY cheaper than attending 3 ietf conferences a year.

Enjoy Montreal!

Sincerely,

Dave Taht
>From my sailboat in Alameda