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

[[e-mail]]

It seems like some sort of Errata may be useful to advise people of this
issue.

However, there's probably more text here than I'd have expected in an Errata.

I suspect  the original intention was that "delay" in the original text was
to refer to  'SACK.Delay', as below:

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

Does more need to be noted as text changes in the Errata? (Also noting the
table addition).

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