idnits 2.17.1 draft-stewart-tsvwg-sctpecn-04.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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2013) is 4028 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 2481 (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. R. Stewart 3 Internet-Draft Adara Networks 4 Intended status: Standards Track M. Tuexen 5 Expires: October 19, 2013 Muenster Univ. of Appl. Sciences 6 X. Dong 7 Huawei 8 April 17, 2013 10 ECN for Stream Control Transmission Protocol (SCTP) 11 draft-stewart-tsvwg-sctpecn-04.txt 13 Abstract 15 This document describes the addition of the ECN to the Stream Control 16 Transmission Protocol (SCTP). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 19, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Chunk and Parameter Formats . . . . . . . . . . . . . . . . . 3 56 4.1. ECN Support Parameter (32768) . . . . . . . . . . . . . . 3 57 4.2. ECN Echo (12) . . . . . . . . . . . . . . . . . . . . . . 3 58 4.3. CWR Chunk(13) . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. SCTP Initialization . . . . . . . . . . . . . . . . . . . 5 61 5.2. The SCTP Sender . . . . . . . . . . . . . . . . . . . . . 6 62 5.3. The SCTP Receiver . . . . . . . . . . . . . . . . . . . . 8 63 5.4. Congestion on the SACK path . . . . . . . . . . . . . . . 9 64 5.5. Retransmitted SCTP Packets . . . . . . . . . . . . . . . 9 65 5.6. SCTP Window Probes . . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Normative references . . . . . . . . . . . . . . . . . . 10 71 9.2. Informational References . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 At the time SCTP was initially defined in [RFC2960] ECN - [RFC2481] 77 was still an experimental document. This left the authors of SCTP in 78 a position where they could not directly refer to ECN without 79 creating a normative reference in a standards track document to an 80 experimental RFC. To work around this problem the authors of SCTP 81 decided to add two reserved chunk types for ECN (CWR and ECNE) but 82 did not fully specify how they were to be used except in a vague way 83 within an appendix of the document. This worked around the document 84 reference problem, but left ECN and its implementation for SCTP 85 unspecified. This document is intended to fill in the details of ECN 86 processing in SCTP in a standards track document. 88 This document assumes that the reader is familiar with ECN [RFC3168]. 89 Readers unfamiliar with ECN are strongly encouraged to first read 90 [RFC3168] since this document will not repeat any of the details on 91 how the various IP level bits are set. This document will use the 92 same terminology has [RFC3168]. For example the term ECT is used to 93 indicate that the IP level packet is marked indicating the transport 94 (SCTP) supports ECN. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Terminology 104 All integer fields defined in this document included in an SCTP 105 packet MUST be transmitted in network byte order, unless otherwise 106 stated. 108 ECT - The term used to indicate that the IP level packet is 109 marked indicating the transport is willing to support ECN for this 110 packet. 112 not-ECT - The term used to indicate that the IP level packet is 113 marked indicating the transport is NOT willing to support ECN for 114 this packet. 116 CE - The term used to indicate that the IP level packet is 117 marked indicating that a router in the network has marked the 118 packet as having experienced congestion 120 4. Chunk and Parameter Formats 122 4.1. ECN Support Parameter (32768) 124 0 1 2 3 125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Parameter Type = 32768 | Parameter Length = 4 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 This parameter is used to indicate the support for ECN. If this 131 parameter is present, the sender of the chunk is indicating that it 132 supports ECN and wishes to use ECN for the newly forming association. 134 Valid Chunk Appearance 136 The ECN Supported Parameter may appear in the INIT, or the INIT-ACK 137 chunk type. 139 4.2. ECN Echo (12) 141 0 1 2 3 142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Chunk Type=12 | Flags=00000000| Chunk Length = 12 | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Lowest TSN Number | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Number CE Marked Packets Seen since CWR | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Chunk Flags: 8 bits 153 Set to all zeros on transmit and ignored on receipt. 155 Lowest TSN Number: 32 bits (unsigned integer) 157 This parameter contains the lowest TSN number contained in the 158 last packet received that was marked by the network with a CE 159 indication. 161 Number CE Marked Packets: 32 bits (unsigned integer) 163 This parameter contains the total number of CE marked packets that 164 has been seen since the first CE mark received while waiting for a 165 CWR chunk. Note that the CE counter will overflow from 0xffffffff 166 to 0 if a CWR chunk is not recieved. 168 Note that the appendix of [RFC4960] did not have the field Number CE 169 Marked Packets. Implementations SHOULD accept an 8 byte form of this 170 chunk that does not include this field. In such a case the 171 implementation SHOULD treat the missing field as indicating one CE 172 marked packet for any purpose for which the implementation is using 173 this field. 175 4.3. CWR Chunk(13) 177 0 1 2 3 178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Chunk Type=13 | Flags=0000000R| Chunk Length = 8 | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | TSN Number | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Chunk Flags: 8 bits 187 The R Bit indicates if the CWR is a retransmission of an earlier CWR 188 that may have been lost. If this bit is set, then the TSN number 189 included is the latest TSN that a CWR has been responded to. If the 190 o bit is clear, than the TSN indicated is the latest TSN for that 191 destination. 193 Set to all zeros on transmit and ignored on receipt. 195 TSN Number: 32 bits (unsigned integer) 197 This parameter contains the TSN number to which the sender has 198 reduced his congestion window to. 200 5. Procedures 202 5.1. SCTP Initialization 204 In the SCTP association setup phase, the source and destination SCTP 205 endpoints exchange information about their willingness to use ECN. 206 After the completion of this negotiation, an SCTP sender sets an ECT 207 codepoint in the IP header of data packets to indicate to the network 208 that the transport is capable and willing to participate in ECN for 209 this packet. This indicates to the routers that they may mark this 210 packet with the CE codepoint. 212 If the SCTP association does not wish to use ECN notification for a 213 particular packet, the sending SCTP sets the ECN codepoint to not- 214 ECT, and the SCTP receiver ignores the CE codepoint in the received 215 packet. 217 For this discussion we will call the endpoint initiating the SCTP 218 association as EP-A and the listening SCTP endpoint as EP-Z. 220 Before an SCTP association can use ECN, EP-A sends an INIT chunk 221 which includes the ECN Support parameter. By including the ECN 222 Support parameter the sending endpoint (EP-A) will participate in ECN 223 as both a sender and a receiver. Specifically, as a receiver, it 224 will respond to incoming data packets that have the CE codepoint set 225 in the IP header by sending an ECN Echo chunk bundled with the next 226 outgoing SACK Chunk. As a sender, it will respond to incoming 227 packets that include an ECN Echo chunk by reducing the congestion 228 window and sending a CWR chunk when appropriate. 230 Including an ECN Support parameter in an INIT or INIT-ACK does not 231 commit the SCTP sender to setting the ECT codepoint in any or all of 232 the packets it may transmit. However, the commitment to respond 233 appropriately to incoming packets with the CE codepoint set remains. 235 When EP-Z sends INIT-ACK chunk, it also includes an ECN Support 236 parameter. Including the ECN Support parameter indicates that the 237 SCTP transmitting the INIT-ACK chunk is ECN-Capable. 239 The following rules apply to the use of ECN for an SCTP association. 241 * If the SCTP Endpoint supports ECN a sender of either an INIT or 242 INIT-ACK chunk MUST ALWAYS include the ECN Supported Parameter. 244 * After the exchange of the INIT and INIT-ACK if both endpoints have 245 NOT indicated support of ECN by including an ECN Supported 246 Parameter, then ECT MUST NOT be set on any IP packets sent by any 247 endpoint which is ECN capable. Furthermore upon receiving IP 248 packets with a CE codepoint set, the ECN capable endpoint SHOULD 249 ignore the CE codepoint. 251 * If both endpoints have included an ECN Supported Parameter in the 252 INIT and INIT-ACK exchange, then both endpoints MUST follow the 253 ECN procedures defined in the rest of this document. 255 * A sending endpoint SHOULD set the ECT code points on IP packets 256 that carry Data chunk. This includes IP packets that have other 257 control chunks bundled with the Data. 259 5.2. The SCTP Sender 261 For an SCTP association using ECN, new data packets are transmitted 262 with an ECT codepoint set in the IP header. When only one ECT 263 codepoint is needed by a sender for all packets sent on an SCTP 264 association ECT(0) SHOULD be used. If the sender receives an ECN- 265 Echo chunk packet, then the sender knows that congestion was 266 encountered in the network on the path from the sender to the 267 receiver. The indication of congestion should be treated just as a 268 congestion loss in non-ECN-Capable SCTP. That is, the SCTP source 269 halves the congestion window "cwnd" for the destination address that 270 the sender transmitted the data to and reduces the slow start 271 threshold "ssthresh". A packet containing an ECN-Echo chunk 272 shouldn't trigger new data to be sent. SCTP follows the normal 273 procedures for increasing the congestion window when it receives a 274 packet with a SACK chunk without the ECN Echo chunk. 276 SCTP should not react to congestion indications more than once every 277 round-trip time. That is, the SCTP sender's congestion window should 278 be reduced only once in response to a series of dropped and/or CE 279 packets from a single window of data. In addition, the SCTP source 280 should not decrease the slow-start threshold, ssthresh, if it has 281 been decreased within the last round trip time. 283 One method to accomplish this is as following: 285 1) During association setup, create a new state variable ECN_ECHO_TSN 286 and ECN_ECHO_LAST for each destination. The initial value of 287 these variables are set to the initial TSN that will be assigned 288 minus 1. 290 2) When an ECN Echo chunk arrives, use the TSN in the ECN Echo to 291 establish which destination the packet was sent to. We will call 292 this destination the selected destination.If the chunk cannot be 293 found note that an override is occuring From the selected 294 destination (if found) select its ECN Echo TSN. 296 3) Compare the ECN Echo TSN with the ECN_ECHO_TSN for the selected 297 destination. If an override is not noted and the value of the 298 ECN_ECHO_TSN is greater than the ECN Echo TSN proceed to step 4; 299 else proceed to step 6b. 301 4) Reduce the cwnd and ssthresh for the selected destination the same 302 as if a loss was detected during a fast retransmit. For details, 303 see [RFC4960] Section 7.2.3 and Section 7.2.4. 305 5) Record in the ECN_ECHO_TSN value, the last TSN that was sent and 306 recorded in ECN_ECHO_LAST the TSN number from the ECN Echo Chunk. 308 6a) If the implementation is tracking the number of marked packets, 309 record the value found in the 'Number CE Marked Packets Seen since 310 CWR' field and also add this number to the running loss count. If 311 such a count is not being maintained, then proceed to step 7. 313 6b) If the implementation is tracking the number of marked packets, 314 compare the number in the ECN Echo Chunk TSN to the ECN_ECHO_LAST. 315 If it is greater than ECN_ECHO_LAST, update ECN_ECHO_LAST with 316 this value. Take the difference between the stored 'Number CE 317 Marked Packets' field and the value from the newly arriving 318 'Number CE Marked Packets' and add this difference to the total 319 loss count. Then update the stored 'Number CE Marked Packets' 320 with the ECN Echo Chunk TSN. 322 7) Create a CWR chunk with the value found in the ECN_ECHO_LAST for 323 the selected destination.If an override was noted, set the 'O' bit 324 within the CWR flags. Queue this chunk for transmission to the 325 peer destination. Note if there is already such a chunk in queue 326 to be sent, remove that chunk and replace it with the new chunk. 328 After the sending SCTP reduces its congestion window in response to a 329 ECN Echo, incoming SACKs that continue to arrive can "clock out" 330 outgoing packets as allowed by the reduced congestion window. Note 331 that continued arrival of ECN Echo chunks should still be processed 332 as described above, possibly reducing the cwnd, but always sending a 333 CWR to the receiving SCTP. This assures that the ECN Echo and CWR 334 are robust with regard to loss in either direction and that the 335 implementation, if it desires, can maintain an accurate loss count 336 per destination. 338 Note, originally in the appendix of [RFC4960] a definition was 339 supplied for the ECN Echo chunk. This definition did NOT include the 340 'Number CE Marked Packets' field. An implementation SHOULD accept 341 such a chunk, delineating it from the standards track version by the 342 fact that the length field will be 8 bytes instead of 12. When 343 processing this older style chunk, the 'Number CE Marked Packets' 344 should be treated as if it contains the number 1. This may cause 345 incorrect loss counts but will NOT cause any issues with SCTP's ECN 346 handling. 348 5.3. The SCTP Receiver 350 When an SCTP endpoint first receives a CE data packet at the 351 destination end-system, the SCTP data receiver creates an ECN Echo 352 chunk and records the lowest TSN number found in the data packet. It 353 also sets the 'Number CE Marked Packets' to 1 and queues this chunk 354 for transmission at the next opportunity. If there is any ACK 355 withholding implemented, as in current "delayed-SACK" SCTP 356 implementations where the SCTP receiver can send an SACK for two 357 arriving data packets, then the ECN Echo chunk will not be sent until 358 the SACK is sent. If the next arriving data packet also has the CE 359 codepoint set, then the receiver updates the queued ECN Echo chunk to 360 have a higher TSN value (the lowest one in the newly arriving data 361 packet) and increments the 'Number CE Marked Packets' field in the 362 queued chunk. 364 Multi-homing requires one added restriction upon the ECN Echo chunk, 365 such a chunk MUST be bundled with a SACK, and the SACK MUST follow 366 the ECN Echo Chunk. This ordering is necessary so that the receiver 367 of the ECN Echo chunk will at least one time find the proper 368 destination to which the chunk was originally sent. Without this 369 restriction it is possible a SACK could arrive ahead of the ECN Echo 370 Chunk, no matter what the sending order, causing the sender to free 371 the DATA chunk and thus loose the association with what destination 372 it was sent to. For the same reason we also require the ECN Echo 373 Chunk be earlier in the packet ahead of the SACK so that the SACK is 374 not processed before the ECN Echo Chunk. 376 After transmission of the ECN Echo chunk, usually bundled with the 377 SACK, the receiver does NOT discard the ECN Echo chunk. Instead it 378 keeps the chunk in its queue and continues to send this chunk bundled 379 with at least a SACK chunk on each outgoing packet, updating it as 380 described above if other CE codepoint data packets arrive. The ECN 381 Echo chunk should only be discarded when a CWR Chunk arrives holding 382 a TSN value that is greater than or equal to the value inside the ECN 383 Echo Chunk. 385 This provides robustness against the possibility of a dropped SACK 386 packet carrying an ECN Echo chunk. The SCTP receiver continues to 387 transmit the ECN Echo chunk in subsequent SACK packets until the 388 correct CWR is received. 390 After the receipt of the CWR chunk, acknowledgments for subsequent 391 non-CE data packets will not have an ECN Echo chunk bundled with 392 them. If another CE packet is received by the data receiver, the 393 receiver would once again send SACK packets bundled with a newly 394 created ECN Echo chunk. The receipt of a CWR packet guarantees that 395 the data sender has received the ECN Echo chunk for the TSN 396 specified, and reduced its congestion window at some point *after* it 397 sent the data packet for which the CE codepoint was set. 399 When processing a CWR, it is important that the receiver of the CWR 400 validate the source address from which the CWR came from. It SHOULD 401 match the destination the ECN Echo was sent to unless the override 402 bit is set in the CWR Chunk. 404 5.4. Congestion on the SACK path 406 For the current generation of SCTP congestion control algorithms, 407 pure acknowledgement packets (e.g., packets that do not contain any 408 accompanying data) MUST be sent with the not-ECT codepoint. Current 409 SCTP receivers have no mechanisms for reducing traffic on the SACK- 410 path in response to congestion notification. Mechanisms for 411 responding to congestion on the SACK-path are areas for current and 412 future research. For current SCTP implementations, a single dropped 413 SACK generally has only a very small effect on SCTP's sending rate. 415 5.5. Retransmitted SCTP Packets 417 This document specifies ECN-capable SCTP implementations MUST NOT set 418 either ECT codepoint (ECT(0) or ECT(1)) in the IP header for 419 retransmitted data packets, and that the SCTP data receiver SHOULD 420 ignore the ECN field on arriving data packets that are outside of the 421 receiver's current window. The reasons for this can be found in 422 [RFC3168] Section 6.1.5. 424 5.6. SCTP Window Probes 426 When the SCTP data receiver advertises a zero window, the SCTP data 427 sender sends window probes to determine if the receiver's window has 428 increased. Window probe packets for SCTP do contain user data (one 429 chunk). If a window probe packet is dropped in the network, this 430 loss can be detected by the receiver. Therefore, the SCTP data 431 sender MAY set an ECT codepoint on the initial send of the window 432 probe, but the SCTP sender MUST NOT set the ECT codepoint on 433 retransmissions of that TSN. 435 6. Security Considerations 437 [RFC3168] defines the security considerations for ECN. These same 438 consideration that are described for TCP are applicable to SCTP. 440 7. IANA Considerations 442 TBD 444 8. Acknowledgements 446 Thanks to Richard Scheffenegger for his helpful comments and review. 448 9. References 450 9.1. Normative references 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 456 of Explicit Congestion Notification (ECN) to IP", RFC 457 3168, September 2001. 459 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 460 4960, September 2007. 462 9.2. Informational References 464 [RFC2481] Ramakrishnan, K.K. and S. Floyd, "A Proposal to add 465 Explicit Congestion Notification (ECN) to IP", RFC 2481, 466 January 1999. 468 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 469 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 470 Zhang, L., and V. Paxson, "Stream Control Transmission 471 Protocol", RFC 2960, October 2000. 473 Authors' Addresses 475 Randall R. Stewart 476 Adara Networks 477 Chapin, SC 29036 478 USA 480 Email: randall@lakerest.net 482 Michael Tuexen 483 Muenster University of Applied Sciences 484 Stegerwaldstr. 39 485 48565 Steinfurt 486 Germany 488 Email: tuexen@fh-muenster.de 490 Xuesong Dong 491 Huawei 492 Pleasanton, CA 94566 493 USA 495 Email: stevedong@huawei.com