Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)

Mirja Kuehlewind <> Mon, 22 March 2021 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51DDA3A0EA4 for <>; Mon, 22 Mar 2021 03:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GHCQ_fI3wxPt for <>; Mon, 22 Mar 2021 03:08:45 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 581443A0CEE for <>; Mon, 22 Mar 2021 03:08:45 -0700 (PDT)
Received: from ([2003:de:e71f:e600:f9cd:4c64:4f6a:754d]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lOHU9-0006su-Oe; Mon, 22 Mar 2021 11:08:33 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Mon, 22 Mar 2021 11:08:31 +0100
Cc: Yoshifumi Nishida <>, tcpm IETF list <>, "Scheffenegger, Richard" <>, Yoshifumi Nishada <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3608.
X-HE-SMSGID: 1lOHU9-0006su-Oe
Archived-At: <>
Subject: Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error 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, 22 Mar 2021 10:08:51 -0000

See inline.

> On 19. Mar 2021, at 18:37, Bob Briscoe <> wrote:
> Yoshi,
> On 17/03/2021 07:22, Yoshifumi Nishida wrote:
>> Hi Bob,
>> On Fri, Mar 12, 2021 at 2:54 AM Bob Briscoe <> wrote:
>> Yoshi, tcpm list,
>> As promised we set up a small design team on the single issue of occasionally ACKing pure ACKs if they carry new info (ECN marking at the IP layer). The design team has two solutions and everyone would be prepared to accept either, but preferences differ. So we're seeking wider opinions (more opinions obviously won't narrow the choices, but at least the WG can then make a decision informed by those who care).
>> To understand the question, you can either read the email below. Or the 3 slides for the tcpm meeting are briefer, and include pictures:
>> Here's the current draft text in question (see here for context ):
>> Data Receiver Safety Procedures
>>    An AccECN Data Receiver:
>>    o  SHOULD immediately send an ACK whenever a data packet marked CE
>>       arrives after the previous packet was not CE.
>>    o  MUST immediately send an ACK once 'n' CE marks have arrived since
>>       the previous ACK, where 'n' SHOULD be 2 and MUST be in the range 2
>>       to 6 inclusive.
>> Only the second bullet is in question. Here is the proposed diff for each alternative, then we explain:
>> Alternative A
>>    o  MUST immediately send an ACK once 'n' CE marks have arrived since
>> -     the previous ACK,
>> +     the previous ACK and there is outstanding data to acknowledge,
>>       where 'n' SHOULD be 2 and MUST be in the range 2 to 6 inclusive.
>> Alternative B
>>    o  MUST immediately send an ACK once 'n' CE marks have arrived since
>> -     the previous ACK, where 'n' SHOULD be 2 and MUST be in the range 2
>> +     the previous ACK, where 'n' SHOULD be 3 and MUST be in the range 3
>>       to 6 inclusive.
>> Extra guidance text would be required in each case too (see the end).
>> Background: 
>> AccECN is a change to the TCP wire protocol that requires the packet count of congestion feedback to include any congestion experienced (CE) arriving on Pure ACKs (amongst other things). AccECN doesn't require Pure ACKs to be ECN-capable, but allows for them to be. Similarly, AccECN doesn't require any congestion response to CE on pure ACKs, but having the feedback information there allows a response to be added with a one-ended update, if desired/necessary. Basically the data receiver is a 'dumb reflector'.
>> The above two bullets were designed to ensure that an ACK is triggered a) on the first sign of congestion, and b) frequently enough for the count of CE markings to be fed back using the 3-bit ACE field before it wraps, even if an               occasional pure ACK is lost.
>> We then realized that the wording could require an ACK to be triggered in response to a CE-marked pure ACK. The circumstance when this could occur would be when peer X sends a volley of data to Y then stops, and the path back from Y to X is congested (probably by other flow(s) so that many of the ACKs are CE-marked. The second bullet above under alternative (B) would require X to ACK every 'n-th' CE-marked pure ACK. However, if Y immediately started sending a volley of data to X, Y could misinterpret those ACKs (of ACKs) from X as DupACKs.
>> There are two ways to deal with this:
>> A) Some of us prefer to completely prevent ACKs on pure ACKs, on the basis that they do not want to risk sometimes generating more ACKs today
>> B) Others want to ensure that these rules will cause pure ACKs to be ACKed when the amount of CE on the ACKs merits it. But sparingly and strongly damping any ACK ping-pong.
>> Hmm. This is not easy.. 
>> My personal preference is if SACK is negotiated and it 's utilized to distinguish dupacks, then (B) is fine for me. Otherwise, I would prefer (A). 
>> BTW, I am wondering if this could leave it to implementations since both methods have pros and cons. 
>> I think It's hard to tell one is much better than the order. 
> [BB] The problem is that the decision impacts the complexity of the other end, not just the implementer's own code.
> * If an implementer chooses (A) (doesn't ACK pure ACKs at all), when it finally does send some data, it's CE counter could have built up an (unlimited) store of unreported CE marks, which it will report all at once. So implementations will have to include code that copes with receiving potentially multiple wraps of the ACE field (or just ignore the possibility).

You always need to cover this case because it is always possible to lose ACKs  and then counter may wrap. However, I don’t think you actually need to implement any logic to detect this. It only means the counters on both ends are off by N x 8 but congestion information is only valid that the point when it happens and resyncing on outdated information doesn’t help anybody.

> * If an implementer chooses (B), the code at the other end should just work without any specific logic to recognize the other end is doing behaviour (B). It could add the checks on DupACKs using SACK or timestamps, but I think that could be a MAY or SHOULD.
> Put another way, if the draft left the choice between A & B to the implementer, the benefit of B in simplifying everyone's code would have been lost because, even if an implementer chose B herself, everyone would still have to write extra code in case the other end had chosen A.
> This is why I would recommend that the draft says B and doesn't leave A as a choice.
> Bob
>> Thanks,
>> --
>> Yoshi
>> There are complexity arguments on both sides.
>> B more complex: 
>>     extra (non-mandatory) 'if' condition for lack of SACK options on a pure ACK (to decide it's not a DupACK).
>> B less complex: 
>>     consistent handling of CE marking whether on pure ACKs or data (which would probably remove an 'if' condition).
>> A more complex: 
>>     CE markings on a string of pure ACKs can build up without feeding them back, until released by a data packet (if ever). 
>>     More code at the other end to deal with the resulting risk of many wraps of the ACE field (or ignore?).
>> A less complex: 
>>     less different from current TCP.
>> Extra guidance text would be necessary in either case.
>> * Alt A) would need text on handling the risk of many ACE wraps 
>>     (to be written).
>> * Alt B) would need something like the following changes:
>>     For the avoidance of doubt, the above change-triggered ACK mechanism 
>>     is deliberately worded to solely apply to data packets, and to ignore 
>>     the arrival of a control packet with no payload, because it is 
>> -  important that TCP does not acknowledge pure ACKs.  The change- 
>> +  important that TCP does not acknowledge pure ACKs which convey no new 
>> +  state information to the sender. The change- 
>>     triggered ACK approach can lead to some additional ACKs but it feeds 
>>     back the timing and the order in which ECN marks are received with 
>>     minimal additional complexity.  If only CE marks are infrequent, or 
>>     there are multiple marks in a row, the additional load will be low. 
>>     Other marking patterns could increase the load significantly. 
>> + 
>> +  Providing feedback on the congestion state of the return channel 
>> +  after a sender has ceased transmitting more data helps inform the 
>> +  clients TCP congestion controller about the state of the return path. 
>> +  Should the role of data sender and receiver subsequently change, the 
>> +  new sender has more up to date knowledge of the network state, 
>> +  preventing transmissions of inappropriate size at that moment. 
>>     Even though the first bullet is stated as a "SHOULD", it is important 
>>     for a transition to immediately trigger an ACK if at all possible, so 
>>     that the Data Sender can rely on change-triggered ACKs to detect 
>>     queue growth as soon as possible, e.g. at the start of a flow.  This 
>>     requirement can only be relaxed if certain offload hardware needed 
>>     for high performance cannot support change-triggered ACKs (although 
>>     high performance protocols such as DCTCP already successfully use 
>>     change-triggered ACKs).  One possible compromise would be for the 
>>     receiver to heuristically detect whether the sender is in slow-start, 
>>     then to implement change-triggered ACKs while the sender is in slow- 
>>     start, and offload otherwise. 
>> +   The second bullet creates a possible case where an AccECN implementation 
>> +   could sometimes ACK pure ACKs, which in turn might be mistaken for
>> +   duplicate ACKs (in scenarios where TCP peers take turns to send
>> +   sets of data packets). To prevent spurious transmissions in such
>> +   circumstances, if SACK has been negotiated, an implementation could
>> +   optionally assume that an ACK is not a Duplicate ACK if it has no SACK option,
>> +   which would indicate it was an ACK of an  ACK. Alternatively it could use 
>> +   timestamp options to rule out DupACKs.
>> Bob
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               
> -- 
> ________________________________________________________________
> Bob Briscoe