Re: [tcpm] bit length for byte counter fields in accurate ecn

Bob Briscoe <> Mon, 16 November 2020 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB3A13A127D for <>; Mon, 16 Nov 2020 08:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A1TCFg2sfEK3 for <>; Mon, 16 Nov 2020 08:26:48 -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 2F5A73A127A for <>; Mon, 16 Nov 2020 08:26:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=axnmvtFz7lf9+s9zDEu7vqL0ZT14Xe2BHMZKvS5nWZo=; b=TFH535SeTIrrBh41pJa63THq2 AVxveXE+UQv20n0UgdS5dm6wm9c5Fvsj09LKP+kHLWgtSCW4UUeERVugHJP5PpZ3g2p2nrJEnNOEX fcKqaFiZCTzaNlv3+3LUNd86Y61gCSiZi4uAxkvfuOO3WBbCDh2JrZmTL+jWORX7X4k6PFJxJwkkl 6AxbtDn+XTDvv5kDiiZvmFon349Uji5qaPtFtt7ov0+AmvMQwWEUcfnoEam+abDFdDBeIE+aKtKUp sLImJpCdYJfB8hgNTHVDY9s+M96mILfSj/XE11oMY6GDtQK2LQ0aguY4b6N2BdYmZ7X65ht2lTIVU DnJktU5GQ==;
Received: from ([]:33990 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1kehL3-006UmV-MJ; Mon, 16 Nov 2020 16:26:46 +0000
To: Yoshifumi Nishida <>, " Extensions" <>
References: <>
From: Bob Briscoe <>
Message-ID: <>
Date: Mon, 16 Nov 2020 16:26:45 +0000
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: multipart/alternative; boundary="------------ED3F3044BCC62FCC8822913A"
Content-Language: en-GB
X-OutGoing-Spam-Status: No, score=-1.0
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] bit length for byte counter fields in accurate ecn
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: Mon, 16 Nov 2020 16:27:01 -0000


While searching for a recent email from you just now, I found this one 
unanswered. My apologies.
In case you are still interested in the answer... inline tagged [BB]...

On 30/04/2020 10:06, Yoshifumi Nishida wrote:
> Hi,
> I am still a bit wondering about the length of the field for the byte 
> counter.
> In my understanding, the length of the counter is (at least) 32 bits 
> and encoded into 24 bits field.
> So, I am thinking that reducing the bit size doesn't affect accuracy 
> directly while the potential risks for miscalculation will be 
> increased. Is this incorrect?

Here's the calculations we went through to determine the 24b field size.

Each lowest 24b of the counter are sent every time the receiver sends an 
AccECN Option. Both ends start a connection from the same value, so they 
can maintain 24-bit counters locally just with simple modulo arithmetic 
(example in appendix A). So the field only has to be large enough that, 
if it wraps, the sender can tell, even if some ACKs were lost around the 
time it wrapped.

Each feedback counter increments by the size in bytes of each data 
segment carrying that codepoint.
Theoretical max packet size is 2^16 (IPv4 & IPv6).
You detect wrap most easily by detecting the counter going from the top 
quarter of the range to the bottom quarter (i.e. perhaps highest two 
bits transitioning 0b11->0b00).
So you would have to lose 2^(24-16-2) = 2^6 = 64 ACKs of max size 
packets in a row to miss a wrap.

Losing 64 ACKs in a row is pretty unlikely.

Notice I haven't said that packets of size 2^16 are pretty unlikely. 
'Cos if we get there they won't be.
9000B is fairly common in DCs. That's >2^13.


> Thanks,
> --
> Yoshi
> _______________________________________________
> tcpm mailing list

Bob Briscoe