Re: [tsvwg] David Black (individual) on safety of L4S for the Internet

[Neal Cardwell <[e-mail]>]

On Sat, May 9, 2020 at 5:42 AM Jonathan Morton <[e-mail]> wrote:
> And that is the case for the "shallow marking" switches you mentioned earlier.  ...
>  a conventional TCP crossing DCTCP traffic in that same switch may find
> itself completely starved.

I guess here "conventional TCP" is referring to a TCP sender using
RFC3168 ECN? The sites that have deployed shallow-marking ECN switches
know who they are, and know not to (and already ensure that they do
not) mix RFC3168 ECN and DCTCP/L4S-style shallow-threshold ECN senders
in the same queue. Part of my point is that because of such issues,
such sites will likely decide they can only deploy L4S, and not
RFC3168 or SCE.

> A consequence of that is that L4S expects the network to be upgraded, in
> full, to either understand its classification signal or implement FQ. The
> *whole Internet*, from datacentre to CDN to core to backhaul to last-mile to
> third-world farmer just trying to check his e-mail. That is not going to
> happen within any reasonable timeframe.

It is not the case that L4S expects "the whole Internet" to be
upgraded. AFAICT the L4S ecosystem is expecting something like the
following:

*If* you are one of the few ISPs that has deployed RFC3168 ECN
bottlenecks that do not have FQ or other mechanisms to ensure robust
fairness properties in the face of flows that mark ECT(0|1) and do not
follow RFC3168, *and* you are not comfortable with the L4S mechanisms
to infer the presence of RFC3168 bottlenecks, then you should either
(a) upgrade your RFC3168 ECN bottlenecks to something with more robust
fairness properties (e.g. fq_codel or cake), or (b) simply change your
existing DSCP rewriting rules at the ISP ingress to bleach ECT(1) to
Not-ECT (or any other mechanism of your chosing to treat ECT(1) as
Not-ECT).

neal