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

[Sebastian Moeller <[e-mail]>]

Hi Oliver,

> On Nov 11, 2019, at 01:38, Tilmans, Olivier (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> 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.

	[SM] You are telling me you were sitting on the knowledge that DualQ does not work as advertised, and just accepted that? No attempt have been made to remedy this (like setting the WRR to 50%).

> 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.

	[SM] Sorry that is not how humans interpret the claim in the introduction of the dualQ rfc. Similar conditions clearly imply the externally visible path length (aka unloaded RTT). 

> 
> 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.

	[SM] This confirms my hypothesis that dualQ is not the proper tool here, just compare https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png with https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-13T045427-r1/l4s-s2-2/batch-l4s-s2-2-cubic-vs-prague-50Mbit-10ms_fixed.png. This is the expected 50:50 haring behaviour the dualQ draft implies, this is what you need to get close to if you want dualQ to be allowed on the internet, as on short RTTs to the nearest DC, L4S/TCP Prague will absolutely eat normal TCP's lunch and dinner. 

> 
> [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...).

	[SM] Again that implies that on intranet timescales dualQ does not offer the quality of isolation required to have L4S and non-L4S-style traffic peacefully coexist. But that is dualQ's whole "raison d'être". And this in the best case scenario, with an L4S AQM, this is quite sad. 


> 
> 
> 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
>