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

[Bless, Roland (TM)]

Hi Dave and all,

[sorry, I'm a bit behind all the recent discussion, however...]
I agree in several points here:
1) burning ECT(1) for L4S is less beneficial than using ECT(1)
   as different kind of congestion signal as proposed in SCE
2) L4S could also use the very same signal, probably in
   addition to an L4S DSCP.
3) I don't think that we need to couple a particular SCE
   implementation to the ECT(1) usage.

Regards,
 Roland

Am 19.07.19 um 17:37 schrieb 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
>