Re: [tcpm] AccECN and updating RFC3449

Gorry Fairhurst <> Mon, 21 March 2022 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BC753A078A for <>; Mon, 21 Mar 2022 06:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yMWiuT6KyQuc for <>; Mon, 21 Mar 2022 06:43:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D36F3A03F1 for <>; Mon, 21 Mar 2022 06:43:39 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 684201B001AD; Mon, 21 Mar 2022 13:43:28 +0000 (GMT)
Content-Type: multipart/alternative; boundary="------------UtBzKCxzmjQv9kWSNM0QufcM"
Message-ID: <>
Date: Mon, 21 Mar 2022 14:42:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
To: Bob Briscoe <>
Cc: tcpm IETF list <>
References: <> <> <> <>
From: Gorry Fairhurst <>
In-Reply-To: <>
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 13:43:49 -0000

On 21/03/2022 10:19, Bob Briscoe wrote:
> Gorry,
> One response inline, tagged [BB2]...
Thanks - see GF2:
> 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?
> Bob

GF2: I like both of these proposals, and would be happy with this.


P.S. To be fully clear, *IF* AccECN is deployed, which I really hope, 
and people start using it, e.g. for L4S, and then I expect the IETF will 
know  what to recommend, I'd hen be really happy to see an RFC that 
updates RFC3449 by adding "appropriate" procedures to the BCP.
>>>> 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