Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

Jonathan Morton <> Tue, 09 March 2021 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 846303A1430 for <>; Tue, 9 Mar 2021 09:18:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QPkbMpYahbsc for <>; Tue, 9 Mar 2021 09:18:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FE123A1435 for <>; Tue, 9 Mar 2021 09:18:03 -0800 (PST)
Received: by with SMTP id q14so21667959ljp.4 for <>; Tue, 09 Mar 2021 09:18:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t9RF/N+YM4d22kgDwbZ1n5dsztdrrEuwAfHURRjrjAI=; b=ZsT0n5IZIHSLjvKNsDODXyKZ/Kpm2dcfMLhb5s4+J7zz0sWxXbKWB1nWelIcNEep6o aAsv8HhqBYdmd5cP54G65NcTelLXbpV1C1nJAJDAl4gpz1TWSKn7B7TqsqMOQyaf1Zj5 JlUe6w+ZDDLMRmxF3c5/p62Y5SNbS5pn1nEDpgo1INqaTiEFAyhyG12m5RFea3hdbOdp fNGs945d5ox5TKMK9UglDZ+icF7e00kpeNobWxekEsgdwq5dZLh0moWznVuy55C8NsYn JtlCFFNMF4N2DE+ZY61RzgDa38tSzcFdDW9Mza3X32kCQj3IuR8oeUW35EZ6voZpPXoq hXjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t9RF/N+YM4d22kgDwbZ1n5dsztdrrEuwAfHURRjrjAI=; b=pQEyaFefSttDSHR6No+AqRvwZX/JktjUNo4rtnoDngl/Cv8eYEB22P5fse45614rCF tvyW0hj7Jc9k8PW9Te176uegDfGD4IhwKvCg47Ne8A2djSBCJDsW0GpVIAXNyFWHRuDl F4uJp+VDdFkW95MdHdLrQ7o5RNZLDJwFdevylxR8kuLjZ0y3lWeYLyWW4tNb5cFdrVhE cEigtGzGHQkbGzGfLtPn0DjciEUyLUBSUWfFsDbPTIA6WyJSh06PQF0VDRdHWBl7jwqb oRwF9ke3R6Uz+qQRjGYOn6ueL5U/8TH10VxsD8cJw1+3aWeBESB9IBoY7bHYKjnL6u1G 6ddQ==
X-Gm-Message-State: AOAM5326IqbOFZFU+scW0Rl33gGQcvpvAt/LVqT0Bcq7tdEyCx88Aye9 1pZJDlU2vkh4YLOLEqJAmmE=
X-Google-Smtp-Source: ABdhPJwy0goY0gpaDErLsXX45tzgKFasWcVNgQq87iY9/Tf3+M4mErpJV2sC2xRZNTyLLthEUNCU7Q==
X-Received: by 2002:a2e:874e:: with SMTP id q14mr17900537ljj.75.1615310280654; Tue, 09 Mar 2021 09:18:00 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id x13sm1964562lfr.46.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 09:18:00 -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 <>
In-Reply-To: <>
Date: Tue, 9 Mar 2021 19:17:57 +0200
Cc: Gorry Fairhurst <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt
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: Tue, 09 Mar 2021 17:18:06 -0000

> On 9 Mar, 2021, at 6:33 pm, wrote:
> With hindsight, I'm not sure why rfc8311 (which is standards track) didn't deprecate marking ECT(1) the same way it deprecated endpoints using it, outside experiments.

Because there's more than one possible experiment involving the ECN field.  SCE actually prefers that existing networks and endpoints continue to comply with RFC-3168 in these respects, originating ECT(0) (though if they originated ECT(1) it actually wouldn't hurt anything) and treating both ECT codepoints as equivalent.  If we started treating ECT(1) differently in the network, that would make deploying SCE more difficult.

Which is another reason I'm opposed to pre-emptively moving to accommodate L4S.  But even if I were to make that change "today" (which I probably couldn't, because Linux kernel maintainers also like to be RFC compliant), there would be a *long* transition period as existing equipment sits around with old firmware, during which L4S would still need to accommodate existing networks or stay away from them, not the other way around.

 - Jonathan Morton