Re: [tsvwg] FQ & VPNs

Sebastian Moeller <moeller0@gmx.de> Sun, 21 February 2021 22:50 UTC

Return-Path: <moeller0@gmx.de>
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 1D11B3A12B1 for <tsvwg@ietfa.amsl.com>; Sun, 21 Feb 2021 14:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 YZZC9cHF_uzZ for <tsvwg@ietfa.amsl.com>; Sun, 21 Feb 2021 14:50:14 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDF23A12B0 for <tsvwg@ietf.org>; Sun, 21 Feb 2021 14:50:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613947807; bh=ndEIKMdLP52sTdbIk+xDYyFrTECMmJIU8hupXF+oo7E=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=GzvLAiCea8vxzuKmphHxhOWlJ9zdKnmd5Xb6/2hu1grOhw7NrL2rZ4kQ9iPiaNKwN z4flI6El4c3cMBv/z1P1kns3WIbJ0rG4gmr3/ft55/4DcuHjJJO5D+8zCH440euE+3 pygdvnyk/5Fhm5RNf1CZFW/fHhgp/h4TqYqBc7q0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.42.229] ([77.0.174.91]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKsjH-1lZ4ni1VK1-00LCfT; Sun, 21 Feb 2021 23:50:07 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <00c450ca-ab87-0904-2a6a-1d53a6d68964@tomh.org>
Date: Sun, 21 Feb 2021 23:50:06 +0100
Cc: Jonathan Morton <chromatix99@gmail.com>, TSVWG <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8567715D-8C4A-4649-B77E-310BE7D4C0E9@gmx.de>
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> <13EBAF97-A9AF-47A1-AB71-546C31F762C2@gmail.com> <HE1PR0701MB22999A319816198B515234BEC2829@HE1PR0701MB2299.eurprd07.prod.outlook.com> <CAA93jw6GNbgOSDfWo2mQPWSS5GQdTNqtq=fBgspP=MNkyPNtfA@mail.gmail.com> <eef468c8-1152-f6e8-cfbf-c80cb2d465a0@tomh.org> <94BF48C8-733B-42AC-ABC1-246692E2E0A1@gmail.com> <00c450ca-ab87-0904-2a6a-1d53a6d68964@tomh.org>
To: Tom Henderson <tomh@tomh.org>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:3P6bF6wjo8/RJvqggtPI81yySDNF+R2INX/atHzrSQ6IK2wtNBX TsJOyCN/lPr+eFPLRgATTOHuf7Ukw4T9de9J4megw0dk9iUHs75eGu6X5SbkWHl4Qy1Z+Yg odfLTkhE2HZau5+XLM9yH6bnur8oT40CeF9qvJRQBqepuxwz//5Ge8qcBCqqSf+Kk5ftaCk Mfh/3kp2/V/Kl0TSF/yeA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mbRb4YwzvUI=:qd6EtNAnngqrkUCKEmR+EH fH2KggiadtafHVeKgCoP8208tvjIoRKHxLuA27TBEzydG0UgpKmS3fVZ2a8zzJkWAqfcxAs5f Q6SVRDBTycr6AELoi3pEcncCoQmZJOrm0dv73lmFMhS+gjImlLEYw+c3i0bjyzutATz+6WHTO 2gWRmHfo96WgHCKsmQ2wRREdw6UHIqQw90fj7c7mwKG/YUtpEVg7hVc9CpG8Z2qLFLYCXmX5y k+NPSopPJElDTcbpX7udtfRmNnkTdeCJjJtbLO6En3uDQTrZC5PhvJEBb4VfTv2MO2aKNm6bK kIg7J27Ko9I4rOAdD9MXIo74ZP7FFCYu/ovIWGEeKohy9gPVV/yH01U4oYcmBY1dgo5l5ry7E 1h3P9HQ9lGOY1zQct/vf6pXATuDM0uQ92QUokV1UDgak/oIekSCUIPR5xLLwbQDgL0wZ562Az So1a20xbFRTlc0AoECmSpxSsuZ2NefHwvOwAGi0VXXotD9hE8Gr4/5tSxhrYZkEcghXMgOLDd hgWdUVeQJ3Zrq/iU+j/BRj2PlGY1QnB+r/WxZfaeNWqfJQYSFjL7J3nLu4XUjLt9HqLIK/rHB s2oBToywgIJ2xxcDgbvnYWRv+ucPOuZdZZR59vDxX2sVpzI7fX4n+lGXNyIsHtuJ139mrhqI6 A/thHBLiC8TM199+vR10iIUih/rxfBrNvgymewXOb+l1VZEPq4a/kqJhLG2/BerHhvSOblKHC c3PvN7TAG/TvfnkCZe2/HqdgmC5qTGP5cAHN9N+nh/kSLiQMPEBV6eqyxZQmZjIS6xzbiZU1h 40ZhITyxtA1F884mvGCrunY7+5iHR7S8apIrP0NceYQINvafBPucrzt4kkEXUdprBSOzJYNvL uo6pnyGbJvMXY7BYcbCw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qn5KWeHvtxGlmTY9l4guKLg4wr0>
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: Sun, 21 Feb 2021 22:50:16 -0000

Hi Tom,

> On Feb 21, 2021, at 23:33, Tom Henderson <tomh@tomh.org> wrote:
> 
> On 2/21/21 11:10 AM, Jonathan Morton wrote:
>>> On 21 Feb, 2021, at 8:56 pm, Tom Henderson <tomh@tomh.org> wrote:
>>> 
>>> 1) upstream a patch to the Linux kernel (and ask other OS vendors to do similarly) to treat ECT(1) as not-ECT
>>> 2) later add options to enable alternative semantics of ECT(1)
>>> 
>>> I don't see any reason to postpone the first step.
>> I do.
>> RFC-3168 specifies that routers "treat ECT(0) and ECT(1) as equivalent".  So implementing this first step would cause these Linux AQMs to violate RFC-3168.  I'm sure the kernel maintainers will be justified in rejecting patches on that basis.  Certainly I would raise such objections were such a patch to come to my attention.
>> To make that objection go away, you must first update and obsolete RFC-3168 so that it no longer contains that requirement.  That requires convincing the IETF that it's a good idea.  Again, I will maintain that it is a spectacularly bad idea.
> 
> Jonathan,
> I do not see any practical downside to disabling classic ECN response to ECT(1).  I have thought about writing a draft on this point or suggesting an errata to RFC 8311 on it, but decided to raise it here now.
> 
> There is a point in RFC 8311 (section 2.2 point 1) that says that treating ECT(0) and ECT(1) as equivalent is the preferred behavior.
> 
> However, point 3 says that hosts MUST NOT originate ECT(1) traffic according to old semantics.  Furthermore, the IANA protocol registry says that ECT(1) is for experimental use only.  I have been considering whether the above two points are sufficient in themselves to justify such a Linux patch.
> 
> The data that Pete Heist just published also would seem to support taking the step I suggested.  It seems to me that if the WG wants to support L4S experiments of any flavor, it would support first disabling the classic response to ECT(1).

	[SM] Why? Honest question. Sure L4S requires exclusive access to ECT(1) but in SCE promoting a weak ECT(1) to a stronger CE at a later node seems like exactly the right behavior. 

Sebastian



> 
> - Tom