Re: [tsvwg] Question about proper node behavior -ECN

Jonathan Morton <> Thu, 18 May 2023 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BFD0C151074 for <>; Thu, 18 May 2023 15:35:32 -0700 (PDT)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Cwe7AtZTUnC8 for <>; Thu, 18 May 2023 15:35:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 27AB1C14CE24 for <>; Thu, 18 May 2023 15:35:28 -0700 (PDT)
Received: by with SMTP id 38308e7fff4ca-2ac89e6a5a1so28314251fa.0 for <>; Thu, 18 May 2023 15:35:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1684449326; x=1687041326; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uwFzeHxPAV9kFyumE2gEDccltfiC27ejOaY9RxK47fY=; b=sVomHxj8s7uX9W93nilBrI8mKwmeXZ9oy8aXCROMzsQCDw8dJ45E5nAo/jQKcX5+m0 IM3ja9KvA3ZvOBFKY4vM3H3KpPV/XQWFDOXAStnRqWmrbebeTIsgqSRA4f0qKSYnAKCq JIPXaF3AiKoyUyDt1b4CY0wqsb//sXxAaOPAISqtEV3OZ3oPKIXlsUNGyzhwsEtgAsTG O/Cxn7DnNSyoSFM2dblK61BicYU35CSurpye/XCIJqcpNBxxbYVJBpXnkj23GujLx/z7 Ogaz4Ee1Uk1UC9aOIX2rPgOOGytvLoGW7u41pvCaLnbdR3KhsKZWd8DFGUvoIea8QGuz Z58A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1684449326; x=1687041326; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uwFzeHxPAV9kFyumE2gEDccltfiC27ejOaY9RxK47fY=; b=ho7ib/upkHoQpfPxJjz4ohTTZPNxfeLCd9IBK8VM4F4cQ2S0zy52+mlqYI+k+oQvHB MWx3biqAX+jsFVrqrfZEg5PCWPTBj5/kJJpLTZzd/j8X0jWMhjLYeMYg0yHB7mXS+tM5 ESKghoNesXp9p6ssou+yFkymzuk2Zaf8vCav7moq6IVCs/xK0gaJir7FXLSN49lK3+57 xKYMUPBJYEGXrRIEnyKBjJhpBNzrr2kj/VMvTW65bfugmTKz/xv0MQ75P8pBZe9L3OWx UwnW7apjpcdkoiclIspUUyt6BiBssNCMgfZw6EI4ql6c4ZGNEjqVu9H2pd1ZqwIMwYrk f2pQ==
X-Gm-Message-State: AC+VfDyB6oWGDURT02IGU0KFSSmg2zSRGgqSGCxUwjSwdqVAhjvzJkuS uDjzn3KiQ91ZKMZ/jRXPEaI=
X-Google-Smtp-Source: ACHHUZ7Ax/8mWzHhemOYYNCFIbFO56c1JCH/yCQqkdPJWewmj4sYBtylpAyjJcoY9WbaCe+egFPqVQ==
X-Received: by 2002:a05:651c:1031:b0:2ae:e214:482f with SMTP id w17-20020a05651c103100b002aee214482fmr5247454ljm.52.1684449325470; Thu, 18 May 2023 15:35:25 -0700 (PDT)
Received: from ( []) by with ESMTPSA id v17-20020ac25591000000b004f2769a120dsm374760lfg.249.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2023 15:35:25 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Fri, 19 May 2023 01:35:23 +0300
Cc: Gorry Fairhurst <>, Ingemar Johansson S <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Greg White <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [tsvwg] Question about proper node behavior -ECN
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 May 2023 22:35:32 -0000

> On 18 May, 2023, at 10:32 pm, Greg White <> wrote:
> RFC3168 also includes a statement which allows manipulation of the ECN field:  
> “When the router's buffer
>    is not yet full and the router is prepared to drop a packet to inform
>    end nodes of incipient congestion, the router should first check to
>    see if the ECT codepoint is set in that packet's IP header.  If so,
>    then instead of dropping the packet, the router MAY instead set the
>    CE codepoint in the IP header.”
> And, it includes a section 18 which talks about possible changes of the ECN field in the network, and specifically 18.1.4 “Falsely Indicating ECN-Capability” which describes the transition of Not-ECT to ECT0 or ECT1 (and by extension CE) as being “incorrect”.
> RFC9331 section 5.1 discusses L4S network node behavior and includes the statement: “An L4S AQM treatment follows similar codepoint transition rules to those in [RFC3168].” But, I haven’t found those rules stated very explicitly in RFC3168.

My general interpretation of these rules is as follows:

Not-ECT MUST NOT be changed to any other value by a node (per RFC-3168).  This would falsely indicate an ECN-Capable Transport to other nodes, which might then choose not to drop the packet in response to congestion, since they believe they can indicate congestion by other means.

ECT(0) and ECT(1) MAY be changed to CE in order to indicate congestion without packet loss (per RFC-3168).  These values MAY also be changed to Not-ECT when circumstances dictate, eg. under certain abnormal conditions at the decapsulation end of a tunnel, but ideally this should never occur in well-behaved scenarios.

There is no established rule stating whether ECT(0) may be changed to ECT(1) by a node or vice versa.  An obsolete RFC did rely on this *not* occurring in the network, but this RFC was never deployed in the wild.  There remains the possibility of using these transitions to indicate fine-grained congestion information, so ideally nodes not participating in such experiments should avoid them.

CE MUST NOT be changed to another value, since that would erase congestion information (per RFC-3168):

> When a CE packet (i.e., a packet that has the CE codepoint set) is
>    received by a router, the CE codepoint is left unchanged…

If it is necessary (due to the aforementioned abnormal conditions) to change it to Not-ECT, then the entire packet MUST instead be dropped, as a Not-ECT packet would have been instead of receiving the CE mark.  See also the discussion on reassembling fragmented packets in RFC-3168.

I hope that is intuitive enough to follow.

 - Jonathan Morton