Re: [tsvwg] FQ & VPNs

[Jonathan Morton <[e-mail]>]

> On 21 Feb, 2021, at 9:04 am, Ingemar Johansson S <[e-mail]> wrote:
> 
> 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 the current situation, where the flows sharing the tunnel do so on a roughly equal basis, the choice is an *optional* performance enhancement, to be undertaken only when actual experience shows it to be necessary.  Usually it is not enough of a problem to bother with the hassle - and it *is* a hassle, because by default VPNs do not work that way.  I mentioned it only to illustrate that the VPN user has some agency and is reasonably able to predict what will happen, and know that it won't be too bad either way.

Adding L4S to the mix means that the flows no longer share the tunnel on anything even approximating an equal basis.  A single L4S flow will bully all others out of its way, as soon as the bottleneck is at a conventional ECN AQM (whether with FQ, AF, or not).  It does not even matter whether the conventional flows support ECN themselves; if not, the conventional AQM will simply drop their packets at the same rate that it would have marked them, producing the same effect on congestion control and throughput.

Which means that separating the L4S flows out to a separate tunnel becomes *necessary*, not optional, to retain anything resembling normal performance.  And this would *not* be helped by deleting FQ from the AQM in question, as Bob suggested earlier; that would only permit the L4S flow to bully flows outwith the tunnel that happen to traverse the same bottleneck, rather than its harm being contained to the tunnel it occupies.

While the VPN user might reasonably be able to estimate the number of flows running through his tunnel, he might not be aware of the particularly drastic effect that L4S traffic would have.  I think it likely that his troubleshooting will lead to a conclusion that the L4S traffic is "unresponsive" to congestion control signals, immediate shutdown of the L4S traffic source, and a strongly worded letter of complaint to the vendor(s) perceived to be responsible for it.

> And then, there is always a possibility to upgrade the AQMs to support L4S as well ?

To be deployable outside of carefully prepared networks, L4S *MUST* be capable of coexisting, at default settings, with conventional traffic in existing networks.  That is mandatory, not optional.  Pete's new data is prima facie evidence that fq_codel (and other ECN AQMs) is a feature of existing networks.  I'm sure you can work out the logical conclusion to that equation.

 - Jonathan Morton