[tsvwg] Deprecating RFC 3168 for future ECN experimentation

[Steven Blake <[e-mail]>]

A lot (not all) of the recent arguments revolve around the assumption
by some that RFC 3168 ECN deployment barely exists in the Internet, and
the few networks where it does can be safely ignored, or cleaned out,
or be expected to take proactive measures to protect themselves, which
may in practice require them to lobby their router vendors to spin
patch releases to enable (some of) the mitigation measures detailed in
-l4ops-02 Sec. 5.

If that is the WG consensus, then I *strongly urge* the WG to do the
following:

1. Push to move RFC 3168 ECN to Historic

2. Adopt the following "New ECN" signals for future ECN
experimentation:

- Not-ECT
- ECT
- CE-a
- CE-b

This second step would allow for two sets of experiments. The semantics
of CE-a and CE-b for the first set of experiments would be as follows:

- CE-a: "Decelerate"
- CE-b: "Decelerate harder" (multiplicative decrease)

The exact behavior elicited by the "Decelerate" signal would be the
subject of investigation. Since we are certain that any remaining RFC
3168 deployments can be safely ignored, then ECT/CE-a/CE-b can be used
as unambiguous signals to steer packets into a low-latency queue, if
desired.

The semantics of CE-a and CE-b for the second set of experiments would
be as follows:

- CE-a: "Decelerate"
- CE-b: "Accelerate"

An aggressive fraction (100%?) of CE-b marked packets traversing a
queue not in "Accelerate" state would be re-marked to either CE-a or
ECT. Any packet discard (or detection of high delay variation?) must
disable the transport's "Accelerate" mechanism for some interval and
should cause the transport to revert to "TCP-friendly" behavior for
some (different?) interval. The exact behaviors of "Accelerate" and
"Decelerate" signals would be the subject of investigation. Again,
since we are certain that any remaining RFC 3168 deployments can be
safely ignored, then ECT/CE-a/CE-b can be used as unambiguous signals
to steer packets into a low-latency queue.

The differences between these two sets of experiments hinge on whether
there is more utility in an "Accelerate" signal coupled with a
"Decelerate" signal, or with two separate levels of "Decelerate"
signals. Since it is WG consensus that the RFC 3168 ECN experiment
failed after two decades, we probably only get one more chance to get
this right, so careful and exhaustive experimentation which explores
the design space is in order.

Obviously, both sets of experiments cannot be run simultaneously on
intersecting parts of the Internet. I leave the options for safely
isolating these experiments as an exercise for the reader. Since we are
certain that any remaining RFC 3168 ECN deployments can be safely
ignored, I suggest choosing bit assignments for the four signals that
induce maximum pain in the obstinate minority that might still deploy
RFC 3168 ECN.

Now, *if it is not WG consensus* that any existing RFC 3168 ECN
deployments can be safely ignored, then I *strongly urge* the WG *to
not adopt* experimental proposals that place burden and/or risk on
networks that have deployed it.


TL;DR: Either RFC 3168 ECN exists in the Internet, or it doesn't.
Decide, and act appropriately.


Regards,

// Steve