Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-morand-tsvwg-sctp-parameters-update-00.txt Дата изменения: Mon Mar 7 19:24:04 2016 Дата индексирования: Sun Apr 10 08:12:49 2016 Кодировка:

Transport Area Working Group (tsvwg) L. Morand, Ed.
Internet-Draft
Updates: RFC4960 (if approved) C. Bonnet
Intended status: Standards Track March 7, 2016
Expires: September 8, 2016


Update of the List of Configurable SCTP Protocol Parameters
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

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 8, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents



Morand & Bonnet Expires September 8, 2016 [Page 1]

Internet-Draft Configurable SCTP Protocol Parameters March 2016


(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SACK Delay . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. List of Configurable SCTP Protocol parameters . . . . . . . . 4
5. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6

1. Introduction

The Stream Control Transmission Protocol (SCTP) is specified in the
IETF RFC 4960 [RFC4960], document that obsoletes IETF RFC 2960 and
RFC 3309. In the section 15 of IETF RFC 4960 [RFC4960], there is a
list of SCTP protocol parameter values that are recommended. This
list is given below:

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



Morand & Bonnet Expires September 8, 2016 [Page 2]

Internet-Draft Configurable SCTP Protocol Parameters March 2016


HB.interval - 30 seconds

HB.Max.Burst - 1

In the SCTP protocol stack implementations available in the
operational field, it has been usually observed that the list of
parameters that can be configured by the operators is often
restricted to the list of parameters given in the section 15 of the
IETF RFC 4960 [RFC4960]. However, this list is not exhaustive and
therefore, depending on the SCTP stack implementations, some
parameters may or may not be part of the list of parameters that can
be configured by the SCTP administrators.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

This document uses terminology defined [RFC4960].

3. SACK Delay

As part of the parameters that are not listed as configurable
parameters, a specific parameter is the Selective Acknowledgement
(SACK) delay. In SCTP, the SACK (3) is sent to a peer endpoint to
acknowledge received DATA chunks and to inform the peer endpoint of
gaps in the received subsequences of DATA chunks as represented by
their Transmission Sequence Numbers (TSNs). This SACK should be sent
within a maximun delay. The following recommendation is given in the
section 6.2 of the IETF RFC 4960 [RFC4960] "Acknowledgement on
Reception of DATA Chunks":

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.

Moreover, in the same section, there is the following implementation
note:

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.

The following normative statement is also added:




Morand & Bonnet Expires September 8, 2016 [Page 3]

Internet-Draft Configurable SCTP Protocol Parameters March 2016


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.

Based on the statements given in the section 6.2 of the IETF RFC 4960
[RFC4960], it is implied that the maximum delay for generating a SACK
must also be configurable by the SCTP administrator. If the
recommended delay for sending a SACK is 200ms, this delay must not
exceed 500ms, which leaves latitudes for the setting of the SACK
delay value. However, as SCTP stack implementers usually refer only
to the section 15 of the IETF RFC 4960 [RFC4960] to identify the list
of configurable SCTP parameters, the configuration of the maximum
delay for generating a SACK is commonly not supported.

It is then proposed to update the IETF RFC 4960 [RFC4960] to include
the SCTP protocol parameter "SACK.Delay" as one of the configurable
SCTP protocol parameters, in addition to the existing parameters
given in the section 15 of the IETF RFC 4960 [RFC4960].

4. List of Configurable SCTP Protocol parameters

This document updates the IETF RFC 4960 [RFC4960] by including the
SACK delay as part of the list of SCTP protocol parameters that MUST
be configurable. The updated list is given below:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| SCTP Parameters | Description |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| RTO.Initial | see section 6.3.1 [RC4960] |
| RTO.Min | see section 6.3.1 [RC4960] |
| RTO.Max | see section 6.3.1 [RC4960] |
| Max.Burst | see section 6.1 [RC4960] |
| RTO.Alpha | see section 6.3.1 [RC4960] |
| RTO.Beta | see section 6.3.1 [RC4960] |
| Valid.Cookie.Life | see section 5.1.3 [RC4960] |
| Association.Max.Retrans | see section 8.1 [RC4960] |
| Path.Max.Retrans | see section 8.2 [RC4960] |
| Max.Init.Retransmits | see section 4 [RC4960] |
| HB.interval | see section 8.3 [RC4960] |
| B.Max.Burst | see section 5.4 [RC4960] |
| SACK.Delay | see section 6.2 [RC4960] |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++








Morand & Bonnet Expires September 8, 2016 [Page 4]

Internet-Draft Configurable SCTP Protocol Parameters March 2016


5. Suggested SCTP Protocol Parameter Values

This document updates the IETF RFC 4960 [RFC4960] by including the
SACK delay recommended value in the list of suggested SCTP protocol
parameter values. The updated list is given below:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| SCTP Parameters | Recommended Values |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| 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 |
| B.Max.Burst | 1 |
| SACK.Delay | 200 milliseconds |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IMPLEMENTATION NOTE: The SCTP implementation may allow Upper Layer
Protocol (ULP) to customize some of these protocol parameters (see
Section 10 of the IETF RFC 4960 [RFC4960].

Note: RTO.Min SHOULD be set as recommended above.

6. IANA Considerations

This document makes no request for IANA.

Note to RFC Editor: this section may be removed on publication as an
RFC.

7. Security Considerations

This document does not modify the security considerations given in
section 11 of the IETF RFC 4960 [RFC4960].

8. Acknowledgments

The authors of this document want to thank... (TBC).






Morand & Bonnet Expires September 8, 2016 [Page 5]

Internet-Draft Configurable SCTP Protocol Parameters March 2016


9. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007,
.

Authors' Addresses

Lionel Morand (editor)

Email: lionel.morand@orange.com


Cedric Bonnet

Email: cedric.bonnet@orange.com






























Morand & Bonnet Expires September 8, 2016 [Page 6]