RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (3)

RFC 7413, "TCP Fast Open", December 2014

Source of RFC: tcpm (wit)

Errata ID: 4238
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Matthew Luckie
Date Reported: 2015-01-22
Verifier Name: Martin Stiemerling
Date Verified: 2015-11-02

Section 4.1.1 says:

   Kind            1 byte: value = 34
   Length          1 byte: range 6 to 18 (bytes); limited by
                           remaining space in the options field.
                           The number MUST be even.
   Cookie          0, or 4 to 16 bytes (Length - 2)

It should say:

   Kind            1 byte: value = 34
   Length          1 byte: range 2 to 18 (bytes); limited by
                           remaining space in the options field.
                           The number MUST be even.
   Cookie          0, or 4 to 16 bytes in length (Length - 2)

Notes:

A Nil cookie is a fast open option with no cookie value. A length range of 6 to 18 bytes excludes a Nil cookie.

Errata ID: 4239
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Matthew Luckie
Date Reported: 2015-01-22
Verifier Name: Martin Stiemerling
Date Verified: 2015-10-31

Section 4.2.1 says:

   1. The client sends a SYN packet with a Fast Open option with a
      Length field of 0 (empty cookie field).

It should say:

   1. The client sends a SYN packet with a Fast Open option with a
      Length field of 2 (empty cookie field).

Notes:

A Nil fast-open option has an option length of 2. A length field of zero would mean an invalid TCP option.

Errata ID: 5373
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Vladimir Nicolici
Date Reported: 2018-05-31
Verifier Name: Mirja Kühlewind
Date Verified: 2018-06-14

Section 4.1.3.1. says:

   For any negative responses, the client SHOULD disable Fast Open on
   the specific path (the source and destination IP addresses and ports)
   at least temporarily.

It should say:

   For any negative responses, the client SHOULD disable Fast Open on
   the specific path (the source and destination IP addresses 
   and the destination port) at least temporarily.

Notes:

The original language seems to imply that the cached negative response should only affect connections if they are initiated from the same source port and source IP.

Since the client source port can change for subsequent TCP connections, and it's unlikely that just changing the source port would result in a successful TCP FO connection when a previous connection from a different source port failed, associating the cached negative response with the source port is probably not very useful, and could actually be detrimental to performance and reliability, depending on the implementation.

If the implementation would decide to check the source port when matching negative cached responses to a new connection, it would negatively impact performance when the source port changes, because the implementation wouldn't find a matching negative response in the cache.

Furthermore, if each connection retry is made from a different source port, checking the source port when matching the cached negative responses would make the client unable to connect to the server, until all possible source ports are included in cached negative responses.

This means it's much better not recommending to associate the source port to the cached negative responses, to prevent any confusion and possible implementation issues.

Either that, or add additional clarification, describing exactly how a negative cached response should be matched to a subsequent connection attempt.

Status: Rejected (1)

RFC 7413, "TCP Fast Open", December 2014

Source of RFC: tcpm (wit)

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

Reported By: Simon khng ren hao
Date Reported: 2020-07-27
Rejected by: Martin Duke
Date Rejected: 2020-07-27

Section 5.2 says:

produces responses earlier before the handshake completes

It should say:

produces responses after the handshake completes

Notes:

Located on last paragraph last line of section on page 16. First line states 'not to respond with data until the handshake finishes' which contradicts the last line.
--VERIFIER NOTES--
This erratum does not correctly interpret the paragraph.

The sentence is:
"But the potential latency saving from TFO may diminish if the server application
produces responses earlier before the handshake completes."

The text refers to when the server response is available, not when it is sent. If the server data isn't yet available, then there is no message to withhold and therefore no performance penalty in waiting for the handshake to complete.

Report New Errata



Advanced Search