Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656)

[Michael Tuexen <[e-mail]>]

> On 06 Apr 2016, at 08:18, RFC Errata System <[e-mail]> wrote:
> 
> 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_search.php?rfc=4960&eid=4656
> 
> --------------------------------------
> Type: Technical
> Reported by: Lionel Morand <[e-mail]>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 6.2.  Acknowledgement on Reception of DATA Chunks
> 
>   The SCTP endpoint MUST always acknowledge the reception of each valid
>   DATA chunk when the DATA chunk received is inside its receive window.
> 
>   When the receiver's advertised window is 0, the receiver MUST drop
>   any new incoming DATA chunk with a TSN larger than the largest TSN
>   received so far.  If the new incoming DATA chunk holds a TSN value
>   less than the largest TSN received so far, then the receiver SHOULD
>   drop the largest TSN held for reordering and accept the new incoming
>   DATA chunk.  In either case, if such a DATA chunk is dropped, the
>   receiver MUST immediately send back a SACK with the current receive
>   window showing only DATA chunks received and accepted so far.  The
>   dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
>   not accepted.  The receiver MUST also have an algorithm for
>   advertising its receive window to avoid receiver silly window
>   syndrome (SWS), as described in [RFC0813].  The algorithm can be
>   similar to the one described in Section 4.2.3.3 of [RFC1122].
> 
>   The guidelines on delayed acknowledgement algorithm specified in
>   Section 4.2 of [RFC2581] SHOULD be followed.  Specifically, an
>   acknowledgement SHOULD be generated for at least every second packet
>   (not every second DATA chunk) received, and SHOULD be generated
>   within 200 ms of the arrival of any unacknowledged DATA chunk.  In
>   some situations, it may be beneficial for an SCTP transmitter to be
>   more conservative than the algorithms detailed in this document
>   allow.  However, an SCTP transmitter MUST NOT be more aggressive than
>   the following algorithms allow.
> 
>   An SCTP receiver MUST NOT generate more than one SACK for every
>   incoming packet, other than to update the offered window as the
>   receiving application consumes new data.
> 
>   IMPLEMENTATION NOTE: The maximum delay for generating an
>   acknowledgement may be configured by the SCTP administrator, either
>   statically or dynamically, in order to meet the specific timing
>   requirement of the protocol being carried.
> 
>   An implementation MUST NOT allow the maximum delay to be configured
>   to be more than 500 ms.  In other words, an implementation MAY lower
>   this value below 500 ms but MUST NOT raise it above 500 ms.
> 
> [ remaining of the section unchanged ]
> 
> ***********************************************************************
> 15.  Suggested SCTP Protocol Parameter Values
> 
>   The following protocol parameters are RECOMMENDED:
> 
>      RTO.Initial - 3 seconds
>      RTO.Min - 1 second
>      RTO.Max - 60 seconds
>      Max.Burst - 4
>      RTO.Alpha - 1/8
>      RTO.Beta - 1/4
>      Valid.Cookie.Life - 60 seconds
>      Association.Max.Retrans - 10 attempts
>      Path.Max.Retrans - 5 attempts (per destination address)
>      Max.Init.Retransmits - 8 attempts
>      HB.interval - 30 seconds
>      HB.Max.Burst - 1
> 
>   IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
>   customize some of these protocol parameters (see Section 10).
> 
>   Note: RTO.Min SHOULD be set as recommended above.
> 
> Corrected Text
> --------------
> 6.2.  Acknowledgement on Reception of DATA Chunks
> 
>   The SCTP endpoint MUST always acknowledge the reception of each valid
>   DATA chunk when the DATA chunk received is inside its receive window.
> 
>   When the receiver's advertised window is 0, the receiver MUST drop
>   any new incoming DATA chunk with a TSN larger than the largest TSN
>   received so far.  If the new incoming DATA chunk holds a TSN value
>   less than the largest TSN received so far, then the receiver SHOULD
>   drop the largest TSN held for reordering and accept the new incoming
>   DATA chunk.  In either case, if such a DATA chunk is dropped, the
>   receiver MUST immediately send back a SACK with the current receive
>   window showing only DATA chunks received and accepted so far.  The
>   dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
>   not accepted.  The receiver MUST also have an algorithm for
>   advertising its receive window to avoid receiver silly window
>   syndrome (SWS), as described in [RFC0813].  The algorithm can be
>   similar to the one described in Section 4.2.3.3 of [RFC1122].
> 
>   The guidelines on delayed acknowledgement algorithm specified in
>   Section 4.2 of [RFC2581] SHOULD be followed.  Specifically, an
>   acknowledgement SHOULD be generated for at least every second packet
>   (not every second DATA chunk) received, and SHOULD be generated
>   within 200 ms of the arrival of any unacknowledged DATA chunk.  In
>   some situations, it may be beneficial for an SCTP transmitter to be
>   more conservative than the algorithms detailed in this document
>   allow.  However, an SCTP transmitter MUST NOT be more aggressive than
>   the following algorithms allow.
> 
>   An SCTP receiver MUST NOT generate more than one SACK for every
>   incoming packet, other than to update the offered window as the
>   receiving application consumes new data.
> 
>   IMPLEMENTATION NOTE: The maximum delay for generating an
>   acknowledgement may be configured by the SCTP administrator, either
>   statically or dynamically, in order to meet the specific timing
>   requirement of the protocol being carried.
> 
>   An implementation MUST NOT allow the maximum delay (protocol 
>   parameter 'SACK.Delay') to be configured to be more than 500 ms.
>   In other words, an implementation MAY lower the value of 
>   'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms.
> 
> [ remaining of the section unchanged ]
> 
> ***********************************************************************
> 15.  Suggested SCTP Protocol Parameter Values
> 
>   The following protocol parameters are RECOMMENDED:
> 
>      RTO.Initial - 3 seconds
>      RTO.Min - 1 second
>      RTO.Max - 60 seconds
>      Max.Burst - 4
>      RTO.Alpha - 1/8
>      RTO.Beta - 1/4
>      Valid.Cookie.Life - 60 seconds
>      Association.Max.Retrans - 10 attempts
>      Path.Max.Retrans - 5 attempts (per destination address)
>      Max.Init.Retransmits - 8 attempts
>      HB.interval - 30 seconds
>      HB.Max.Burst - 1
>      SACK.Delay - 200 milliseconds
> 
>   IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
>   customize some of these protocol parameters (see Section 10).
> 
>   Note: RTO.Min SHOULD be set as recommended above.
> 
> Notes
> -----
> In section 6.2, the name 'SACK.Delay' is given to the protocol parameter that indicate themaximum delay for generating a SACK.
> 
> In section 15, the list of SCTP protocol parameters and associated recommended value is not complete. The maximum delay for generating an acknowledgement ('SACK.Delay') is missing from this list.
> 
> 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 (IESG)
> 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
> 
This looks good to me. This SACK.delay parameter should have been listed in the table.

Best regards
Michael