RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Held for Document Update (1)

RFC 7323, "TCP Extensions for High Performance", September 2014

Source of RFC: tcpm (wit)

Errata ID: 5585
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Marco Caspers
Date Reported: 2018-12-27
Held for Document Update by: Mirja Kühlewind
Date Held: 2019-03-18

Section 2.2 says:

2.2.  Window Scale Option

   The three-byte Window Scale option MAY be sent in a <SYN> segment by
   a TCP.  It has two purposes: (1) indicate that the TCP is prepared to
   both send and receive window scaling, and (2) communicate the
   exponent of a scale factor to be applied to its receive window.
   Thus, a TCP that is prepared to scale windows SHOULD send the option,
   even if its own scale factor is 1 and the exponent 0.  The scale
   factor is limited to a power of two and encoded logarithmically, so
   it may be implemented by binary shift operations.  The maximum scale
   exponent is limited to 14 for a maximum permissible receive window
   size of 1 GiB (2^(14+16)).

It should say:

2.2.  Window Scale Option

   The three-byte Window Scale option MAY be sent in a <SYN> segment by
   a TCP.  It has two purposes: (1) indicate that the TCP is prepared to
   both send and receive window scaling, and (2) communicate the
   exponent of a scale factor to be applied to its receive window.
   Thus, a TCP that is prepared to scale windows SHOULD send the option,
   even if its own scale factor is 1 and the exponent 0.  The scale
   factor is limited to a power of two and encoded logarithmically, so
   it may be implemented by binary shift operations.  The maximum scale
   exponent is limited to 14 for a maximum permissible receive window
   size of approximately 1 GiB ((2^30-1) - (2^14-1)).

Notes:

Left shift inserts zero's on the right hand side so the maximum window size is actually 16KiB shy of 1 GiB. The exact calculation would be ((2^30-1) - (2^14-1)). As it is stated as "approximately 1 GiB" the text is not incorrect but it would be good to provide the complete calculation in a document update to avoid invalid implementations.

Status: Rejected (2)

RFC 7323, "TCP Extensions for High Performance", September 2014

Source of RFC: tcpm (wit)

Errata ID: 5586
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Marco Caspers
Date Reported: 2018-12-27
Rejected by: Mirja Kühlewind
Date Rejected: 2020-03-06

Section 2.3 says:

Since the max window is 2^S (where S is the scaling shift count)
   times at most 2^16 - 1 (the maximum unscaled window), the maximum
   window is guaranteed to be < 2^30 if S <= 14.  Thus, the shift count
   MUST be limited to 14 (which allows windows of 2^30 = 1 GiB).  If a
   Window Scale option is received with a shift.cnt value larger than
   14, the TCP SHOULD log the error but MUST use 14 instead of the
   specified value.  This is safe as a sender can always choose to only
   partially use any signaled receive window.  If the receiver is
   scaling by a factor larger than 14 and the sender is only scaling by
   14, then the receive window used by the sender will appear smaller
   than it is in reality.


It should say:

Since the max window is 2^S (where S is the scaling shift count)
   times at most 2^16 - 1 (the maximum unscaled window), the maximum
   window is guaranteed to be < 2^30-2^14 if S <= 14.  Thus, the shift
 count
   MUST be limited to 14 (which allows windows of 2^30-2^14 ~ 1 GiB).
  If a
   Window Scale option is received with a shift.cnt value larger than
   14, the TCP SHOULD log the error but MUST use 14 instead of the
   specified value.  This is safe as a sender can always choose to only
   partially use any signaled receive window.  If the receiver is
   scaling by a factor larger than 14 and the sender is only scaling by
   14, then the receive window used by the sender will appear smaller
   than it is in reality.

Notes:

Shifting is inserting zeroes on the right hand side. Thus for S = 14 the 14 right most bits are zero and thus the calculation 2^30 is invalid for the guaranteed maximum window size.

Correct calculation formulae is (2^30 - 1) - (2^14 -1).
Which can be simplified to 2^30 - 2^14.
--VERIFIER NOTES--
That section is for illustration purposes only, and not intended as an exact value for the maximum supported window size.

It is correct that the maximum supported window size is 2^30-2^14, but the requirement is, that the window size has to remain smaller than 2^30.

Errata ID: 6798
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Yaakov Stein
Date Reported: 2021-12-26
Rejected by: Martin Duke
Date Rejected: 2022-05-13

Throughout the document, when it says:

The Timestamps option may appear in any data or <ACK> segment, adding

The timestamp clock may be derived from a system clock that is

A random offset may be added to the timestamp clock on a per-

It should say:

The Timestamps option MAY appear in any data or <ACK> segment, adding

The timestamp clock MAY be derived from a system clock that is

A random offset MAY be added to the timestamp clock on a per-

Notes:

several "MAY"s were incorrectly written as non RFC 2119 "may"s
--VERIFIER NOTES--
These examples are non-normative. The first is explanatory, and the other two are examples of ways to meet the requirement.

Report New Errata



Advanced Search