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

[Sebastian Moeller <[e-mail]>]

Hi Roland,



> On Nov 11, 2019, at 10:34, Bless, Roland (TM) <[e-mail]> wrote:
> 
> Hi Olivier,
> 
> Am 11.11.19 um 01:38 schrieb Tilmans, Olivier (Nokia - BE/Antwerp):
>> 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
> 
> Not sure that I understand what you mean here. Flows with different RTTs
> typically need different CWnds to achieve sufficient throughput, but
> their share of queued data at the bottleneck needs to be the same in
> case you want flow rate fairness between them. This is, however,
> different from requiring their CWnds to be equal...

	The Issue seems to be that, the language in the introduction not withstanding, DualQ/L4S effectively only guarantees to not completely starve non-L4S flows; as designed L4S traffic will outcompete non-L4S-traffic at any reference RTT, the shorter the base RTT the more pronounced this issue is going to be. Lets look at https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10:

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

"Similar conditions" here according to Oliver is intended to denote RTT under load (wonder how this would look with codel's 5ms target @ 100ms instead of pi2's 15ms?). This might be working as intended, but I am still not convinced that that is as safe a design as claimed:

"However, until now, Scalable congestion controls
   did not co-exist with existing TCP Reno/Cubic traffic --- Scalable
   controls are so aggressive that 'Classic' TCP algorithms drive
   themselves to a small capacity share."

As fas as I can see this paragraph is still true for the currently implemented DualQ AQM TC Prague versions.

For what it is worth:

"Therefore, until now, L4S
   controls could only be deployed where a clean-slate environment could
   be arranged, such as in private data centres (hence the name DCTCP).
   This specification defines `DualQ Coupled Active Queue Management
   (AQM)', which enables these Scalable congestion controls to safely
   co-exist with Classic Internet traffic."

Effectively also seems counter to the data, as especially traffic from close by data centers will show the base RTT dependent imbalance. IMHO this effectively renders all the lofty words about decoupling latency under load from bandwidth moot.

Best Regards
	Sebastian



>> 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...).
> 
> Regards,
> Roland
>