Re: [tsvwg] New Version Notification for draft-morand-tsvwg-sctp-parameters-update-00.txt

[<[e-mail]>]

Hi Jeff,

Thank you for your feedback.
Updating the RFC 4960 would be a hint for implementors to allow the SACK delay tuning.
If this is approved, then an update of the RFC 6458 makes sense. Not before I think.

Regards,

Lionel

Envoyé depuis Surface

De : Jeff Morriss<mailto:[e-mail]>
Envoyé : ‎lundi‎ ‎21‎ ‎mars‎ ‎2016 ‎19‎:‎06
À : Lionel MORAND<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>

It's been a while since I had to use (fight with) multiple SCTP implementations but my (at this point vague) memory was that SACK delay was one frustrating area: at least initially (this was years ago) not all implementations allowed tuning the SACK delay which could be a major problem in (e.g., Telco) networks with very tight RTO parameters (i.e., RTO.min less than the default SACK delay of 200 msec).

I can't really say if the approach taken (RFC 4960 update) is the right one but one area that I think could use further improvement is to specify that the SACK delay should be separately configurable in each association.  I've had that requirement myself in systems that have connections both to local (same room) peers where the operator wanted very tight RTOs and remote peers where the operator needed looser parameters.  A similar problem arises in interconnect systems when different peers (controlled by different entities) use/want/require different parameters.

I imagine this could be specified in an update to RFC 4960 section 10 and/or an update to RFC 6458.

On Mon, Mar 21, 2016 at 12:33 PM, <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

it would be nice to have feedback on the issue addressed in this draft.
The idea is not to push the draft but to see if the issue exists and if the proposed approach (update of RFC 4960) to solve this issue is the correct one.
Any proposed alternative would be fine as long as the concern is addressed.

Regards,

Lionel

> -----Message d'origine-----
> De : MORAND Lionel IMT/OLN
> Envoyé : lundi 7 mars 2016 17:44
> À : '[e-mail]<mailto:[e-mail]>'
> Objet : New Version Notification for draft-morand-tsvwg-sctp-parameters-
> update-00.txt
>
> Hi,
>
> The following draft has just been submitted: draft-morand-tsvwg-sctp-
> parameters-update-00.txt
>
> The intent of this draft is to update the RFC 4960 to include the recommend
> value for the SACK delay in the list of suggested SCTP protocol parameter
> values given in the section 15 of the RFC.
> This list of recommended values is often used by SCTP stack implementors as
> reference for defining the list of parameters that can be configured by SCTP
> administrators. As the SACK delay is missing in this list, it is usually not
> possible to configure the value required for the SACK delay.
>
> There is no change to the SCTP protocol and the existing recommended
> values for SCTP parameters. This draft has to be seen as a clarification and
> not an enhancement or a correction.
>
> Please comment.
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] Envoyé : lundi
> 7 mars 2016 17:34 À : BONNET Cédric IMT/OLN; MORAND Lionel IMT/OLN
> Objet : New Version Notification for draft-morand-tsvwg-sctp-parameters-
> update-00.txt
>
>
> A new version of I-D, draft-morand-tsvwg-sctp-parameters-update-00.txt
> has been successfully submitted by Lionel Morand and posted to the IETF
> repository.
>
> Name:         draft-morand-tsvwg-sctp-parameters-update
> Revision:     00
> Title:                Update of the List of Configurable SCTP Protocol Parameters
> Document date:        2016-03-07
> Group:                Individual Submission
> Pages:                6
> URL:            https://www.ietf.org/internet-drafts/draft-morand-tsvwg-sctp-
> parameters-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-morand-tsvwg-sctp-
> parameters-update/
> Htmlized:       https://tools.ietf.org/html/draft-morand-tsvwg-sctp-
> parameters-update-00
>
>
> Abstract:
>    In the SCTP protocol stack implementations available for deployment
>    in operational networks, it has been usually observed that the list
>    of parameters that can be configured by the operators is often
>    restricted to the list of SCTP protocol parameter values that are
>    recommended for SCTP given in the IETF RFC 4960.  However, this list
>    is not exhaustive.
>
>    This document updates the IETF RFC 4960 by including the SACK delay
>    as part of the list of SCTP protocol parameters that can be
>    configurable by an SCTP administrator.  The associated recommended
>    value is also given, according to the IETF RFC 4960
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat


_________________________________________________________________________________________________________________________

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.