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

[Jonathan Morton <[e-mail]>]

> On 15 Nov, 2020, at 3:26 am, Black, David <[e-mail]> wrote:
> 
> 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.

Along these lines, let's look at the components of L4S:

1: The "architecture" involves a qualitative, revolutionary alteration to the meaning of a CE mark (relative to that established in RFC-3168 and revised quantitatively in RFC-8511).  In essence, it introduces AIAD semantics where AIMD was previously expected.

2: A classifier codepoint - ECT(1) - asserts to the network that this alternative CE semantic is in force on a given flow.  Important to note that existing networks do not expect this signal, and are thus incapable of correctly interpreting it; they assume that an ECT(1) packet should be treated the same as an ECT(0) packet, because that is what RFC-3168 specifies.

3: AccECN is a TCP extension that provides precise, reliable feedback of the density of CE marks on TCP flows.  This is deemed necessary because the AIAD steady-state has multiple CE marks per RTT, rather than multiple RTTs per CE mark in the AIMD steady-state.

4: TCP Prague, as the reference congestion-control algorithm, implements the classifier codepoint at origin when AccECN is negotiated, and exhibits a DCTCP-like (AIAD) response to CE feedback, and a NewReno-like (AIMD) response to packet loss.

5: DualPI2, as the reference L4S-aware AQM and qdisc, uses the classifier codepoint to implement what amounts to a PHB, differentiating L4S traffic from "classic" conventional traffic.  This PHB both implements the required change in AQM behaviour and provides an effective prioritisation of L4S traffic.  According to the designers, it explicitly avoids maintaining per-flow state.

6: Operational guidelines, which - as far as we can tell - boil down to "run L4S only across specially prepared networks and functionally isolate it from the conventional Internet".

The collection of components above, in the forms thus far demonstrated, fail to achieve both #4 and #5 of the "Prague requirements", namely "Fall back to Reno-friendly congestion control on classic ECN bottlenecks" and "Reduce RTT dependence".  We demonstrated that through test results some months ago, and again in the test results released just now.  We have not explicitly tested for achievement of Requirement #6, since we believe that to be less vital to interoperability with the existing Internet.

If we're going to get specific, I believe the failure to achieve Requirement #4 is the fault of Component #1 in the above list, while the failure to achieve Requirement #5 is the fault of Component #5.  Meanwhile, Component #2 is blocking progress on an alternative design which has a better chance of success.  I think these conclusions are supported by the failure of attempts to address these shortcomings by modifying Component #4, and by the introduction of Component #6 after the discussion in March rather than proceeding with technical refinements to the other components.

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


From a systems engineering perspective, it is possible to both see how the design of L4S was developed iteratively starting from DCTCP, and to recognise that this was an inherently flawed approach.  It was well known from the start that DCTCP did not interoperate with AIMD transports at common bottlenecks, but after the dust has cleared, the basic mechanism of DCTCP is the one thing that has been held constant in L4S' design - almost dogmatically, in fact.

The result is a system that, like DCTCP, can only be deployed into networks that have been specially prepared for it, and fails to interoperate with AIMD traffic without specific assistance from L4S-aware in-network components.  That is not really the sort of progress that justifies so much of the WG's time and attention, regardless of how desirable a move towards high-fidelity congestion control is.

So I fear that a substantial redesign of L4S is indeed called for, if it is to actually succeed.  This has to start with component #1 in the above list - the redefinition of the semantics of a CE mark.  Restore CE to RFC-8511 semantics, and most of the severe interoperability problems we have ben talking about for the past two years simply disappear; only networks trying to take advantage of the new behaviour need even be aware that it exists.

I need hardly remind the WG that I and my colleagues have been presenting an alternative design which does exactly that.  We'll happy to discuss it further as and when appropriate.

 - Jonathan Morton