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

[Luca Muscariello <[e-mail]>]

On Sat, May 9, 2020 at 3:55 PM Neal Cardwell <ncardwell=
[e-mail]> wrote:

> 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).
>


The network operations you describe above assume that the issues
are just about the heuristics used by DCTCP in L4S to fallback
to ECN RFC3168 or the separation of DCTCP and TCP.

The behaviour of L4S at the bottleneck is actually
well defined by dualQ
https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11
<https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11>
So, the safety issues are more complex as I wrote
in my rationale that summarizes, I think, many other concerns
in the message below.

https://mailarchive.ietf.org/arch/msg/tsvwg/T3CLKTE6gRjV_6cBjTO7ALe4h7Q/


>
>