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

[Dave Taht <[e-mail]>]

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.

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