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

[Gorry Fairhurst <[e-mail]>]

If you have good deployment data on devices with ECN enabled by default, 
then please share it.

It would be extremely helpful to also know if the home routers you 
mention were deployed using FQ.

Gorry

On 29/03/2021 09:26, Bless, Roland (TM) wrote:
> Hi,
>
> On 27.03.21 at 15:41 Pete Heist wrote:
>> I agree overall. If we want to introduce a proposal that's incompatible
>> with RFC3168, we should first make it historic.
>
> I just want to add that RFC 3168 is a proposed standard, whereas we
> want to introduce L4S as an _experiment_. All the recent work of the
> AQM WG would be also void and I thought that vendors are actually
> implementing this in home routers. I think that we must be really sure
> about RFC3168 (non-)deployment before deprecating RFC3168. Even RFC 8311
> still stated: "Forwarding behavior as described in RFC 3168 remains the
> preferred approach for routers that are not involved in ECN 
> experiments,".
>
>> 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.
>
> I'm also in favor of having better (i.e., more fine grained)
> explicit congestion signals as end-systems may use them to
> come up with better decisions. I expressed this clearly in the
> ECT(1) input cs. output signal discussion. Now, if we come up
> with a DSCP as additional safeguard qualifier for L4S,
> which I support, then it makes sense to revisit the earlier
> WG decision and use ECT(1) as additional congestion signal.
>
>> 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://github.com/heistp/l4s-tests/#intra-flow-latency-spikes).
>
> In case home routers are using RFC 3168 and congestion is in
> downstream direction one would only be able to detect this by seeing
> ECE in the other direction. Maybe servers from large content providers
> could also provide data about this...
>
> Regards,
> Roland
>
>> 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
>>>
>>>
>>>
>>
>>