RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.rfc-editor.org/errata/rfc3782 below:

RFC Errata Report » RFC Editor

Found 2 records.

Status: Verified (1) RFC 3782, "The NewReno Modification to TCP's Fast Recovery Algorithm", April 2004

Note: This RFC has been obsoleted by RFC 6582

Source of RFC

: tsvwg (wit)

Errata ID: 231
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2004-06-07

Section 8 says:

   When not in Fast Recovery, the value of the state variable "recover"
   should be pulled along with the value of the state variable for
   acknowledgments (typically, "snd_una") so that, when large amounts of
   data have been sent and acked, the sequence space does not wrap and
   falsely indicate that Fast Recovery should not be entered (Section 3,
   step 1, last paragraph).

It should say:

   When updating the Cumulative Acknowledgement field outside of
   Fast Recovery, the "recover" state variable may also need to be
   updated in order to continue to permit possible entry into Fast
   Recovery (Section 3, step 1).  This issue arises when an update
   of the Cumulative Acknowledgement field results in a sequence
   wraparound that affects the ordering between the Cumulative
   Acknowledgement field and the "recover" state variable.  Entry
   into Fast Recovery is only possible when the Cumulative
   Acknowledgment field covers more than the "recover" state variable.

Notes:

Status: Rejected (1) RFC 3782, "The NewReno Modification to TCP's Fast Recovery Algorithm", April 2004

Note: This RFC has been obsoleted by RFC 6582

Source of RFC

: tsvwg (wit)

Errata ID: 6789
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Clive Bloom
Date Reported: 2021-12-19
Rejected by: Martin Duke
Date Rejected: 2022-05-13

Section 6.1 says:

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).

It should say:

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.
--VERIFIER NOTES--
RFC 3782 has been obsoleted by RFC 6582.

Report New Errata

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4