Re: [tsvwg] FQ & VPNs

[Dave Taht <[e-mail]>]

Participating reluctantly, as usual.

On Sat, Feb 20, 2021 at 11:04 PM Ingemar Johansson S <
[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]>
> *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]> 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] <Dave Täht> CTO, TekLibre, LLC Tel: [phone]