[tsvwg] Update to Position Statement on ECT(1)

["Holland, Jake" <[e-mail]>]

Hi tsvwg,

As promised in my original position statement[1], if I substantially changed
my views on the ECT(1) question I would post an update.

It has come to my attention that a technical fix is possible for my safety
concerns with "ECT(1) as an input" by changing the signaling scheme.

Although I still stand by all my claims in the original position statement,
the existence of a safe signaling scheme that uses ECT(1) as a network input
has changed my conclusion on the input/output question.

New position:
- I slightly prefer ECT(1) as an input (with qualifiers, given below)

(Note that this position should not be taken as an endorsement of L4S's
safety as currently proposed.)

The new signaling scheme that drove my change of position is this:

- ECT(1) is set from sender after negotiating endpoint support
- On-path devices change ECT(1)->ECT(0) to signal low levels of congestion
- On-path devices continue to use CE, as in RFC3168, to signal high levels
  of congestion, resulting in a required multiplicative decrease response.

Under this scheme, for any path with a single AQM that's dualq, ECT(1)
remains a very good classifier for that AQM.  Since this covers most
relevant paths that aren't within a controlled environment like datacenters,
it has a low downside.

Under this scheme, ECT(0) becomes the 1/p signal for dualq+TCP Prague, and
CE becomes the 1/sqrt(p) signal from the classic queue if the LL queue
overflows, and results in multiplicative decrease from the sender.

This would make L4S compatible with RFC 3168 without relying on a fragile
classic queue detection algorithm, so it would address my safety concerns.

As with all available signaling schemes, I acknowledge that this approach
is not perfect, and comes with tradeoffs.  A few of the known tradeoffs
would include (with thanks to Bob, Koen, and Kyle for explaining some of
these to me offline):
- existing tunneling decapsulation specs would often lose non-CE signals
- the existing accecn spec would often lose non-CE signals
- For paths with multiple AQMs, the classifier partially loses integrity in
  later AQMs when earlier AQMs are loaded.  (Note also the worse downside
  that increasing deployment of new AQMs potentially reduces the fidelity
  further.)

In spite of the downside from these tradeoffs (and the work that would be
necessary to fix the specs and their deployment to capture the most value
from L4S), a signaling scheme with the backward compatibility that this
approach provides is what would make the key difference between a safely
deployable L4S and not, IMO.

As I said, I still stand by my previous claims.  In particular, I still
believe that DSCP is a reasonable and appropriate classifier for L4S
traffic at this stage of its maturity.

However, I also acknowledge that there's value in getting a quicker wide
deployment, as long as it can be done safely.  Since I believe ECT(1) with
the above signaling scheme can do so, I now think it's as reasonable a
choice as DSCP, but carries substantial benefits.

Since this approach would give almost the same benefits as "ECT(1) as
output", and also provides a classifier that can serve dualq's needs well
in most of the deployment scenarios, "ECT(1) as input" is my current
preference, because of my new belief that it can be made compatible
with RFC 3168 queues and still mostly get the classification job done.

I remain opposed to moving L4S forward in a way that's not compatible with
RFC 3168 queues, as it's currently proposed.

I also remain skeptical that it's possible to get the classic queue
detection working robustly, I think that's probably a dead end. And I
have become more skeptical of the viability of the queue protection
mechanisms mentioned, because those seem to require access to the layer 4
packet contents, which has been flagged as too hard to be practical.

So I remain skeptical of the safety stories told so far for the current
L4S proposal, because it has no MD fallback signal except loss or detection.

Best,
Jake

PS: I also have some mostly-supportive comments on Kyle's remarks about
the input/output question that might be relevant.  Thread is here and should
soon get a new message:
https://mailarchive.ietf.org/arch/msg/tsvwg/VhgCiE9dF6F2Z-eN9wkpeVG2LX0/

[1] Jake's original position on ECT(1):
https://mailarchive.ietf.org/arch/msg/tsvwg/Zrk7Up6g9BwfnJLjKD44K0riAg4/