RFC Errata
RFC 4960, "Stream Control Transmission Protocol", September 2007
Note: This RFC has been obsoleted by RFC 9260
Note: This RFC has been updated by RFC 6096, RFC 6335, RFC 7053, RFC 8899
Source of RFC: tsvwg (wit)See Also: RFC 4960 w/ inline errata
Errata ID: 5202
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Wilson
Date Reported: 2017-12-13
Verifier Name: Spencer Dawkins
Date Verified: 2018-07-10
Section 3.3.4. says:
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack.
It should say:
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. The sequence of Gap Ack Blocks MUST be an increasing sequence of ranges, non-intersecting, and with at least one TSN as a gap between each Block and between the Cumulative TSN Ack and the first Block.
Notes:
It seems clear that the Gap Ack sequence must be sent in its "canonical" form (monotonic non-overlapping ranges) but I can't find anywhere where this is actually stated.
It is implied (but not stated) by the following sentence on the next page, which implies that there is no freedom of choice in how the Gap Ack sequence is encoded:
"For example, assume that ...
then the parameter part of the SACK MUST be constructed as follows"
Verifier Notes:
This errata suggests two corrections:
(1) Ensure that the gap ack blocks are not overlapping.
(2) Ensure that the gap ack blocks are monotonic.
Subsequent discussion in TSVWG, as documented in
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.47,
has converged on this resolution:
* The intention actually was to have the gap blocks isolated. So (1) ought
to be included in the next revision of SCTP.
* In some cases gap blocks might not be monotonic. This is the same as with
the handling of gap reports in TCP SACK. Therefore (2) ought not be
included in the next revision of SCTP.