Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs

[Jonathan Morton <chromatix99@gmail.com>]

> On 26 Jul, 2019, at 4:07 pm, Black, David <David.Black@dell.com> wrote:
> 
>> I believe under this nomenclature, L4S in a queue with RFC3168-style
>> marking at a bottleneck should be classified as a flow that is
>> responsive but not TCP-compatible, and therefore poses a significant
>> threat to internet performance within this context.
>> 
>> I'm not sure how best to describe this discrepancy, but I think it's
>> fair to call it an incompatibility between a RFC3168-style marking
>> queue and L4S.
> 
> Based on the L4S slides in today's meeting and related discussion, the L4S folks are starting to deal with this concern.
> 
> I share your technical view that this concern is not safe to ignore.

Based on our post-session discussions, I feel that it may not actually be entirely clear to the L4S people just how serious the situation with L4S and Codel is.

The impression I gained was that they consider *Codel* to be broken, and that *it* should be changed to match what L4S expects.  This is impractical given how widely Codel is already deployed, and the fact that it was carefully designed specifically with RFC-compliant transport flows in mind.  The result of their proposed changes would no longer resemble Codel at all.

Unfortunately contributing to their apparent confusion, TCP Prague is currently broken in such a way as to mask the problem if tested directly.  To experimentally verify our hypothesis, we had to synthesise a pseudo-Prague implementation by inserting a firewall rule (mangling CE into SCE) in front of our DCTCP-SCE implementation, the results of which matched our mathematical predictions perfectly.  We saw no evidence of a Classic ECN detector in our TCP Prague tests.

Codel is itself documented in an Experimental RFC, authored by no less personages than Kathy Nichols and VJ.  The derivative FQ-Codel is similarly documented in an RFC.  The variant I use named COBALT (aka Codel-BLUE Alternate) is not yet in an RFC (nor even a draft), but possibly it should be made into one, as the improvements are at least interesting and are proven by both research and deployment.

 - Jonathan Morton