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 <moell...@gmx.de> wrote:
>
> Hi Jason
>
>> On 22. May 2024, at 14:27, Livingood, Jason <jason_living...@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?
>
>
>
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
