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

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

Hi Bob,

For brevity and clarity, I've trimmed and reordered quotes to highlight
the relevant bits I'm responding to, leaving aside discussion on some
of the lower level details you raised to focus on a higher level point.
But for easier reference in case there's questions of context, the full
preceding message is here:
https://mailarchive.ietf.org/arch/msg/tsvwg/-uFazVf2tupkK011Y5ps83ENCvc/

> From: Bob Briscoe <[e-mail]>
> Date: Tuesday, May 19, 2020 at 4:18 PM
...
> There are a hundred or so companies that have said they are planning to 
> deploy L4S, many with products imminent, but hanging on this IETF 
> decision. Under this proposal, they will then be expected to wait a few 
> years (probably more like a decade) until these tunnels are designed, 
> specified, implemented and deployed. Until then, L4S just doesn't work 
> at all over 60-70% of the Internet.
>
> This isn't going to happen. This is fantasy. Can you not see how this 
> will look? Actually, how it does look? It looks like you are trying to 
> give the IETF a reputation for shooting itself in both feet, then laying 
> land mines and blowing off both legs.

This sounds to me like “whoops, we have made a terrible mistake by
defining the tunnel semantics in such a way that only one wire signal
(CE) can be transported, and now we realized we would like to provide a
signal with a different meaning, and unfortunately are painted into a
corner, since CE’s meaning is defined and used in widely distributed
implementations that are currently engaged in a long-overdue rollout”.

If there is a "fantasy" here, it's this notion that we'll quickly just
breeze through a transition period before classic ECN is phased out, and
so the interoperability problems don't need a serious and long-term
solution, unless I'm misunderstanding the meaning of the "transition"
you've referred to with remarks like these:

(Sample "transition" remark 1):
  > So please be correct and precise and say that a CE response is needed 
  > for the possibility of encountering a single-queue RFC3168 AQM /during 
  > transition/.
  >
  > Beyond transition, a fixed 'back-stop'  response in addition to 1/p 
  > signalling would be completely redundant.

(Sample "transition" remark 2):
  > [BB] Again, see above - the second signal is purely for transition, so
  > no need to try to convince yourself that it's also a useful backstop in 
  > its own right. Extent-based congestion signalling inherently contains 
  > its own backstop.


What seems to be suggested here sounds like it requires a flag day, unless
the interoperability problems we've seen, which come as a direct consequence
of the proposed major change in the meaning of CE, have a robust solution.

> We need to focus on other ways of mitigating any problems with existing 
> single-queue RFC 3168 AQMs.

Perhaps the right choice is to deprecate classic ECN in shared queues and
have the flag day.  Put that to a consensus call, and if it's really such
a small footprint of people who would be affected, maybe it will fly.

But I do not think we can bless the deployment of something incompatible
without taking this step, and right now it looks like the L4S CE signal and
its associated response is fundamentally incompatible with the classic CE
signal, because of the effect it has on the classic queue.  (And while it's
great that FQ comes with a built-in partial mitigation for the non-compliant
traffic, the core problem here is the signaling incompatibility.)

To me it seems irresponsible to disregard the decades of work that is
now, finally, beginning to come to fruition from people turning on the
widely available and already deployed implementations that only need
a config update to enable, just in time to tell everybody they should
stop doing that and upgrade their hardware and endpoints to this new
idea.

I sincerely wish this problem had gotten more focus early enough for
the companies that have imminent products to realize this proposal
would have serious interoperability issues that now seem intractable.
But that doesn't make it OK to ship this stuff without either organizing
the flag day or finding a robust solution.

Nonetheless, there is some very promising work here, and some real value
looks like it can be salvaged, with time and effort.  That's what's
underpinning my efforts to discuss ways to get the new signal exported
in an incrementally deployable way that wouldn't suffer the interop
problems.

Upgrading the tunneling semantics to provide multiple signals could be
a step forward that could help solve this problem, and might make this
kind of thing possible to get to eventually without needing the flag
day.  It's not fast, but as you point out, the future is much bigger
than the present.

But attempting to wipe out the existing meaning of CE by fiat is a
disaster in the making.  It would wipe out vastly more value than the
unfortunate delay to the immediate plans of the early L4S adopters,
because it seems likely to result in bleaching of the classifier
codepoint that might never go away.

Best regards,
Jake