[Ecn-sane] where the l4s ect1 takeover is documented

[Jonathan Morton]

> On 3 Apr, 2019, at 11:18 pm, David P. Reed <dpreed at deepplum.com> wrote:
> 
> One would need to prove that they are compatible and cause performance to converge when used at the same time.

And that's the problem; the precise opposite has been proved, unless either:

- the traffic runs through an FQ system at the bottleneck (where the FQ system enforces fair convergence), or

- the DualQ system is at the bottleneck (where the AQMs handling each class are coupled in a compatible manner), or

- a dumb tail-drop FIFO is at the bottleneck (which we're trying to get the heck away from, but L4S' response to drops is TCP friendly).

If there's a simple single-queue ECN-enabled AQM at the bottleneck, L4S ends up squashing any Classic ECN or Not-ECT traffic out of existence, simply because it responds less to each CE mark and requires a continuous stream of them (two per RTT) to hold the cwnd stable.  That same CE marking (or packet dropping) rate will cause normal TCPs to collapse to minimum cwnd within a handful of RTTs, whether they implement the 50% reduction of Reno, the 70% of CUBIC, or the 85% permitted by the ABE spec - so L4S cannot safely coexist with normal traffic.

Much of the present debate revolves around how prevalent these AQMs actually are now, or might become in the foreseeable future.  It's obvious to me that DualQ is designed as a way to make L4S work in places where a single-queue AQM would normally be deployed, as much as been made of the relative simplicity of implementing it in high-speed hardware, and the initial rollout appears to be in the same class of devices for which PIE was developed.

By adopting ECT(1) as SCE and retaining the existing meaning of CE, the two forms of AQM marking are much better integrated and have a much better chance of coexisting in a heterogeneous environment.  I and some others are now actively engaged in proving that by example.

 - Jonathan Morton