Re: [tsvwg] FQ & VPNs

Tom Henderson <> Sun, 21 February 2021 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4882C3A127D for <>; Sun, 21 Feb 2021 14:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.755
X-Spam-Status: No, score=-0.755 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, NICE_REPLY_A=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MUqYSDSeo1jv for <>; Sun, 21 Feb 2021 14:33:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E6943A1271 for <>; Sun, 21 Feb 2021 14:33:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 93EEBE946E9 for <>; Sun, 21 Feb 2021 16:33:40 -0600 (CST)
Received: from ([]) by cmsmtp with SMTP id DxIKl1iPNDT64DxIKljHCW; Sun, 21 Feb 2021 16:33:40 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6Uj1RXeolaUXn4HhbiwsFoPn8R63+fSHz9FAKQOnSiw=; b=YWzhztmEhEmAX8Mp0jo0lTt2xg ReKBz8dAyA890BMmm1amn0ttOGjhpOK5u3iMFlo1oegywgI/hzcrobt28RKEAhGc1vJXyP7Gpv/T6 NCcV4zkYKcLDM7zsza+QeUYo0qkWDIRzJkBflSbXjUtmy66pMpqA/DpRtDbCdb1d0F/ZtqPzNYd5L 7YAOLv1pzJPndgaZJMaAsgb1+WaNYbov7+FHRJj1nj+JAraHr3ZqYpM73+QNcFPWaJ6AHXiM+Qlf3 V/6LEGiTWs6hR1q1AD/ez1nTxqEwcejZKdsPAWDdZNkN5bEUI9+0mPY6sq0WHggEKxpmFFbomlg2V oS9evalQ==;
Received: from ([]:46524 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1lDxIK-003Tva-91; Sun, 21 Feb 2021 15:33:40 -0700
To: Jonathan Morton <>
Cc: Dave Taht <>, Ingemar Johansson S <>, TSVWG <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Henderson <>
Message-ID: <>
Date: Sun, 21 Feb 2021 14:33:38 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-L: No
X-Exim-ID: 1lDxIK-003Tva-91
X-Source-Sender: ([]) []:46524
X-Source-Auth: tomhorg
X-Email-Count: 4
X-Source-Cap: dG9taG9yZzt0b21ob3JnO2JveDU4NjcuYmx1ZWhvc3QuY29t
X-Local-Domain: yes
Archived-At: <>
Subject: Re: [tsvwg] FQ & VPNs
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: Sun, 21 Feb 2021 22:33:43 -0000

On 2/21/21 11:10 AM, Jonathan Morton wrote:
>> On 21 Feb, 2021, at 8:56 pm, Tom Henderson <> 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.

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).

- Tom