Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

[Sebastian Moeller <[e-mail]>]

Hi Greg,

great that you found this "bug".


But this also indicates to me that basically all testing for the L4S project needs to be repeated, since at least early tests were performed with DCTCP and it is clear that DCTCP and TCP Prague are not bug-to-bug compatible.

I wonder whether the proper order of things might not be:
a) finalize and stress-test at least one TCP Prague implementation
b) write a RFC describing TCP Prague
c) wait for acceptance of that RFC
d) introduce the next L4S related drafts again

Starting with d) before at least a) is achieved does not strike me as terribly efficient, as if a) should prove elusive d) would not need to be retracted?

Best Regards
	Sebastian



> On Nov 6, 2019, at 17:23, Greg White <[e-mail]> wrote:
> 
> Good timing __
> 
> We've just wrapped up our findings on Issue 17, and have posted them here (along with some comments on Issue 16 as well):
> 
> https://l4s.cablelabs.com 
> 
> (Note, the ns3 repo is not public yet, but will be shortly.   We'll update that page with links within a day or two.)
> 
> In summary, we reached the following conclusions:
> 
> - the main result of concern was due to a bug in initializing the value of TCP Prague alpha, which has been fixed and demonstrated to resolve the latency impact that was spanning multiple seconds
> 
> - the remaining short duration latency spike in the FIFO queue is seen in *all* congestion control variants tested, including BBRv1, NewReno, and Cubic, and is not specific to Prague
> 
> - if the CoDel queue is upgraded to perform Immediate AQM on L4S flows, the latency spike can be largely avoided.
> 
> We invite a thorough review of the work, but believe that this closes issue #17.
> 
> 
> Best Regards,
> 
> Greg White, Tom Henderson, Olivier Tilmans
> 
> 
> 
> 
> 
> 
> On 11/6/19, 12:59 AM, "Sebastian Moeller" <[e-mail]> wrote:
> 
>    Hi Greg,
> 
> 
>> On Sep 11, 2019, at 19:16, Greg White <[e-mail]> wrote:
>> 
>> I'm planning on doing testing as well, but it will be more than a day or two to get it done.  Rough timeframe would be 2-3 weeks from now.
> 
>    	Since I can not hide my impatience any loger, did anything come out of this yet?
> 
>    Best Regards
>    	Sebastian
> 
>> 
>> -Greg
>> 
>> On 9/11/19, 1:52 AM, "Pete Heist" <[e-mail]> wrote:
>> 
>> 
>>> On Sep 9, 2019, at 9:01 PM, Wesley Eddy <[e-mail]> wrote:
>>> 
>>> Since this thread seems to have dwindled, I just wanted to summarize that it looks to me like we have agreement that testing as described is needed.
>>> 
>>> I updated the issue tracker with a comment saying as much and pointing back to this thread in the archive for reference.
>>> 
>>> Is anyone planning to perform this testing in a rough timeframe they might want to share?
>> 
>>   Hi Wesley, I’ll share results from relevant testing in the next day or two...
>> 
>>   Regards,
>>   Pete
>> 
>> 
>> 
> 
> 
>