[tsvwg] Decomposing the question

[Kyle Rose <[e-mail]>]

The problem I have with the consensus call is that ECT(1) is already a
network input, and as a result the real question that must be answered is
not so simple.

The space of possible meanings for ECT(1) was constrained by the ECT(0)
equivalence prescribed by RFC 3168 back in 2001, and over time further
ossified through the deployment of CE-marking AQMs, such as fq_codel. RFC
8311 updated 3168 to *permit* differential behavior in experiments, but
does not mandate deprecation of equivalent treatment, and anyway was
published too recently to expect any real effect on the behavior of
existing deployments. Expanding the space of possible meanings for ECT(1)
now, as the L4S team wants to do, seems like a very high hurdle.

Thus, any novel use of ECT(1) as a network input or output must be
compatible with its already existing meaning as an input; OR, this original
meaning for ECT(1) must be explicitly deprecated in standards and removed
from existing deployments before any new meaning can be safely deployed.

I contend that it is not sufficient to simply consider whether to use
ECT(1) as an input or output independently of the consequences of whatever
specific new meaning is proposed. One must consider whether the proposed
novel meaning is compatible with the existing meaning, and if not, evaluate
the costs in un-deploying the existing meaning.

Consequently, like pretty much everyone else who chimed in, I answered the
consensus call as if "input" were a proxy for "move forward with L4S",
because while I'm sure there are multiple uses for ECT(1) as either a
network input or output that can safely coexist with the existing meaning
as a network input, that's not what the question is really asking.

If the question is decided in favor of "input", I would propose that one of
the following must be done:

* Classic queue detection must demonstrate exceptional robustness in
transparent, replicable testing to accommodate co-existence of classic
behavior with L4S for an extended period; or
* RFC 3168 should be updated more strongly than 8311 does to eliminate the
existing meaning for ECT(1) (or deprecated entirely and moved to historic),
with this working group publishing documents on how to safely achieve a
near-total elimination of the old meaning, *before* any deployment of L4S
on the public internet, which probably means prior to standarization.

In either case, it is also this working group's responsibility to produce
informational documents on how to safely deploy L4S incrementally under the
assumption that it will need to be disabled for connections to some
networks. This might include, for instance, bleaching of the ECN setup in
TCP for affected ASes or CIDRs and recommendations for incorporation of
path signaling into other protocols prospectively employing ECN (such as
QUIC).

The burden of achieving safe deployment is on those who propose a new
meaning for an existing signal, which means this working group if the
consensus is to move forward with L4S.

Kyle