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

[Sebastian Moeller <[e-mail]>]

Hi Dave,


> On Nov 11, 2019, at 02:09, Dave Taht <[e-mail]> wrote:
> 
> 
> As I keep sayin, a rrul test on an asymmetric network will also show
> the side-effects of the RTT path inflation any of this stuff induces.

	Back of the envelop, instead of 1ms versus 15, we would in the best case see 2ms versus 30, same ratio but double the delta, this will make the imbalance probably even worse. I wonder how this would look with codel's 5ms @100ms interval instead of the proposed 15ms for pi2. Effectively this design gives a massive bandwidth advantage to L4S flows that can only be remedied by placing the non-L4S sources >=15ms closer to the endpoint, which for close DC type of loads does not seem very realistic.
	I now would like to see tests with say 5-10 flows for both classes with different RTTs each to see how/if the bandwidth distribution differs. It is well possible that I am overly alarmists here, but that can be easily ruled-out by simple tests.

Best Regards
	Sebastian



> 
> looking forward to seeing that result one day soon.
> 
> "Tilmans, Olivier (Nokia - BE/Antwerp)"
> <[e-mail]> writes:
> 
>> Hi Sebastian,
>> 
>>> I wonder how you intend to deal with scenario 1, cubic versus prague, where
>>> prague for short RTTs pummels cubic throughput, quite unlike what one
>>> naively could expect from reading the dualQ draft:
>>> 
>>> "Analytical study and implementation testing of the Coupled AQM have
>>>   shown that Scalable and Classic flows competing under similar
>>>   conditions run at roughly the same rate."
>>> 
>>> at 0ms RTT prague is ~10 times faster than cubic, and at 10ms this still is
>>> around a factor of 3, only at 80ms that gets into what I would consider
>>> "roughly the same rate". 
>> 
>> I had the same question a couple of months ago when introduced to the dualQ.
>> The short answer here is that both flows do not compete under similar conditions:
>> they operate at different RTTs, which varies depending on their propagation delays.
>> E.g., at 0ms base, L4S flows see 1ms on average while classic flows see 15ms; at
>> 10ms base, L4S sees 11ms and classic 25ms.
>> 
>> Given that flows have different overall RTTs, but are subject to the same marking
>> probabilities (albeit tuned to their reponse, i.e., linear or multiplicative), you
>> instead need to look at their cwnd--which must be equal[1]. Unfortunately, eye-balling
>> this from flent graph is not super convenient--tracing it, e.g., using eBPF, is
>> however straightforward.
>> 
>> [1] The 0ms case will likely yield a smaller than expected cwnd for L4S, cause by
>> 10% WRR protection kicking it and artificially increasing classic's cwnd (as 1ms
>> vs 15ms would yield a 15x throughput difference if it was reno).
>> 
>>> I now wonder what happens if you pair a short RTT
>>> (say 10ms) prague flow (simulating traffic from a nearby data center) with a
>>> cubic flow with a typical internet RTT (say 80ms). My prediction is that
>>> prague will dominate cubic similarly to the 0ms RTT. I guess this is coming
>>> from the default 1/16 scheduling weight for the normal queue, do you agree?
>> 
>> You can disable the WRR entirely (i.e., set it to 0%) and the results will stay
>> the same (except for the 0ms case...).
>> 
>> 
>> Best,
>> Olivier
>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Nov 8, 2019, at 11:41, Tilmans, Olivier (Nokia - BE/Antwerp)
>>> <[e-mail]> wrote:
>>>> 
>>>>> Hi Greg, would it be possible to merge any changes you’d like to include
>>> in
>>>>> further testing into the testing (default) branch at
>>>>> https://github.com/L4STeam/linux? We’ll evaluate what we can with what
>>> time
>>>>> there is, but a prerequisite to that is making sure we have the right
>>>>> changes you want tested. :)
>>>> 
>>>> Hi Pete,
>>>> 
>>>> As mentioned at https://l4s.cablelabs.com/l4s-testing/README.html (link
>>>> at the bottom of the page Greg linked), we ran your full set of flent
>>>> tests using this tag:
>>>> https://github.com/L4STeam/linux/releases/tag/testing%2F5-11-2019
>>>> 
>>>> I doubt we'll push anything else on that repo for the moment being
>>>> unless someone comes out with a bug/fix/improvement.
>>> 
>>> 	Well, I would like to see scenario 1 with unequal RTTs between the
>>> two flows, like prague@10ms vs. cubic@80ms, and prage@80ms vs. cubic@10ms
>>> (and the same for cubic vs. cubic)
>>> and I would like to see tests pitting 2 flows of one type versus one flow of
>>> the other type, like 2 cubic versus 1 prague and 2 prague vs. 1 cubic.
>>> 
>>> Best Regards
>>> 	Sebastian
>>> 
>>>> 
>>>> 
>>>> Best,
>>>> Olivier