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

[Pete Heist <[e-mail]>]

Hi, thanks for working on the issues we posted in our “bakeoff” tests on Sep. 12. We have updated our repo with a re-run of the tests using the L4S code as of the tag 'testing/5-11-2019', and those results are at the same location:

https://github.com/heistp/sce-l4s-bakeoff/

We’ve put together a list of changes we saw in the results:

https://github.com/heistp/sce-l4s-bakeoff#changes

The changes are:

- The previously reported intermittent TCP Prague utilization issues appear to be fixed.

- TCP Prague vs Cubic now does converge to fairness, but appears to have fairly long convergence times at 80ms RTT (example: https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s3-2/batch-l4s-s3-2-prague-vs-prague-50Mbit-80ms_fixed.png). Convergence times in other scenarios are similarly long.

- In scenarios 2, 5 and 6, the previously reported L4S interaction with CoDel seems to be partially, but not completely fixed. By reversing the flow start order (prague vs cubic instead of cubic vs prague, second flow delayed by 10 seconds), we can see that while the TCP RTT spikes no longer occur at flow start, they are still present when a second flow is introduced after slow-start exit (example: https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s2-2/batch-l4s-s2-2-prague-vs-cubic-50Mbit-80ms_fixed.png).

- In scenario 3 (single queue AQM at 10ms RTT), the previously reported unfairness between TCP Prague and Cubic grew larger, from ~4.1x (40.55/9.81Mbit) to ~7.7x (44.25/5.78Mbit). This trend appears to be consistent at other RTT delays in the same scenario (0ms and 80ms).

I will update the issues in trac with these results, and if there are any questions let us know…

Pete

> On Nov 6, 2019, at 5:23 PM, 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
>> 
>> 
>> 
> 
> 
>