[tsvwg] Explaining my ect(1) as input to network position

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi all,

A short version of the points I want to make related to the safety issues:

  *   Classic RFC3168 unfairness can be easily mitigated/fixed in the network if it would cause problems, preferably by reusing and reconfiguring exactly the RFC3168 functionality some people think L4S will make useless. It will become on the contrary a driver for better support for L4S.
  *   Vulnerability to non-responsiveness flows exists today in SingleQ AQMs and this is accepted. DualQ behaves exactly the same without benefitting L4S. Like other AQMs, it provides no solution to "save" responsive flows from non-responsive ones, as this is not a requirement for an AQM. So it can't be claimed this is a safety issue of L4S/DualQ.

The big advantage of ECT(1) as the input to the network is that the new traffic can be identified very easily by the network (IP-header only). This is also a big advantage for potential safety issues wrt Classic RFC3168 ECN bottlenecks. A network operator can indeed bleach ECT(1) to prevent the new behavior on its Classic ECN RFC3168 nodes if it would be needed, but even better, an operator can make use of these Classic ECN nodes to support L4S. The identification can be used to separate the 2 traffic types in different queues (or even links/paths), with each its dedicated Classic ECN configuration (a larger target with smoothed response for Classic and a shallow immediate threshold for L4S). The queues can be scheduled with WRR of for example 50/50 for each traffic type. This has been described in early papers for DCTCP deployments in DataCenters. It is actually a NON-Coupled DualQ. This config can be easily configured on existing equipment. It won't have all Coupled features, but is a good starting point, and preserves the low latency for L4S.

I noticed that there are quite some "safety due to non-responsive TCP"-concerns raised again which were solved already. We have shown in the past that the Coupled DualQ responds to non-responsive traffic as a normal Single Q Classic bottleneck (with or without ECN). No fast-lane for L4S non-responsive traffic, only lower latency. Try sending 3 non-responsive UDP/CBR flows using each one of the non-ECT, ECT(0) and ECT(1) with each a sending rate of 100% link capacity into a DualQ. They will each get 33% of the link capacity, while pushing away all TCP traffic (no matter which ECT they are). Note that cumulative, L4S gets even only 33%, while Classic gets 66% capacity in this case! It shows again that the coupled AQM disables the scheduling and fully overrules its claimed "priority"-behavior. This is a very unintuitive concept of DualQ, that seems to be easily overlooked. Depending on the overload strategy, the Classic flows can experience 15ms extra latency compared to the ECT(1), but there won't be throughput benefit. Do the same experiment on a correctly designed Classic ECN bottleneck and the behavior will be exactly the same (except for the latency benefit for ECT(1)). This sensitivity to non-responsiveness has been always the case, even now on the Internet you all are using. It is typically constrained within a single subscriber/user by per user scheduling.

So concluding again, related to the safety-issues:

  *   Classic RFC3168 unfairness can be easily mitigated/fixed in the network if it would cause problems, preferably by reusing and reconfiguring exactly the RFC3168 functionality some people think L4S will make useless. It will become on the contrary a driver for better support for L4S.
  *   Vulnerability to non-responsiveness flows exists today in SingleQ AQMs and this is accepted. DualQ behaves exactly the same without benefitting L4S. Like other AQMs, it provides no solution to "save" responsive flows from non-responsive ones, as this is not a requirement for an AQM. So it can't be claimed this is a safety issue of L4S/DualQ.

So let's go for the forward looking solution with the best opportunity for success...

Koen.