Subject: [tsvwg] [Technical Errata Reported] RFC4960 (5202)

From: RFC Errata System <[email-masked]>
Date: Wed, 13 Dec 2017 06:11:06 -0800 (PST)

The following errata report has been submitted for RFC4960,
"Stream Control Transmission Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5202

--------------------------------------
Type: Technical
Reported by: Nicholas Wilson <[email-masked]>

Section: 3.3.4.

Original Text
-------------
   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.

Corrected Text
--------------
   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"

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4960 (draft-ietf-tsvwg-2960bis-05)
--------------------------------------
Title               : Stream Control Transmission Protocol
Publication Date    : September 2007
Author(s)           : R. Stewart, Ed.
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 13 Dec 2017 16:09:42 +0100

> On 13. Dec 2017, at 15:11, RFC Errata System <[email-masked]> wrote:
> 
Part of this is already clarified in
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04#section-3.47
The missing piece is that the Gap Ack Blocks should be increasing.

I know that the FreeBSD implementation always send them in increasing order,
but can handle them in any order when a SACK is received.

Please note that TCP allows them in any order, see the last sentence from
https://tools.ietf.org/html/rfc2018#section-4

      * The SACK option SHOULD be filled out by repeating the most
      recently reported SACK blocks (based on first SACK blocks in
      previous SACK options) that are not subsets of a SACK block
      already included in the SACK option being constructed.  This
      assures that in normal operation, any segment remaining part of a
      non-contiguous block of data held by the data receiver is reported
      in at least three successive SACK options, even for large-window
      TCP implementations [RFC1323]).  After the first SACK block, the
      following SACK blocks in the SACK option may be listed in
      arbitrary order.

So I'm not sure if we need to require this. If we do, doesn't the same
ordering requirement apply to the Duplicate TSNs?

>    then the parameter part of the SACK MUST be constructed as follows"
I agree, this "MUST" is not correct. Please note in particular that the new text in
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04#section-3.47
uses a SHOULD for the isolation property...

Best regards
Michael