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

[Ingemar Johansson S <[e-mail]>]

Hi
I am not sure about the purpose of this discussion but it is free speech.

I any case it could be worth stating (for the general audience) that the 
charter of the WG is still as given by
https://tools.ietf.org/wg/tsvwg/charters
In particular
  Oct 2021 - Submit "Low Latency, Low Loss, Scalable Throughput (L4S) Internet 
Service: Architecture"
     as an Informational RFC
  Oct 2021 - Submit "DualQ Coupled AQM for Low Latency, Low Loss and Scalable 
Throughput" as an Experimental RFC
  Oct 2021 - Submit "Identifying Modified Explicit Congestion Notification 
(ECN) Semantics for Ultra-Low Queuing Delay"
     as an Experimental RFC

The ideas below have likely been floated before, after all they are not rocket 
science. In particular the accelerate/decelerate was recently presented in a 
Stanford or MIT paper (not sure which) and I am pretty sure that it was 
discussed even before that.
There are reasons to why we are at the present proposed solution.

/Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Pete Heist
> Sent: den 27 mars 2021 15:41
> To: Steven Blake <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] Deprecating RFC 3168 for future ECN experimentation
>
> I agree overall. If we want to introduce a proposal that's incompatible with
> RFC3168, we should first make it historic.
>
> Before we do that though, we should make sure that the current CE is not
> actually useful. Figure 5 in this paper suggests some benefit to two bits of
> signal as opposed to one:
> http://buffer-workshop.stanford.edu/papers/paper34.pdf
>
> A second signal provides a harder backoff without packet loss, for example
> during capacity changes or flow introductions. It wouldn't be ideal to
> deprecate RFC3168, only to find out that another bit of signal in line with 
> CE,
> along with ABE in RFC8511, or something similarly deployable with today's
> equipment, is still useful.
>
> It's also my position that we can't ignore existing RFC3168 bottlenecks, not
> just for safety but also for performance. The recent ISP study we did
> suggested RFC3168 AQMs may be present on ~10% of Internet paths there.
> Prior to that we heard 5% elsewhere. Whatever the number is exactly, these
> AQMs do exist and mark in response to both
> ECT(0) and ECT(1). If you introduce traffic that backs off much less in
> response to CE, the AQMs may operate sub-optimally, since they weren't
> designed with that kind of traffic in mind
> (https://protect2.fireeye.com/v1/url?k=d314eb2b-8c8fd268-d314abb0-
> 861fcb972bfc-578ed7f13c74c412&q=1&e=ebe2f7ed-6fe3-4c6b-8b9d-
> 07170e08ad77&u=https%3A%2F%2Fgithub.com%2Fheistp%2Fl4s-
> tests%2F%23intra-flow-latency-spikes).
>
> On Fri, 2021-03-26 at 13:01 -0400, Steven Blake wrote:
> > 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
> >
> >
> >
>