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

[Frantisek Borsik <frantisek.borsik@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4826 bytes --]

Sharing the picture and link directly (because Gmail let me to do it):


https://camo.githubusercontent.com/bbbcbf00baa8455073b8a9676d0a6d46a7aee25c7e456a44ad51b64abb30db5a/687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f38306d735f38306d732e737667


All the best,

Frank
Frantisek (Frank) Borsik

https://www.linkedin.com/in/frantisekborsik
Signal, Telegram, WhatsApp: +421919416714
iMessage, mobile: +420775230885
Skype: casioa5302ca
frantisek.borsik@gmail.com


On Wed, 22 May 2024 at 7:40 AM, Sebastian Moeller via Bloat <
bloat@lists.bufferbloat.net> wrote:

> 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
> ://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@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@comcast.com>
> *Cc: *Jonathan Morton <chromatix99@gmail.com>, bloat <
> bloat@lists.bufferbloat.net>
> *Reply-To: *Sebastian Moeller <moeller0@gmx.de>
>
> 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...
>
>
>
> 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
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #1.2: Type: text/html, Size: 18812 bytes --]

[-- Attachment #2: image_123650291.JPG --]
[-- Type: image/jpeg, Size: 253722 bytes --]