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

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

[Livingood, Jason]

On 5/22/24, 09:11, "Sebastian Moeller" <moeller0@gmx.de <mailto:moeller0@gmx.de>> wrote:
>[SM] The solution is IMHO not to try to enforce rfc7282 

[JL] ISTM that the things in 7282 are well reflected in how TSVWG operates. I know from experience it can be hard when rough consensus doesn't go your way - it happens. And at the end of the day there are always competing technical solutions - and if L4S indeed does not scale up well and demonstrate sufficient benefit (or demonstrate downside) then something else will win the day. 

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

[Sebastian Moeller]

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

Hi Jason,

It is not just l4s, nqb and udp options are similarly flawed process-wise... so this is not about me being in the rough.
It is rather determination of consensus, however rough, seems under more or less sole power of the chairs (like in a court, but without a jury) and chairs are not bound to act as fair and impartial arbiters... and unlike in court there is no supposedly rigid set of rules by which to assess a chairs decision, let alone reliable methods to appeal a decision. Sure the IETF lets jockels like me participate in the process, but no, we do not have any meaningful say. Because in the end rough consensus is what the chairs declare it to be... And this is where in private strategy discussions with chairs become problematic.

Now, I understand why/how one ends up with a system like this, but thay does not make that a great or desirable system IMHO.

On 23 May 2024 02:06:26 CEST, "Livingood, Jason" <jason_livingood@comcast.com> wrote:
>On 5/22/24, 09:11, "Sebastian Moeller" <moeller0@gmx.de <mailto:moeller0@gmx.de>> wrote:
>>[SM] The solution is IMHO not to try to enforce rfc7282 
>
>[JL] ISTM that the things in 7282 are well reflected in how TSVWG operates. I know from experience it can be hard when rough consensus doesn't go your way - it happens. And at the end of the day there are always competing technical solutions - and if L4S indeed does not scale up well and demonstrate sufficient benefit (or demonstrate downside) then something else will win the day. 
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2207 bytes --]

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

[Sebastian Moeller]

Hi Jason,

> On 22. May 2024, at 14:48, Livingood, Jason <jason_livingood@comcast.com> wrote:
> 
> > in the IETF the gap between the 'no politics' motto  There have always been politics at the IETF and in every other SDO, open source project, etc. – it is human nature IMO.

[SM] I agree, but most other organisations openly accept that, it is only the IETF that claims to abhor politics. The IETF however publishes https://datatracker.ietf.org/doc/html/rfc7282 arguing against exactly the kind of horse-trading happening out in the open. The solution is IMHO not to try to enforce rfc7282 but to accept that politics is unavoidale and implement processes that takr that into account. As is the IETF rules allow chairs and ADs tremendous leeway without recourse or checks and balances.
BUT, I do admit that even with my limited experience with the IETF I have also seen WGs were the IETF process works really well, civil and productive, so not all is bad, but IMHO TSVWG demonstrates how easily that can derail or be derailed on purpose. Like when for a humming event (cough, ECT(1) input or output, cough) dozens of members appear that seem to never before or after have given any attributable input on a draft...


>  > And the fact that WG members see no harm in having private only strategy discussions with chairs and ADs.
>  In my personal experience at the IETF, when you are lead author or editor of a working group document it is routine to strategize with WG chairs and even ADs on how to keep the document moving forward, how to resolve conflict and achieve consensus, and how to be well-prepared for meetings. That IMO is a sign of WG chairs and ADs doing their job of developing standards on a timely basis.

[SM] Chairs and ADs function as arbiters in the process (whether they like it or not) and I like my arbiters neutral and unbiased. What would be the harm to have the discussion how to keep a document moving forward open on the mailing list? Doing it in secret is IMHO not a good optic (even if, what I assume and hope nothing untowardly happens).
My understanding is that "timely basis" is a far too important factor in recent years, I prefer no RFC over sup-standard RFCs. 



Regards
	Sebastian


>   JL

Re: [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@gmx.de> wrote:
> 
>> 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.

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

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

[Sebastian Moeller]

[-- 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

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

[Livingood, Jason]

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. 

Jason

Re: [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 6:31 pm, Frantisek Borsik via Bloat <bloat@lists.bufferbloat.net> wrote:
> 
> Just "fresh from the oven", shared by Jason on social media:
> 
> https://ripe88.ripe.net/wp-content/uploads/presentations/67-20240521_RIPE88_L4S_introduction_Werner_Coomans_upload.pdf

The usual set of half-truths, with a fresh coat of paint.  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*.  There's also no mention whatsoever of what happens when L4S traffic meets a conventional AQM.

 - Jonathan Morton

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

[Frantisek Borsik]

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

Just "fresh from the oven", shared by Jason on social media:

https://ripe88.ripe.net/wp-content/uploads/presentations/67-20240521_RIPE88_L4S_introduction_Werner_Coomans_upload.pdf


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

[-- Attachment #2: Type: text/html, Size: 1723 bytes --]