Re: [tsvwg] L4S: Guard DSCP

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

Hi Jonathan

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. 
This gives me the impression that fq-codel is used as a pawn in this endless debate for whatever reason. I don't believe that it will be a particularly successful approach in the long run if L4S proves to be widely picked up. If you want fq-codel to be relevant in the future you should really take possibility that L4S will fly into account and weight the risks/benefits accordingly. 

/Ingemar


> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Jonathan Morton
> Sent: den 1 maj 2021 19:18
> To: Greg White <[e-mail]>
> Cc: TSVWG <[e-mail]>
> Subject: Re: [tsvwg] L4S: Guard DSCP
> 
> > On 1 May, 2021, at 12:21 am, Greg White <[e-mail]> wrote:
> >
> > There has been little evidence shown of single queue RFC3168 bottlenecks.
> In Pete Heist’s data (one small ISP in Czech) the known instances of RFC3168
> were all fq_codel, and the rest of the observed CE markings were agreed to
> likely be fq_codel or CAKE as well.  Similarly the earlier data from Apple
> showing some level of ECN marking in France were consistent with the
> reported fq_codel deployments by one of the ISPs there.  Also, I don’t
> believe that any ISP has come forward to state that they have single queue
> RFC3168 bottlenecks in their network (and, given the amount of list traffic on
> this topic, I would assume that any ISP that monitors TSVWG would have
> self-identified by now).
> 
> Let's not forget that there are other ways that parts of the 5-tuple can get
> hidden from an otherwise flow-aware AQM.  When all the flows are of
> conventional type, this is only of minor consequence.  When an L4S flow gets
> mixed in, there is a big problem which the conventional flows' endpoints
> have no way to mitigate (in particular, disabling ECN for themselves doesn't
> help).
> 
> We've shown that this can feasibly happen with existing VPN tunnels, and
> we saw some evidence of VPN tunnels being used in the Czech data.  Though
> we couldn't reliably conclude that ECN was being used over them, that does
> not mean there is no problem.  If L4S endpoints were introduced at both
> ends of one of those tunnels, there would be L4S traffic over that tunnel,
> and that would interact with the conventional traffic in that same tunnel,
> regardless of whether it was RFC-3168 enabled or Not-ECT.
> 
> The persistent minimisation of this externalised risk by calling it "rare", rather
> than tackling it honestly, is a big part of why I, and others I'm aware of, do not
> trust L4S to conduct their experiment safely or produce an accurate appraisal
> of the results.
> 
>  - Jonathan Morton