Re: [tsvwg] FQ & VPNs

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

Hi

 

The question.. fq-codel took 8 years to deploy, does this mean that it takes 8 more years (or 5 or whatever) to roll out fq-codel that supports L4S ?. Note that we have by now spent almost two years arguing on the TSVWG list.  These two years could have been spent more wisely, for instance on studies on how to integrate L4S in fq-codel (or the like). 

 

And also.. even though I am enthusiastic about L4S, I don’t expect it to happen overnight. This would give you time to update fq-codel for L4S and have it deployed. Meanwhile algorithms that fallback to RFC3168 ECN and/or separate VPN tunnels for L4S traffic can do some damage control. 

 

/Ingemar 

 

 

From: Dave Taht <[e-mail]> 
Sent: den 21 februari 2021 13:00
To: Ingemar Johansson S <[e-mail]>
Cc: Jonathan Morton <[e-mail]>; Bob Briscoe <[e-mail]>; TSVWG <[e-mail]>
Subject: Re: [tsvwg] FQ & VPNs

 

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. 

 

Total (documented) L4S market penetration of its mis-interpretation of the CE field - 0. I might be kind and say "alternate", rather than mis, but slamming L4S through a rfc3168 fq_codel'd system does have the documented effects so often discussed here.

 

The ce_threshold parameter has been part of fq_codel for many years also. Tweaking that to instead trigger off of ECT(1) is straightforward. Without clear data - which we didn't have at the time of this debate hitting public mailing lists - doing that seemed dicy - and there was indeed a encapsulation bug regarding that transition that was found and fixed a while back which will take years to propagate to the field, also. 

 

The SCE alternative is a backward compatible interpretation of the ECN related bits - and fails safe -  and could have gone into wider distribution 2 years ago with near zero impact on end-user OSes, and as gradual upgrade, and been (well, actually, has, as fq_codel_fast and the alternate cake have been tested by a few parties at this point) tested as to other impacts. Coupled also with a DSCP field a la "nqb" (and preferably a few other dscp bits) it could be effective, sooner.

 

I have been tempted a lot to at least make SCE available as an option in the upcoming openwrt release, but neither side has made a convincing argument that doing this to ECN at all makes sense, and in fact the flood of negative data on it (rtt unfairness in particular), makes me more inclined to just recommend ecn be disabled entirely.

 

 

With that said.. I believe that Bob is right. It benefits the TSVWG group better that we continue this discussion off list. It is just the same old arguments over and over again, albeit packaged in different wording. 

 

/Ingemar

 

From: Jonathan Morton <[e-mail] <mailto:[e-mail]> > 
Sent: den 20 februari 2021 22:29
To: Ingemar Johansson S <[e-mail] <mailto:[e-mail]> >
Cc: Dave Taht <[e-mail] <mailto:[e-mail]> >; Bob Briscoe <[e-mail] <mailto:[e-mail]> >; TSVWG <[e-mail] <mailto:[e-mail]> >
Subject: Re: [tsvwg] FQ & VPNs

 

On 20 Feb, 2021, at 8:42 pm, Ingemar Johansson S <[e-mail] <mailto:[e-mail]> > wrote:

Quoting Jonathan " However, I would remind you that neither SFQ nor fq_codel can distinguish between flows carried inside an encrypted tunnel, so this cannot be relied upon alone to make L4S safe.  Pete's data shows significant tunnelled traffic, much of which is probably due to people working from home and using VPNs to access a corporate network."

This line of reasoning makes me confused.
Section 6.2 in RFC8290 ( https://tools.ietf.org/html/rfc8290#section-6.2) clearly says that fq-codel will not deliver its intended benefits for encrypted tunnels. If ISP's still rely on fq-codel to do it´s job well even though a substantial share of the traffic is VPN, then that is of course a problem. But I see that only as an fq-codel problem.

 

I will just note here that although treating a VPN containing multiple flows as a single flow results in a reduction in throughput, when it has to compete against other traffic at a saturated bottleneck, this is a relatively minor and infrequent event at the ISP in question.  

 

The degree of impairment experienced by the VPN is also strictly bounded by the number of saturating flows carried within it.  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.

 

So what I cannot at all understand.. Why should a known problem (or read design feature) in fq-codel (or SFQ) be interpreted as something that makes L4S unsafe ?. 

 

The problem is entirely due to L4S flows' harm to conventional AIMD flows when passing through the same queue and AQM instance, unless the AQM is of a type that specifically understands L4S.  This is a predictable and inevitable consequence of L4S flows responding qualitatively less (by what is effectively an Additive Decrease, despite claims to the contrary) to each CE mark than defined in either RFC-3168 or RFC-8511 (which both mandate a Multiplicative Decrease to a single CE mark).

 

Consequently, if L4S and AIMD flows share a single VPN tunnel, which passes through a conventional ECN AQM at the bottleneck, the AIMD flows will collapse to a very low throughput.  It is crucial to understand here that all existing ECN-marking AQMs deployed in the Internet today - most of which are fq_codel or similar - fall into this category.

 

I attach an example of the likely consequences.  The red trace at the top is L4S throughput; the light blue trace at the very bottom is the AIMD flow starting ten seconds later.  You may refer to previous data sets published by Pete Heist and myself for further examples.

 

 - Jonathan Morton

 





-- 

"For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman

[e-mail] <mailto:[e-mail]>  <Dave Täht> CTO, TekLibre, LLC Tel: [phone]