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

<lionel.morand@orange.com> Wed, 06 April 2016 17:41 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F1112D6FB for <tsvwg@ietfa.amsl.com>; Wed, 6 Apr 2016 10:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.929
X-Spam-Level:
X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0Vr8te5ERlj for <tsvwg@ietfa.amsl.com>; Wed, 6 Apr 2016 10:41:32 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D3612D6E4 for <tsvwg@ietf.org>; Wed, 6 Apr 2016 10:41:28 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 8AB8B1803E0; Wed, 6 Apr 2016 19:41:27 +0200 (CEST)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.52]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 57B191A0057; Wed, 6 Apr 2016 19:41:27 +0200 (CEST)
Received: from OPEXCNORM4D.corporate.adroot.infra.ftgroup ([fe80::604f:15da:866b:fd8b]) by OPEXCNORM54.corporate.adroot.infra.ftgroup ([fe80::d4c1:bb8:4040:a2bb%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 19:41:27 +0200
From: lionel.morand@orange.com
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Thread-Topic: [tsvwg] [Technical Errata Reported] RFC4960 (4656)
Thread-Index: AQHRj/Yp6yDRRhqrKEaVgky0ckM4dJ98xyGAgAAC2gCAAB9SAIAADrUAgAA5f7D//+HNAIAAI9EQ
Date: Wed, 06 Apr 2016 17:41:26 +0000
Message-ID: <4567_1459964487_57054A47_4567_404_1_6B7134B31289DC4FAF731D844122B36E01E2E78F@OPEXCNORM4D.corporate.adroot.infra.ftgroup>
References: <20160406111821.B8CF718000C@rfc-editor.org> <527C8FB5-16A5-46DE-8C5C-EE3E382F32BC@lurchi.franken.de> <D2F8A287-E4A1-4A3F-95F3-EF20CE31BB18@netflix.com> <0396d9f4a09005fafbaee8c876ca8c5c.squirrel@erg.abdn.ac.uk> <75455A46-31E7-4081-A155-1264119527C5@lurchi.franken.de> <10367_1459963377_570545F0_10367_19607_1_6B7134B31289DC4FAF731D844122B36E01E2E734@OPEXCNORM4D.corporate.adroot.infra.ftgroup> <F56A4099-9461-47EB-B7B3-CAEEC30D5D28@lurchi.franken.de>
In-Reply-To: <F56A4099-9461-47EB-B7B3-CAEEC30D5D28@lurchi.franken.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tsvwg/02dJwHMfy5FXDRAE_TjvdHmnjBw>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "mls.ietf@gmail.com" <mls.ietf@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Randall Ray Stewart <randall@lakerest.net>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2016 17:41:41 -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

> -----Message d'origine-----
> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> Envoyé : mercredi 6 avril 2016 19:33
> À : MORAND Lionel IMT/OLN
> Cc : Gorry Fairhurst; mls.ietf@gmail.com; tsvwg@ietf.org; Randall Ray
> Stewart; RFC Errata System
> Objet : Re: [tsvwg] [Technical Errata Reported] RFC4960 (4656)
> 
> > On 06 Apr 2016, at 14:22, <lionel.morand@orange.com>
> <lionel.morand@orange.com> 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:tsvwg-bounces@ietf.org] De la part de Michael
> >> Tuexen Envoyé : mercredi 6 avril 2016 17:55 À : Gorry Fairhurst Cc :
> >> mls.ietf@gmail.com; RFC Errata System; Randall Ray Stewart;
> >> tsvwg@ietf.org Objet : Re: [tsvwg] [Technical Errata Reported]
> >> RFC4960 (4656)
> >>
> >>> On 06 Apr 2016, at 12:02, gorry@erg.abdn.ac.uk 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
> >>>> <Michael.Tuexen@lurchi.franken.de> wrote:
> >>>>
> >>>>>
> >>>>>> On 06 Apr 2016, at 08:18, RFC Errata System
> >>>>>> <rfc-editor@rfc-editor.org>
> >>>>>> 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 <lionel.morand@orange.com>
> >>>>>>
> >>>>>> 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
> >>>> rrs@netflix.com
> >>>> 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.
> >


_________________________________________________________________________________________________________________________

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.