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

[Sebastian Moeller <[e-mail]>]

Dear All,

Ingemar helpfully directed my to our charter. Where I find among other's:

"(C) Maintenance of IP Differentiated Services (DiffServ) mechanisms,
    which involves mostly advisory documents on the use of DiffServ in
    specific application scenarios. Other work items related to DiffServ
    require Area Director approval."


Based on this, I would say, mandating a guard DSCP for the duration of the L4S experiment (and after depending on the experiments evaluation?) seems to be fully within this WG charter, at worst after talking to the respective AD. 

Best Regards
	Sebastian



> On Mar 28, 2021, at 20:36, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> 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