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

From: RFC Errata System <[email-masked]>
Date: Wed, 6 Apr 2016 04:18:21 -0700 (PDT)

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 <[email-masked]>

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Apr 2016 10:00:27 -0300

> On 06 Apr 2016, at 08:18, RFC Errata System <[email-masked]> wrote:
> 
This looks good to me. This SACK.delay parameter should have been listed in the table.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Wed, 6 Apr 2016 10:10:40 -0300

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

> This looks good to me. This SACK.delay parameter should have been listed in the table.

--------
Randall Stewart
[email-masked]
803-317-4952

---

From: [email-masked]
Date: Wed, 6 Apr 2016 16:02:39 +0100

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
> On Apr 6, 2016, at 10:00 AM, Michael Tuexen
> <[email-masked]> wrote:
>
>>
>>> 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:
>>> -------------

---

From: [email-masked]
Date: Wed, 6 Apr 2016 16:02:46 +0100

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Apr 2016 12:55:24 -0300

> On 06 Apr 2016, at 12:02, [email-masked] wrote:
> 
I don't think so.

Best regards
Michael
>> the word changes (see sack table) that have been added here
> 
>>

---

From: <[email-masked]>
Date: Wed, 6 Apr 2016 17:22:55 +0000

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.
Except that, I don't think that any other additional changes is required.

Regards,

Lionel

> -----Message d'origine-----
> De : tsvwg [mailto:[email-masked]] De la part de Michael Tuexen
> Envoyé : mercredi 6 avril 2016 17:55
> À : Gorry Fairhurst
> Cc : [email-masked]; RFC Errata System; Randall Ray Stewart;
> [email-masked]
> Objet : Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656)
> 
> > It seems like some sort of Errata may be useful to advise people of
> > this issue.
> >
> > I suspect  the original intention was that "delay" in the original
> > text was to refer to  'SACK.Delay', as below:
> >
> > 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
> >>
> >>
> >>>> On 06 Apr 2016, at 08:18, RFC Errata System
> >>>> <[email-masked]>
> >>>> wrote:
> >>>>
> >>>> The following errata report has been submitted for RFC4960, "Stream
> >>>> Control Transmission Protocol".
> >>>>
> >>>> The SCTP endpoint MUST always acknowledge the reception of each
> >>>> valid DATA chunk when the DATA chunk received is inside its receive
> window.
> >>>>
> >>>> 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].
> >>>>
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> **********************************************************
> *********
> >>>> **** 15.  Suggested SCTP Protocol Parameter Values
> >>>>
> >>>> The SCTP endpoint MUST always acknowledge the reception of each
> >>>> valid DATA chunk when the DATA chunk received is inside its receive
> window.
> >>>>
> >>>> 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].
> >>>>
> >>>> 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.
> >>>>
> **********************************************************
> *********
> >>>> **** 15.  Suggested SCTP Protocol Parameter Values
> >>>>
> >>>> 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

_________________________________________________________________________________________________________________________

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.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Apr 2016 14:33:06 -0300

> On 06 Apr 2016, at 14:22, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Gorry,
> 
... 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

---

From: <[email-masked]>
Date: Wed, 6 Apr 2016 17:41:26 +0000

Understood!

If the report can be edited, a copy/paste of only the modified paragraph could be enough. Policies vary depending on the WG.

Lionel

> De : Michael Tuexen [mailto:[email-masked]]
> Envoyé : mercredi 6 avril 2016 19:33
> À : MORAND Lionel IMT/OLN
> Cc : Gorry Fairhurst; [email-masked]; [email-masked]; Randall Ray
> Stewart; RFC Errata System
> > the first  change is just to introduce the name of the protocol parameter.
> Otherwise not possible to just list 'SACK.Delay' in the table.
> 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
> >> De : tsvwg [mailto:[email-masked]] De la part de Michael
> >> Tuexen Envoyé : mercredi 6 avril 2016 17:55 À : Gorry Fairhurst Cc :
> >> [email-masked]; RFC Errata System; Randall Ray Stewart;
> >> [email-masked] Objet : Re: [tsvwg] [Technical Errata Reported]
> >> RFC4960 (4656)
> >>
> >>> However, there's probably more text here than I'd have expected in
> >>> an
> >> Errata.
> >>>
> >>> 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
> >>>
> >>>>
> >>>>>> 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].
> >>>>>>
> >>>>>> transmitter to be more conservative than the algorithms detailed
> >>>>>> in this document allow.  However, an SCTP transmitter MUST NOT be
> >> more
> >>>>>> 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.
> >>>>>>
> >>>>>> 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].
> >>>>>>
> >>>>>> transmitter to be more conservative than the algorithms detailed
> >>>>>> in this document allow.  However, an SCTP transmitter MUST NOT be
> >> more
> >>>>>> 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.
> >>>>>>
> >>>>>> In section 15, the list of SCTP protocol parameters and
> >>>>>> associated recommended value is not complete. The maximum
> delay
> >>>>>> for
> >> generating
> >>>>>> 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.
> >>>>>>
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > 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,
> > 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.

---

From: [email-masked]
Date: Wed, 6 Apr 2016 18:53:36 +0100

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

>> the first  change is just to introduce the name of the protocol
>> parameter. Otherwise not possible to just list 'SACK.Delay' in the
>> table.
> have
>> 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,
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Apr 2016 15:11:55 -0300

> On 06 Apr 2016, at 14:53, [email-masked] wrote:
> 
> 
What about:

OLD:

NEW:

OLD:

     RTO.Initial - 3 seconds
     RTO.Min - 1 second
     RTO.Max - 60 seconds
     Max.Burst - 4
     RTO.Alpha - 1/8
     RTO.Beta - 1/4

NEW:

     RTO.Initial - 3 seconds
     RTO.Min - 1 second
     RTO.Max - 60 seconds
     Max.Burst - 4
     RTO.Alpha - 1/8
     RTO.Beta - 1/4

Best regards
Michael