Subject: [tcpm] [Technical Errata Reported] RFC8257 (6697)

From: RFC Errata System <[email-masked]>
Date: Tue, 28 Sep 2021 00:18:18 -0700 (PDT)

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

--------------------------------------
Type: Technical
Reported by: Vidhi Goel <[email-masked]>

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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 30 Sep 2021 12:48:43 +0100

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:
========

    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:

    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:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

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

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 30 Sep 2021 11:43:57 -0400

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:
==========

   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:

   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.*

neal

On Thu, Sep 30, 2021 at 11:22 AM Bob Briscoe <[email-masked]> 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
>    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.*
>
> You may review the report below and at:https://www.rfc-editor.org/errata/eid6697
>
> Reported by: Vidhi Goel <[email-masked]> <[email-masked]>
>
> Section: 3.3
>
> Original Text
> -------------
> tcpm mailing [email-masked]://www.ietf.org/mailman/listinfo/tcpm
>
>
> --

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 30 Sep 2021 16:07:03 +0000

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:

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 <[email-masked]>
Sent: Thursday, September 30, 2021 8:44 AM
To: Bob Briscoe <[email-masked]>
Cc: RFC Errata System <[email-masked]>; [email-masked]; Dave Thaler <[email-masked]>; Praveen Balasubramanian <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [tcpm] [Technical Errata Reported] RFC8257 (6697)

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

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

   update cwnd as follows:

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

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

   windows used to update DCTCP.Alpha in Section 3.3.

3.5.  Handling of Congestion Window Growth...

neal

On Thu, Sep 30, 2021 at 11:22 AM Bob Briscoe <[email-masked]<mailto:[email-masked]>> 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:
========

   misconfigurations.

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

3.4. Congestion Window Reduction

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

   update cwnd as follows:

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

   windows used to update DCTCP.Alpha in Section 3.3.

3.5.  Handling of Congestion Window Growth...

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

Bob

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 <[email-masked]><mailto:[email-masked]>

Section: 3.3

Original Text

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

Corrected Text

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

Notes

-----

Instructions:

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

Category            : INFORMATIONAL

Area                : Transport

Stream              : IETF

Verifying Party     : IESG

tcpm mailing list

[email-masked]<mailto:[email-masked]>

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
[email-masked]<mailto:[email-masked]>
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>

---

From: Vidhi Goel <[email-masked]>
Date: Thu, 30 Sep 2021 14:07:18 -0700

Thank you Bob for providing a complete suggestion.

Section 3.3 is titled Processing Echoed Congestion Indications on the Sender, so probably this should include Congestion Window Reduction as well. That’s why I suggested to create two sub-sections.

Alternatively, we can also use your suggestion by re-titling Section 3.3, something like,
Section 3.3 Computing Moving Average of ECN Feedback
Section 3.4 Reducing Congestion Window based on ECN Feedback
Section 3.5 Handling of Congestion Window Growth
…

Thanks,
Vidhi

> On Sep 30, 2021, at 4:48 AM, Bob Briscoe <[email-masked]> wrote:
> 
> Vidhi,
> 
>> https://www.rfc-editor.org/errata/eid6697 <https://www.rfc-editor.org/errata/eid6697>
>> 
>> Reported by: Vidhi Goel <[email-masked]> <mailto:[email-masked]>
>> 
>> Section: 3.3
>> 
>> Original Text
>> -------------
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> -- 
> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>_______________________________________________
> tcpm mailing list
> [email-masked]

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 30 Sep 2021 21:14:38 +0000

Trying to send my old response again as it got stuck in moderation.

Great catch Vidhi!

So all we need is:

From: Vidhi Goel <[email-masked]>
Sent: Thursday, September 30, 2021 2:07 PM
To: Bob Briscoe <[email-masked]>
Cc: RFC Errata System <[email-masked]>; [email-masked]; Dave Thaler <[email-masked]>; Praveen Balasubramanian <[email-masked]>; [email-masked]; [email-masked]; Martin Duke <[email-masked]>; [email-masked]; [email-masked]; Michael Tuexen <[email-masked]>; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [tcpm] [Technical Errata Reported] RFC8257 (6697)

Section 3.3 is titled Processing Echoed Congestion Indications on the Sender, so probably this should include Congestion Window Reduction as well. That's why I suggested to create two sub-sections.

...

Thanks,
Vidhi

On Sep 30, 2021, at 4:48 AM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:

Vidhi,

CURRENT:
========

   misconfigurations.

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

   update cwnd as follows:

Bob

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%7C6adfa975d9744f6a289b08d984564c71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686328526119642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xqxUAHtiFNrST8HTP5sWFhpDq2SJ2%2Bsl8tQ%2Byh1OaUM%3D&reserved=0>

Type: Technical

Section: 3.3

Original Text

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

Corrected Text

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

Notes

-----

Instructions:

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

Category            : INFORMATIONAL

Area                : Transport

Stream              : IETF

Verifying Party     : IESG

tcpm mailing list

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%7C6adfa975d9744f6a289b08d984564c71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686328526119642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X63EYFpc%2FnO4Px7I61QHgopu4Qs09fOEYOhdWfeo%2F4U%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%7C6adfa975d9744f6a289b08d984564c71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686328526119642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lG5TRWIlxHSVIj6gDXj1I83tHKCkcfWfcVr%2BgnzzomI%3D&reserved=0>
_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm