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

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

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

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! "

[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

[Bloat] Fwd: "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: 4195 bytes --]

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@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 <mailto:Bloat@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat


[-- Attachment #2.1: Type: text/html, Size: 10951 bytes --]

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

[-- Attachment #2.3: Type: text/html, Size: 8139 bytes --]

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

[Frantisek Borsik]

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

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

[Livingood, Jason]

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

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

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


JL



[-- Attachment #2: Type: text/html, Size: 2849 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] [EXTERNAL] Re: "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! "

[Livingood, Jason]

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

[JL] That is good feedback for you to send to Nokia. But as I mentioned, all our comparisons in lab and field testing are of AQM vs L4S - so we have that covered (and lots of other tests cases I won't cover here). 

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

[Livingood, Jason]

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

[SM] 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...

[JL] That graph is not anything like what we’ve seen in lab or field testing. I suspect you may have made some bad assumptions in the simulation.

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

Re: [Bloat] [EXTERNAL] "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:27, Livingood, Jason <jason_livingood@comcast.com> wrote:
> 
> [SM] 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...
> 
> [JL] That graph is not anything like what we’ve seen in lab or field testing. I suspect you may have made some bad assumptions in the simulation.


So have you actually tested 1 TCP CUBIC versus 1 TCP Prague flow over a FIFO bottleneck with 80ms minRTT?
Then, I would appreciate if you could share that data.

My best guess is, that you did not explicitly test that (*). I expect almost all testing used short RTTs and likely the low latency docsis scheduler/AQM combination (essentially an implementation close to DualQ). But I am happy to be wrong.

One of my complaints of the data presented in favor of L4S during the ratification process was (and still is) that we got a multitude of very similar tests all around locations n parameter space that were known to work, while the amount od even mildly adversarial testing was miniscule.

*) As Jonathan implied the issue might be TCP Prague"s pedigree from TCP Reno mostly, as Reno and Cubic compete similarly unequal at 80ms RTT. To which I asked, who came up with the idea of basing TCP Prague on Reno in the first place? Changing that now, essentially will invalidate most previous L4S testing. See above why I do not believe this to be a terrible loss, but just procedurally I consider than not very impressive engineering. That aside. if this explanation is correct, the only way for you not having encountered that dutring your tests is by not actually testing that condition. But that in turn makes waters down the weight of the claim "not anything like what we’ve seen in lab or field testing" considerably, no?

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

[Sebastian Moeller]

Hi Jason

let me apologise for the harsh tone. I should have been able to phrase my point way politer, but clearly failed.
I am sure your testing matrix was large enough already and tested those conditions you considered most urgent for your use-cases.
I understand that I am free to test what ever I am interested in L4S myself.

Regards
	Sebastian


> On 22. May 2024, at 14:54, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Hi Jason
> 
>> On 22. May 2024, at 14:27, Livingood, Jason <jason_livingood@comcast.com> wrote:
>> 
>> [SM] 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...
>> 
>> [JL] That graph is not anything like what we’ve seen in lab or field testing. I suspect you may have made some bad assumptions in the simulation.
> 
> 
> So have you actually tested 1 TCP CUBIC versus 1 TCP Prague flow over a FIFO bottleneck with 80ms minRTT?
> Then, I would appreciate if you could share that data.
> 
> My best guess is, that you did not explicitly test that (*). I expect almost all testing used short RTTs and likely the low latency docsis scheduler/AQM combination (essentially an implementation close to DualQ). But I am happy to be wrong.
> 
> One of my complaints of the data presented in favor of L4S during the ratification process was (and still is) that we got a multitude of very similar tests all around locations n parameter space that were known to work, while the amount od even mildly adversarial testing was miniscule.
> 
> *) As Jonathan implied the issue might be TCP Prague"s pedigree from TCP Reno mostly, as Reno and Cubic compete similarly unequal at 80ms RTT. To which I asked, who came up with the idea of basing TCP Prague on Reno in the first place? Changing that now, essentially will invalidate most previous L4S testing. See above why I do not believe this to be a terrible loss, but just procedurally I consider than not very impressive engineering. That aside. if this explanation is correct, the only way for you not having encountered that dutring your tests is by not actually testing that condition. But that in turn makes waters down the weight of the claim "not anything like what we’ve seen in lab or field testing" considerably, no?
> 
> 
>