IETF Logo Mail Archive

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

Jonathan Morton <chromatix99@gmail.com> Fri, 04 December 2020 11:45 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 C75AA3A0B8B for <tsvwg@ietfa.amsl.com>; Fri, 4 Dec 2020 03:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
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: 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 dKVORwMu1Ert for <tsvwg@ietfa.amsl.com>; Fri, 4 Dec 2020 03:45:37 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 42ED23A0B8A for <tsvwg@ietf.org>; Fri, 4 Dec 2020 03:45:37 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id t6so7205389lfl.13 for <tsvwg@ietf.org>; Fri, 04 Dec 2020 03:45:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bpeqaBc9vovmmueGSApUjrZBniJOHqFTIKscPXvAYwY=; b=XlxzDRA5QjALknAQ23ObfXNId8G4Ukpo7G+G1oFgc3yyXiWzd2aF7xepeERjl0jRA6 llHiSIukbQF9IlEahwbEBYKOXXqk2MaYKW4QtTWHRt4RnTHUmC+M4iwvonSrqurz45FE P6pOqXZSenK6ilBQc9auxGH8fo1/FTBAYfC7ZjJa1jzVTVprXrDBaDvxB88D4OB7/8Iy 29kPkdFAhUKxppz7FdA8OSFNnu6XpQlyCIDasQ9h6mZ44Ml+vbkSK3TYOc+Tl7K9ajrv D3G6r3u52asInbFg2fHE8fviI+lQ0b/wydYM0DlRJFwhNzcYnrgkLDJ3pV/wI1g3O5mV vBqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bpeqaBc9vovmmueGSApUjrZBniJOHqFTIKscPXvAYwY=; b=mYXtbFQK7ZuPqm9850qJXEqsWxxZLS9TAf2ZoC7WyVjzCIACq5WSuA0vfl3RikIxcR yEAEr5rZ7ee6dB1yABLP8pilJDMS777IfCI/R1VMnuvmKUPEglilEAsxBG4q9pUaNyvx rTLcofj+8EMSxTDoa5+aWxbzOZ99xDOprsdc6viyoKhu2kd0k00XWPBYTqNxHjzO5dbr 0en4dI8VDgGSWeQZAzYGM3GQ8PZz4LX+gbwcjJSOcLpgLSZ4rPyV6s6Xfbp2j7G1z7YU bkkdDvJvOb5fDQqnIqhxS1oMzg+w/MTvz3gm8FdqsK5+hO5o2GcFwF9NL5EiFo3hYUpJ OaRw==
X-Gm-Message-State: AOAM532BZ0eX8yiyduMQwPmR42KZZ4QZEayxg2OLWBx7poz7iaasFsVM GySIx+DQEG95hRw6lV092Zc=
X-Google-Smtp-Source: ABdhPJwNiWa7JqN9ox0NKAMhRlbUspaMl2iErXO1opDpSa/aNxfvNNXO1cSEslBtFIIlGBpsQGHqUQ==
X-Received: by 2002:ac2:5334:: with SMTP id f20mr3273611lfh.30.1607082335177; Fri, 04 Dec 2020 03:45:35 -0800 (PST)
Received: from jonathartonsmbp.lan (178-55-159-67.bb.dnainternet.fi. [178.55.159.67]) by smtp.gmail.com with ESMTPSA id m30sm197173lfj.107.2020.12.04.03.45.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 03:45:34 -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 <chromatix99@gmail.com>
In-Reply-To: <1AB2EA08-4494-4668-AD82-03AEBD266689@ifi.uio.no>
Date: Fri, 04 Dec 2020 13:45:32 +0200
Cc: Wesley Eddy <wes@mti-systems.com>, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC06401C-2345-4F68-96FA-B4A87C25064E@gmail.com>
References: <MN2PR19MB4045A76BC832A078250E436483E00@MN2PR19MB4045.namprd19.prod.outlook.com> <HE1PR0701MB2876A45ED62F1174A2462FF3C2FF0@HE1PR0701MB2876.eurprd07.prod.outlook.com> <56178FE4-E6EA-4736-B77F-8E71915A171B@gmx.de> <0763351c-3ba0-2205-59eb-89a1aa74d303@bobbriscoe.net> <CC0517BE-2DFC-4425-AA0A-0E5AC4873942@gmx.de> <35560310-023f-93c5-0a3d-bd3d92447bcc@bobbriscoe.net> <b86e3a0d-3f09-b6f5-0e3b-0779b8684d4a@mti-systems.com> <7335DBFA-D255-43BE-8175-36AB231D101F@ifi.uio.no> <DA84354E-91EC-4211-98AD-83ED3594234A@gmail.com> <1AB2EA08-4494-4668-AD82-03AEBD266689@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LNCDEen19cvJOYiUGKLPww_zylM>
Subject: Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)
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: Fri, 04 Dec 2020 11:45:39 -0000

> On 4 Dec, 2020, at 1:33 pm, Michael Welzl <michawe@ifi.uio.no> 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.

 - Jonathan Morton

v2.23.0 | Report a Bug | By Email