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

[Sebastian Moeller <moeller0@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Hi Jason,


> On 21. May 2024, at 19:13, Livingood, Jason via Bloat <bloat@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. 
> 
>> 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...

[-- Attachment #2: 687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f38306d735f38306d732e737667.svg --]
[-- Type: image/svg+xml, Size: 194422 bytes --]

[-- Attachment #3: Type: text/plain, Size: 266 bytes --]



That is not really fit for use over the open internet...

Regards
	Sebastian



>
> Jason
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat