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

[Bob Briscoe <[e-mail]>]

Mike,

On 10/05/2021 00:26, C. M. Heard wrote:
> 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.
>

[BB]
On 1. the two meanings of CE are both 'highest severity', which is all 
tunnels need to care about. So I don't see what you mean here.
On 2. I agree - on both your sentences.
But you'll see from my response to Martin just now ( 
https://mailarchive.ietf.org/arch/msg/tsvwg/GuqY3UvUE78VNcZVR5S7PRipAes/ )
that I strongly believe that the 'changing-tunnel-behaviour' ship has 
sailed. We have to move on.

We had to choose which number was higher. In hindsight the other would 
have been better.
a) Enabling both 1>0 and 0>1 in tunnels would foreclose much more 
subtle, but possibly much more important, security options.
b) Switching tunnels from 1>0 to 0>1 would effectively be equivalent to 
(a) for 2 or 3 decades.

Thx for pointing Martin's posting out. I was off mail over that period 
so you'll see I've just replied to it. Pls treat that as a partial 
answer for you to.

Cheers



Bob

> Allow me to quote from Martin Duke's message of March 26 (see
> https://mailarchive.ietf.org/arch/msg/tsvwg/qosIqFlvjo9ZPKYoTzF1V8ZmI6g/ 
> <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.
>



Bob

>
> Mike Heard

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/