Subject: [tsvwg] Decomposing the question

From: Kyle Rose <[email-masked]>
Date: Wed, 6 May 2020 08:56:02 -0400

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

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 6 May 2020 17:01:36 -0700

> as a network input, that's not what the question is really asking.

I somewhat share your dissatisfaction, but consistent the chair's
instruction "[i]f you believe L4S will not be safe for the internet without
significant architectural changes, you are in [the ECT(1) and an output]
group," I answered in the same way that you did.

> behavior with L4S for an extended period; or

+1 to that. Of all the items in the list of deliverables from the (Jul
2016) BOF at IETF 96 (
https://www.ietf.org/proceedings/96/slides/slides-96-l4s-6.pdf), that is
the one critical item that as far as I can tell still does not have a home
in the IETF. There is a very interesting research paper (
https://arxiv.org/abs/1911.00710) with on-line measurement results (
http://folk.uio.no/asadsa/ecn-fbk/results_v2.2/) but all I see in an IETF
stream document is what is in the non-normative appendix A of the l4s-id
draft (
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#appendix-A.1.4).

> on the public internet, which probably means prior to standardization.
>

Well, what RFC 8311 does with ECT(1) is to say "unless you are part of an
IETF-sanctioned experiment, don't set this codepoint in anything you send,
and treat is the same as ECT(0) if you receive it." Since anything else
would render existing implementations of RFC 3168 non-compliant, I'm not
sure what else you could do short of actually deprecating it (i.e.,
declaring it to be historic).  Going that route could certainly simplify
L4S (the classifier would be ECT, as originally envisaged) and while it
would not purge the Internet of existing 3168-compliant AQMs, it would
remove the safety issue by fiat. Not a good idea, IMO, and I am glad that
it did not get traction.

> consensus is to move forward with L4S.

Indeed.

Mike Heard

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 8 May 2020 20:39:09 +0000

+1 to most of Kyle's remarks.

I think the chairs made a noble attempt to crystallize the best question
to ask in "input or output", but in the end it now seems to me it's beside
the point, particularly because of the way it was framed as roughly a proxy
for "L4S: is it sufficiently safe, or no?".

However, I will disagree that the 2 options Kyle suggested are the only ways
forward (those being: update RFC3168 more strongly than 8311 or demonstrate
much better robustness for detection).  I believe there's at least one more
way, which I've tried to outline here:
https://mailarchive.ietf.org/arch/msg/tsvwg/vW8eEt7V58SWPoLIJ5dklCG4WqM/

I think Neal's recent suggestion to recommend bleaching is 4th possible
way forward:
https://mailarchive.ietf.org/arch/msg/tsvwg/kyDZ7vYLeOk1V15nZfNXGmaUNxk/

However, I'll give a strong +1 to all David's remarks on how unfortunate
that would be from his message here:
https://mailarchive.ietf.org/arch/msg/tsvwg/JVdZm1heomcZg5YXBQ9GAMVWKic/

I'd add that it also would work against the success of existing or under-way
deployments of RFC 3168 queues by imposing a new bleaching requirement that
may not be trivial for all networks with marking queues.

(Even so, I agree it’s a worthwhile mitigation that should be mentioned
in the L4S docs, if I'm in the rough and we land on choosing not to support
robust RFC 3168 compatibility.)

Best,
Jake