Re: [tcpm] AccECN and updating RFC3449

Bob Briscoe <> Mon, 21 March 2022 09:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66EBA3A1928 for <>; Mon, 21 Mar 2022 02:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Status: No, score=-7.109 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 0xhbcbn_yYTZ for <>; Mon, 21 Mar 2022 02:19:23 -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 E97CD3A191D for <>; Mon, 21 Mar 2022 02:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type: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=dCiOVamBXceU6nPsKPU+U/goPHXrtWRKxzqrzQP4oNo=; b=1PLoccbBFelNdXomDocFsN6pe6 8SqEb2JWeh2g5103z4z+9VPpgnOX8hFj2tFrMuD3Id0/jxi/1iwa/YZtpmb/hCTEbDV+5uLlnDNd3 pJ1Q/mIDPSSx0JgBsKvB+68ymFc7lxWP0LacboNhKyj4ZdBiN6DTwvbG4wgopCz6DhVrwX7NDLTZY bd4kR/gFFsClelrRENzZUtQNKna4Jwegcw0s9w+TTApc5JIXg/TVCfOMAtSQfEvlgZJjA+vVABSJ5 XhyiDM0v/QICCNjmHzv/pzBbrPx2TllwviELyx1wiIaz6egwD41sICfmk2zLw0iRcPSmHzcUv3+Hc It3hVg6Q==;
Received: from ([]:50708 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1nWECA-0000b3-EV; Mon, 21 Mar 2022 09:19:20 +0000
Content-Type: multipart/alternative; boundary="------------33m0E8wd4Zkrcc6IRQxV0f1q"
Message-ID: <>
Date: Mon, 21 Mar 2022 09:19:18 +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
To: Gorry Fairhurst <>
Cc: tcpm IETF list <>
References: <> <> <>
From: Bob Briscoe <>
In-Reply-To: <>
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] AccECN and updating RFC3449
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, 21 Mar 2022 09:19:29 -0000


One response inline, tagged [BB2]...

On 21/03/2022 08:07, Gorry Fairhurst wrote:
> On 21/03/2022 01:04, Bob Briscoe wrote:
>> Gorry, [cc'ing tcpm, given this is a tcpm draft]
>> On 18/03/2022 19:31, Gorry Fairhurst wrote:
>>> I have problems with the proposal for AccECN update to RFC3449.
>>> I found the ID complex spec to read, as it digs into multiple ways 
>>> to perform accurate ECN reporting, so when thinking about ACK 
>>> modification in a router, it's not easy too see what level of 
>>> transport processing is desirable.
>>> The method seems robust to loss, and ought to work with tunnels, etc.
>>> RFC3449 references RFC3168, which is itself updated. That seems oK 
>>> to me.
>>> The latest rev. of the AccECN ID says in the abstract:
>>> “The document also specifies the
>>>    treatment of this updated TCP wire protocol by middleboxes, updating
>>>    BCP 69 with respect to ACK filtering.”
>>> - I did not find a specification in 3.3.3 that looked like it would 
>>> be accepted into a BCP. That concerns me, so I'm directing my 
>>> comment to the requirements line, 
>> [BB] The original requirement regarding ACK filtering and ECN in 
>> RFC3449 was equally brief and high level:
>>     Appropriate treatment is also needed to preserve correct operation of
>>     ECN feedback (carried in the TCP header) [RFC3168].
> Yes it was.
>> Section 3.3.3 in the AccECN draft 
>> <> 
>> says the two minimal normative things that are surely necessary now 
>> that there will be two different ECN schemes using the same TCP 
>> header bits:
>>     A node that implements ACK filtering (aka. thinning or coalescing)
>>     SHOULD determine if an ACK is part of a connection using AccECN and
>>     SHOULD then preserve the correct operation of AccECN feedback.
> And I have concerns with recommending one of those and I don't see the 
> value of the second.
>>> and the following the two bullets:
>>> Bullet 1:
>>> This bullet motivates that routers seek to detect the use of 
>>> accurate ECN ("SHOULD determine if an ACK is part of a connection 
>>> using AccECN"), I think that needs to be qualified if kept. For me 
>>> there seems a possibility that this add more "complexity" to the ACK 
>>> processing, and therefore less predictable behaviour. This does not 
>>> feel like it is a "SHOULD" or is necessarily good practice.
>> [BB] Presumably you agree that it is reasonable that ACK filtering 
>> ought to preserve the correct operation of ECN (as in RFC3449). And 
>> now that AccECN introduces a second different ECN feedback scheme 
>> using the same bits, surely you agree that ACK filtering ought to 
>> preserve correct operation of AccECN as well.
>> If you think that an ACK filtering function can (or at least might) 
>> preserve the operation of both schemes without knowing which one each 
>> packet is using, then yes we don't need bullet #1. Is this what 
>> you're saying?
>> We also need to bear in mind the subsequent para, which says that 
>> AccECN hosts have to be robust in the face of *existing* ACK 
>> filtering, whether or not it preserves the correct operation of 
>> AccECN. I believe what we're trying to do here is ensure that ACK 
>> filtering preserves its intention to *improve* performance - then 
>> merely functioning would be OK, but not the goal.
> I think much more work is needed to write this update to a BCP.

[BB2] RFC3449 is a BCP with one sentence about RFC3168 ECN and ACK 
filtering, which gives no guidance on what the problem is or what to do. 
It just says
     "Appropriate treatment is also needed to preserve correct operation 
of ECN feedback (carried in the TCP header) [RFC3168]."
If that sentence wasn't there, it wouldn't need to be updated. But it 
is. So surely it does.

One possible way forward: RFC3449 is structured as a number of sections 
on each topic, with discussion then a concluding paragraph always headed 
'RECOMMENDATION:' In the RECOMMENDATION section about ACK filtering, all 
it says about ECN is: "Suitable algorithms to support IPSec 
authentication, SACK, and ECN remain areas of ongoing research."

So, given the sentence about preserving correct operation of RFC3168 is 
not in a section headed RECOMMENDATION, presumably it is not normative. 
If so, we wouldn't need to formally update RFC3449. Then we could 
rephrase the sentences with the two SHOULDs as discussion (using your 
other responses further down the email), rather than normative. Although 
these are only bureaucratic changes, that do nothing about actual 
performance, at least they would satisfy your desire not to update RFC3449.

To deal with actual performance, we could say that, from the PoV of end 
systems, the sure-fire way to be robust against existing ACK filtering 
would be to implement the AccECN TCP Option. I would add this where it 
says the AccECN TCP Option is optional to implement. Then refer to it 
from the ACK Filtering section.

Is this moving towards what you are asking for?


>>> Bullet 2:
>>> This second bullet raises a concern that was motivated in 2.3, and I 
>>> think that the text is useful as it warns, but does not propose. I 
>>> think it is correct and proper to indicate that the use of AccECN 
>>> can be impacted by routers that manipulate/thin ACKs.
>> 2.3 talks about what Data Receivers need to watch for. It doesn't 
>> mention middleboxes.
>> 3.3 collects together all the items of interest to middlebox 
>> implementers. This second bullet merely explains the concern. I 
>> thought that's what you want.
>>> At the moment, the related requirement as written is:
>>> "SHOULD then preserve the correct operation of AccECN feedback.", 
>>> which I didn't see specified.I think it could also be useful perhaps 
>>> as you do to speculate that it might be beneficial to update these 
>>> routers, however the current text does not seem to be best current 
>>> practice, at best it seems too vague.  For instance: I'm not clear 
>>> what the text advocates when a queue of accurate ECN ACKs build at 
>>> an intermediary.
>> [BB]  I don't really understand what you want us to do. You seem to 
>> want us to be less specific and more specific.
>> You seem to want us to warn not propose (which I agree with), and 
>> that's what I thought we were doing.
>> But then you seem to want us to say how an ACK filter should actually 
>> work with AccECN, which is surely beyond the scope of this draft.
>> Can you perhaps hint towards the text you are hoping for?
> Describe the effects, and estimate their significance.
>>> In summary, I think I don't understand the need for the Updates 
>>> line, and I do not see a BCP-style recommendation emerging yet. 
>>> Maybe we just need experience and a short draft could write down 
>>> what the IETF recommendation is, if there is finally a need for a 
>>> change?
>> [BB] It's problematic, because RFC3449 is a BCP, but it only says the 
>> bare minimum (quoted above) about ACK filtering with ECN. However, 
>> that bare minimum needs to be updated because ensuring the correct 
>> operation of RFC3168 is no longer enough.
>> Given RFC3449 doesn't use normative language, where the AccECN draft 
>> updates RFC3449, I would be happy not to use normative language either.
>> But I think it would still have to update RFC3449. Wouldn't it?
> No, I don't think we need to do this, until we know what we recommend.
>> [BB] Finally, during this conversation I've noticed the following two 
>> lines. If they remain after we complete this conversation, I suggest 
>> they are clarified as below:
>>           ACE field wrap is of less concern if
>>           packets also carry the AccECN TCP Option
>>           ACE field wrap *might**be* of less concern if
>>           packets also carry the AccECN TCP Option. *However, **
>> **                   note that logic to read an AccECN TCP Option is 
>> optional to **
>> **                   implement (albeit recommended   see Section 
>> 3.2.3).  So one end **
>> **                   writing an AccECN TCP Option into a packet does 
>> not necessarily **
>> **                   imply that the other end will read it.*
>> Bob
>>> Gorry
>> -- 
>> ________________________________________________________________
>> Bob Briscoe
> I suggest you do not try to fix this inside a document that is mainly 
> about how to implement TCP.
> I am also not yet convinced this describes something specific that has 
> been tested across different platforms and actually is the best 
> practice. I think if the WG wants to do this work, then they should 
> decide what is needed and show that it works across the different 
> possible use cases, asking people to deply extra code that modifies 
> packets on a path is not something I think we should encourage in 
> general.
> Gorry

Bob Briscoe