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

[Michael Tuexen <[e-mail]>]

> On 06 Apr 2016, at 12:02, [e-mail] wrote:
> 
> 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).
I don't think so.

Best regards
Michael
> 
> 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
>> 
>> 
>> 
>> 
>> 
>> 
>