Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency

[Sebastian Moeller <[e-mail]>]

Hi Pete,

great data. IMHO Especially the fact that short-RTT Prague will severely outcompete long-RTT Prague way more than the traditional dumb FIFO will, strongly supports  the following hypotheses I have been posting before:

a) Dualpi2/TCP Prague are no way ready for deployment, but are basically still in the toy stage

b) all that L4S will effectively do, be it by intent or simply by mis-design, is built a "fast lane" for short RTT low hop count traffic. Given all the hype (still!) in the L4S internet drafts about how this is the future of the internet... Also a fast lane that requires active cooperation from the leaf ISP (if they keep their bottlenecks at FIFO, I see no compelling reason for TCP Prague at all), which will require SLAs between CDNs and ISPs.

c) too little, too late. Really only modest gains in RTT (compared to best of class AQMs like fq_codel or cake) and noticeable regressions in sharing behavior both between different CCs and flows of different RTTs (and that compared to dumb queue "management" with a simple FIFO).



Also quite sobering, that it AGAIN was not team L4S bringing real data to the table to support their claims and promises. Then again looking at the RTT fairness for Prague versus Prague under DualQ, I can understand why team L4S stayed mumm, and rather argued for allowing unfettered self-mutilation of L4S compliant transport protocols in regards to RTT fairness:

"So there is no need  to mandate that an L4S implementer does no harm to themselves, which window-based congestion controls tend to do at higher RTT. Of course, this doesn't preclude implementers reducing or eliminating RTT bias for larger than typical RTTs, but it removes any requirement to do so."

After years of advertising on increased RTT independence (in spite of the data showing that the proposed combination of DualQ and TCP Prague actually increases RTT bias), team L4S in the last minute no less, decides to do a 180 and just change the requirements to allow for the rather unhealthy behavior demonstrated for L4S... 
With the current enhanced RTT bias, who in their right mind is going to use TCP Prague; which currently is the only transport, that at least attempted to tackle all the "requirements" L4S poses for transports that want to use the ECT(1) express way? Then again, since none of the network elements are designed and required to actually check and enforce these requirements, calling these "requirements" is a bit of stretch anyway, maybe they should be changed from MUST requirements to COULD musings.... 


Best Regards
	Sebastian


> On Nov 12, 2020, at 21:31, Pete Heist <[e-mail]> wrote:
> 
> Hi,
> 
> We have posted some new tests of L4S here:
> 
> https://github.com/heistp/l4s-tests
> 
> These tests cover two-flow fairness in several qdiscs with different
> path RTTs per-flow, and transient behavior in fq_codel queues.
> 
> The results raise some concerns about a bias in favor of L4S flows in
> DualPI2 queues, throughput imbalances between flows with different path
> RTTs, and intra-flow latency spikes upon rate reductions in fq_codel.
> The repo above contains a walk-through of the key findings, and links
> to more results in the Appendix.
> 
> Regards,
> Pete
> 
>