Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-16.txt

Bob Briscoe <> Thu, 03 February 2022 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 318083A08B7 for <>; Thu, 3 Feb 2022 07:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Status: No, score=-2.812 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.714, RCVD_IN_DNSWL_BLOCKED=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 ZFJuKBD0P9BX for <>; Thu, 3 Feb 2022 07:24:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 895753A088D for <>; Thu, 3 Feb 2022 07:24:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:Cc:From:References:To:Subject:MIME-Version:Date:Message-ID: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=rO8N+fHbGxpm1eR6qiQKDr6JesldMhy+p+1rr6kJ/BQ=; b=T49ZYcNfpOPmlrMmEElhraTjUI +InjGTdp634o2t0sseA7a3ZaMn0ph+eLO/8UJ8oDvitQX+HJMGF5nvI3wXxWNBaqECU6CVB4Tv3dZ hzkBN10BVtaeIMx8lFhMnQOWURRU/2YBis0MdFW9yb/4ozVgSe6DDf66UCKNFSMLHxtarDBhVzEi4 4m02yL64c/DxWnuqJIrOSpDxjQyR3DL2COWzhqfxI8l2M0KzPHd8Su+/P1SzwXOIPb+0PYFz0xsvn IQKysZKR/PQevdf0p5w/icPBMGRlJig91crTwCMd1nhUiFmVKAlFzK3o0IW9Wn+AFs7KwVZoOvVs9 6PNsrJYA==;
Received: from ([]:55082 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1nFdyN-0002gg-1Y; Thu, 03 Feb 2022 15:24:28 +0000
Message-ID: <>
Date: Thu, 03 Feb 2022 15:24:26 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-GB
References: <>
From: Bob Briscoe <>
Cc: Ilpo Järvinen <>, Richard Scheffenegger <>, Mirja Kuehlewind <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-16.txt
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: Thu, 03 Feb 2022 15:24:50 -0000

tcpm folks,

This rev to accurate-ecn is the first of two. The second will hopefully 
follow on its heels in the next couple of days.

Diffs between this first rev (-16) and -15:

1.  switches round two fairly large sections, so I've deferred other 
changes to a second rev so the diffs won't be masked by the switch round 
of sections.
Suggested by Ilpo to match the order in which the tests in these 
sections will be executed:
* Test for mangling the IP-ECN field (now,
* Then test for zeroing the ACE field (now

2. Ilpo suggested some clarifications in "  Consistency 
between AccECN Feedback Fields", which is about the receiver of feedback 
ensuring consistency between the mandatory 3-bit ACE field and the 
optional 24-bit counters. In brief (paraphrasing) it previously only 
said "MUST consider both fields", when it is now clearer that it 
actually meant "MUST reconcile both fields", so that there is always a 
consistent baseline for subsequent ACKs.

3. A minor point is added in an appendix about the details that the 
pseudocode doesn't cover.


PS. #2 & #3 were added to the XML ages ago (Jul '21), so you will have 
seen them in the HTML. However, prob due to my clumsiness, the posted 
TXT didn't include them whereas the posted XML did (ironic for a section 
about consistency). In turn, inconsistency was only possible because I 
am having to manually post the TXT for this draft, due to an unresolved 
issue with v3 RFC XML tables.

On 03/02/2022 14:43, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>          Title           : More Accurate ECN Feedback in TCP
>          Authors         : Bob Briscoe
>                            Mirja Kühlewind
>                            Richard Scheffenegger
> 	Filename        : draft-ietf-tcpm-accurate-ecn-16.txt
> 	Pages           : 60
> 	Date            : 2022-02-03
> Abstract:
>     Explicit Congestion Notification (ECN) is a mechanism where network
>     nodes can mark IP packets instead of dropping them to indicate
>     incipient congestion to the end-points.  Receivers with an ECN-
>     capable transport protocol feed back this information to the sender.
>     ECN was originally specified for TCP in such a way that only one
>     feedback signal can be transmitted per Round-Trip Time (RTT).  Recent
>     new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP
>     (DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need more
>     accurate ECN feedback information whenever more than one marking is
>     received in one RTT.  This document specifies a scheme to provide
>     more than one feedback signal per RTT in the TCP header.  Given TCP
>     header space is scarce, it allocates a reserved header bit previously
>     assigned to the ECN-Nonce.  It also overloads the two existing ECN
>     flags in the TCP header.  The resulting extra space is exploited to
>     feed back the IP-ECN field received during the 3-way handshake as
>     well.  Supplementary feedback information can optionally be provided
>     in a new TCP option, which is never used on the TCP SYN.  The
>     document also specifies the treatment of this updated TCP wire
>     protocol by middleboxes.
> The IETF datatracker status page for this draft is:
> There is also an htmlized version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by rsync at
> _______________________________________________
> tcpm mailing list

Bob Briscoe