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

[Randall Stewart <[e-mail]>]

I agree this should have been listed in the table.. not sure we need
the word changes (see sack table) that have been added here…

But we *should* have put the sack-delay 200ms in the table..

R
On Apr 6, 2016, at 10:00 AM, Michael Tuexen <[e-mail]> wrote:

> 
>> 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
> 

--------
Randall Stewart
[e-mail]
803-317-4952