Re: [tsvwg] FQ & VPNs

Jonathan Morton <chromatix99@gmail.com> Sat, 20 February 2021 21:28 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9003A0D93 for <tsvwg@ietfa.amsl.com>; Sat, 20 Feb 2021 13:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC_ja3b6PpI3 for <tsvwg@ietfa.amsl.com>; Sat, 20 Feb 2021 13:28:51 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81423A0D91 for <tsvwg@ietf.org>; Sat, 20 Feb 2021 13:28:50 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id a17so43567756ljq.2 for <tsvwg@ietf.org>; Sat, 20 Feb 2021 13:28:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4dEhKl8P9t7gVXMY4voNG+ymiTmaqa3g2FYpteqYXKI=; b=fc1BnPn4U3fVxCp8PR48XeeWs61z0eRcnTeXi6/r7xusj6PlTw99KBXbR0rY6NIRaO XL5VxcZ7Itj4uKtkRPD6grxAQspqDElUfPsakhQ2oNi/8WCo0R46Hn9Ez1PIp3z5MnpV 9G3pnrBqQ55rVKO+0eCyYTrQPOeqdHOviX8mAoR8IZkECk18u+rTVngMt/6v9rsfgClh ZX6uCz880U5BM0XRO57EZdN8QwHyXdvu3HouyhWLUDP/2GUAyyWpke3v8rludgZPw8F5 l+HxEkgnUeWsfK8VLsSNmUPXwzXXZNTVqF9D+A+58vKnL3zEdSogC/yp5iYEZcoqbuCy BjYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4dEhKl8P9t7gVXMY4voNG+ymiTmaqa3g2FYpteqYXKI=; b=Vi9/R6e2BkILlVWzgbUmQHGmcaXocJ+1foNflVlj+n3qOMjraodaiYcx+UDaWduFbm XG7qpaRGSZwe/SDls6lh03BrNzUKStr3JY4PxtyfJkj3kbKCBRdG02fnlAW4Yoyxcjvm Yc9az27qzCBkeoabsqtFa2PqzCKmoRmhYO4+34IiuoY7bkc/03dHIAcfg2yUq0Yxh2Ud B8wtE7wn56Odm4OEWeh8a+rrqvqjpKCfpDmv2VULyPsSPtAglILleEv+dKge93Lx0fRU HhwIcxFaJie5Cu7i1kN7+B7NOu0ivjFi9HyBNz8rZmLn2rH95fkGRwP6jKnuVzTtniaA swFQ==
X-Gm-Message-State: AOAM532ogb/js1V0nbf2sk4Zy7du/BEUceceHXo4IRSIKe83BUB5Q0nk hVGGz1RjOwts98o1sW64sd1IT9rRZ2A=
X-Google-Smtp-Source: ABdhPJz5HYGVJdTUk21SKVJtv2y9md2RvD+XgMYFnHETx8IleyuVKBs+PPDLOgQkBGjVwhSE1lybbg==
X-Received: by 2002:a2e:3203:: with SMTP id y3mr9174337ljy.449.1613856528883; Sat, 20 Feb 2021 13:28:48 -0800 (PST)
Received: from jonathartonsmbp.lan (176-93-29-60.bb.dnainternet.fi. [176.93.29.60]) by smtp.gmail.com with ESMTPSA id m11sm1194511lfo.168.2021.02.20.13.28.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Feb 2021 13:28:47 -0800 (PST)
From: Jonathan Morton <chromatix99@gmail.com>
Message-Id: <13EBAF97-A9AF-47A1-AB71-546C31F762C2@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D10A428D-57B1-4E9C-B83F-A210FBAB329F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Date: Sat, 20 Feb 2021 23:28:45 +0200
In-Reply-To: <HE1PR0701MB2299CF42CA83576C86070BB0C2839@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Cc: Dave Taht <dave.taht@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, TSVWG <tsvwg@ietf.org>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
References: <161366419040.16138.17111583810851995947@ietfa.amsl.com> <BF0810D9-E742-4FCB-90B1-6957551B585D@heistp.net> <b222bbdf-70ae-3e5b-b122-1160299fb4e2@bobbriscoe.net> <E7CC88FA-F064-4B72-BAA9-8BE40F7AF040@gmail.com> <52cb434a-bd91-6260-7be9-85bdbd07b625@bobbriscoe.net> <BCAB7068-A10A-4FC4-9719-E300F644262C@gmail.com> <43f43fa2-69c4-bc10-3ffb-e95e41809335@bobbriscoe.net> <4835a3cd-4d88-68ac-d172-1e21bc42a150@bobbriscoe.net> <CAA93jw7_yvkqU-uxHkbHkO2g_RFmzCmJcxQhMJcBQjo=+QMh=w@mail.gmail.com> <HE1PR0701MB2299CF42CA83576C86070BB0C2839@HE1PR0701MB2299.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FAL1iGWueATz8yOVtHPsDdzU9aI>
Subject: Re: [tsvwg] FQ & VPNs
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Feb 2021 21:28:54 -0000

> On 20 Feb, 2021, at 8:42 pm, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> 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