sanitized dual q aqm tests

[moeller0]

Hi Pete,

I just noticed that the dual q AQM seems to default to 15ms, which might contribute to the observed unfairness between cubic and prague @0ms RTT. According to Oliver, under load the effective RTTs change from ~0:~0 to 1:15 which he takes as sufficient justification to excuse the unfairness. Now, according to codel theory 15ms target and interval 100 are a really bad match for a 0ms RTT path, as target should be well below 1ms. at 1ms RTT and at 5ms for interval 100. So would it be interesting to repeat the L4S scenario 1 tests with (RTT_typ = 5 ms) instead of the default 15, or even smaller values to see whether that ameliorates the observed bias?

[heistp]

Thanks, I could definitely do that. It reminds me of why we're FQ proponents. :)

[moeller0]

Given the following: "A.1.5. Reduce RTT dependence

Description: A scalable congestion control needs to reduce or eliminate RTT bias over as wide a range of RTTs as possible, or at least over the typical range of RTTs that will interact in the intended deployment scenario.

Motivation: Classic TCP's throughput is known to be inversely proportional to RTT, so one would expect flows over very low RTT paths to nearly starve flows over larger RTTs. However, Classic TCP has never allowed a very low RTT path to exist because it induces a large queue. For instance, consider two paths with base RTT 1ms and 100ms. If Classic TCP induces a 100ms queue, it turns these RTTs into 101ms and 200ms leading to a throughput ratio of about 2:1. Whereas if a Scalable TCP induces only a 1ms queue, the ratio is 2:101, leading to a throughput ratio of about 50:1.

Therefore, with very small queues, long RTT flows will essentially starve, unless scalable congestion controls comply with this requirement.

De Schepper & Briscoe Expires May 7, 2020 [Page 27] Internet-Draft ECN Semantics for Low Queuing Delay November 2019

A.1.6. Scaling down to fractional congestion windows

Description: A scalable congestion control needs to remain responsive to congestion when RTTs are significantly smaller than in the current public Internet.

Motivation: As currently specified, the minimum required congestion window of TCP (and its derivatives) is set to 2 maximum segment sizes (MSS) (see equation (4) in [RFC5681]). Once the congestion window reaches this minimum, all current TCP algorithms become unresponsive to congestion signals. No matter how much drop or ECN marking, the congestion window no longer reduces. Instead, TCP forces the queue to grow, overriding any AQM and increasing queuing delay.

L4S mechanisms significantly reduce queueing delay so, over the same path, the RTT becomes lower. Then this problem becomes surprisingly common [TCP-sub-mss-w]. This is because, for the same link capacity, smaller RTT implies a smaller window. For instance, consider a residential setting with an upstream broadband Internet access of 8 Mb/s, assuming a max segment size of 1500 B. Two upstream flows will each have the minimum window of 2 MSS if the RTT is 6ms or less, which is quite common when accessing a nearby data centre. So, any more than two such parallel TCP flows will become unresponsive and increase queuing delay.

Unless scalable congestion controls are required to comply with this requirement from the start, they will frequently become unresponsive, negating the low latency benefit of L4S, for themselves and for others. One possible sub-MSS window mechanism is described in [TCP-sub-mss-w], and other approaches are likely to be feasible." in https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/?include_text=1

It would be great to see how an fq AQM deals with the challenge of serving unequal RTT flows fair enough....