Re: [tsvwg] L4S: Guard DSCP

[Ingemar Johansson S <[e-mail]>]

Hi

I don't have a desire to take this discussion any further, we have been
there before. You have to weight the risks/benefits with your standpoint and
how/if you wish to adapt to L4S, that's nothing that I (or anybody else?)
can decide for you.

/Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 3 maj 2021 08:34
> To: Ingemar Johansson S <[e-mail]>
> Cc: Greg White <[e-mail]>; TSVWG <[e-mail]>
> Subject: Re: [tsvwg] L4S: Guard DSCP
> 
> > On 3 May, 2021, at 9:21 am, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > This discussion appears to run in circles and each time it delves into
all sorts
> of problems flow aware AQMs will/may see when L4S experiments are run.
> The obvious solution would be to fix these issues as already pointed out
by
> Greg earlier in this mail thread but that appears to be completely out of
the
> question.
> 
> No - the discussion goes in circles because you (in the plural) refuse to
accept
> that L4S is the *cause* of the problem.  I have been consistent in
pointing
> that out, however tiresome it becomes to repeat myself, because it is
simply
> and demonstrably true.
> 
> Notice, for example, that just plain Codel - without the FQ - is an
example of
> the "single queue RFC-3168 AQM" that is *guaranteed* to have problems
> with L4S, while there are merely *some* circumstances where fq_codel is
> unable to supply a workaround.  So FQ is not the villain in this piece.
> 
> The fact is that fq_codel and Cake are out there, and together constitute
the
> majority, at this time, of ECN AQM deployment.  That is the environment
> which L4S must interact appropriately with if it is to deployed on the
Internet.
> Even if we started changing them to accommodate L4S today, the existing
> deployments will not be eliminated for many years - by which time L4S will
be
> a forgotten footnote in the annals of abject failure.
> 
>  - Jonathan Morton