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
