Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

Michael Welzl <> Fri, 04 December 2020 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4F723A09A4 for <>; Fri, 4 Dec 2020 03:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gbuueTFp5wOi for <>; Fri, 4 Dec 2020 03:49:02 -0800 (PST)
Received: from ( [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D0403A0100 for <>; Fri, 4 Dec 2020 03:49:02 -0800 (PST)
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim (envelope-from <>) id 1kl9a8-0008Sb-By; Fri, 04 Dec 2020 12:49:00 +0100
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim (envelope-from <>) id 1kl9a7-000Bxg-K0; Fri, 04 Dec 2020 12:49:00 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Michael Welzl <>
In-Reply-To: <>
Date: Fri, 04 Dec 2020 12:48:59 +0100
Cc: Wesley Eddy <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Jonathan Morton <>
X-Mailer: Apple Mail (2.3608.
X-UiO-SPF-Received: Received-SPF: neutral ( is neither permitted nor denied by domain of client-ip=;; helo=[];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 21B1FB14B315DF6CBB35E7836F6038FF3F414C5F
Archived-At: <>
Subject: Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)
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: Fri, 04 Dec 2020 11:49:05 -0000

> On Dec 4, 2020, at 12:45 PM, Jonathan Morton <> wrote:
>> On 4 Dec, 2020, at 1:33 pm, Michael Welzl <> wrote:
>> Right; bad! But the inherent problem is the same: TCP Prague’s inability to detect the 3168-marking AQM algorithm. I thought that a mechanism was added, and then there were discussions of having it or not having it?  Sorry, I didn’t follow this closely enough.
> Right, there was a heuristic added to TCP Prague to (attempt to) detect if the bottleneck was RFC-3168 or L4S.  In the datasets from around March this year, we showed that it didn't work reliably, with both false-positive and false-negative results in a variety of reasonably common scenarios.  This led to both the L4S "benefits" being disabled, and a continuation of the harm to conventional flows, depending on which way the failure went.
> The code is still there but has been disabled by default, so we're effectively back to not having it.  That is reflected in our latest test data.
> I believe the current proposals from L4S are:
> 1: Use the heuristic data in manual network-operations interventions, not automatically.
> 2: Have TCP Prague treat longer-RTT paths as RFC-3168 but shorter ones as L4S.  I assume, charitably, that this would be accompanied by a change in ECT codepoint at origin.
> Those proposals do not seem very convincing to me, but I am just one voice in this WG.

Yeah, so I have added my voice for this particular issue.