Re: [tsvwg] FQ & VPNs

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

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.

 

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)

 

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]> 
Sent: den 20 februari 2021 22:29
To: Ingemar Johansson S <[e-mail]>
Cc: Dave Taht <[e-mail]>; Bob Briscoe <[e-mail]>; TSVWG <[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