Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

[Martin Duke <[e-mail]>]

Hi Bob

On Mon, May 10, 2021 at 2:42 AM Bob Briscoe <[e-mail]> wrote:

> [BB] The RFC6040 tunnel behaviour shouldn't be thought of as needless. The
> valid ECN transitions are the primary security property of the ECN protocol
> at the IP layer. If it is valid for a middlebox to undo a previous increase
> in severity, it becomes hard if not impossible {1} to add enforcement
> around the system, if found to be necessary later.
>
> I say 'valid', rather than 'possible', advisedly. It's always possible,
> but if it's not valid, it can be detected as an attack, so enforcement
> mechanisms  can be retrofitted. For instance, the Congestion Exposure
> (ConEx {2}) policing and audit enforcement mechanism [RFC7713] relies on
> only upward severity transitions being valid. That's inherent for loss (you
> can't unlose a packet). And it's true for ECN CE. But if both 0>1 and 1<0
> were valid for ECN, I'm certain it would make it hard if not impossible {1}
> to enforce anything about these intermediate transitions, if it became
> necessary in the future.
>
> When we had to choose which would have the higher severity between ECT0
> and ECT1 for RFC6040, I remember going round the relevant intarea and
> secarea groups giving brief heads-ups over a few IETF cycles emphasizing
> that this was a fork in the road - paraphrasing "It's a change to IP v4 &
> v6 and if anyone can see any reason why it should be the other way round,
> speak now or forever hold your peace".
>

Thanks for the context. Maybe "needless" is too strong of a word -- but
this ECT(1) inner/ECT(0) outer combination should not actually happen in
today's internet, and if we could take it back to make this proposal work,
I think we would.


>
> Whatever, as I've said before, relying on any change to the ECN behaviour
> of tunnels is a deployment challenge orders of magnitude greater than ECN
> or L4S is (and they are already 3-party deployments). The number of types
> of tunnel, the number of vendors of each, the tendency of some to be
> implemented in hardware, and their typical lifespan create a far greater
> combinatorial problem for deployment. But the main problem is that their
> developers are not in the companies and departments of companies that would
> monetize any of the improvements that L4S would bring. It would just be
> cost for them
>

I am happy to defer to your deployment experience. I agree this is a
significant problem, but my original argument is that it is a smaller
problem than the ones introduced by the Guard DSCP. If you disagree, and
would actually prefer the Guard DSCP, I am happy to withdraw the
suggestion.

Martin

>