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]