Re: [tsvwg] FQ & VPNs

[Tom Henderson <[e-mail]>]

On 2/21/21 4:00 AM, Dave Taht wrote:
> Participating reluctantly, as usual.
> 
> On Sat, Feb 20, 2021 at 11:04 PM Ingemar Johansson S 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi____
> 
>     __ __
> 
>     Trying to summarize. Your concern is that the L4S flows starve out
>     the non-L4S flows when they share the same VPN tunnel. ____
> 
>     You proposed the solution yourself below: ____
> 
>     “The VPN user is thus in a position to predict, understand, and
>     possibly mitigate the effect by splitting the traffic across
>     multiple VPN flows, if performance turns out to be more important
>     than hiding that piece of information”. ____
> 
>     The same rationale can be used to put the L4S flows in a separate
>     VPN tunnel, problem solved.____
> 
>     __
> 
> 
> In terms of VPNs there are multiple other problems. Site-site, bare 
> metal, running fq_codel over ipsec
> 
>     __
> 
>     And then, there is always a possibility to upgrade the AQMs to
>     support L4S as well ?. It always appear from your argumentation that
>     fq-codel is some kind of untouchable monolith that cannot at any
>     cost be modified, unless of course you see a possibility that VPN
>     tunnels can somehow leak inner header information (see separate
>     discussion around draft-ietf-tsvwg-transport-encrypt)____
> 
>     __
> 
> 
> It's not an untouchable monolith. It is merely the default qdisc in 
> nearly every linux distribution at this point, ios, and osx. It is used 
> by 10s, maybe 100s of millions of devices at this point. It is part of 
> billions of containers. With nearly 9 years of deployment into an ever 
> increasing number of embedded devices that typically lag 5 or more years 
> behind the mainline OSes. Making changes to how ecn is interpreted would 
> take 8+ years to flush out of the field.

Dave, it seems to me that this could be taken in two steps, in much less 
time than 8+ years for the majority of devices, given that most are (or 
should be) patched for other security reasons.

1) upstream a patch to the Linux kernel (and ask other OS vendors to do 
similarly) to treat ECT(1) as not-ECT
2) later add options to enable alternative semantics of ECT(1)

I don't see any reason to postpone the first step.

- Tom