idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2601 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: 'RFCXXXX' is mentioned on line 790, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7053 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Netflix, Inc. 4 Intended status: Standards Track M. Tuexen 5 Expires: September 14, 2017 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 March 13, 2017 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-09.txt 16 Abstract 18 The Stream Control Transmission Protocol (SCTP) is a message oriented 19 transport protocol supporting arbitrarily large user messages. This 20 document adds a new chunk to SCTP for carrying payload data. This 21 allows a sender to interleave different user messages that would 22 otherwise result in head of line blocking at the sender. 24 Whenever an SCTP sender is allowed to send user data, it may choose 25 from multiple outgoing SCTP streams. Multiple ways for performing 26 this selection, called stream schedulers, are defined. A stream 27 scheduler can choose to either implement, or not implement, user 28 message interleaving. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 14, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. User Message Interleaving . . . . . . . . . . . . . . . . . . 5 68 2.1. The I-DATA Chunk Supporting User Message Interleaving . . 6 69 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 8 71 2.2.2. Sender Side Considerations . . . . . . . . . . . . . 8 72 2.2.3. Receiver Side Considerations . . . . . . . . . . . . 9 73 2.3. Interaction with other SCTP Extensions . . . . . . . . . 9 74 2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 9 75 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 11 76 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 11 77 3.1. First Come First Served (SCTP_SS_FCFS) . . . . . . . . . 11 78 3.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 11 79 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 12 80 3.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 12 81 3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) . . . . . . . . . . 12 82 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 12 83 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 12 84 4.1. Exposition of the Stream Sequence Number (SSN) . . . . . 13 85 4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 13 86 4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 13 87 4.3.1. Enable or Disable the Support of User Message 88 Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 13 89 4.3.2. Get or Set the Stream Scheduler 90 (SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 14 91 4.3.3. Get or Set the Stream Scheduler Parameter 92 (SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 15 93 4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 16 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 5.1. I-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . 17 96 5.2. I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . . 18 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 98 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 8.2. Informative References . . . . . . . . . . . . . . . . . 19 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 104 1. Introduction 106 1.1. Overview 108 When SCTP [RFC4960] was initially designed it was mainly envisioned 109 for the transport of small signaling messages. Late in the design 110 stage it was decided to add support for fragmentation and reassembly 111 of larger messages with the thought that someday Session Initiation 112 Protocol (SIP) [RFC3261] style signaling messages may also need to 113 use SCTP and a single Maximum Transmission Unit (MTU) sized message 114 would be too small. Unfortunately this design decision, though valid 115 at the time, did not account for other applications that might send 116 large messages over SCTP. The sending of such large messages over 117 SCTP as specified in [RFC4960] can result in a form of sender side 118 head of line blocking (e.g., when the transmission of an urgent 119 message is blocked from transmission because the sender has started 120 the transmission of another, possibly large, message). This head of 121 line blocking is caused by the use of the Transmission Sequence 122 Number (TSN) for three different purposes: 124 1. As an identifier for DATA chunks to provide a reliable transfer. 126 2. As an identifier for the sequence of fragments to allow 127 reassembly. 129 3. As a sequence number allowing to have up to 2**16 - 1 Stream 130 Sequence Numbers (SSNs) outstanding. 132 The protocol requires all fragments of a user message to have 133 consecutive TSNs. Therefore it is impossible for the sender to 134 interleave different user messages. 136 This document also defines several stream schedulers for general SCTP 137 associations. They can be used with and without user message 138 interleaving being negotiated and possibly behave differently. 140 Figure 1 illustrates the behaviour of a round robin stream scheduler 141 using DATA chunks when three streams with the Stream Identifiers 142 (SIDs) 0, 1, and 2 are used. Please note that the use of such a 143 scheduler implies late TSN assignment but it can be used with an 144 [RFC4960] compliant implementation not supporting user message 145 interleaving. 147 +---+---+---+ 148 | 0/0 |-+ 149 +---+---+---+ | 150 | +---+---+---+---+---+---+---+---+---+ 151 +---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0| 152 |1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---| 153 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 154 | +---+---+---+---+---+---+---+---+---+ 155 +---+---+---+ | 156 | 2/0 |-+ 157 +---+---+---+ 158 +-------+ 159 +-------+ |SID/SSN| 160 |SID/SSN| |-------| 161 +-------+ | TSN | 162 +-------+ 164 Figure 1: Round Robin Scheduler without User Message Interleaving 166 This document describes a new chunk carrying payload data called 167 I-DATA. This chunk incorporates the properties of the current SCTP 168 DATA chunk, all the flags and fields except the Stream Sequence 169 Number (SSN), but also adds two new fields in its chunk header, the 170 Fragment Sequence Number (FSN) and the Message Identifier (MID). The 171 FSN is only used for reassembling all fragments having the same MID 172 and ordering property. The TSN is only used for the reliable 173 transfer in combination with Selective Acknowledgment (SACK) chunks. 175 In addition, the MID is also used for ensuring ordered delivery 176 instead of using the stream sequence number, which has been omitted 177 from the I-DATA chunk. 179 Figure 2 illustrates the behaviour of an interleaving round robin 180 stream scheduler using I-DATA chunks. 182 +---+---+---+ 183 | 0/0 |-+ 184 +---+---+---+ | 185 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 186 +---+---+---+ +->|2/0/2|1/2/0|0/0/2|2/0/1|1/1/0|0/0/1|2/0/0|1/0/0|0/0/0| 187 |1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----| 188 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 189 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 190 +---+---+---+ | 191 | 2/0 |-+ 192 +---+---+---+ 193 +-----------+ 194 +-------+ |SID/MID/FSN| 195 |SID/MID| |-----------| 196 +-------+ | TSN | 197 +-----------+ 199 Figure 2: Round Robin Scheduler with User Message Interleaving 201 The support of the I-DATA chunk is negotiated during the association 202 setup using the Supported Extensions Parameter as defined in 203 [RFC5061]. If I-DATA support has been negotiated for an association 204 I-DATA chunks are used for all user-messages. DATA chunks are not 205 permitted when I-DATA support has been negotiated. It should be 206 noted that an SCTP implementation supporting I-DATA chunks needs to 207 allow the coexistence of associations using DATA chunks and 208 associations using I-DATA chunks. 210 In Section 2 this document specifies the user message interleaving by 211 defining the I-DATA chunk, the procedures to use it and its 212 interactions with other SCTP extensions. Multiple stream schedulers 213 are defined in Section 3 followed in Section 4 by describing an 214 extension to the socket API for using what is specified in this 215 document. 217 1.2. Conventions 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 2. User Message Interleaving 225 The protocol mechanisms described in this document allow the 226 interleaving of user messages sent on different streams. They do not 227 support the interleaving of multiple messages (ordered or unordered) 228 sent on the same stream. 230 The interleaving of user messages is required for WebRTC Datachannels 231 as specified in [I-D.ietf-rtcweb-data-channel]. 233 An SCTP implementation supporting user message interleaving is 234 REQUIRED to support the coexistence of associations using DATA chunks 235 and associations using I-DATA chunks. If an SCTP implementation 236 supports user message interleaving and the extension described in 237 [RFC3758] or [RFC6525], it is REQUIRED to implement the corresponding 238 changes specified in Section 2.3. 240 2.1. The I-DATA Chunk Supporting User Message Interleaving 242 The following Figure 3 shows the new I-DATA chunk allowing user 243 message interleaving. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type = 64 | Res |I|U|B|E| Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | TSN | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Stream Identifier | Reserved | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Message Identifier | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Payload Protocol Identifier / Fragment Sequence Number | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 \ \ 259 / User Data / 260 \ \ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 3: I-DATA chunk format 265 The only differences between the I-DATA chunk in Figure 3 and the 266 DATA chunk defined in [RFC4960] and [RFC7053] are the addition of the 267 new Message Identifier (MID) and the new Fragment Sequence Number 268 (FSN) and the removal of the Stream Sequence Number (SSN). The 269 Payload Protocol Identifier (PPID) and the FSN are stored at the same 270 location of the packet using the B-bit to determine which value is 271 stored at the location. The length of the I-DATA chunk header is 20 272 bytes, which is 4 bytes more than the length of the DATA chunk header 273 defined in [RFC4960] and [RFC7053]. 275 The new fields are: 277 Reserved: 16 bits (unsigned integer) 278 This field is reserved. It MUST be set to 0 by the sender and 279 MUST be ignored by the receiver. 281 Message Identifier (MID): 32 bits (unsigned integer) 282 The MID is the same for all fragments of a user message, it is 283 used to determine which fragments (enumerated by the FSN) belong 284 to the same user message. For ordered user messages, the MID is 285 also used by the SCTP receiver to deliver the user messages in the 286 correct order to the upper layer (similar to the SSN of the DATA 287 chunk defined in [RFC4960]). The sender uses two counters for 288 each outgoing stream, one for ordered messages, one for unordered 289 messages. All counters are independent and initially 0. They are 290 incremented by 1 for each user message. Please note that the 291 serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 292 32 applies. Therefore, the sender MUST NOT have more than 2**31 - 293 1 ordered messages for each outgoing stream in flight and MUST NOT 294 have more than 2**31 - 1 unordered messages for each outgoing 295 stream in flight. A message is considered in flight, if at least 296 on of its I-DATA chunks is not acknowledged in a non-renegable 297 way. Please note that the MID is in "network byte order", a.k.a. 298 Big Endian. 300 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 301 32 bits (unsigned integer) 302 If the B bit is set, this field contains the PPID of the user 303 message. Note that in this case, this field is not touched by an 304 SCTP implementation; therefore, its byte order is not necessarily 305 in network byte order. The upper layer is responsible for any 306 byte order conversions to this field, similar to the PPID of DATA 307 chunks. In this case the FSN is implicitly considered to be 0. 308 If the B bit is not set, this field contains the FSN. The FSN is 309 used to enumerate all fragments of a single user message, starting 310 from 0 and incremented by 1. The last fragment of a message MUST 311 have the 'E' bit set. Note that the FSN MAY wrap completely 312 multiple times allowing arbitrarily large user messages. For the 313 FSN the serial number arithmetic defined in [RFC1982] applies with 314 SERIAL_BITS = 32. Therefore, a sender MUST NOT have more than 315 2**31 - 1 fragments of a single user message in flight. A 316 fragment is considered in flight, if it is not acknowledged in a 317 non-renegable way. Please note that the FSN is in "network byte 318 order", a.k.a. Big Endian. 320 2.2. Procedures 322 This subsection describes how the support of the I-DATA chunk is 323 negotiated and how the I-DATA chunk is used by the sender and 324 receiver. 326 2.2.1. Negotiation 328 A sender MUST NOT send an I-DATA chunk unless both peers have 329 indicated its support of the I-DATA chunk type within the Supported 330 Extensions Parameter as defined in [RFC5061]. If I-DATA support has 331 been negotiated for an association, I-DATA chunks MUST be used for 332 all user messages and DATA-chunks MUST NOT be used. If I-DATA 333 support has not been negotiated for an association, DATA chunks MUST 334 be used for all user messages and I-DATA chunks MUST NOT be used. 336 A sender MUST NOT use the I-DATA chunk unless the user has requested 337 its use (e.g. via the socket API, see Section 4.3). This constraint 338 is made since the usage of this chunk requires that the application 339 is willing to interleave messages upon reception within an 340 association. This is not the default choice within the socket API 341 (see the SCTP_FRAGMENT_INTERLEAVE socket option in Section 8.1.20 of 342 [RFC6458]) thus the user MUST indicate to the SCTP implementation its 343 support for receiving completely interleaved messages. Note that for 344 stacks that do not implement [RFC6458] they may use other methods to 345 indicate interleaved message support and thus enable the usage of the 346 I-DATA chunk. The crucial point is that the SCTP stack MUST know 347 that the application has indicated its choice in wanting to use the 348 extension. 350 2.2.2. Sender Side Considerations 352 The sender side usage of the I-DATA chunk is quite simple. Instead 353 of using the TSN for fragmentation purposes, the sender uses the new 354 FSN field to indicate which fragment number is being sent. The first 355 fragment MUST have the 'B' bit set. The last fragment MUST have the 356 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 357 set. All other properties of the existing SCTP DATA chunk also apply 358 to the I-DATA chunk, i.e. congestion control as well as receiver 359 window conditions MUST be observed as defined in [RFC4960]. 361 Note that the usage of this chunk implies the late assignment of the 362 actual TSN to any chunk being sent. Each I-DATA chunk uses a single 363 TSN. This way messages from other streams may be interleaved with 364 the fragmented message. Please note that this is the only form of 365 interleaving support. For example, it is not possible to interleave 366 multiple ordered or unordered user messages from the same stream. 368 The sender MUST NOT be fragmenting more than one user message in any 369 given stream at any time. At any time, a sender MAY fragment 370 multiple user messages, each of them on different streams. 372 The sender MUST assign TSNs in a way that the receiver can make 373 progress. One way to achieve this is to assign a higher TSN to the 374 later fragments of a user message and send out the TSNs in sequence. 376 2.2.3. Receiver Side Considerations 378 Upon reception of an SCTP packet containing an I-DATA chunk whose 379 user message needs to be reassembled, the receiver MUST first use the 380 SID to identify the stream, consider the U bit to determine if it is 381 part of an ordered or unordered message, find the user message 382 identified by the MID and finally use the FSN for reassembly of the 383 message and not the TSN. The receiver MUST NOT make any assumption 384 about the TSN assignments of the sender. Note that a non-fragmented 385 message is indicated by the fact that both the 'E' and 'B' bits are 386 set. A message (either ordered or unordered) may be identified as 387 being fragmented whose 'E' and 'B' bits are not set both. 389 2.3. Interaction with other SCTP Extensions 391 The usage of the I-DATA chunk might interfere with other SCTP 392 extensions. Future SCTP extensions MUST describe if and how they 393 interfere with the usage of I-DATA chunks. For the SCTP extensions 394 already defined when this document was published, the details are 395 given in the following subsections. 397 2.3.1. SCTP Partial Reliability Extension 399 When the SCTP extension defined in [RFC3758] is used in combination 400 with the user message interleaving extension, the new I-FORWARD-TSN 401 chunk MUST be used instead of the FORWARD-TSN chunk. The difference 402 between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 403 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit 404 Message Identifier (MID) and the largest skipped MID can also be 405 provided for unordered messages. Therefore, the principle applied to 406 ordered message when using FORWARD-TSN chunks is applied to ordered 407 and unordered messages when using I-FORWARD-TSN chunks. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type = 194 | Flags = 0x00 | Length = Variable | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | New Cumulative TSN | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Stream Identifier | Reserved |U| 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Message Identifier | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 \ \ 421 / / 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Stream Identifier | Reserved |U| 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Message Identifier | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 4: I-FORWARD-TSN chunk format 430 The relevant new fields are: 432 Stream Identifier (SID): 16-bits (unsigned integer) 433 This field holds the stream number this entry refers to. 435 Reserved: 15 bits 436 This field is reserved. It MUST be set to 0 by the sender and 437 MUST be ignored by the receiver. 439 U bit: 1 bit 440 The U bit specifies if the Message Identifier of this entry refers 441 to unordered messages (U bit is set) or ordered messages (U bit is 442 not set). 444 Message Identifier (MID): 32 bits (unsigned integer) 445 This field holds the largest Message Identifier for ordered or 446 unordered messages indicated by the U-bit that was skipped for the 447 stream specified by the Stream Identifier. For ordered messages 448 this is similar to the FORWARD-TSN chunk, just replacing the 449 16-bit SSN by the 32-bit MID. 451 The FORWARD-TSN chunk MUST be used in combination with the DATA chunk 452 and MUST NOT be used in combination with the I-DATA chunk. The I- 453 FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk 454 and MUST NOT be used in combination with the DATA chunk. 456 Support for the I-FORWARD-TSN chunk is negotiated during the SCTP 457 association setup via the Supported Extensions Parameter as defined 458 in [RFC5061]. Only if both end points support the I-DATA chunk and 459 the I-FORWARD-TSN chunk, the partial reliability extension can be 460 used in combination with user message interleaving. 462 2.3.2. SCTP Stream Reconfiguration Extension 464 When an association resets the SSN using the SCTP extension defined 465 in [RFC6525], the two counters (one for the ordered messages, one for 466 the unordered messages) used for the MIDs MUST be reset to 0. 468 Since most schedulers, especially all schedulers supporting user 469 message interleaving, require late TSN assignment, it should be noted 470 that the implementation of [RFC6525] needs to handle this. 472 3. Stream Schedulers 474 This section defines several stream schedulers. The stream 475 schedulers may behave differently depending on whether user message 476 interleaving has been negotiated for the association or not. An 477 implementation MAY implement any subset of them. 479 The selection of the stream scheduler is done at the sender side. 480 There is no mechanism provided for signalling the stream scheduler 481 being used to the receiver side or even let the receiver side 482 influence the selection of the stream scheduler used at the sender 483 side. 485 3.1. First Come First Served (SCTP_SS_FCFS) 487 The simple first-come, first-served scheduler of user messages is 488 used. It just passes through the messages in the order in which they 489 have been delivered by the application. No modification of the order 490 is done at all. The usage of user message interleaving does not 491 affect the sending of the chunks, except that I-DATA chunks are used 492 instead of DATA chunks. 494 3.2. Round Robin Scheduler (SCTP_SS_RR) 496 When not using user message interleaving, this scheduler provides a 497 fair scheduling based on the number of user messages by cycling 498 around non-empty stream queues. When using user message 499 interleaving, this scheduler provides a fair scheduling based on the 500 number of I-DATA chunks by cycling around non-empty stream queues. 502 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) 504 This is a round-robin scheduler which only switches streams when 505 starting to fill a new packet. It bundles only DATA or I-DATA chunks 506 referring to the same stream in a packet. This scheduler minimizes 507 head-of-line blocking when a packet is lost because only a single 508 stream is affected. 510 3.4. Priority Based Scheduler (SCTP_SS_PRIO) 512 Scheduling of user messages with strict priorities is used. The 513 priority is configurable per outgoing SCTP stream. Streams having a 514 higher priority will be scheduled first and when multiple streams 515 have the same priority, the scheduling between them is implementation 516 dependent. When using user message interleaving, the sending of 517 lower priority user messages will not block the sending of higher 518 priority user messages. 520 3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) 522 A fair bandwidth distribution between the streams is used. This 523 scheduler considers the lengths of the messages of each stream and 524 schedules them in a specific way to maintain an equal bandwidth for 525 all streams. The details are implementation dependent. Using user 526 message interleaving allows for a better realization of the fair 527 bandwidth usage. 529 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 531 A weighted fair queueing scheduler between the streams is used. The 532 weight is configurable per outgoing SCTP stream. This scheduler 533 considers the lengths of the messages of each stream and schedules 534 them in a specific way to use the bandwidth according to the given 535 weights. If the weight of stream S1 is n times the weight of stream 536 S2, the scheduler should assign to stream S1 n times the bandwidth it 537 assigns to stream S2. The details are implementation dependent. 538 Using user message interleaving allows for a better realization of 539 the bandwidth usage according to the given weights. 541 This scheduler in combination with user message interleaving is used 542 for WebRTC Datachannels as specified in 543 [I-D.ietf-rtcweb-data-channel]. 545 4. Socket API Considerations 547 This section describes how the socket API defined in [RFC6458] is 548 extended to allow applications to use the extension described in this 549 document. 551 Please note that this section is informational only. 553 4.1. Exposition of the Stream Sequence Number (SSN) 555 The socket API defined in [RFC6458] defines several structures in 556 which the SSN of a received user message is exposed to the 557 application. The list of these structures includes: 559 struct sctp_sndrcvinfo 560 Specified in Section 5.3.2 of [RFC6458] and marked as deprecated. 562 struct sctp_extrcvinfo 563 Specified in Section 5.3.3 of [RFC6458] and marked as deprecated. 565 struct sctp_rcvinfo 566 Specified in Section 5.3.5 of [RFC6458]. 568 If user message interleaving is used, the lower order 16 bits of the 569 MID are used as the SSN when filling out these structures. 571 4.2. SCTP_ASSOC_CHANGE Notification 573 When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of 574 [RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or 575 SCTP_RESTART for an SCTP association where both peers support the 576 I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in 577 the sac_info field. 579 4.3. Socket Options 581 +-----------------------------+-------------------------+-----+-----+ 582 | option name | data type | get | set | 583 +-----------------------------+-------------------------+-----+-----+ 584 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 585 | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | 586 | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | 587 | | sctp_stream_value | | | 588 +-----------------------------+-------------------------+-----+-----+ 590 4.3.1. Enable or Disable the Support of User Message Interleaving 591 (SCTP_INTERLEAVING_SUPPORTED) 593 This socket option allows the enabling or disabling of the 594 negotiation of user message interleaving support for future 595 associations. For existing associations it allows to query whether 596 user message interleaving support was negotiated or not on a 597 particular association. 599 This socket option uses IPPROTO_SCTP as its level and 600 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 601 getsockopt() and setsockopt(). The socket option value uses the 602 following structure defined in [RFC6458]: 604 struct sctp_assoc_value { 605 sctp_assoc_t assoc_id; 606 uint32_t assoc_value; 607 }; 609 assoc_id: This parameter is ignored for one-to-one style sockets. 610 For one-to-many style sockets, this parameter indicates upon which 611 association the user is performing an action. The special 612 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 613 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 615 assoc_value: A non-zero value encodes the enabling of user message 616 interleaving whereas a value of 0 encodes the disabling of user 617 message interleaving. 619 sctp_opt_info() needs to be extended to support 620 SCTP_INTERLEAVING_SUPPORTED. 622 An application using user message interleaving should also set the 623 fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE 624 socket option specified in Section 8.1.20 of [RFC6458]. This allows 625 the interleaving of user messages from different streams. Please 626 note that it does not allow the interleaving of ordered and unordered 627 user messages on the same stream. Failure to set this option can 628 possibly lead to application deadlock. Some implementations might 629 therefore put some restrictions on setting combinations of these 630 values. Setting the interleaving level to at least 2 before enabling 631 the negotiation of user message interleaving should work on all 632 platforms. Since the default fragment interleave level is not 2, 633 user message interleaving is disabled per default. 635 4.3.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) 637 A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER 638 option for setsockopt(). The struct sctp_assoc_value is used to 639 specify the association for which the scheduler should be changed and 640 the value of the desired algorithm. 642 The definition of struct sctp_assoc_value is the same as in 643 [RFC6458]: 645 struct sctp_assoc_value { 646 sctp_assoc_t assoc_id; 647 uint32_t assoc_value; 648 }; 650 assoc_id: Holds the identifier for the association of which the 651 scheduler should be changed. The special 652 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 653 is ignored for one-to-one style sockets. 655 assoc_value: This specifies which scheduler is used. The following 656 constants can be used: 658 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 659 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 661 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1. 663 SCTP_SS_RR: Use the scheduler specified in Section 3.2. 665 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3. 667 SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The 668 priority can be assigned with the sctp_stream_value struct. 669 The higher the assigned value, the lower the priority, that is 670 the default value 0 is the highest priority and therefore the 671 default scheduling will be used if no priorities have been 672 assigned. 674 SCTP_SS_FB: Use the scheduler specified in Section 3.5. 676 SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The 677 weight can be assigned with the sctp_stream_value struct. 679 sctp_opt_info() needs to be extended to support 680 SCTP_STREAM_SCHEDULER. 682 4.3.3. Get or Set the Stream Scheduler Parameter 683 (SCTP_STREAM_SCHEDULER_VALUE) 685 Some schedulers require additional information to be set for 686 individual streams as shown in the following table: 688 +-----------------+-----------------+ 689 | name | per stream info | 690 +-----------------+-----------------+ 691 | SCTP_SS_DEFAULT | n/a | 692 | SCTP_SS_FCFS | no | 693 | SCTP_SS_RR | no | 694 | SCTP_SS_RR_PKT | no | 695 | SCTP_SS_PRIO | yes | 696 | SCTP_SS_FB | no | 697 | SCTP_SS_WFQ | yes | 698 +-----------------+-----------------+ 700 This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the 701 corresponding struct sctp_stream_value. The definition of struct 702 sctp_stream_value is as follows: 704 struct sctp_stream_value { 705 sctp_assoc_t assoc_id; 706 uint16_t stream_id; 707 uint16_t stream_value; 708 }; 710 assoc_id: Holds the identifier for the association of which the 711 scheduler should be changed. The special 712 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 713 is ignored for one-to-one style sockets. 715 stream_id: Holds the stream id of the stream for which additional 716 information has to be provided. 718 stream_value: The meaning of this field depends on the scheduler 719 specified. It is ignored when the scheduler does not need 720 additional information. 722 sctp_opt_info() needs to be extended to support 723 SCTP_STREAM_SCHEDULER_VALUE. 725 4.4. Explicit EOR Marking 727 Using explicit End of Record (EOR) marking for an SCTP association 728 supporting user message interleaving allows the user to interleave 729 the sending of user messages on different streams. 731 5. IANA Considerations 733 [NOTE to RFC-Editor: 735 "RFCXXXX" is to be replaced by the RFC number you assign this 736 document. 738 ] 740 [NOTE to RFC-Editor: 742 The suggested values for the chunk types and the chunk flags are 743 tentative and to be confirmed by IANA. 745 ] 747 This document (RFCXXXX) is the reference for all registrations 748 described in this section. 750 Two new chunk types have to be assigned by IANA. 752 5.1. I-DATA Chunk 754 IANA should assign the chunk type for this chunk from the pool of 755 chunks with the upper two bits set to '01'. This requires an 756 additional line in the "Chunk Types" registry for SCTP: 758 +----------+--------------------------------------------+-----------+ 759 | ID Value | Chunk Type | Reference | 760 +----------+--------------------------------------------+-----------+ 761 | 64 | Payload Data supporting Interleaving | [RFCXXXX] | 762 | | (I-DATA) | | 763 +----------+--------------------------------------------+-----------+ 765 The registration table as defined in [RFC6096] for the chunk flags of 766 this chunk type is initially given by the following table: 768 +------------------+-----------------+-----------+ 769 | Chunk Flag Value | Chunk Flag Name | Reference | 770 +------------------+-----------------+-----------+ 771 | 0x01 | E bit | [RFCXXXX] | 772 | 0x02 | B bit | [RFCXXXX] | 773 | 0x04 | U bit | [RFCXXXX] | 774 | 0x08 | I bit | [RFCXXXX] | 775 | 0x10 | Unassigned | | 776 | 0x20 | Unassigned | | 777 | 0x40 | Unassigned | | 778 | 0x80 | Unassigned | | 779 +------------------+-----------------+-----------+ 781 5.2. I-FORWARD-TSN Chunk 783 IANA should assign the chunk type for this chunk from the pool of 784 chunks with the upper two bits set to '11'. This requires an 785 additional line in the "Chunk Types" registry for SCTP: 787 +----------+---------------+-----------+ 788 | ID Value | Chunk Type | Reference | 789 +----------+---------------+-----------+ 790 | 194 | I-FORWARD-TSN | [RFCXXXX] | 791 +----------+---------------+-----------+ 793 The registration table as defined in [RFC6096] for the chunk flags of 794 this chunk type is initially empty. 796 6. Security Considerations 798 This document does not add any additional security considerations in 799 addition to the ones given in [RFC4960] and [RFC6458]. 801 It should be noted that the application has to consent that it is 802 willing to do the more complex reassembly support required for user 803 message interleaving. When doing so, an application has to provide 804 up to two reassembly buffers (one for ordered messages, one for 805 unordered messages) for each incoming stream. It has to protect 806 itself against these buffers taking too many resources. If user 807 message interleaving is not used, only a single reassembly buffer 808 needs to be provided. But the application has to protect itself for 809 excessive resource usages there too. 811 7. Acknowledgments 813 The authors wish to thank Gorry Fairhurst, Christer Holmberg, Marcelo 814 Ricardo Leitner, Karen E. Egede Nielsen, Maksim Proshin, Irene 815 Ruengeler, Felix Weinrank, Michael Welzl, Magnus Westerlund, and 816 Lixia Zhang for their invaluable comments. 818 This work has received funding from the European Union's Horizon 2020 819 research and innovation programme under grant agreement No. 644334 820 (NEAT). The views expressed are solely those of the author(s). 822 8. References 824 8.1. Normative References 826 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 827 DOI 10.17487/RFC1982, August 1996, 828 . 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, 832 DOI 10.17487/RFC2119, March 1997, 833 . 835 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 836 Conrad, "Stream Control Transmission Protocol (SCTP) 837 Partial Reliability Extension", RFC 3758, 838 DOI 10.17487/RFC3758, May 2004, 839 . 841 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 842 RFC 4960, DOI 10.17487/RFC4960, September 2007, 843 . 845 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 846 Kozuka, "Stream Control Transmission Protocol (SCTP) 847 Dynamic Address Reconfiguration", RFC 5061, 848 DOI 10.17487/RFC5061, September 2007, 849 . 851 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 852 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 853 DOI 10.17487/RFC6096, January 2011, 854 . 856 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 857 Transmission Protocol (SCTP) Stream Reconfiguration", 858 RFC 6525, DOI 10.17487/RFC6525, February 2012, 859 . 861 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 862 IMMEDIATELY Extension for the Stream Control Transmission 863 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 864 . 866 8.2. Informative References 868 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 869 A., Peterson, J., Sparks, R., Handley, M., and E. 870 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 871 DOI 10.17487/RFC3261, June 2002, 872 . 874 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 875 Yasevich, "Sockets API Extensions for the Stream Control 876 Transmission Protocol (SCTP)", RFC 6458, 877 DOI 10.17487/RFC6458, December 2011, 878 . 880 [I-D.ietf-rtcweb-data-channel] 881 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 882 Channels", draft-ietf-rtcweb-data-channel-13 (work in 883 progress), January 2015. 885 Authors' Addresses 887 Randall R. Stewart 888 Netflix, Inc. 889 Chapin, SC 29036 890 United States 892 Email: randall@lakerest.net 894 Michael Tuexen 895 Muenster University of Applied Sciences 896 Stegerwaldstrasse 39 897 48565 Steinfurt 898 Germany 900 Email: tuexen@fh-muenster.de 902 Salvatore Loreto 903 Ericsson 904 Torshamnsgatan 21 905 164 80 Stockholm 906 Sweden 908 Email: Salvatore.Loreto@ericsson.com 910 Robin Seggelmann 911 Metafinanz Informationssysteme GmbH 912 Leopoldstrasse 146 913 80804 Muenchen 914 Germany 916 Email: rfc@robin-seggelmann.com