Re: [tcpm] Fwd: [Technical Errata Reported] RFC6582 (6871)

[Yoshifumi Nishida <[e-mail]>]

Hi Martin,
I personally think this errata is correct.
--
Yoshi

On Thu, Jan 18, 2024 at 3:10 PM Martin Duke <[e-mail]> wrote:

> I do not have any TCP code in front of me, but ISTM this errata is
> accurate.
>
> if the window advances by 3 MSS or less, that implies that <= 2 DUPACKs
> were lost, which would not have triggered a Fast Retransmit.
>
> If the window advances by 4 MSS or more, then the peer should have sent at
> least 3 DUPACKs, which if received would have triggered FR.
>
> Am I thinking about this correctly?
>
> ---------- Forwarded message ---------
> From: RFC Errata System <[e-mail]>
> Date: Mon, Mar 7, 2022 at 7:08 AM
> Subject: [Technical Errata Reported] RFC6582 (6871)
> To: <[e-mail]>, <[e-mail]>, <[e-mail]>,
> <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>
> Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
>
>
> The following errata report has been submitted for RFC6582,
> "The NewReno Modification to TCP's Fast Recovery Algorithm".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6871
>
> --------------------------------------
> Type: Technical
> Reported by: Clive Bloom <[e-mail]>
>
> Section: 4.1
>
> Original Text
> -------------
> If the Cumulative Acknowledgment 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 (enter fast retransmit).
> Otherwise, duplicate ACKs likely result from unnecessary
> retransmissions (do not enter fast retransmit).
>
> Corrected Text
> --------------
> If the Cumulative Acknowledgment 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 (enter fast retransmit).
> Otherwise, duplicate ACKs likely result from unnecessary
> retransmissions (do not enter fast retransmit).
>
> Notes
> -----
> RFC6582 (as well as 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 RFC6582 section 4.1 in part of: "If the Cumulative
> Acknowledgment 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 (enter fast retransmit).
> Otherwise, duplicate ACKs
> likely result from unnecessary retransmissions (do not enter fast
> retransmit). ", 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.
>
> --------------------------------------
> RFC6582 (draft-ietf-tcpm-rfc3782-bis-05)
> --------------------------------------
> Title               : The NewReno Modification to TCP's Fast Recovery
> Algorithm
> Publication Date    : April 2012
> Author(s)           : T. Henderson, S. Floyd, A. Gurtov, Y. Nishida
> Category            : PROPOSED STANDARD
> 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
>