Re: [tcpm] RFC3449 & AccECN

Bob Briscoe <> Wed, 06 July 2022 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27221C15A745 for <>; Wed, 6 Jul 2022 09:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.98
X-Spam-Status: No, score=-3.98 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=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 QnjZ5K4lU_2p for <>; Wed, 6 Jul 2022 09:04:20 -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 07BA1C15A747 for <>; Wed, 6 Jul 2022 09:04:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=In-Reply-To:Cc:From:References: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=qmqQOJ1AvmRMyA82QckGivXfJba2ixocYO2ACoXmMSk=; b=8NXaEGpewCW/CnUvzTPR9PnYHx +uFM9bD5dcZnyAcAXGUJ8gL1+Ok7JY2B4kektQD/G4lyl4fKIRL9OZiMTrRzf709a7sYR4Zn4ybzz 6aCC52Gj+1EKxnQszk5OpDVuVU7cqAXGLwuaHmy074JxjcCL1eFWSXucmncQYDUcv8JwD8v4sgfWp YQ7Ctm0z8WIkKYzUMd5f8hSc2EQ/oXgF+mDbyf2Wv7FgAESC1PvNqKbvy4EoMqxlLy3F6TV04wMVC +mfV6TspM9B5NmB1sEUcbDaKhEtt0WqI196fpjdYE61+Etzv5bjB5USPVDswJmeocplKMF7WcaSVb FjKs8EaQ==;
Received: from ([]:50730 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <>) id 1o97Vm-0001ge-0o; Wed, 06 Jul 2022 17:04:17 +0100
Content-Type: multipart/alternative; boundary="------------i8P9PnVDiLrPSkwTSFNxQlmt"
Message-ID: <>
Date: Wed, 06 Jul 2022 17:04:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-GB
To: "Gorry (erg)" <>, Mirja Kuehlewind <>, Richard Scheffenegger <>
References: <>
From: Bob Briscoe <>
Cc: tcpm IETF list <>, Yoshifumi Nishida <>
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] RFC3449 & AccECN
X-Mailman-Version: 2.1.39
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: Wed, 06 Jul 2022 16:04:25 -0000


Yoshi reminded me that we need to tie up the two outstanding items in 
the AccECN draft. This one dates from your email back in March (still 
quoted below so you can reload state).
I haven't run the proposed diffs below past my co-authors but, first, do 
they satisfy your concerns:

Header block:

Updates: 3168, 3449  (if approved)


    The document also specifies the
    treatment of this updated TCP wire protocol by*middleboxes*, updating BCP 69 with respect to ACK filtering.


3.3.3.  Requirements for TCP ACK Filtering

    A node that implements ACK     *Section 5.2.1 of BCP 69 [RFC3449] gives best current practice on*
    filtering (aka. thinning or coalescing)*of pure TCP ACKs. It advises that filtering ACKs carrying ECN feedback 
ought to preserve the correct operation of ECN feedback. As the present 
specification updates the operation of ECN feedback, this section 
discusses how an ACK filter might preserve correct operation of AccECN 
feedback as well. The problem divides into two parts: determining*SHOULD determine  if an ACK is part of
    a connection*that is*  using AccECN and
    SHOULD  thenpreserve  *preserving*  the correct
    operation of AccECN feedback. The following notes might help with each part of this requirement*:*

    o  To determine whether a pure TCP ACK is part of an AccECN
       connection without resorting to connection tracking and per-flow
       state, a useful heuristic would be to check for a non-zero ECN
       field at the IP layer (because the ECN++ experiment only allows
       TCP pure ACKs to be ECN-capable if AccECN has been negotiated
       [I-D.ietf-tcpm-generalized-ecn]).  This heuristic is simple and
       stateless.  However, it might omit some AccECN ACKs, because it is
       only recommended but not obligatory to use ECN++ with AccECN -
       only deployment experience will tell.  Also, TCP ACKs might be
       ECN-capable owing to some scheme other than AccECN, e.g. [RFC5690]
       or some future standards action.  Again, only deployment
       experience will tell.

    o  The main concern with preserving correct AccECN operation involves
       leaving enough ACKs for the Data Sender to work out whether the
       3-bit ACE field has wrapped.*In the worst case, when feeding back a run of packets that were all 
ECN-marked, the ACE field can wrap every 8 acknowledged packets.*   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.*

    Note that the present specification of AccECN in TCP does not presume
    to rely on any of the above ACK filtering behaviour in the network(hence the use of 'SHOULD' rather than 'MUST' above)*,*
    because it has to be robust against pre-existing network nodes that
    do not distinguish AccECN ACKs, and robust against ACK loss during
    overload more generally.

    Section 5.2.1 of BCP 69 [RFC3449] gives best current practice on pure 
TCP ACK filtering. It gives no advice on ACKs carrying ECN feedback, 
other than that filtering ought to preserve the correct operation of ECN 
feedback, because at the time it said that "SACK and ECN remain areas of 
ongoing research". This section updates that best current practice for a 
TCP connection that supports AccECN feedback.


On 19/03/2022 19:47, Gorry (erg) 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, 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.
> 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.
> 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.
> 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?
> Gorry
> _______________________________________________
> tcpm mailing list

Bob Briscoe