Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-17.txt

From: [email-masked]
Date: Mon, 07 Mar 2022 15:17:49 -0800

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 7 Mar 2022 23:25:39 +0000

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
    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-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
    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.2>:
    AccECN Feedback
    made "MUST increment byte counters" conditional on support for
    sending of the AccECN TCP Option
  * §3.2.2.3
    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-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
    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-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
    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-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
    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-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
    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-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, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 20 Mar 2022 02:50:27 -0700

Hi Bob,

   - 'that acknowledges new data' -> 'if any byte counter has incremented
   since the last ACK' {*includes new markings on retransmssions*}

Does this mean when you retransmit a packet, the acc option in the packet
should be updated to contain the latest info?
If we do this, wouldn't it be hard for the receivers to tell which packet
contains the most recent info when there's reordering?
--
Yoshi

On Mon, Mar 7, 2022 at 3:26 PM Bob Briscoe <[email-masked]> wrote:

> 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).
> 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.
>
>    - §3.1.1
>    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
>    made "MUST increment byte counters" conditional on support for sending
>    of the AccECN TCP Option
>    - §3.2.2.3
>       - SHOULD NOT send ECN-capable packets and *then SHOULD NOT respond
>       - *Throughout, it MUST remain in the AccECN feedback mode*
>       {additional requirement}
>       - and it MUST continue to feed back any ECN markings on arriving
>    - §3.2.2.5.1
>    - 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
>    Condition for 'SHOULD include an AccECN TCP Option on every scheduled
>    ACK':
>       - 'that acknowledges new data' -> 'if any byte counter has
>    - §3.3.3
>       - '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
>    - 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
>
> 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
>
>
> tcpm mailing [email-masked]://www.ietf.org/mailman/listinfo/tcpm
>
>
> --
> Bob Briscoe                               http://bobbriscoe.net/
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sun, 20 Mar 2022 16:05:09 +0100

Hi Yoshi,

by design, the AccECN counters (ACE and Option) are strictly
monotonically increasing.

While it may be possible for reordering to be problematic with the ACE
counter (during also high ACK loss, reordering and forward path marking
- all of which would need to coincide), this is much less of a problem
with the full 24-bit counters in the option.

On the upside, not tracking which counter was relevant with the original
segment's data payload dramatically reduces the implementation
complexity in the receiver.

Best regard,
    Richard

Am 20.03.2022 um 10:50 schrieb Yoshifumi Nishida:
> Hi Bob,
>
>   * 'that acknowledges new data' -> 'if any byte counter has incremented
> Does this mean when you retransmit a packet, the acc option in the
> packet should be updated to contain the latest info?
> If we do this, wouldn't it be hard for the receivers to tell which
> packet contains the most recent info when there's reordering?
> --
> Yoshi
>
> On Mon, Mar 7, 2022 at 3:26 PM Bob Briscoe <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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).
>
>         field on the SYN-ACK to make more sense {no technical change,
>         just clearer}
>       * §3.2
>           o SHOULD NOT send ECN-capable packets and *then SHOULD NOT
>             respond to any ECN feedback* {added second part of this
>             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
>           o Changed to 'In either case, *'n' MUST be no greater than
>             7*.' (was 6)
>       * §3.2.3.3
>             {*previously it described how this SHOULD be done, now it
>             just gives the high level requirement*}
>
>
>     Technical
>
>       * §3.2.1
>       * 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, [email-masked]
>     <mailto:[email-masked]> wrote:
>>     https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/  <https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/>
>>
>>     https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html  <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html>
>>
>>     https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-17  <https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-17>
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/tcpm  <https://www.ietf.org/mailman/listinfo/tcpm>
>
>     --
>     Bob Briscoehttp://bobbriscoe.net/  <http://bobbriscoe.net/>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tcpm>
>
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Mar 2022 01:08:11 +0000

Yoshi,

On 20/03/2022 09:50, Yoshifumi Nishida wrote:
> Hi Bob,
>
>   * 'that acknowledges new data' -> 'if any byte counter has

[BB] Yes and No (I don't think so, but perhaps I misunderstand your 
question).

For first question: see end of §3.2, which has been there since the 
start of AccECN:

    Whenever a host feeds back the value of any counter, it MUST report
    the most recent value, no matter whether it is in a pure ACK, an ACK
    with new payload data or a retransmission.  Therefore the feedback
    carried on a retransmitted packet is unlikely to be the same as the
    feedback on the original packet.

For second question, when you say "the receiver"
* if you mean the Data Receiver (i.e. the sender of the feedback), it 
doesn't need to know. It just increments its counters in whatever order 
markings arrive, whether on retransmissions or not, and feeds back the 
latest counter.
* if you mean the Data Sender, see A.1 or A.2.1 where the example 
algorithms at the Data Sender check whether a packet is superseded 
(based on ackno, sack & timestamps if available) before using the feedback.

Does that answer your questions?

Bob

>     below about ACK filtering has been discussed before, but the
>     precise wording hasn't been posted to the list until now.
>
>         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
>         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
>
>         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
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 21 Mar 2022 01:35:37 -0700

Hi Richard, Bob,

Thanks for the responses.

On Sun, Mar 20, 2022 at 6:08 PM Bob Briscoe <[email-masked]> wrote:

> For first question: see end of §3.2, which has been there since the start
> of AccECN:
>
> algorithms at the Data Sender check whether a packet is superseded (based
> on ackno, sack & timestamps if available) before using the feedback.
>

Yes. Thanks for the explanation.
I've thought about the case where there's large re-ordering,
But, given that accecn option has 24bits fields as Rechard pointed out, I
think the possibility of the risk would be pretty low.

Thanks,
--
Yoshi