Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)
Jonathan Morton <chromatix99@gmail.com> Fri, 20 November 2020 06:31 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 CF3F03A191A for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 22:31:22 -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 AiDCF_8jcjkK for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 22:31:21 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 651663A191F for <tsvwg@ietf.org>; Thu, 19 Nov 2020 22:31:21 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id u18so11869143lfd.9 for <tsvwg@ietf.org>; Thu, 19 Nov 2020 22:31:21 -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=DaprJlOKe5HhuYV5AR9sWTGMHf59HWBsd92S44T9R8c=; b=DadHFV4DVTugnmm6uUlSqGxBTfUgcTfOSxX21A9qCmmQ5ddtpoEsHx2xveM4BIRUN8 GkSdK1Yg4cffQIMT7Eyt/2LJgl8e2KJVlzXkZZ1vT8nEtpZ2KcybPiChuowo/8AOaxHX y4SaHKcASLWk4UCWL8VlFBuaXNlB1P5VantYGHSm5fDYQCQYmoqtS9m51cB/aAX7c68O IbGX9kb/7e9YT9gr3X+Ku2ziyq6Piu88dO0KcEWZuQv953vfRIz6wa0a1W+vygwHqDTO L+IyajxioOZ6TBuYfPGy6yhVcQGg/Uxu8jAPKNLHfvYcUeIbfK44HipqmflwOyiKhE1Q i9Ag==
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=DaprJlOKe5HhuYV5AR9sWTGMHf59HWBsd92S44T9R8c=; b=CyHktOpMpUZP5qNqH+nXOlV/r7VYTK1yEPSthwytNMfERwtiQYcvad4q30o4gnoVt1 zskUhNg+0N/BEu6FKM6kEmqdTFWGYhw28dYAB4MmuaHVxtPmGWgO+gGKve7a9Fl9lide UAcgoTnXotjTnLkV16YKJeffzKlQCbWu1c2A0zkcuw62nZD0BuoSLVyEcJKB3Aov06+T 7oeqXJDioe1FlNlHuBiurv3vNrl+3MlKCfRvDHkK/fchE5UsZ9oz7FDzrB1t2B+s7qgq 2YJK+DNG0I3a98rtG2mxrFGiq0nirTyg3fCy1pNiFHJEqden6JECs0mu5z5NIgZnmvQZ n8HQ==
X-Gm-Message-State: AOAM530eb4cDzTtP1nf18bVDC7LAi8GGHprvPccLaD67Mn22twF/sdRV h77t0ak+MW13g3r+hftf5oc=
X-Google-Smtp-Source: ABdhPJwXliFrXkLbAUE93g2k97ILVVb8GWXJKZi9NkXpAojHW7BAYjAimAN/a4uA5FAPeXDiFvi7sQ==
X-Received: by 2002:a19:84c5:: with SMTP id g188mr8168946lfd.270.1605853879520; Thu, 19 Nov 2020 22:31:19 -0800 (PST)
Received: from jonathartonsmbp.lan (178-55-159-67.bb.dnainternet.fi. [178.55.159.67]) by smtp.gmail.com with ESMTPSA id v195sm230239lfa.266.2020.11.19.22.31.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 22:31:18 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <HE1PR0701MB2876A45ED62F1174A2462FF3C2FF0@HE1PR0701MB2876.eurprd07.prod.outlook.com>
Date: Fri, 20 Nov 2020 08:31:17 +0200
Cc: "Black, David" <David.Black@dell.com>, Pete Heist <pete@heistp.net>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <00443F9E-BDDB-4F40-8453-D2A336DC06E4@gmail.com>
References: <MN2PR19MB4045A76BC832A078250E436483E00@MN2PR19MB4045.namprd19.prod.outlook.com> <HE1PR0701MB2876A45ED62F1174A2462FF3C2FF0@HE1PR0701MB2876.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/e557Ue_O2J7ePwEjU-bgoLBcvm4>
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, 20 Nov 2020 06:31:23 -0000
> On 20 Nov, 2020, at 8:04 am, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote: > > I try to make it clear to me what this scenario show is about and somehow I see it more as a flow isolation problem that makes FQ non-functional rather than an L4S problem? The original problem is the result of L4S redefining CE. This means it interacts poorly with AIMD traffic sharing the same queue and AQM. The solution proposed by L4S is to ensure at all times that L4S goes to a different queue than conventional AIMD traffic. The L4S-aware method of doing so is DualPI2, but that is not present on existing networks. Instead, on existing networks, L4S proposes relying on the assumption that FQ is sufficient. The likely existence of a mixture of L4S and AIMD traffic in a tunnel, which appears to FQ as a single flow, indicates that FQ is not necessarily sufficient to overcome the coexistence problem. The latter is still the basic problem; relying on FQ was only ever a workaround. - Jonathan Morton
- [tsvwg] Another tunnel/VPN scenario (was RE: Reas… Black, David
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Ingemar Johansson S
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Jonathan Morton
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Sebastian Moeller
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Bob Briscoe
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Sebastian Moeller
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Jonathan Morton
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Bob Briscoe
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Gorry Fairhurst
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Rodney W. Grimes
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Jonathan Morton
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Sebastian Moeller
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Wesley Eddy
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Jonathan Morton
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Steven Blake
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Michael Welzl
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Jonathan Morton
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Michael Welzl
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Jonathan Morton
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Michael Welzl
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Mirja Kuehlewind
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Michael Welzl
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Sebastian Moeller
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Bob Briscoe
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Steven Blake
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Greg White
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Sebastian Moeller
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Greg White
- Re: [tsvwg] Another tunnel/VPN scenario (was RE: … Sebastian Moeller