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

[Michael Tuexen <[e-mail]>]

> On 06 Apr 2016, at 14:22, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Gorry,
> 
> the first  change is just to introduce the name of the protocol parameter. Otherwise not possible to just list 'SACK.Delay' in the table.
... I think it is citing a long block of text where only a single sentence is changed.
But that is hard to catch.

Possibly only showing the paragraph which has the small text change would have
been easier to read. Not sure if an Errata can be edited...

Best regards
Michael
> Except that, I don't think that any other additional changes is required.
> 
> Regards,
> 
> Lionel
> 
>> -----Message d'origine-----
>> De : tsvwg [mailto:[e-mail]] De la part de Michael Tuexen
>> Envoyé : mercredi 6 avril 2016 17:55
>> À : Gorry Fairhurst
>> Cc : [e-mail]; RFC Errata System; Randall Ray Stewart;
>> [e-mail]
>> Objet : Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656)
>> 
>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>