Re: [tcpm] [EXTERNAL] Re: [Technical Errata Reported] RFC8257 (6697)

Great catch Vidhi!

We don't need to change the section numbers. ECE is processed on acceptable ACK packets and there is already another bullet 3 which specifies that condition:

3.  If the ECE flag is set, update the bytes marked:

          DCTCP.BytesMarked += BytesAcked

So all we need is:

  9.  If the ECE flag is set, rather than always halving the congestion window as described in
       [RFC3168<https://datatracker.ietf.org/doc/html/rfc3168>], the sender SHOULD update cwnd as follows:

          cwnd = cwnd * (1 - DCTCP.Alpha / 2)

I don't think we need the additional explanation of how to implement the once per window reaction, even RFC 3168 does not specify those details.

From: Neal Cardwell <ncardwell@google.com>
Sent: Thursday, September 30, 2021 8:44 AM
To: Bob Briscoe <in@bobbriscoe.net>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>; sbens@microsoft.com; Dave Thaler <dthaler@microsoft.com>; Praveen Balasubramanian <pravb@microsoft.com>; lars@netapp.com; glenn.judd@morganstanley.com; martin.h.duke@gmail.com; Zaheduzzaman.Sarker@ericsson.com; Michael.Scharf@hs-esslingen.de; tuexen@fh-muenster.de; nsd.ietf@gmail.com; tcpm@ietf.org
Subject: [EXTERNAL] Re: [tcpm] [Technical Errata Reported] RFC8257 (6697)

I agree with the points made by Vidhi and Bob, and really like Bob's text.

In the suggested text there may be a typo; I believe we want s/SND.UNA/SND.NXT/. And probably we want to be more specific about only suppressing further ECN-based reductions (further loss-triggered reductions would be good to allow). I'm posting my suggested tweaks in blue, starting from Bob's nice green text:

SUGGESTED:
==========

3.4. Congestion Window Reduction

   Rather than always halving the congestion window as described in

   [RFC3168], on the arrival of ECN congestion feedback, the sender SHOULD

   update cwnd as follows:

      cwnd = cwnd * (1 - DCTCP.Alpha / 2)

   Just as specified in [RFC3168], DCTCP does not react to congestion

   indications more than once for every window of data. Therefore, as

   for RFC3168 ECN, it sets the variable for the end of congestion

   window reduced (CWR) state to SND.NXT and suppresses further

   ECN-triggered reductions until this TCP sequence number is acknowledged. Periods

   of CWR state are triggered by congestion feedback, and therefore

   occur at times unrelated to the continuous cycle of observation

   windows used to update DCTCP.Alpha in Section 3.3.

   The setting of the CWR bit is also as per [RFC3168].  This is

   required for interoperation with classic ECN receivers due to

   potential misconfigurations.

3.5.  Handling of Congestion Window Growth...

neal

On Thu, Sep 30, 2021 at 11:22 AM Bob Briscoe <in@bobbriscoe.net<mailto:in@bobbriscoe.net>> wrote:
Vidhi,

You're right. It's incorrect to have the window reduction hanging off the end of the list of steps for updating the EWMA.

To make this concrete, here's some specific additional text (in green for those with HTML mail readers). Also, rather than splitting into sub-subsections, I have suggested that Item 9. of the list in subsection 3.3 is moved out of the list, and instead forms the basis of a new subsection 3.4. entitled "Congestion Window Reduction".

CURRENT:
========

   9.  Rather than always halving the congestion window as described in

       [RFC3168], the sender SHOULD update cwnd as follows:

          cwnd = cwnd * (1 - DCTCP.Alpha / 2)

   Just as specified in [RFC3168], DCTCP does not react to congestion

   indications more than once for every window of data.  The setting of

   the CWR bit is also as per [RFC3168].  This is required for

   interoperation with classic ECN receivers due to potential

   misconfigurations.

3.4.  Handling of Congestion Window Growth...

SUGGESTED:
==========

3.4. Congestion Window Reduction

   Rather than always halving the congestion window as described in

   [RFC3168], on the arrival of congestion feedback, the sender SHOULD

   update cwnd as follows:

      cwnd = cwnd * (1 - DCTCP.Alpha / 2)

   Just as specified in [RFC3168], DCTCP does not react to congestion

   indications more than once for every window of data. Therefore, as

   for RFC3168 ECN, it sets the variable for the end of congestion

   window reduced (CWR) state to SND.UNA and suppresses further

   reductions until this TCP sequence number is acknowledged. Periods

   of CWR state are triggered by congestion feedback, and therefore

   occur at times unrelated to the continuous cycle of observation

   windows used to update DCTCP.Alpha in Section 3.3.

   The setting of the CWR bit is also as per [RFC3168].  This is

   required for interoperation with classic ECN receivers due to

   potential misconfigurations.

3.5.  Handling of Congestion Window Growth...

Then the of numbering all subsequent subsections of section 3. will increment by 0.1.

Bob
On 28/09/2021 08:18, RFC Errata System wrote:

The following errata report has been submitted for RFC8257,

"Data Center TCP (DCTCP): TCP Congestion Control for Data Centers".

--------------------------------------

You may review the report below and at:

https://www.rfc-editor.org/errata/eid6697<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6697&data=04%7C01%7Cpravb%40microsoft.com%7C1bfca5149bd24bc83e3608d9842927dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686134599340937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vA5l%2Be1sLhWo8%2BRg9yrBlahGry2U2rsQwjkEB0hKrUo%3D&reserved=0>

--------------------------------------

Type: Technical

Reported by: Vidhi Goel <vidhi_goel@apple.com><mailto:vidhi_goel@apple.com>

Section: 3.3

Original Text

-------------

The below pseudocode follows after DCTCP.Alpha is updated on ACK processing. This is wrong as cwnd should only be reduced using DCTCP.Alpha when ECE is received.

9. Rather than always halving the congestion window as described in

       [RFC3168], the sender SHOULD update cwnd as follows:

          cwnd = cwnd * (1 - DCTCP.Alpha / 2)

Corrected Text

--------------

Instead, a new paragraph for Congestion Response to ECN feedback would be much clearer. First start with RFC 3168's response to ECE and then provide DCTCP's response to ECE.

I am thinking splitting section 3.3 into two sub-sections -

3.3.1 Computation of DCTCP.Alpha

3.3.2 Congestion Response to ECE at sender

Notes

-----

Although RFC 8257 refers to RFC 3168 congestion window halving at step 9, but it is confusing to put it right after step 8.

Instructions:

-------------

This erratum is currently posted as "Reported". If necessary, please

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party

can log in to change the status and edit the report, if necessary.

--------------------------------------

RFC8257 (draft-ietf-tcpm-dctcp-10)

--------------------------------------

Title               : Data Center TCP (DCTCP): TCP Congestion Control for Data Centers

Publication Date    : October 2017

Author(s)           : S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd

Category            : INFORMATIONAL

Source              : TCP Maintenance and Minor Extensions

Area                : Transport

Stream              : IETF

Verifying Party     : IESG

_______________________________________________

tcpm mailing list

tcpm@ietf.org<mailto:tcpm@ietf.org>

https://www.ietf.org/mailman/listinfo/tcpm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7C1bfca5149bd24bc83e3608d9842927dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686134599350894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nfQWrs6AQILOXyUMDakUfjbLZ4rO%2FxPboBCt%2F3oAg9A%3D&reserved=0>

--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbobbriscoe.net%2F&data=04%7C01%7Cpravb%40microsoft.com%7C1bfca5149bd24bc83e3608d9842927dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686134599350894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B7pyxiEVcF4tkQ3G5IDlVmUKvpG7Tfs5HumS71Pt1Qs%3D&reserved=0>
_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7C1bfca5149bd24bc83e3608d9842927dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686134599360856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vlPWpQfej2%2BcLgrJqWMLnoNFeJ%2BtFdKaw%2BR4%2BQPtJOM%3D&reserved=0>