[tsvwg] Question regarding acceptable sharing behavior between "normal traffic" and L4S traffic

[Sebastian Moeller <[e-mail]>]

Dear All,

I have been making an argument repeatedly on this list in different threads to which I received inconsistent feed-back. So, I would very much like to raise this issue explicitly to the full list, as I believe this to be important to address in regards to L4S.

It has been observed by two independent measurements that the reference dual queue AQM demonstrates RTT-dependent unfairness between L4S and standard TCP traffic, the shorter the RTT the more of a bandwidth-advantage L4S gets.
At a nominal RTT of 0ms (which as far as I can tell just means no additional netem delay, so a real RTT in the <1ms range) TCP Prague gets ~5-times more bandwidth than TCP cubic:
The L4S team's measurement:
https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png
The SCE-team's measurement:
https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s1-2/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_fixed.png

That leads to my questions:

A) Is/was everybody aware of this unequal sharing over a nominally equal path? 

I ask because the following two statements from the L4S-arch and the dualq-coupled I.D.'s seem to indicate a different kind of more equal sharing to me:

https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10 :
"This specification defines `DualQ Coupled Active Queue Management
  (AQM)', which enables these Scalable congestion controls to safely
  co-exist with Classic Internet traffic.
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."

and

https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-04 :
"Further, the network part is simple to
  deploy - incrementally with zero-config.  Both parts, sender and
  network, ensure coexistence with other legacy traffic."

In the limit, the dual queue AQM will share traffic between the L4S queue and the normal queue approximately 15:1. Unless coexistence is considered to mean "does not starve" I fail to understand how claims and observed data match up.

B) Does everybody here think that this what is implied by the above stanzas and that this is an acceptable guarantee to merit allowing/endorsing the use of dual queue AQM over the internet?



	Oliver Tilmans helpfully explained, that this behavior is draft-compatible but relies on a specific interpretation of "under similar conditions", once the queue under load is taken into consideration the RTT ration goes from 1:1 to 1:15 and hence the observed bandwidth sharing is considered acceptable due to conditions not being similar enough any more. 

I have two issues with that rationale:

1) this does not seem to be the natural way to read that claim (Oliver mentioned that he had the same question/observation when he started to look into dualq, so my reading of the text is not completely outlandish)

2) It is to a large degree a consequence of a design decision in the dual queue AQM that does not seem to have been sufficiently thoroughly considered.
	The point is that dual queue simply copies the recommendation to set the target for the "normal queue's" pie instance to 15 milliseconds (simply copying from QDELAY_REF in https://tools.ietf.org/html/rfc8033#appendix-B) without taking the consequence into consideration how this affects bandwidth sharing behavior between the two queues at short RTTs. According to codel's theory (https://tools.ietf.org/html/rfc8289#section-4.3) target should be set to ~5-10% of the interval, so instead of 15 ms, 5 ms probably should do to maintain bandwidth utilization while at the same time addressing part of the root cause for unequal sharing at low RTTs. It is well possible that 5ms will not wrk for a PIE derivative shaper like dualQ, but this should at least be explored before designing an undeserved advantage for L4S into the specifications.


Best Regards
	Sebastian