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

[[e-mail]]

I suggest we try to make a shorter text, can we manage to construct a new
text in the following format:

OLD:
...XXX

NEW:
...XXX

- It should then be possible to update the present Errata request in the
system. (Or at least for someone with the correct permissions to do this).

Gorry


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