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

Wed May 22 01:40:31 EDT 2024

Dear All,

since my attached image did not seem to make it to the list (thanks Frantisek for letting me know) here a link to the image:
h++ps <hps://camo.githubusercontent.com/8b4e94662ae0758195d4e6b6a82d81897c46c4f254f400b721f015081475b3a8/687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f31306d735f3136306d732e737667>://camo.githubusercontent.com/bbbcbf00baa8455073b8a9676d0a6d46a7aee25c7e456a44ad51b64abb30db5a/687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f38306d735f38306d732e737667
Due my mail agents outgoing SPAM marking I need to replace the 't' in the URL with + signs....

The point remains, TCP Prague does not gracefully compete with Cubic in a FIFO bottleneck, and given that many bottlenecks are still FIFOs that does not bode well for TCP Prague. It is unclear whether that is simply a bug/misfeature in Prague or whether that is a consequence of L4S signalling. IMHO the IETF has done the internet a disservice to ratify the L4S RFC before making sure that everything works as expected.

The whole L4S ratification process disillusioned me about the IETF in general and TSVWG specifically. I understand and accept that horse-trading is unavoidable when groups of humans cooperate, but in the IETF the gap between the 'no politics' motto and the amount of horse-trading that actually happens is breathtaking...
Exemplified by the fact that nobody seems to bother that chairs and ADs are not even trying to be impartial, but pretend they can separate themselves out into a 'chair' and a 'non-chair' persona... And the fact that WG members see no harm in having private only strategy discussions with chairs and ADs. I am not saying that these things are necessarily below the board, but there clearly is plenty of opportunity.
But enough of that.

My 

> Begin forwarded message:
> 
> From: Sebastian Moeller via Bloat <bloat at lists.bufferbloat.net>
> Subject: Re: [Bloat] "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "
> Date: 21. May 2024 at 19:32:47 CEST
> To: "Livingood, Jason" <jason_livingood at comcast.com>
> Cc: Jonathan Morton <chromatix99 at gmail.com>, bloat <bloat at lists.bufferbloat.net>
> Reply-To: Sebastian Moeller <moeller0 at gmx.de>
> 
> Hi Jason,
> 
> 
>> 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. 
>> 
>>> 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...

> 
> That is not really fit for use over the open internet...
> 
> Regards
> 	Sebastian
> 
> 
> 
>> 
>> Jason
>> 
>> 
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net <mailto:Bloat at lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20240522/d2ced4ba/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f38306d735f38306d732e737667.svg
Type: image/svg+xml
Size: 194422 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20240522/d2ced4ba/attachment-0001.svg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20240522/d2ced4ba/attachment-0003.html>