[Bloat] "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "

[Jonathan Morton]

> On 21 May, 2024, at 8:32 pm, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 
>> On 21. May 2024, at 19:13, Livingood, Jason via Bloat <bloat at lists.bufferbloat.net> wrote:
>> 
>> On 5/21/24, 12:19, "Bloat on behalf of Jonathan Morton via Bloat wrote:
>> 
>>> Notice in particular that the only *performance* comparisons they make are between L4S and no AQM at all, not between L4S and conventional AQM - even though they now mention that the latter *exists*.
>> 
>> I cannot speak to the Nokia deck. But in our field trials we have certainly compared single queue AQM to L4S, and L4S flows perform better.

I don't dispute that, at least insofar as the metrics you prefer for such comparisons, under the network conditions you also prefer.  But by omitting the conventional AQM results from the performance charts, the comparison presented to readers is not between L4S and the current state of the art, and the expected benefit is therefore exaggerated in a misleading way.

An unbiased presentation would alert readers to the fact that merely deploying a conventional AQM would already eliminate nearly all of the queue-related delay associated with a dumb FIFO, without sacrificing much if any goodput.  By doing this, they would also not expose themselves to the risks associated with deploying L4S (see below).

>>> There's also no mention whatsoever of what happens when L4S traffic meets a conventional AQM.
>> 
>> We also tested this and all is well; the performance of classic queue with AQM is fine.
> 
> [SM] I think you are thinking of a different case than Jonathan, not classic traffic in the C-queue, but L4S traffic (ECT(1)) that by chance is not hiting abottleneck employing DualQ but the traditional FIFO...
> This is the case where at least TCP Prague just folds it, gives up and goes home...
> 
> Here is Pete's data showing that, the middle two bars show what happens when the bottleneck is not treating TCP Prague to the expected signalling...

This isn't even the case I was thinking of.  Neither "classic" traffic in the C queue (a situation which L4S has always been designed to accommodate, however much we might debate the effectiveness of the design), nor L4S traffic in a dumb FIFO (which, though it performs badly, is at least "safe"), but L4S traffic in a "classic" RFC-3168 AQM, of the type which is already deployed to some extent.  This is what exposes the fundamental incompatibility between L4S and conventional traffic, as I have been saying from practically the moment I heard about L4S.

It's unfortunate that this case is not covered in the chart that Sebastian linked.  The situation arose because that particular chart is focused on a performance concern, not a safety concern which was treated elsewhere in the report.  What it would show, if a fourth qdisc such as "codel" were included (with ECN turned on), is a similar magnitude of throughput bias as in the "pfifo" qdisc, but in the opposite direction.  Note that the bias in the "pfifo" case arises solely because Prague does not *scale up* to high BDPs in the way that CUBIC does.

 - Jonathan Morton