Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-15.txt

Bob Briscoe <> Mon, 12 July 2021 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E8993A1264 for <>; Mon, 12 Jul 2021 15:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_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 Dw-_f6SVrSGM for <>; Mon, 12 Jul 2021 15:34:04 -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 1D4523A137D for <>; Mon, 12 Jul 2021 15:34:03 -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:Cc:From:References: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=53pLgM5TPpAfxMK84ap3Fa8dUzXSEBF2WAvTQrnjn3k=; b=D926/sZM4jiMLEjDGwFwEcVmuU iTzkolCnegG3duCG5wp4+LWi6snuCImI1kX7sFV3UdTqvzBzxAbxeM29OF1JlnY33truHv3/O/lGN lAZT/NpN//V+9k9u06uXaEAP8aedLTQ+RIEj61nrjg7H9ukNqu3di4HyauSyPRTCXkOm66bx//fWV 0be1+9e6BE2vhgpO01cewaFi73Di8I709FsV3PGvCFFY7PVA0bLFJH9rYu9JI2pbK+gUmiqIj89x6 QoDgTwYU0h8bnskEpGvWUCUwIQYgc5oxulFZXz9D0+WnokQLFyRGihD6ylLcrPQKBigGiv8fip+UK TsRJwiOA==;
Received: from ([]:35968 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1m34V1-0003FE-O0; Mon, 12 Jul 2021 23:34:00 +0100
References: <>
From: Bob Briscoe <>
Cc: Mirja Kuehlewind <>, Richard Scheffenegger <>, "Scheffenegger, Richard" <>
Message-ID: <>
Date: Mon, 12 Jul 2021 23:33:59 +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="------------FD8C327A58112FBD06DB2AA6"
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] I-D Action: draft-ietf-tcpm-accurate-ecn-15.txt
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, 12 Jul 2021 22:34:09 -0000


Just posted draft-15. Here's a summary of the main changes wrt draft-14.

Technical changes:

  * Major changes to " Data Receiver Safety Procedures":
      o the rules on Change-Triggered ACKs, Increment-Triggered ACKs,
        including discussion of ACKs of ACKs,
      o and clarification of what the rules mean when using receive offload
      o both as discussed at length on the list under the heading
        "Seeking WG opinions on ACKing ACKs with good cause"
  * Ignore AccECN TCP Option on a SYN if it does somehow arrive, even
    tho the sender shouldn't send it.
  * Major changes to "  Usage of the AccECN TCP Option":
      o recommended the most effective and simplest scheme to always
        send fields that have changed at some time during the connection
        on every packet that acks new data, and rearranged the other
        rules as variants of this
      o removed the rule to emit an ACK if any byte counter changes
        (AFAIR, I thought I had removed this when we made the option
        optional, but obviously not)
      o using experience from Ilpo's recent implementation and testing
        (and actually mostly making the text as we had intended it to
        be, but didn't realize we had left old stuff in there)
  * Updates to "3.3.2.  Requirements for Transparent Middleboxes and TCP
    Normalizers" as discussed with Gorry on list some time ago.
      o Mostly editorial rather than technical changes - made a clear
        distinction between what's expected from transparent middleboxes
        and from normalizers

Editorial changes:

  * Clearer distinction between ECN fields in IP and in TCP,
    particularly in the explanations in the early parts of the draft.
  * Replaced the ToDo in Security Considerations with a summary of the
    covert channel discussion
      o and added a sentencethat should have been saying sender
        misbehaviour is out of scope (following SECDIR review)
  * Took out remnants of references to experiments.
  * Minor updates throughout


Bob and co-authors.

On 12/07/2021 22:48, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>          Title           : More Accurate ECN Feedback in TCP
>          Authors         : Bob Briscoe
>                            Mirja Kühlewind
>                            Richard Scheffenegger
> 	Filename        : draft-ietf-tcpm-accurate-ecn-15.txt
> 	Pages           : 59
> 	Date            : 2021-07-12
> Abstract:
>     Explicit Congestion Notification (ECN) is a mechanism where network
>     nodes can mark IP packets instead of dropping them to indicate
>     incipient congestion to the end-points.  Receivers with an ECN-
>     capable transport protocol feed back this information to the sender.
>     ECN was originally specified for TCP in such a way that only one
>     feedback signal can be transmitted per Round-Trip Time (RTT).  Recent
>     new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP
>     (DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need more
>     accurate ECN feedback information whenever more than one marking is
>     received in one RTT.  This document specifies a scheme to provide
>     more than one feedback signal per RTT in the TCP header.  Given TCP
>     header space is scarce, it allocates a reserved header bit previously
>     assigned to the ECN-Nonce.  It also overloads the two existing ECN
>     flags in the TCP header.  The resulting extra space is exploited to
>     feed back the IP-ECN field received during the 3-way handshake as
>     well.  Supplementary feedback information can optionally be provided
>     in a new TCP option, which is never used on the TCP SYN.  The
>     document also specifies the treatment of this updated TCP wire
>     protocol by middleboxes.
> The IETF datatracker status page for this draft is:
> There is also an htmlized version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> tcpm mailing list

Bob Briscoe