idnits 2.17.00 (12 Aug 2021) /tmp/idnits48412/draft-morand-tsvwg-sctp-parameters-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2016) is 2259 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RC4960' is mentioned on line 186, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group (tsvwg) L. Morand, Ed. 3 Internet-Draft 4 Updates: RFC4960 (if approved) C. Bonnet 5 Intended status: Standards Track March 7, 2016 6 Expires: September 8, 2016 8 Update of the List of Configurable SCTP Protocol Parameters 9 draft-morand-tsvwg-sctp-parameters-update-00 11 Abstract 13 In the SCTP protocol stack implementations available for deployment 14 in operational networks, it has been usually observed that the list 15 of parameters that can be configured by the operators is often 16 restricted to the list of SCTP protocol parameter values that are 17 recommended for SCTP given in the IETF RFC 4960. However, this list 18 is not exhaustive. 20 This document updates the IETF RFC 4960 by including the SACK delay 21 as part of the list of SCTP protocol parameters that can be 22 configurable by an SCTP administrator. The associated recommended 23 value is also given, according to the IETF RFC 4960 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 8, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. SACK Delay . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. List of Configurable SCTP Protocol parameters . . . . . . . . 4 63 5. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 The Stream Control Transmission Protocol (SCTP) is specified in the 73 IETF RFC 4960 [RFC4960], document that obsoletes IETF RFC 2960 and 74 RFC 3309. In the section 15 of IETF RFC 4960 [RFC4960], there is a 75 list of SCTP protocol parameter values that are recommended. This 76 list is given below: 78 RTO.Initial - 3 seconds 80 RTO.Min - 1 second 82 RTO.Max - 60 seconds 84 Max.Burst - 4 86 RTO.Alpha - 1/8 88 RTO.Beta - 1/4 90 Valid.Cookie.Life - 60 seconds 92 Association.Max.Retrans - 10 attempts 94 Path.Max.Retrans - 5 attempts (per destination address) 96 Max.Init.Retransmits - 8 attempts 97 HB.interval - 30 seconds 99 HB.Max.Burst - 1 101 In the SCTP protocol stack implementations available in the 102 operational field, it has been usually observed that the list of 103 parameters that can be configured by the operators is often 104 restricted to the list of parameters given in the section 15 of the 105 IETF RFC 4960 [RFC4960]. However, this list is not exhaustive and 106 therefore, depending on the SCTP stack implementations, some 107 parameters may or may not be part of the list of parameters that can 108 be configured by the SCTP administrators. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 This document uses terminology defined [RFC4960]. 118 3. SACK Delay 120 As part of the parameters that are not listed as configurable 121 parameters, a specific parameter is the Selective Acknowledgement 122 (SACK) delay. In SCTP, the SACK (3) is sent to a peer endpoint to 123 acknowledge received DATA chunks and to inform the peer endpoint of 124 gaps in the received subsequences of DATA chunks as represented by 125 their Transmission Sequence Numbers (TSNs). This SACK should be sent 126 within a maximun delay. The following recommendation is given in the 127 section 6.2 of the IETF RFC 4960 [RFC4960] "Acknowledgement on 128 Reception of DATA Chunks": 130 Specifically, an acknowledgement SHOULD be generated for at least 131 every second packet (not every second DATA chunk) received, and 132 SHOULD be generated within 200 ms of the arrival of any 133 unacknowledged DATA chunk. 135 Moreover, in the same section, there is the following implementation 136 note: 138 IMPLEMENTATION NOTE: The maximum delay for generating an 139 acknowledgement may be configured by the SCTP administrator, 140 either statically or dynamically, in order to meet the specific 141 timing requirement of the protocol being carried. 143 The following normative statement is also added: 145 An implementation MUST NOT allow the maximum delay to be 146 configured to be more than 500 ms. In other words, an 147 implementation MAY lower this value below 500 ms but MUST NOT 148 raise it above 500 ms. 150 Based on the statements given in the section 6.2 of the IETF RFC 4960 151 [RFC4960], it is implied that the maximum delay for generating a SACK 152 must also be configurable by the SCTP administrator. If the 153 recommended delay for sending a SACK is 200ms, this delay must not 154 exceed 500ms, which leaves latitudes for the setting of the SACK 155 delay value. However, as SCTP stack implementers usually refer only 156 to the section 15 of the IETF RFC 4960 [RFC4960] to identify the list 157 of configurable SCTP parameters, the configuration of the maximum 158 delay for generating a SACK is commonly not supported. 160 It is then proposed to update the IETF RFC 4960 [RFC4960] to include 161 the SCTP protocol parameter "SACK.Delay" as one of the configurable 162 SCTP protocol parameters, in addition to the existing parameters 163 given in the section 15 of the IETF RFC 4960 [RFC4960]. 165 4. List of Configurable SCTP Protocol parameters 167 This document updates the IETF RFC 4960 [RFC4960] by including the 168 SACK delay as part of the list of SCTP protocol parameters that MUST 169 be configurable. The updated list is given below: 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 172 | SCTP Parameters | Description | 173 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 174 | RTO.Initial | see section 6.3.1 [RC4960] | 175 | RTO.Min | see section 6.3.1 [RC4960] | 176 | RTO.Max | see section 6.3.1 [RC4960] | 177 | Max.Burst | see section 6.1 [RC4960] | 178 | RTO.Alpha | see section 6.3.1 [RC4960] | 179 | RTO.Beta | see section 6.3.1 [RC4960] | 180 | Valid.Cookie.Life | see section 5.1.3 [RC4960] | 181 | Association.Max.Retrans | see section 8.1 [RC4960] | 182 | Path.Max.Retrans | see section 8.2 [RC4960] | 183 | Max.Init.Retransmits | see section 4 [RC4960] | 184 | HB.interval | see section 8.3 [RC4960] | 185 | B.Max.Burst | see section 5.4 [RC4960] | 186 | SACK.Delay | see section 6.2 [RC4960] | 187 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 189 5. Suggested SCTP Protocol Parameter Values 191 This document updates the IETF RFC 4960 [RFC4960] by including the 192 SACK delay recommended value in the list of suggested SCTP protocol 193 parameter values. The updated list is given below: 195 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 196 | SCTP Parameters | Recommended Values | 197 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 198 | RTO.Initial | 3 seconds | 199 | RTO.Min | 1 second | 200 | RTO.Max | 60 seconds | 201 | Max.Burst | 4 | 202 | RTO.Alpha | 1/8 | 203 | RTO.Beta | 1/4 | 204 | Valid.Cookie.Life | 60 seconds | 205 | Association.Max.Retrans | 10 attempts | 206 | Path.Max.Retrans | 5 attempts (per destination address) | 207 | Max.Init.Retransmits | 8 attempts | 208 | HB.interval | 30 seconds | 209 | B.Max.Burst | 1 | 210 | SACK.Delay | 200 milliseconds | 211 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 213 IMPLEMENTATION NOTE: The SCTP implementation may allow Upper Layer 214 Protocol (ULP) to customize some of these protocol parameters (see 215 Section 10 of the IETF RFC 4960 [RFC4960]. 217 Note: RTO.Min SHOULD be set as recommended above. 219 6. IANA Considerations 221 This document makes no request for IANA. 223 Note to RFC Editor: this section may be removed on publication as an 224 RFC. 226 7. Security Considerations 228 This document does not modify the security considerations given in 229 section 11 of the IETF RFC 4960 [RFC4960]. 231 8. Acknowledgments 233 The authors of this document want to thank... (TBC). 235 9. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 243 RFC 4960, September 2007, 244 . 246 Authors' Addresses 248 Lionel Morand (editor) 250 Email: lionel.morand@orange.com 252 Cedric Bonnet 254 Email: cedric.bonnet@orange.com