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

[Martin Duke <[e-mail]>]

Yes, I'm the one to apply the erratum to the RFC.

The rfc-editor page presents both the original and corrected version of the
RFC. A future RFC that obsoletes this one would be expected to incorporate
all verified errata.

On Thu, Nov 4, 2021 at 9:57 AM t petch <[e-mail]> wrote:

> n 04/11/2021 00:37, Vidhi Goel wrote:
> >>> The status of this erratum is 'Reported'. I think some consensus was
> reached on the list. What happens now? Who is meant to propose updated text
> for the erratum based on the discussion?
> >> Hi Bob,
> >>
> >> as far as I know, the WG chairs can't change erratas. That might be
> possible for AD, I think,
> >> but I'm not sure.
> >
> > I am a bit new to the errata process and would like to understand a bit
> more about next steps. Based on Bob’s suggestion about updated text and
> feedback from others, how do we proceed to make the necessary change to the
> RFC 8257?
> > Is the only thing we can do now is somehow update the Suggestion in
> errata itself? When would the update me applied to the RFC?
>
>
> The usual form of an Erratum is along the lines of
> OLD
> <current text>
> NEW
> <proposed text>
> Note
> Section 31.102 is ambiguous and could be interpreted as ... or ....
> This erratum .....
>
>
> Discussion may result in a better version of <proposed text> in which
> case the usual practice is to reject the Erratum and craft a new one.
>
> ADs sometimes add notes explaining why the action that is being taken is
> being taken but I think it unusual for an AD to do more than that.
>
> This Erratum I do not understand and so would reject.  What is the
> problem?  What is the fix?
>
> As others have said, an Erratum cannot change the consensus expressed in
> the RFC.  The RFC is immutable.  A change of meaning is a new RFC.
>
> Perhaps discuss on the list what you perceive the problem to be and if
> there is consensus that there is a problem and that it falls within the
> limited scope of an Erratum, then craft an Erratum.
>
> Tom Petch
>
> > Thanks,
> > Vidhi
> >
> >> On Nov 3, 2021, at 12:02 PM, [e-mail] wrote:
> >>
> >>> On 3. Nov 2021, at 19:09, Bob Briscoe <[e-mail]> wrote:
> >>>
> >>> TCPM chairs,
> >>>
> >>> The status of this erratum is 'Reported'. I think some consensus was
> reached on the list. What happens now? Who is meant to propose updated text
> for the erratum based on the discussion?
> >> Hi Bob,
> >>
> >> as far as I know, the WG chairs can't change erratas. That might be
> possible for AD, I think,
> >> but I'm not sure.
> >>
> >> Best regards
> >> Michael
> >>>
> >>>
> >>> Bob
> >>>
> >>> On 01/10/2021 14:12, Bob Briscoe wrote:
> >>>> Neal,
> >>>>
> >>>> On 30/09/2021 16:43, Neal Cardwell wrote:
> >>>>> 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/.
> >>>>
> >>>> [BB] Agree (and your next point about solely ECN indications).
> >>>>
> >>>> I only said SND.UNA 'cos I was looking back at this earlier sentence
> in the RFC, and I copied the idea without engaging brain:
> >>>>    o  DCTCP.WindowEnd: the TCP sequence number threshold when one
> >>>>       observation window ends and another is to begin; initialized to
> >>>>       SND.UNA.
> >>>>
> >>>> Why does this say SND.UNA? Is this another erratum? I believe the
> Linux code initializes to SND.NXT in dctcp_reset(), which is called from
> dctcp_init():
> >>>> https://elixir.bootlin.com/linux/v4.7/source/net/ipv4/tcp_dctcp.c#L78
> >>>>
> >>>> BTW, step 7 correctly says SND.NXT:
> >>>>    7.  Determine the end of the next observation window:
> >>>>
> >>>>           DCTCP.WindowEnd = SND.NXT
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Bob
> >>>>
> >>>>> 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 <[e-mail]>
> 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
> >>>>>>
> >>>>>>
> >>>>>> --------------------------------------
> >>>>>> Type: Technical
> >>>>>> Reported by: Vidhi Goel
> >>>>>> <[e-mail]>
> >>>>>>
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/tcpm
> >>>>>
> >>>>> --
> >>>>> ________________________________________________________________
> >>>>> Bob Briscoe
> >>>>> http://bobbriscoe.net/
> >>>>> _______________________________________________
> >>>>> tcpm mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/tcpm
> >>>>
> >>>> --
> >>>> ________________________________________________________________
> >>>> Bob Briscoe
> >>>> http://bobbriscoe.net/
> >>>
> >>> --
> >>> ________________________________________________________________
> >>> Bob Briscoe
> >>> http://bobbriscoe.net/
> >>
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
>