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

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 <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://www.rfc-editor.org/errata/eid6697>
>> 
>> --------------------------------------
>> 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://www.ietf.org/mailman/listinfo/tcpm>
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>_______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm