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

[Martin Duke <[e-mail]>]

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