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

[RFC Errata System <[e-mail]>]

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