Re: [tsvwg] FQ & VPNs

Jonathan Morton <> Sun, 21 February 2021 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04D7B3A0D9C for <>; Sun, 21 Feb 2021 09:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nW7femLXRSmC for <>; Sun, 21 Feb 2021 09:50:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E5043A0D9B for <>; Sun, 21 Feb 2021 09:50:00 -0800 (PST)
Received: by with SMTP id a22so51519219ljp.10 for <>; Sun, 21 Feb 2021 09:50:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FNkblPurX0WCm3X0oIJF5xKCXzQtAgq51X6Y6aAZptI=; b=sJ2fR7yfg0pC52PJGznHtOCBxXkFJKwUbrz3iOOeRfZ3WkMWs/22yvrblSzzyWAE+5 vSFnQeOITuNhzJF8GgCZwtW4Y8hG6PSbBQt2LDvxcd0rbVa7lHeXnCSZfR9R3eq47wT8 EOnHQn5kJYi/9YR8OcB1+SXPn3X0e1QsApnzZL52G+7f0JQ8daaJ0VXXP5KUR4uAmo9n rC9cOlie0LbIyvAzSpkGED/aAnorY418w9lE+C25m+A9qVYK0QqmBbDEVqzRaAFEDmtn DiPolqdVGpUE53wQD3SHwnTVN80uFiIysXtcB/PurlySthgQSLzVHFyWf17nFidVjxNp oCzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FNkblPurX0WCm3X0oIJF5xKCXzQtAgq51X6Y6aAZptI=; b=ZVWVGIhavRo4NGplJAy//SmMzNF+QOyrC1HV8diHkD6kUgIPONnVWBLd21i4SQnE1k BH0cf06+R7uj7YxBI2pFvMXvw9YkvaiEnTJ8uC5HOTBh/CndFo76VYSg71Uz6vGsnck+ GnXF3q1kcIDKd2sPMpmKQ6ylXwCJGPqcLEur195gCYgztCOIt8N039MD2AWy2yJmNVba 5Vgz//5jjsxrhcY6VFRM1lx0PnplxOhyf3MRNPyrh2W3FM+oPS4ZjbNt2UJ9BoH0q5nm LE3KmAvdou+jTyLGX/v+qBDUR7p0pfjBjqTO4yiSyONW5LjH8xRTyA+/S0M6vAQBlETF X6ow==
X-Gm-Message-State: AOAM531oKohOcOlkEvVFsgjv1cxzei1ZeRnLKXOpWPNaCC9Kl6CzHO+n lBYLpAsdBo0lO41P74yHO30=
X-Google-Smtp-Source: ABdhPJymXNB0IBzFeYmRwCAadsc3Ph6J2GCBPRlb23Vjfg5TePRQ2lJDCs3/EubESPI7x1/GXjn7Wg==
X-Received: by 2002:a19:c7c7:: with SMTP id x190mr11073896lff.558.1613929799027; Sun, 21 Feb 2021 09:49:59 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id h11sm1013166lfc.298.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Feb 2021 09:49:58 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Sun, 21 Feb 2021 19:49:57 +0200
Cc: Dave Taht <>, Bob Briscoe <>, TSVWG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] FQ & VPNs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Feb 2021 17:50:04 -0000

> On 21 Feb, 2021, at 9:04 am, Ingemar Johansson S <> 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