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

[Sebastian Moeller <[e-mail]>]

Hi Greg,


> On Nov 11, 2019, at 22:51, Greg White <[e-mail]> wrote:
> 
> ....actually, I think I misread your comment (and plot*).   The latency spike is _not_ for the TCP cubic flow, but rather for the Prague flow.
> 
> So, this is a case of fq immediately cutting the BDP in half due to the arrival of a second flow, but not providing sufficient congestion signaling to Prague to cause it to reduce its cwnd quickly.   The sluggish ramp up of the marking probability in the CoDel AQM being a mismatch to the Prague congestion response is the cause here.

	Interestingly, it seems that the recent change of exiting slow start by ~halving the sending rate helps for Prague on position 2, by effectively making Prague respond to the first CE mark in a RFC3168 compatible fashion, but as the Prague at 1st position test shows, this does not help if Prague is running at too high a rate in congestion avoidance mode.
	IMHO, that is one of the reasons why there is so much concern about re-defining the meaning of CE markings. In this specific case the negative side-effect of this seem to be restricted to Prague, that is something I could live with. 
What happens at scenario 1 at low RTTs and at scenario 3 is different, here it is the non-L4S traffic that takes an unexpected/undeserved hit. 


> 
> -Greg
> 
> *in my defense the flent plots aren't the friendliest for color-deficient viewers.

	I believe no defense necessary, there are lots of plots with often only subtle differences and colors that are nicely organized, but hard to keep apart. Loading the files into flent's GUI allows to hover over the legend and the according line gets highlighted, maybe an option if higher saliency is required?

Sebastian

> 
> 
> 
> On 11/11/19, 2:32 PM, "tsvwg on behalf of Greg White" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    Hi Pete,
> 
>    Thanks for posting the updated results.
> 
>    In the Issue 17 related scenario (Scenario 6), you observed that there was a 5-second-long latency spike for the TCP cubic flow (but for none of the other flows) when the cubic flow starts up.  
> 
>    https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s6-2/batch-l4s-s6-2-prague-vs-cubic-50Mbit-80ms_fixed.png
> 
>    Since this latency spike is only present for the cubic flow, it is clearly not in the shared FIFO, but in the fq_codel queue. I'm having trouble understanding how TCP Prague could be causing queuing delay that *only* affects a cubic flow in a different queue.  Could you explain how this is possible?  It seems like it may be an error in your result.
> 
>    -Greg
> 
> 
> 
> 
> 
>    On 11/11/19, 12:57 PM, "Pete Heist" <[e-mail]> wrote:
> 
>        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
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> 
>