Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation

[daihuichen <[e-mail]>]

Hello,

The discussion in this thread, as well as the discussion in the thread of L4S adoption call, seems only consider the Internet scenario. 
Today, ECN has been widely deployed in data center networks for low-latency transports like RoCE, I think we should also consider the results to data center networks if deprecating RFC 3168.
I don’t have a proposal, just a reminder that we cannot leave data center networks out.

Regards,
/Huichen

-----Original Message-----
From: tsvwg [mailto:[e-mail]] On Behalf Of Steven Blake
Sent: 2021年3月27日 1:02 AM
To: [e-mail]
Subject: [tsvwg] Deprecating RFC 3168 for future ECN experimentation

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