Re: [Ecn-sane] IETF 110 quick summary

["Holland, Jake" <jholland@akamai.com>]

On 3/9/21, 9:50 AM, "Steven Blake" <slblake@petri-meat.com> wrote:
> Actually, that is the ideal outcome. ECT(0) signals ECT-Capable, ECT(1)
> and CE signal two levels of congestion. In other words, SCE everywhere.
>
> Maybe that is an argument that you can throw at them: if it is safe to
> ignore classic ECN, might as well move straight to SCE with non-ECT
> traffic shunted off to a separate queue(s).

The L4S drafts address this somewhat already, I think.  The main argument
is probably best-articulated in Appendix B.2 of l4s-id:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#appendix-B.2

From more of a summary of (my recollection of) live discussion, the
main reason it's rejected is that classic ECN traffic will not
respond as quickly as L4S, so you could not get lower latency than
classic ECN offers in a shared queue with competing classic ECN traffic,
which would impede adoption by providing no latency benefit plus some 
throughput penalty for upgrading.

(Also of note: L4S is trying to target bigger devices upstream
of the home gateway, where flow-aware queuing is less practical, and
also where most of the congestion and buffering delay occurs for
those who are not throttling at their home gateway.)

This was one point where a lot of the people in tsvwg explicitly
expressed that you really do need a classifier to improve on classic
aqm latency, hence preferred ECT(1)-as-input.  (I think even some
who do not agree it should be deployed due to safety concerns did
agree with this point.)

So I don't expect raising that point would be helpful.

-Jake