From nobody Mon Mar 7 15:25:49 2022 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10053A0FBE for ; Mon, 7 Mar 2022 15:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.109 X-Spam-Level: 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T7Azj5ODTlO for ; Mon, 7 Mar 2022 15:25:42 -0800 (PST) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A313A0E14 for ; Mon, 7 Mar 2022 15:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:From:References:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To:Cc: 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=pIuJbMtZ55YSVHmA1lRV0Glbevn4MtoNpUQt8FgUEpw=; b=682rdRLpJa3LmclqcPXWFmS0Fz ZIYA5GlmwJJdwFPBvMAbzJXKN4GCYM1rpAKVKhW6lNWDj6oTR+jcU1zMgDTqjWDFxgrPyJesUEMgX 6spNK8XHiMl+ucTUAP4v5KyagYzcNtF0m0Obz4Vv2U5MhXKMqrLHQ3IlOjsjJk3tabBLnR89htaq2 ot5dGi4UZDw/hKm1vZMoctCQ1TZUPdm0KxhXxmq7gmsLFkRUb3oHcLOCwh/mx6JnEEzt7Be0cWsOJ RsqCsP1f7CMF4BsP0t7FERlcncYI73PHh1u9Hl6OlzsBT6+Qo3cZaw8uUJfxlubF9eDM6d48L6PAa cRiliT6g==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:55854 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nRMjW-00055l-HW for tcpm@ietf.org; Mon, 07 Mar 2022 23:25:39 +0000 Content-Type: multipart/alternative; boundary="------------IsxLHzMOIs0b43bAIlKMK3rw" Message-ID: <2603fe69-5d17-f23b-53cb-b69690673f7d@bobbriscoe.net> Date: Mon, 7 Mar 2022 23:25:39 +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: tcpm@ietf.org References: <164669506897.29288.5626108129531513971@ietfa.amsl.com> From: Bob Briscoe In-Reply-To: <164669506897.29288.5626108129531513971@ietfa.amsl.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [tcpm] Summary of updates in draft-ietf-tcpm-accurate-ecn-17 X-BeenThere: tcpm@ietf.org 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, 07 Mar 2022 23:25:48 -0000 This is a multi-part message in MIME format. --------------IsxLHzMOIs0b43bAIlKMK3rw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit tcpm-ers, The AccECN draft has just been updated to roll up all the changes over the last month since draft-16 (3 Feb 22). https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn All the changes have already been discussed on this list, but they are enumerated below for convenience. The last normative change below about ACK filtering has been discussed before, but the precise wording hasn't been posted to the list until now. As always, the full diff can be accessed from the datatracker (via the above link). Normative (Changes intended to make a technical difference are *in bold*) * §3.1.1 : Negotiation during the TCP handshake Reordered the requirements for feeding back the incoming IP-ECN field on the SYN-ACK to make more sense {no technical change, just clearer} * §3.2 : AccECN Feedback made "MUST increment byte counters" conditional on support for sending of the AccECN TCP Option * §3.2.2.3 : Testing for Mangling of the IP/ECN Field If continuous CE-marking is detected, Data Sende: o SHOULD NOT send ECN-capable packets and *then SHOULD NOT respond to any ECN feedback* {added second part of this requirement} o *Throughout, it MUST remain in the AccECN feedback mode* {additional requirement} o and it MUST continue to feed back any ECN markings on arriving packets (in its role as Data Receiver) {just reworded a bit} * §3.2.2.5.1 : Data Receiver Safety Procedures Increment-Triggered ACKs: o Clarified that the condition about 'new data' means 'newly delivered data' {no difference in meaning, just clearer} o Changed to 'In either case, *'n' MUST be no greater than 7*.' (was 6) * §3.2.3.3 : Usage of the AccECN TCP Option Condition for 'SHOULD include an AccECN TCP Option on every scheduled ACK': o 'that acknowledges new data' -> 'if any byte counter has incremented since the last ACK' {*includes new markings on retransmssions*} * §3.3.3 : Requirements for TCP ACK Filtering o 'SHOULD preserve the correct operation of AccECN feedback' {*previously it described how this SHOULD be done, now it just gives the high level requirement*} Technical * §3.2.1 : Initialization of Feedback Counters Made initialization of ECT(1) feedback counter r.e1b the same as r.e0b, now that we have the two different TCP Option orders. Editorial * Made other parts of the spec consistent with the above changes * Called out the updates to other RFCs in the abstract * Increased depth of table of contents to 4 (was 3) * Added titles to all tables (xml2rfc now adds a 'Table xx' caption to the HTML rendering whether or not there is a caption title, and even if suppress-title=true i enabled). * Other minor edits Bob On 07/03/2022 23:17, internet-drafts@ietf.org 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-17.txt > Pages : 60 > Date : 2022-03-07 > > 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 updates the original ECN > specification to specify 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, updating > BCP 69 with respect to ACK filtering. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-17 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------IsxLHzMOIs0b43bAIlKMK3rw Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit tcpm-ers,

The AccECN draft has just been updated to roll up all the changes over the last month since draft-16 (3 Feb 22).
    https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn
All the changes have already been discussed on this list, but they are enumerated below for convenience. The last normative change below about ACK filtering has been discussed before, but the precise wording hasn't been posted to the list until now.

As always, the full diff can be accessed from the datatracker (via the above link).

Normative (Changes intended to make a technical difference are in bold)
  • §3.1.1: Negotiation during the TCP handshake
    Reordered the requirements for feeding back the incoming IP-ECN field on the SYN-ACK to make more sense {no technical change, just clearer}
  • §3.2: AccECN Feedback
    made "MUST increment byte counters" conditional on support for sending of the AccECN TCP Option
  • §3.2.2.3: Testing for Mangling of the IP/ECN Field
    If continuous CE-marking is detected, Data Sende:
    • SHOULD NOT send ECN-capable packets and then SHOULD NOT respond to any ECN feedback {added second part of this requirement}
    • Throughout, it MUST remain in the AccECN feedback mode {additional requirement}
    • and it MUST continue to feed back any ECN markings on arriving packets (in its role as Data Receiver) {just reworded a bit}
  • §3.2.2.5.1: Data Receiver Safety Procedures
    Increment-Triggered ACKs:
    • Clarified that the condition about 'new data' means 'newly delivered data' {no difference in meaning, just clearer}
    • Changed to 'In either case, 'n' MUST be no greater than 7.' (was 6)
  • §3.2.3.3: Usage of the AccECN TCP Option
    Condition for 'SHOULD include an AccECN TCP Option on every scheduled ACK':
    • 'that acknowledges new data' -> 'if any byte counter has incremented since the last ACK' {includes new markings on retransmssions}
  • §3.3.3: Requirements for TCP ACK Filtering
    • 'SHOULD preserve the correct operation of AccECN feedback' {previously it described how this SHOULD be done, now it just gives the high level requirement}

Technical
  • §3.2.1: Initialization of Feedback Counters
    Made initialization of ECT(1) feedback counter r.e1b the same as r.e0b, now that we have the two different TCP Option orders.

Editorial
  • Made other parts of the spec consistent with the above changes
  • Called out the updates to other RFCs in the abstract
  • Increased depth of table of contents to 4 (was 3)
  • Added titles to all tables (xml2rfc now adds a 'Table xx' caption to the HTML rendering whether or not there is a caption title, and even if suppress-title=true i enabled).
  • Other minor edits


Bob

On 07/03/2022 23:17, internet-drafts@ietf.org 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-17.txt
	Pages           : 60
	Date            : 2022-03-07

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 updates the original ECN
   specification to specify 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, updating
   BCP 69 with respect to ACK filtering.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-17


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------IsxLHzMOIs0b43bAIlKMK3rw--