Re: [tsvwg] FQ & VPNs

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

Jonathan

So.. on the one hand you can set up multiple VPN's to overcome the fq-codel problem. But then when I mention that you can use that very same method to put L4S traffic it becomes overly complex. I am not going to analyze what makes it so hard. 
I've seen similar arguments in the past in the form of edge devices that are impossible to upgrade.  

I believe that we (the WG), has to make a decision. The current discussion has been ongoing for almost 2 years. Are we going to put arguments back and forth for two more years.. or work together to bridge the gaps ?. After all fq-codel with L4S support would have been ripe and ready in one year if there had only been an incentive to have it done. Why not spend the time and effort on that instead?  

/Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 21 februari 2021 18:50
> To: Ingemar Johansson S <[e-mail]>
> Cc: Dave Taht <[e-mail]>; Bob Briscoe <[e-mail]>;
> TSVWG <[e-mail]>
> Subject: Re: [tsvwg] FQ & VPNs
> 
> > 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