Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause

Bob Briscoe <> Sat, 10 July 2021 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C46193A101D for <>; Sat, 10 Jul 2021 14:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 m5Gua0BhfQCQ for <>; Sat, 10 Jul 2021 14:13:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07C163A1019 for <>; Sat, 10 Jul 2021 14:13:50 -0700 (PDT)
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:Cc:To:Subject:Sender:Reply-To: 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=WYk0NIGcNshODQ80mws2We1/RBJ1ux5kfEyLftCxY3U=; b=DrvNOMBSYPeX3fXk6fs3UHLllt SJxg3qSksghGTATP6NB33xiZ7v6Rh4lND2Bz0XbXD40m+MR0cpVIIrRoPTOMm7GbH6OcpHFmZXNuv nbtXL6IZQisJViPhy36old3cN+8hBnl1/+4fPyM/Ls3h4QbKrglAXj6LHbpMsqJs8XCwQrXF9yJj+ 5R+cE+v9KHV5Lxqy9z8SzbKJMpcxnSJQw6vXbS4Xml7wN768BZsPfrwB9xpDWaWupQ6us+FbdUTLl 80+RWhxpagoHOI+arEL2/FDZnF1e1u3aElAJ4GaOQRTcWUcN/MttGCmIuZHwIhWTF+6/48QuI0/fv O+TxeytQ==;
Received: from ([]:58002 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1m2KIR-0007Kd-A7; Sat, 10 Jul 2021 22:13:49 +0100
To: Yoshifumi Nishida <>, "" <>, Mirja Kuehlewind <>, "" <>, "" <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Sat, 10 Jul 2021 22:13:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------0D7D0624489156F45105AE18"
Content-Language: en-GB
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] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause
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: Sat, 10 Jul 2021 21:13:56 -0000

Yoshi, Richard, Mirja, tcpm list,

We came to a good consensus in late March on the conditions to place 
around ACKing ACKs in order to keep congestion feedback flowing, but to 
ensure ping-pong ACKs are rapidly damped as well as avoiding false 
DupACK detection. I have written that up in a rev of the draft, which I 
will post separately so as not to distract from the question I have here...
...While writing up, I realized we had glossed over a possibly more 
important point, when we proposed to change the number in the basic rule 
from 2 to 3, as follows:

       An AccECN Data Receiver MUST immediately send an ACK once 'n'
       CE marks have arrived since the previous ACK, where 'n' SHOULD
       be 3 and MUST be in the range 3 to 6 inclusive.

I'd like to suggest an alternative:

       An AccECN Data Receiver MUST immediately send an ACK once 'n'
       CE marks have arrived since the previous ACK. If there is new
       data to acknowledge, 'n' SHOULD be 2.  If there is no new data
       to acknowledge, 'n' SHOULD be 3 and MUST be no less than 3.
       In either case, 'n' MUST be no greater than 6.

Rationale: The data ACKs case shouldn't be compromised by the ACKs of 
ACKs case.

When we were originally only thinking of the data ACKs case (before we 
realized this rule might trigger ACKs of ACKs), we recommended n=2  
because it ensures congestion information is kept fresh, and during runs 
of congestion it generates more ACKs, which might make it more likely 
that at least one ACK survives some types of coalescing before the ACE 
field wraps. Also 2 is the default for the equivalent repetition of 
DCTCP feedback.

Then, we noticed the ACKs of ACKs case, and we wanted to damp any ACK 
ping-pong, so we recommended 3. Without really discussing the pros and 
cons, we extended 3 to all cases (both data ACKs and ACKs of ACKs). I 
suspect the main reason was that it is just simpler to have a single 
rule. But these two cases are likely to be controlled from different 
parts of the code anyway.

I've also realized that, in the data ACKs case, it was wrong to set a 
lower bound on 'n', let alone a /mandatory/ lower bound. There might be 
scenarios where it makes sense to trigger an ACK every CE mark; we have 
no reason to stop implementers doing that if they want. A lower bound 
could even be perversely read to mean that you're not allowed to 
immediately ACK data until you've received 'n' CE marks.



Bob Briscoe