Re: [tsvwg] FQ & VPNs

Sebastian Moeller <> Sun, 21 February 2021 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 214EE3A11B2; Sat, 20 Feb 2021 17:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mddzG_Cltkpo; Sat, 20 Feb 2021 17:21:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86F4F3A11B0; Sat, 20 Feb 2021 17:21:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1613870435; bh=eQkd4V2MVB+J8jr7Qc1mKzbfBKBiprcdmWXX31f03O0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=YK7B9fIVQ2/uWcNdU5NK/gsCjGgJd5P2PqW0sX77OEPtxEG8g7WV3WA2Ox0O6jhgm SOGmjTltLtKbglNfHHszJQCUhnNJXIPqw8UeC1KiGK/3bv4lgrwwwXqGZ0pt/PDdpp DsA6gO27Flx8YYuJKmyR7qOQtiFV4CVO3RWI6n4k=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1MEFvj-1l5cX82TiP-00AHwI; Sun, 21 Feb 2021 02:20:35 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Sun, 21 Feb 2021 02:20:30 +0100
Cc: =?utf-8?Q?Dave_T=C3=A4ht?= <>, Bob Briscoe <>, TSVWG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:0r/vPZDjI5npi3wQIC/rIYW4TlHqHl8olYJU0zfoxTiq1V5RPFW tPgKdK7ri2PjBM28h4DVs6rop/X79eKZJ0Vch/w4pzr7WpC2QlDhAkzfSHIDQieIzO/RT+c 5hTt4tyI1Gc8WEOUpwq7tXZ3ZyseYcSBM1jOCeFg/QfvRGxCMtXIXWyoOcl+iDWotQxu1UT cjGkHX9Cl1RTyF21CAZPA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:XwT4PRo8WbM=:CEmqyS/6xrMegrKX3lgsFh IPkB/jS26YzbFV6wnL+eWnBM5bTF8pzDB5+TE9YfYj+kDLf0mzY0xIBGpMB8YS2i281V1rkCH sfF8gtEsoaPFucyfXgxkL/G+20kKSjqSi0p3N4JUsL5kDo2uNaTIeqSjbFWNezpAJG3vyvRjS EzUQI0OIcur1hLb3qwkx7BOKSa5JthnT1juKgyiXgHVw+3n+jeii8sjlk1Ze/eckJ6xh+i0Sa c6M2HSiU70iTEbsz0qg9sdMOrJhzQ+wIT9BiAYcVzLhriC6Q5G76trLS0i9F0/QBgAw6zUNy7 4qa5Ebez1ZocxzTLw5MxjiSraZaNADQHvPZkP/82pf/mDhQ2FXFYSo31RK3KI89OLtB9c7hlY nDY0kRvyOtnq6FrRE6gJimlj+rS/KnyrM92uyc3g76RJUTC37EPf5beL1wEuh0dcKSAkCEahG X7DM7/uu00gBvgw/6mlZF2hhDXupAjq2YRQ6z1yFz6Xl5ajSQQg/2ds9YOcSECu91DAHv5jI9 oiAB2E/qwWGovpXMwyDKwxINZ8ZYPAsPG/t8sMdeLzyz5y8QJVxVibv5utxTChuuJTeHLldgM fOqlSQL5I9L6S0n0dIFsw47fLAjIuL/Of0tJf9GrgdLVPk9I2bFzZ6Kih/r7igaZ4woAZVmyd fvSalJOrXlFrypmuANpbWRgUAqL8ckflvG8+p6KR5PLWQoGM/SboQAxM5NqR7/E3TZISTGMDw YXFLgwNfHgC9rPJpwWUbdd7J9XsUmSVJG1A5i2PfJS2mUP5yTfxj7sxFZOTiMli9Ung1LC1k8 UeDc8MfNNqj0bjjy7EK3YA1XRZe1cunE/adgNFBJsM/Ev/MNGkhopN/JmDKyN5d7Nw+IEIV4s eRULD/nYjyT54YQsPuQQ==
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 01:21:31 -0000

Ingemar, List,

let me note that a tunneled connection as you seem to describe, will either yield and behave like a single flow at any AQM/bottleneck or will risk to look like a non- or  under-responsive flow that violates the internet's assumption of rough equitable sharing of capacity (TCP-friendlyness).

	Sure, the tunnel end-points might know that the tunnel carries X flows and hence might consider it desirable and "fair" to get roughly X/N throughput on a congested node with N true flows, but how is the intermittent node expected to figure this out and still assure rough sharing?

	Are you really proposing that all bottleneck nodes should give the least responsive flows most capacity? That seems like an ideal strategy to be 
exploited/gamed by all transport protocols, leading to a race to congestion collapse. 

	As before, I am happy to concede that approximate flow fair queueing is almost never optimal, but also rarely pessimal, and without additional information probably the most deterministic/predictable behavior an intermittent node can choose. 

	In theory we could use the IPv6 flow label to pass information about flow identities to the outside of tunneled packets, in which case FQ will work reasonably well (this is harder to game, unless the traffic is completely re-ordering tolerant, as an FQ system only maintains order inside each "flow", but is free to re-order between flows).

	None of that discussion seems novel or particularly pertinent at this point in L4S' evolution though; how did we end up in this side-discussion again? Ah, yes, L4S' lack of safety by design; the point is that the argument has been made multiple times that L4S' under responsiveness to CE marks could be ignored assuming most all rfc3168 AQM employ FQ and hence the fall out of L4S's wrong interpretation of CE marks would be restricted to the (stochastic) queue used mostly be the L4S flow itself and hence would not cause harm to other traffic. Which has two issues, one: due to the birthday paradox hash collisions are not that rare, that L4S will cause harm to non-L4S bystander flows that happen to hash into the same queue, and the whole thing goes pear shaped with tunneled traffic containing a mix of L4S and non L4S packets. 

Best Regards

> On Feb 20, 2021, at 19:42, Ingemar Johansson S <> wrote:
> Dave, Jonathan
> Getting back to the subject. 
> 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 ( 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.
> 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 ?. 
> /Ingemar
>> -----Original Message-----
>> From: tsvwg <> On Behalf Of Dave Taht
>> Sent: den 20 februari 2021 02:22
>> To: Bob Briscoe <>
>> Cc: TSVWG <>
>> Subject: Re: [tsvwg] FQ & VPNs
>> It takes an awful lot here for me to bother to reply to a thread.
>>> Here is an algorithm to find the truth. Take one of your emails, and do a diff
>> with the previous email in the thread. Then the other person's text that you
>> silently deleted (as above) will invariably be the truth.
>> Here is a better algorithm to find the truth. Purchase any of dozens of
>> commercial routers today running cake or fq_codel, or the thousands
>> available via reflash to openwrt/dd-wrt/tomato construct a repeatable
>> experiment, and publish the code and results. The results from running,
>> repeatable, code trumps theoretical objections every time.
>> The evenroute v3 and edgerouter X series are pretty good bases for
>> experimentation.
>> Wilful ignorance, and the lack of a willingness to construct repeatable
>> experiments is not science. If you have a point to make, make it with a
>> repeatable experiment against running code, please.
>> Tuning out again.
>>> Bob
>>> --
>> __________________________________________________________
>> ______
>>> Bob Briscoe
>> 86073b36ea28-0086813e29ae2dfb&q=1&e=e1b27d62-c59c-43ba-b512-
>> e8cf13c35f2c&
>> --
>> "For a successful technology, reality must take precedence over public
>> relations, for Mother Nature cannot be fooled" - Richard Feynman
>> <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729