RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4960, "Stream Control Transmission Protocol", September 2007

Source of RFC: tsvwg (tsv)
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.

Report New Errata