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

["Black, David" <[e-mail]>]

Hi Sebastian,

Some comments as an individual, not a WG chair.

First, I think Pete has pretty clearly established that TCP Prague is research, and hence (IMHO) TCP Prague ought to be headed for ICCRG as its primary forum rather than TSVWG.

To date, the 'Prague L4S Requirements' (Appendix A of draft-ietf-tsvwg-ecn-l4s-id) have been strongly associated with TCP Prague.  That association ought to be teased apart so that the resulting L4S scalable congestion control requirements provide a reasonable design space that can include a number of other congestion control designs - in addition to what's been discussed, e.g., SCReAM, it would be useful to better understand what it would take for implementations of protocols such as DCTCP and BBR (e.g., for QUIC) to meet those requirements.

My overall take on the requirements is that in 20/20 hindsight, some of them were overly optimistic, and hence need to be backed off/toned down/broadened to encompass what is reasonable in "running code" well beyond TCP Prague. That sort of collision between interesting ideas and network realities is not an unheard-of scenario in IETF, so I hesitate to view the need for changes to these requirements as evidence that the original ideas were inherently defective, as I've seen far more dramatic changes, e.g., some number of years ago, the first design of iSCSI login was elegant ... and resulted in implementations that did not interoperate, resulting in a complete redesign.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
> Sent: Thursday, November 12, 2020 6:11 PM
> To: Pete Heist
> Cc: tsvwg IETF list
> Subject: Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency
> 
> 
> [EXTERNAL EMAIL]
> 
> 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
> >
> >