idnits 2.17.00 (12 Aug 2021) /tmp/idnits17968/draft-ietf-tsvwg-sctp-ndata-08.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 (October 31, 2016) is 2027 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 735, but not defined == Outdated reference: draft-ietf-rtcweb-data-channel has been published as RFC 8831 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 4, 2017 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 October 31, 2016 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-08.txt 16 Abstract 18 The Stream Control Transmission Protocol (SCTP) is a message oriented 19 transport protocol supporting arbitrary large user messages. This 20 document adds a new data chunk to SCTP. This allows a sender to 21 interleave different user messages that would otherwise result in 22 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 May 4, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 7 71 2.2.2. Sender Side Considerations . . . . . . . . . . . . . 8 72 2.2.3. Receiver Side Considerations . . . . . . . . . . . . 8 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 . . . . . . . . 10 76 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1. First Come First Serve (SCTP_SS_FCFS) . . . . . . . . . . 10 78 3.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 11 79 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 11 80 3.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 11 81 3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) . . . . . . . . . . 11 82 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 11 83 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 12 84 4.1. Exposition of the Stream Sequence Number (SSN) . . . . . 12 85 4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 12 86 4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 15 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 99 8.2. Informative References . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 1.1. Overview 106 When SCTP [RFC4960] was initially designed it was mainly envisioned 107 for the transport of small signaling messages. Late in the design 108 stage it was decided to add support for fragmentation and reassembly 109 of larger messages with the thought that someday Session Initiation 110 Protocol (SIP) [RFC3261] style signaling messages may also need to 111 use SCTP and a single Maximum Transmission Unit (MTU) sized message 112 would be too small. Unfortunately this design decision, though valid 113 at the time, did not account for other applications that might send 114 large messages over SCTP. When such large messages are sent over 115 SCTP as specified in [RFC4960] can result in a form of sender side 116 head of line blocking (e.g., when the transmission of an urgent 117 message is blocked from transmission because the sender has started 118 transmission of another, possibly large, message). This head of line 119 blocking is caused by the use of the Transmission Sequence Number 120 (TSN) for three different purposes: 122 1. As an identifier for DATA chunks to provide a reliable transfer. 124 2. As an identifier for the sequence of fragments to allow 125 reassembly. 127 3. As a sequence number allowing to have up to 2**16 - 1 Stream 128 Sequence Numbers (SSNs) outstanding. 130 The protocol requires all fragments of a user message to have 131 consecutive TSNs. Therefore it is impossible for the sender to 132 interleave different user messages. 134 This document also defines several stream schedulers for general SCTP 135 associations. If support for user message interleaving has been 136 negotiated, several more schedulers are available. 138 The following Figure 1 illustrates the behaviour of a round robin 139 stream scheduler using DATA chunks. Please note that the use of such 140 a scheduler implies late TSN assignment but it can be used with an 141 [RFC4960] compliant implementation not supporting user message 142 interleaving. 144 +---+---+---+ 145 | 0/0 |-+ 146 +---+---+---+ | 147 | +---+---+---+---+---+---+---+---+---+ 148 +---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0| 149 |1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---| 150 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 151 | +---+---+---+---+---+---+---+---+---+ 152 +---+---+---+ | 153 | 2/0 |-+ 154 +---+---+---+ 155 +-------+ 156 +-------+ |SID/SSN| 157 |SID/SSN| |-------| 158 +-------+ | TSN | 159 +-------+ 161 Figure 1: Round Robin Scheduler without User Message Interleaving 163 This document describes a new Data chunk called I-DATA. This chunk 164 incorporates all the flags and fields except the Stream Sequence 165 Number (SSN) and properties of the current SCTP Data chunk but also 166 adds two new fields in its chunk header, the Fragment Sequence Number 167 (FSN) and the Message Identifier (MID). Then the FSN is only used 168 for reassembling all fragments having the same MID and ordering 169 property. The TSN is used only for the reliable transfer in 170 combination with Selective Acknowledgment (SACK) chunks. 172 In addition, the MID is also used for ensuring ordered delivery 173 instead of using the stream sequence number, which has been omitted 174 from the I-DATA chunk. 176 The following Figure 2 illustrates the behaviour of an interleaving 177 round robin stream scheduler using I-DATA chunks. 179 +---+---+---+ 180 | 0/0 |-+ 181 +---+---+---+ | 182 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 183 +---+---+---+ +->|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| 184 |1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----| 185 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 186 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 187 +---+---+---+ | 188 | 2/0 |-+ 189 +---+---+---+ 190 +-----------+ 191 +-------+ |SID/MID/FSN| 192 |SID/MID| |-----------| 193 +-------+ | TSN | 194 +-----------+ 196 Figure 2: Round Robin Scheduler with User Message Interleaving 198 The support of the I-DATA chunk is negotiated during the association 199 setup using the Supported Extensions Parameter as defined in 200 [RFC5061]. If I-DATA support has been negotiated for an association 201 I-DATA chunks are used for all user-messages. DATA chunks are not 202 permitted when I-DATA support has been negotiated. It should be 203 noted, that an SCTP implementation needs to support the coexistence 204 of associations using DATA chunks and associations using I-DATA 205 chunks. 207 This document specifies in Section 2 the user message interleaving by 208 defining the I-DATA chunk, the procedures to use it and its 209 interactions with other SCTP extensions. Multiple stream schedulers 210 are defined in Section 3 followed by describing in Section 4 an 211 extension to the socket API for using what is specified in this 212 document. 214 1.2. Conventions 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 2. User Message Interleaving 222 The interleaving of user messages is required for WebRTC Datachannels 223 as specified in [I-D.ietf-rtcweb-data-channel]. 225 An SCTP implementation supporting user message interleaving is 226 REQUIRED to support the coexistence of associations using DATA chunks 227 and associations using I-DATA chunks. If an SCTP implementation 228 supports user message interleaving and the extension described in 229 [RFC3758] or [RFC6525], it is REQUIRED to implement the corresponding 230 changes specified in Section 2.3. 232 2.1. The I-DATA Chunk supporting User Message Interleaving 234 The following Figure 3 shows the new I-DATA chunk allowing user 235 messages interleaving. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type = 64 | Res |I|U|B|E| Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | TSN | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Stream Identifier | Reserved | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Message Identifier | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Payload Protocol Identifier / Fragment Sequence Number | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 \ \ 251 / User Data / 252 \ \ 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 3: I-DATA chunk format 257 The only differences between the I-DATA chunk in Figure 3 and the 258 DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the 259 new Message Identifier (MID) and Fragment Sequence Number (FSN) and 260 the removal of the Stream Sequence Number (SSN). The length of the 261 I-DATA chunk header is 20 bytes, which is 4 bytes more than the 262 length of the DATA chunk header defined in [RFC4960]. 264 The new fields are: 266 Reserved: 16 bits (unsigned integer) 267 This field is reserved. It MUST be set to 0 by the sender and 268 MUST be ignored by the receiver. 270 Message Identifier (MID): 32 bits (unsigned integer) 271 The MID is the same for all fragments of a user message, it is 272 used to determine which fragments (enumerated by the FSN) belong 273 to the same user message. For ordered user messages, the MID is 274 also used by the SCTP receiver to deliver the user messages in the 275 correct order to the upper layer (similar to the SSN of the DATA 276 chunk defined in [RFC4960]). The sender uses two counters for 277 each outgoing stream, one for ordered messages, one for unordered 278 messages. All counters are independent and initially 0. They are 279 incremented by 1 for each user message. Please note that the 280 serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 281 32 applies. Therefore the sender MUST NOT have more than 2**31 - 282 1 ordered messages for each outgoing stream in flight and MUST NOT 283 have more than 2**31 - 1 unordered messages for each outgoing 284 stream in flight. Please note that the MID is in "network byte 285 order", a.k.a. Big Endian. 287 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 288 32 bits (unsigned integer) 289 If the B bit is set, this field contains the PPID of the user 290 message. Note that in this case, this field is NOT touched by an 291 SCTP implementation; therefore, its byte order is not necessarily 292 in network byte order. The upper layer is responsible for any 293 byte order conversions to this field, similar to the PPID of DATA 294 chunks. In this case the FSN is implicitly considered to be 0. 295 If the B bit is not set, this field contains the FSN. The FSN is 296 used to enumerate all fragments of a single user message, starting 297 from 0 and incremented by 1. The last fragment of a message MUST 298 have the 'E' bit set. Note that the FSN MAY wrap completely 299 multiple times allowing arbitrary large user messages. For the 300 FSN the serial number arithmetic defined in [RFC1982] applies with 301 SERIAL_BITS = 32. Therefore a sender MUST NOT have more than 302 2**31 - 1 fragments of a single user message in flight. Please 303 note that the FSN is in "network byte order", a.k.a. Big Endian. 305 2.2. Procedures 307 This subsection describes how the support of the I-DATA chunk is 308 negotiated and how the I-DATA chunk is used by the sender and 309 receiver. 311 2.2.1. Negotiation 313 A sender MUST NOT send an I-DATA chunk unless both peers have 314 indicated its support of the I-DATA chunk type within the Supported 315 Extensions Parameter as defined in [RFC5061]. If I-DATA support has 316 been negotiated on an association, I-DATA chunks MUST be used for all 317 user messages and DATA-chunk MUST NOT be used. If I-DATA support has 318 not been negotiated on an association, DATA chunks MUST be used for 319 all user messages and I-DATA chunks MUST NOT be used. 321 A sender MUST NOT use the I-DATA chunk unless the user has requested 322 that use (e.g. via the socket API, see Section 4.3). This constraint 323 is made since usage of this chunk requires that the application be 324 willing to interleave messages upon reception within an association. 325 This is not the default choice within the socket API (see [RFC6458]) 326 thus the user MUST indicate support to the protocol of the reception 327 of completely interleaved messages. Note that for stacks that do not 328 implement [RFC6458] they may use other methods to indicate 329 interleaved message support and thus enable the usage of the I-DATA 330 chunk, the key is that the stack MUST know the application has 331 indicated its choice in wanting to use the extension. 333 2.2.2. Sender Side Considerations 335 Sender side usage of the I-DATA chunk is quite simple. Instead of 336 using the TSN for fragmentation purposes, the sender uses the new FSN 337 field to indicate which fragment number is being sent. The first 338 fragment MUST have the 'B' bit set. The last fragment MUST have the 339 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 340 set. All other properties of the existing SCTP DATA chunk also apply 341 to the I-DATA chunk, i.e. congestion control as well as receiver 342 window conditions MUST be observed as defined in [RFC4960]. 344 Note that the usage of this chunk implies the late assignment of the 345 actual TSN to any chunk being sent. Each I-DATA chunk uses a single 346 TSN. This way messages from other streams may be interleaved with 347 the fragmented message. Please note that this is the only form of 348 interleaving support. For example, it is not possible to interleave 349 multiple ordered or unordered user messages from the same stream. 351 The sender MUST NOT be fragmenting more than one user message in any 352 given stream at any time. At any time, a sender MAY fragment 353 multiple user messages, each of them on different streams. 355 The sender MUST assign TSN's in a way that the receiver can make 356 progress. One way to achieve this is to assign the later fragments 357 of a user message a higher TSN and send out the TSNs in sequence. 359 2.2.3. Receiver Side Considerations 361 Upon reception of an SCTP packet containing an I-DATA chunk if the 362 message needs to be reassembled, then the receiver MUST use the FSN 363 for reassembly of the message and not the TSN. The receiver MUST NOT 364 make any assumption about the TSN assignments of the sender. Note 365 that a non-fragmented message is indicated by the fact that both the 366 'E' and 'B' bits are set. A message (either ordered or unordered) 367 may be identified as being fragmented by seeing that not both bits 368 have been set. 370 2.3. Interaction with other SCTP Extensions 372 The usage of the I-DATA chunk might interfere with other SCTP 373 extensions. Future SCTP extensions MUST describe if and how they 374 interfere with the usage of I-DATA chunks. For the SCTP extensions 375 already defined when this document was published, the details are 376 given in the following subsections. 378 2.3.1. SCTP Partial Reliability Extension 380 When the SCTP extension defined in [RFC3758] is used in combination 381 with the user message interleaving extension, the new I-FORWARD-TSN 382 chunk MUST be used instead of the FORWARD-TSN chunk. The difference 383 between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 384 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit 385 Message Identifier (MID) and the largest skipped MID can also be 386 provided for unordered messages. Therefore the principle applied to 387 ordered message when using FORWARD-TSN chunks is applied to ordered 388 and unordered messages when using I-FORWARD-TSN chunks. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type = 194 | Flags = 0x00 | Length = Variable | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | New Cumulative TSN | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Stream Identifier | Reserved |U| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Message Identifier | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 \ \ 402 / / 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Stream Identifier | Reserved |U| 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Message Identifier | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 4: I-FORWARD-TSN chunk format 411 The relevant new fields are: 413 Stream Identifier (SID): 16-bits (unsigned integer) 414 This field holds the stream number this entry refers to. 416 Reserved: 15 bits 417 This field is reserved. It MUST be set to 0 by the sender and 418 MUST be ignored by the receiver. 420 U bit: 1 bit 421 The U bit specifies if the Message Identifier of this entry refers 422 unordered messages (U bit is set) or ordered messages (U bit is 423 not set). 425 Message Identifier (MID): 32 bits (unsigned integer) 426 This field holds the largest Message Identifier for ordered or 427 unordered messages indicated by the U-bit that was skipped for the 428 stream specified by the Stream Identifier. For ordered messages 429 this is similar to the FORWARD-TSN chunk, just replacing the 430 16-bit SSN by the 32-bit MID. 432 The FORWARD-TSN chunk MUST be used in combination with the DATA chunk 433 and MUST NOT be used in combination with the I-DATA chunk. The I- 434 FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk 435 and MUST NOT be used in combination with the DATA chunk. 437 Support for the I-FORWARD-TSN chunk is negotiated during the SCTP 438 association setup via the Supported Extensions Parameter as defined 439 in [RFC5061]. Only if both end points support the I-DATA chunk and 440 the I-FORWARD-TSN chunk, the partial reliability extension can be 441 used in combination with user message interleaving. 443 2.3.2. SCTP Stream Reconfiguration Extension 445 When an association resets the SSN using the SCTP extension defined 446 in [RFC6525], the two counters (one for the ordered messages, one for 447 the unordered messages) used for the MID MUST be reset to 0. 449 Since most schedulers, especially all schedulers supporting user 450 message interleaving, require late TSN assignment, it should be noted 451 that the implementation of [RFC6525] needs to handle this. 453 3. Stream Schedulers 455 This section defines several stream schedulers. The stream 456 schedulers may behave differently depending on whether user message 457 interleaving has been negotiated for the association or not. The set 458 of schedulers being implemented is implementation dependent. 460 3.1. First Come First Serve (SCTP_SS_FCFS) 462 The simple first-come, first-serve scheduler of user messages is 463 used. It just passes through the messages in the order in which they 464 have been delivered by the application. No modification of the order 465 is done at all. The usage of user message interleaving does not 466 affect the sending of the chunks, except that I-DATA chunks are used 467 instead of DATA chunks. 469 3.2. Round Robin Scheduler (SCTP_SS_RR) 471 When not using user message interleaving, this scheduler provides a 472 fair scheduling based on the number of user messages by cycling 473 around non-empty stream queues. When using user message 474 interleaving, this scheduler provides a fair scheduling based on the 475 number of I-DATA chunks by cycling around non-empty stream queues. 477 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) 479 This is a round-robin scheduler but bundles only DATA or I-DATA 480 chunks referring to the same stream in a packet. This minimizes 481 head-of-line blocking when a packet is lost because only a single 482 stream is affected. 484 3.4. Priority Based Scheduler (SCTP_SS_PRIO) 486 Scheduling of user messages with strict priorities is used. The 487 priority is configurable per outgoing SCTP stream. Streams having a 488 higher priority will be scheduled first and when multiple streams 489 have the same priority, the scheduling between them is implementation 490 specific. When using user message interleaving, the sending of lower 491 priority user messages will not block the sending of higher priority 492 user messages. 494 3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) 496 A fair bandwidth distribution between the streams is used. This 497 scheduler considers the lengths of the messages of each stream and 498 schedules them in a certain way to maintain an equal bandwidth for 499 all streams. The details are implementation specific. Using user 500 message interleaving allows for a better realization of the fair 501 bandwidth usage. 503 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 505 A weighted fair queueing scheduler between the streams is used. The 506 weight is configurable per outgoing SCTP stream. This scheduler 507 considers the lengths of the messages of each stream and schedules 508 them in a certain way to use the bandwidth according to the given 509 weights. The details are implementation specific. Using user 510 message interleaving allows for a better realization of the bandwidth 511 usage according to the given weights. 513 This scheduler in combination with user message interleaving is used 514 for WebRTC Datachannels as specified in 515 [I-D.ietf-rtcweb-data-channel]. 517 4. Socket API Considerations 519 This section describes how the socket API defined in [RFC6458] is 520 extended to allow applications to use the extension described in this 521 document. 523 Please note that this section is informational only. 525 4.1. Exposition of the Stream Sequence Number (SSN) 527 The socket API defined in [RFC6458] defines several structures in 528 which the SSN of a received user message is exposed to the 529 application. The list of these structures includes: 531 struct sctp_sndrcvinfo 532 Specified in Section 5.3.2 of [RFC6458] and marked as deprecated. 534 struct sctp_extrcvinfo 535 Specified in Section 5.3.3 of [RFC6458] and marked as deprecated. 537 struct sctp_rcvinfo 538 Specified in Section 5.3.5 of [RFC6458]. 540 If user message interleaving is used, the lower order 16 bits of the 541 MID are used as the SSN when filling out these structures. 543 4.2. SCTP_ASSOC_CHANGE Notification 545 When an SCTP_ASSOC_CHANGE notification is delivered indicating a 546 sac_state of SCTP_COMM_UP or SCTP_RESTART for an SCTP association 547 where both peers support the I-DATA chunk, 548 SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in the sac_info 549 field. 551 4.3. Socket Options 553 +-----------------------------+-------------------------+-----+-----+ 554 | option name | data type | get | set | 555 +-----------------------------+-------------------------+-----+-----+ 556 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 557 | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | 558 | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | 559 | | sctp_stream_value | | | 560 +-----------------------------+-------------------------+-----+-----+ 562 4.3.1. Enable or Disable the Support of User Message Interleaving 563 (SCTP_INTERLEAVING_SUPPORTED) 565 This socket option allows the enabling or disabling of the 566 negotiation of user message interleaving support for future 567 associations. For existing associations it allows to query whether 568 user message interleaving support was negotiated or not on a 569 particular association. 571 User message interleaving is disabled per default. 573 This socket option uses IPPROTO_SCTP as its level and 574 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 575 getsockopt() and setsockopt(). The socket option value uses the 576 following structure defined in [RFC6458]: 578 struct sctp_assoc_value { 579 sctp_assoc_t assoc_id; 580 uint32_t assoc_value; 581 }; 583 assoc_id: This parameter is ignored for one-to-one style sockets. 584 For one-to-many style sockets, this parameter indicates upon which 585 association the user is performing an action. The special 586 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 587 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 589 assoc_value: A non-zero value encodes the enabling of user message 590 interleaving whereas a value of 0 encodes the disabling of user 591 message interleaving. 593 sctp_opt_info() needs to be extended to support 594 SCTP_INTERLEAVING_SUPPORTED. 596 An application using user message interleaving should also set the 597 fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE 598 socket option specified in Section 8.1.20 of [RFC6458]. This allows 599 the interleaving of user messages from different streams. Please 600 note that it does not allow the interleaving of ordered and unordered 601 user messages on the same stream. Failure to set this option can 602 possibly lead to application deadlock. Some implementations might 603 therefore put some restrictions on setting combinations of these 604 values. 606 4.3.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) 608 A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER 609 option for setsockopt(). The struct sctp_assoc_value is used to 610 specify the association for which the scheduler should be changed and 611 the value of the desired algorithm. 613 The definition of struct sctp_assoc_value is the same as in 614 [RFC6458]: 616 struct sctp_assoc_value { 617 sctp_assoc_t assoc_id; 618 uint32_t assoc_value; 619 }; 621 assoc_id: Holds the identifier for the association of which the 622 scheduler should be changed. The special 623 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 624 is ignored for one-to-one style sockets. 626 assoc_value: This specifies which scheduler is used. The following 627 constants can be used: 629 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 630 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 632 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1. 634 SCTP_SS_RR: Use the scheduler specified in Section 3.2. 636 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3. 638 SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The 639 priority can be assigned with the sctp_stream_value struct. 640 The higher the assigned value, the lower the priority, that is 641 the default value 0 is the highest priority and therefore the 642 default scheduling will be used if no priorities have been 643 assigned. 645 SCTP_SS_FB: Use the scheduler specified in Section 3.5. 647 SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The 648 weight can be assigned with the sctp_stream_value struct. 650 4.3.3. Get or Set the Stream Scheduler Parameter 651 (SCTP_STREAM_SCHEDULER_VALUE) 653 Some schedulers require additional information to be set for 654 individual streams as shown in the following table: 656 +-----------------+-----------------+ 657 | name | per stream info | 658 +-----------------+-----------------+ 659 | SCTP_SS_DEFAULT | n/a | 660 | SCTP_SS_FCFS | no | 661 | SCTP_SS_RR | no | 662 | SCTP_SS_RR_PKT | no | 663 | SCTP_SS_PRIO | yes | 664 | SCTP_SS_FB | no | 665 | SCTP_SS_WFQ | yes | 666 +-----------------+-----------------+ 668 This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the 669 corresponding struct sctp_stream_value. The definition of struct 670 sctp_stream_value is as follows: 672 struct sctp_stream_value { 673 sctp_assoc_t assoc_id; 674 uint16_t stream_id; 675 uint16_t stream_value; 676 }; 678 assoc_id: Holds the identifier for the association of which the 679 scheduler should be changed. The special 680 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 681 is ignored for one-to-one style sockets. 683 stream_id: Holds the stream id for the stream for which additional 684 information has to be provided. 686 stream_value: The meaning of this field depends on the scheduler 687 specified. It is ignored when the scheduler does not need 688 additional information. 690 4.4. Explicit EOR Marking 692 Using explicit End of Record (EOR) marking for an SCTP association 693 supporting user message interleaving allows the user to interleave 694 the sending of user messages on different streams. 696 5. IANA Considerations 698 [NOTE to RFC-Editor: 700 "RFCXXXX" is to be replaced by the RFC number you assign this 701 document. 703 ] 705 [NOTE to RFC-Editor: 707 The suggested values for the chunk type and the chunk flags are 708 tentative and to be confirmed by IANA. 710 ] 712 This document (RFCXXXX) is the reference for all registrations 713 described in this section. 715 A new chunk type has to be assigned by IANA. IANA should assign this 716 value from the pool of chunks with the upper two bits set to '01'. 717 This requires an additional line in the "Chunk Types" registry for 718 SCTP: 720 +----------+-------------------------+-----------+ 721 | ID Value | Chunk Type | Reference | 722 +----------+-------------------------+-----------+ 723 | 64 | New DATA chunk (I-DATA) | [RFCXXXX] | 724 +----------+-------------------------+-----------+ 726 The registration table as defined in [RFC6096] for the chunk flags of 727 this chunk type is initially given by the following table: 729 +------------------+-----------------+-----------+ 730 | Chunk Flag Value | Chunk Flag Name | Reference | 731 +------------------+-----------------+-----------+ 732 | 0x01 | E bit | [RFCXXXX] | 733 | 0x02 | B bit | [RFCXXXX] | 734 | 0x04 | U bit | [RFCXXXX] | 735 | 0x08 | I bit | [RFCXXXX] | 736 | 0x10 | Unassigned | | 737 | 0x20 | Unassigned | | 738 | 0x40 | Unassigned | | 739 | 0x80 | Unassigned | | 740 +------------------+-----------------+-----------+ 742 6. Security Considerations 744 This document does not add any additional security considerations in 745 addition to the ones given in [RFC4960] and [RFC6458]. 747 It should be noted that the application has to consent that it is 748 willing to do the more complex reassembly support required for user 749 message interleaving. 751 7. Acknowledgments 753 The authors wish to thank Gorry Fairhurst, Christer Holmberg, Marcelo 754 Ricardo Leitner, Karen E. Egede Nielsen, Irene Ruengeler, Felix 755 Weinrank, and Lixia Zhang for her invaluable comments. 757 This work has received funding from the European Union's Horizon 2020 758 research and innovation programme under grant agreement No. 644334 759 (NEAT). The views expressed are solely those of the author(s). 761 8. References 763 8.1. Normative References 765 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 766 DOI 10.17487/RFC1982, August 1996, 767 . 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, 771 DOI 10.17487/RFC2119, March 1997, 772 . 774 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 775 Conrad, "Stream Control Transmission Protocol (SCTP) 776 Partial Reliability Extension", RFC 3758, 777 DOI 10.17487/RFC3758, May 2004, 778 . 780 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 781 RFC 4960, DOI 10.17487/RFC4960, September 2007, 782 . 784 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 785 Kozuka, "Stream Control Transmission Protocol (SCTP) 786 Dynamic Address Reconfiguration", RFC 5061, 787 DOI 10.17487/RFC5061, September 2007, 788 . 790 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 791 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 792 DOI 10.17487/RFC6096, January 2011, 793 . 795 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 796 Transmission Protocol (SCTP) Stream Reconfiguration", 797 RFC 6525, DOI 10.17487/RFC6525, February 2012, 798 . 800 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 801 IMMEDIATELY Extension for the Stream Control Transmission 802 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 803 . 805 8.2. Informative References 807 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 808 A., Peterson, J., Sparks, R., Handley, M., and E. 809 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 810 DOI 10.17487/RFC3261, June 2002, 811 . 813 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 814 Yasevich, "Sockets API Extensions for the Stream Control 815 Transmission Protocol (SCTP)", RFC 6458, 816 DOI 10.17487/RFC6458, December 2011, 817 . 819 [I-D.ietf-rtcweb-data-channel] 820 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 821 Channels", draft-ietf-rtcweb-data-channel-13 (work in 822 progress), January 2015. 824 Authors' Addresses 826 Randall R. Stewart 827 Netflix, Inc. 828 Chapin, SC 29036 829 United States 831 Email: randall@lakerest.net 832 Michael Tuexen 833 Muenster University of Applied Sciences 834 Stegerwaldstrasse 39 835 48565 Steinfurt 836 Germany 838 Email: tuexen@fh-muenster.de 840 Salvatore Loreto 841 Ericsson 842 Hirsalantie 11 843 Jorvas 02420 844 Finland 846 Email: Salvatore.Loreto@ericsson.com 848 Robin Seggelmann 849 Metafinanz Informationssysteme GmbH 850 Leopoldstrasse 146 851 80804 Muenchen 852 Germany 854 Email: rfc@robin-seggelmann.com