Re: [tcpm] [tsvwg] [Technical Errata Reported] RFC3782 (6789)

[Yoshifumi Nishida <[e-mail]>]

I personally think the errata looks correct, but I would like to see if
there're other opinions.
But, in any case, it should be for RFC6582 rather than for RFC3782.
--
Yoshi

On Mon, Jan 3, 2022 at 9:02 AM Black, David <[e-mail]> wrote:

> +tcpm, Thanks, --David
>
> -----Original Message-----
> From: RFC Errata System <[e-mail]>
> Sent: Sunday, December 19, 2021 3:15 AM
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; Black, David; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [Technical Errata Reported] RFC3782 (6789)
>
>
> [EXTERNAL EMAIL]
>
> The following errata report has been submitted for RFC3782,
> "The NewReno Modification to TCP's Fast Recovery Algorithm".
>
> --------------------------------------
> You may review the report below and at:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6789__;!!LpKI!xxWA_mawfGxDiokgZx4JlYDNW_ZS26fWQiKHj4sSE9uTS0HGa1KsqyaqZqDwU0qQ$
> [rfc-editor[.]org]
>
> --------------------------------------
> Type: Technical
> Reported by: Clive Bloom <[e-mail]>
>
> Section: 6.1
>
> Original Text
> -------------
> If the Cumulative Acknowledgement field didn’t cover more than
> "recover", check to see if the congestion window is greater than
> SMSS bytes and the difference between highest_ack and
> prev_highest_ack is at most 4*SMSS bytes. If true, duplicate
> ACKs indicate a lost segment (proceed to Step 1A in Section 3).
> Otherwise, duplicate ACKs likely result from unnecessary
> retransmissions (proceed to Step 1B in Section 3).
>
> Corrected Text
> --------------
> If the Cumulative Acknowledgement field didn’t cover more than
> "recover", check to see if the congestion window is greater than
> SMSS bytes and the difference between highest_ack and
> prev_highest_ack is at most 3*SMSS bytes. If true, duplicate
> ACKs indicate a lost segment (proceed to Step 1A in Section 3).
> Otherwise, duplicate ACKs likely result from unnecessary
> retransmissions (proceed to Step 1B in Section 3).
>
> Notes
> -----
> RFC3782 references to Gur03 and GF04 papers as to the initial sources
> of the heuristics both ACK-based and Timestamp-based. Neither of those
> papers nor Gur03 nor GF04 defines difference between highest_ack and
> previous_highest_ack
> of at least 4*SMSS bytes upon receiving the third duplicate ACK as an
> indication
> of droped retransmitted segment. Instead, section III of GF04 says:
>
> "The acknowledgment heuristic is based on an observation that if the
> TCP sender unnecessarily retransmits at least three adjacent packets,
> there will be a jump by at least four segments in a cumulative
> acknowledgment field. The sender will have correctly retransmitted at least
> one packet, to advance the cumulative acknowledgment field, and
> unnecessarily retransmitted at least three more to result in three
> duplicate
> acknowledgments. Following the advancement of the cumulative acknowledgment
> field, the sender stores the value of the previous cumulative
> acknowledgment
> as prev_highest_ack and stores the latest cumulative acknowledgment as
> highest_ack. Upon receiving the third duplicate acknowledgment,
> the sender invokes a Fast Retransmit if its congestion window is greater
> than one MSS (Maximum Segment Size), and the difference between highest_ack
> and prev_highest_ack is at most three MSS."
>
> According to GF04 if TCP sender in absence of any droped acknowledgments
> upon receiving
> the third duplicate ACK has difference between highest_ack and
> prev_highest ack values
> of at most/i.e. no more than 3*SMSS bytes then this is explicite
> indication of droped retransmitted
> segment and leads TCP sender to invoke Fast Retransmit, but current
> description of ACK-based
> heuristic in RFC3782 section 6.1 in part of: "if the congestion window is
> greater than
> SMSS bytes and the difference between highest_ack and
> prev_highest_ack is at most 4*SMSS bytes. If true, duplicate
> ACKs indicate a lost segment (proceed to Step 1A in Section 3)", makes TCP
> sender to treat
> difference between highest_ack and prev_highest_ack of 4SMSS bytes upon
> receiving 3rd
> duplicate ACK as indication of lost retransmitted segment but again
> according to GF04 this is NOT so,
> and makes TCP sender to invoke Fast Retransmit when in fact those three
> duplicate acknowledgments
> indicate unnecessarily retransmitted segments and have in their
> acknowledgment fields sequence
> number which receiver expects to receive next but which sender has NOT
> sent yet, so Fast Retransmit
> has no point in this case.
>
> 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.
>
> --------------------------------------
> RFC3782 (draft-ietf-tsvwg-newreno-02)
> --------------------------------------
> Title               : The NewReno Modification to TCP's Fast Recovery
> Algorithm
> Publication Date    : April 2004
> Author(s)           : S. Floyd, T. Henderson, A. Gurtov
> Category            : PROPOSED STANDARD
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
>