Re: [tcpm] Is ECN a valid TCP header flag?

Jonathan Morton <> Fri, 24 September 2021 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC82F3A0809 for <>; Fri, 24 Sep 2021 08:03:09 -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, 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 XzHGwYHS5cNu for <>; Fri, 24 Sep 2021 08:03:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 145583A0805 for <>; Fri, 24 Sep 2021 08:03:06 -0700 (PDT)
Received: by with SMTP id y28so41087265lfb.0 for <>; Fri, 24 Sep 2021 08:03:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UeimCjMNaqBtJPlyBwTsqWYAr/KE5TDRytbFlWJvMGE=; b=oVXcUcsYxc+wdigAWSArIU9+OiHX17fdIu6Qge5jElB9Xc1/5W+ZpCOay2p6C1a4e2 j2rr+VA91h3Cad5s96ZGzHQGeV4MibAUpozVdf52wvHD+PP3opimv67NaSpLuCGgh+bb jZS+sL/rtE+kajuXNGeWUJ6x9oIudrK/OWPyyKLq7YPGlo/rWjJXOXLV6wMgux831OZz 6EJJBOOKUjikeRAPxt0bmDlIn6ttU9JNg0weiGsCRNKlignY1DFvMKOljjtOUIYuAaR9 v5sdobsvpmo+Q3EoFd848Ub2bexuRNmYy3/LN9C/ErrCLH0UBMTaGuEJMaPacFIgEokx xaMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UeimCjMNaqBtJPlyBwTsqWYAr/KE5TDRytbFlWJvMGE=; b=2ASd+hHjZLrEcCEmZkiHFzof4EIFyxiWpw8n/YzaZ+SMpYk5osie34e5aUdvFlGU90 jjxe32n+IfHOy1WoRkZNCd7rmzB9jsZr988nuXSYSeiY7qO+VSfuaREgP0bWkNMDy9UY 4SzhdhqJLFmVDTz0hnVsmk85tgvWHCAH5WiHyWHsvQssn/MLtPCaeWxr+OUJrQP09aYK WHNHd+I20cEcW2lcvn83hiHBsdr0kVrm5pkOWCR+fcC6fsoPtLbmMalZZJ8+5IbROsCX ThSvC6kL2+j9iAErreyl5mzWXxeS1LxaHgLVW+gia37P7YZqLQi/TuPVmP1pkdAJpd5P 820w==
X-Gm-Message-State: AOAM532a7vnCr2SDebaARt+sZYJrYPUYbeZEv2xnf5MsGJ+2F7ht22sF FGg3BjGqIE0ZxPbmqCru0K0=
X-Google-Smtp-Source: ABdhPJwo05kvhdWahexNGNllHqiU3+l1rbW1ZuWOyfz/dJTNAw/om7iPqb6C7kH0xEcWSFBF5fT6Yw==
X-Received: by 2002:a05:6512:3189:: with SMTP id i9mr9947179lfe.152.1632495775468; Fri, 24 Sep 2021 08:02:55 -0700 (PDT)
Received: from ( []) by with ESMTPSA id j1sm778066lfr.248.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Sep 2021 08:02:54 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Fri, 24 Sep 2021 18:02:53 +0300
Cc: tcpm <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: t petch <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [tcpm] Is ECN a valid TCP header flag?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Sep 2021 15:03:10 -0000

> On 24 Sep, 2021, at 1:05 pm, t petch <> wrote:
>  base tcp-flags;
>    identity cwr {
>    identity ecn {
>    identity urg {
>    identity ack {
>    identity psh {
>    identity rst {
>    identity syn {
>    identity fin {
> with descriptions and references.  My knowledge of this is limited but I suspect that the reference for 'ecn' should be RFC3168 and not RFC793 but then should it be 'ece' and not 'ecn'?  I suspect that a TCP expert might see rather more idiosyncrasies.

I agree, it should definitely be ECE and not ECN.  The abbreviation is for "Echo Congestion Experienced", where "Congestion Experienced" refers to a codepoint of the ECN field in the IP header.  RFC-3168 describes the ECE and CWR (Congestion Window Reduced) flags and how they must be used.

The remaining established TCP flags are named here with their usual and familiar abbreviations.  I don't see any cause for concern there.

There are several additional TCP flags, in an adjacent byte, which are reserved for future use - effectively "should be zero" at origin and "should be ignored" upon receipt.  One of them was, for example, historically defined as NS (Nonce Sum), and other uses may arise in future.  Are these flags accounted for in the model?

 - Jonathan Morton