Re: [tsvwg] Neal Cardwell's rationale for supporting ECT(1) as an input/L4S signal

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

Hi Neal,

Thanks for posting this, it’s a helpful explanation.

A couple of points I wanted to respond to:

From: Neal Cardwell <ncardwell=[e-mail]>
> - Much of the installed base of switch hardware around the world can already be configured to signal shallow-threshold congestion with DCTCP/L4S-style CE marks. Many have CE-marking mechanisms baked into hardware, and would need to be replaced in order to deploy SCE.

I wanted to check to make sure I understand:
To what extent do you think it's an L4S goal to accommodate the
existing installed base of switch hardware that’s currently in use
for DCTCP in datacenters?

I thought the existing deployments generally wouldn’t be compliant
L4S-compatible dualq devices suitable for general internet traffic
anyway, and would continue to need traffic isolation the way they do
now.  Is that different from your understanding?

> - More generally, if there is any problem discovered with the L4S experiment, either the algorithm or particular implementations, bottlenecks can easily identify L4S traffic and bleach it into Not-ECT, and treat it like Reno/CUBIC traffic.

To repeat in what's maybe a better thread for it:

I agree that bleaching is an option where there’s RFC 3168 trouble,
that’s a good point and thanks for mentioning it.

I’d consider it a poor choice to land there if there's other options,
because it works against the success of existing or under-way
deployments of RFC 3168 queues by imposing a new bleaching requirement
that may not be trivial for all networks with marking queues

It would also be an unfortunate choice to endorse bleaching because it
would lose much of the potential value in the code point, as David
recently mentioned.

But I do agree it would work, and that it’s a worthwhile mitigation
that should be mentioned in the L4S docs if we end up not finding a
way to support robust 3168 compatibility.

> - Encapsulation/decapsulation is a widely prevalent and important technology today in production networks. With the installed base of encap/decap mechanisms, it is likely that for many implementations any SCE marking applied to packets would just get stripped off with the outer header when decapsulated.

I'd be interested in more information about this.  Is there anything
publicly known about the deployment footprint of different tunnel
implementations in the places likely to deploy L4S dualqs, and
whether they're managed by the same entities who control the queues?

I'm not sure it changes my position much, but it seems at least
useful to know how big a lift it would be to do a tunnel
decapsulation change, if that's a necessary piece of a safe
approach to L4S that can achieve low latency effectively.

(I know Bob gave a long list of tunneling protocols not long ago, but
it seems like only some of them are likely to be relevant to the L4S
question, and probably only in a reasonably specific set of
implementations for at least the early stages...)

Thanks and regards,
Jake