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

From: <[email-masked]>
Date: Mon, 7 Mar 2016 16:44:29 +0000

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

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.

---

From: <[email-masked]>
Date: Mon, 21 Mar 2016 16:33:16 +0000

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

> De : MORAND Lionel IMT/OLN
> Envoyé : lundi 7 mars 2016 17:44
> À : [email-masked]'
> 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
> 
> De : [email-masked] [mailto:[email-masked]] Envoyé : lundi
> 7 mars 2016 17:34 À : BONNET Cédric IMT/OLN; MORAND Lionel IMT/OLN
> 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.
> 
> The IETF Secretariat

---

From: Jeff Morriss <[email-masked]>
Date: Mon, 21 Mar 2016 14:06:08 -0400

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

> 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.
> Envoyé : lundi
> > 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/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 21 Mar 2016 10:49:06 -0600

Lionel,

[email-masked] wrote:          (Mon, 21 Mar 2016 16:33:16)
> 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.

I thought that the reason that we did not recommend a
value was because the bounds of the SACK delay comes
from a different RFC.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.com/

---

From: <[email-masked]>
Date: Tue, 22 Mar 2016 09:46:17 +0000

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:[email-masked]>
Envoyé : ‎lundi‎ ‎21‎ ‎mars‎ ‎2016 ‎19‎:‎06
À : Lionel MORAND<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>

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, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Lionel

> À : [email-masked]<mailto:[email-masked]>'
> De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Envoyé : lundi
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 22 Mar 2016 11:38:46 +0100

> On 22 Mar 2016, at 10:46, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Jeff,
> 
Why do you need to update RFC 6458? An application can control the SACK delay and
its frequency on a per association base using
https://tools.ietf.org/html/rfc6458#section-8.1.19

Best regards
Michael
> De : Jeff Morriss
> À : Lionel MORAND
> Cc : [email-masked]

---

From: <[email-masked]>
Date: Tue, 22 Mar 2016 14:54:47 +0000

> De : Michael Tuexen [mailto:[email-masked]]
> Envoyé : mardi 22 mars 2016 11:39
> À : MORAND Lionel IMT/OLN
> Cc : Jeff Morriss; [email-masked]
> Objet : Re: [tsvwg] New Version Notification for draft-morand-tsvwg-sctp-
> parameters-update-00.txt
> 
> Why do you need to update RFC 6458? An application can control the SACK
> delay and its frequency on a per association base using

[LM] right!

> 
> Best regards
> Michael
> >
> > Regards,
> >
> > Lionel
> >
> > Envoyé depuis Surface
> >
> > De : Jeff Morriss
> > Envoyé : ‎lundi‎ ‎21‎ ‎mars‎ ‎2016 ‎19‎:‎06 À : Lionel MORAND Cc :
> > [email-masked]
> >
> 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
> 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
> arises in interconnect systems when different peers (controlled by different
> entities) use/want/require different parameters.
> >
> > 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.
> > > 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.
> > >
> > > values for SCTP parameters. This draft has to be seen as a
> > > clarification and not an enhancement or a correction.
> > >
> > > Please comment.
> > >
> > > Regards,
> > >
> > > Lionel
> > >
> > > 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
> > > URL:            https://www.ietf.org/internet-drafts/draft-morand-tsvwg-
> sctp-
> > > parameters-update-00.txt
> > > 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.
> > >
> > > 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,
> > 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: Michael Tuexen <[email-masked]>
Date: Sat, 26 Mar 2016 11:33:01 +0100

> On 21 Mar 2016, at 17:33, [email-masked] wrote:
> 
> Hi,
> 
Hi Lionel,

I think the SACK delay parameter can just be added to the list of parameters in section 15
of RFC 4960. I have also seen problems related to SACK.Delay and RTO.Min configurations
in the field.
We are currently working on an update of RFC 4960.
The list of proposed changes is collected in the following ID:
https://tools.ietf.org/html/draft-tuexen-tsvwg-rfc4960-errata
If you agree, we could work on a section for that ID covering your suggested change.
Please note that the above ID is still an individual submission, but we will
ask for WG adoption at the next IETF meeting.

What do you think?

Best regards
Michael