Re: [tsvwg] ECT(1) Flag Day Plausibility

["C. M. Heard" <[e-mail]>]

On Sat, May 8, 2021 at 8:29 PM Holland, Jake  wrote:

> With those examples as context, I'll start by stating that I don't
> see a reason it would be harmful to change the standard behavior
> to treat ECT(1) as NECT instead of as ECT(0) in middle boxes, so I
> don't know what objections would be raised to a standards track
> document doing that?  (Aside from futility as we move to L4S, which
> I'll try to address below.)  So I'm assuming "none" for the sake
> of this argument.
>

Jake, the question that arose for me on seeing this proposal was:

Why not instead try to clean up tunnel behavior so that the transitions
ECT(1) -> ECT(0) and ECT(0) -> ECT(1)  within the network make it through
tunnels? If we go for a flag day, wouldn't this be more profitable?

The specification change would be to one case in RFC 6040 Fig. 4. The other
steps would be as you describe.

The issues that I see with treating ECT(1) and not-ECT are

   1. The fundamental problem is the incompatible meaning of CE, not that
   of ECT(1)
   2. Treating ECT(1) as not ECT forecloses many options. Fixing tunnel
   behavior does not.

Allow me to quote from Martin Duke's message of March 26 (see
https://mailarchive.ietf.org/arch/msg/tsvwg/qosIqFlvjo9ZPKYoTzF1V8ZmI6g/):

On Fri, Mar 26, 2021 at 10:15 AM Martin Duke wrote:

> Bob has identified all of the problems with using DSCP for L4S. Among them
> is running L4S through a tunnel.
>
> Another axis of discussion was changing the L4S signal to be
> ECT(1)->ECT(0) and preserving the CE signal (thread: [1]), which
> comprehensively solves the coexistence issues. But this fell down,
> partially because of the (needless) RFC6040 tunnel decap behavior, which
> will revert any outer-header changes. There are some other problems, of
> course, they don't affect bystanders and I don't see them as likely to be
> fatal.
>
> Honestly, if we're going to break L4S in tunnels anyway, I would just as
> soon break it with the semantic change and not take all the other DSCP
> baggage that Bob describes. We could even bis the mistake in 6040 so that
> "eventually" the needless behavior goes away.
>
> This is not a statement in favor of 1->0 marking. It is a statement that
> if the WG is going to insist on a DSCP to ship this design, I would prefer
> 1->0 over that.
>

Mike Heard