idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-07.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 (July 21, 2016) is 2835 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 716, 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: January 22, 2017 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 July 21, 2016 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-07.txt 16 Abstract 18 The Stream Control Transmission Protocol (SCTP) is a message oriented 19 transport protocol supporting arbitrary large user messages. 20 However, the sender can not interleave different user messages which 21 causes head of line blocking at the sender side. To overcome this 22 limitation, this document adds a new data chunk to SCTP. 24 Whenever an SCTP sender is allowed to send a user data, it can 25 possibly choose from multiple outgoing SCTP streams. Multiple ways 26 for this selection, called stream schedulers, are defined. Some of 27 them don't require the support of user message interleaving, some do. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 22, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. User Message Interleaving . . . . . . . . . . . . . . . . . . 5 67 2.1. The I-DATA Chunk supporting User Message Interleaving . . 5 68 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 7 70 2.2.2. Sender Side Considerations . . . . . . . . . . . . . 8 71 2.2.3. Receiver Side Considerations . . . . . . . . . . . . 8 72 2.3. Interaction with other SCTP Extensions . . . . . . . . . 8 73 2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 9 74 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 10 75 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1. First Come First Serve (SCTP_SS_FCFS) . . . . . . . . . . 10 77 3.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 11 78 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 11 79 3.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 11 80 3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) . . . . . . . . . . 11 81 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 11 82 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 12 83 4.1. Exposition of the Stream Sequence Number (SSN) . . . . . 12 84 4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 12 85 4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 12 86 4.3.1. Enable or Disable the Support of User Message 87 Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 13 88 4.3.2. Get or Set the Stream Scheduler 89 (SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 14 90 4.3.3. Get or Set the Stream Scheduler Parameter 91 (SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 15 92 4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 15 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 98 8.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 1.1. Overview 105 When SCTP [RFC4960] was initially designed it was mainly envisioned 106 for the transport of small signaling messages. Late in the design 107 stage it was decided to add support for fragmentation and reassembly 108 of larger messages with the thought that someday Session Initiation 109 Protocol (SIP) [RFC3261] style signaling messages may also need to 110 use SCTP and a single MTU sized message would be too small. 111 Unfortunately this design decision, though valid at the time, did not 112 account for other applications which might send very large messages 113 over SCTP. When such large messages are now sent over SCTP a form of 114 sender side head of line blocking becomes created within the 115 protocol. This head of line blocking is caused by the use of the 116 Transmission Sequence Number (TSN) for three different purposes: 118 1. As an identifier for DATA chunks to provide a reliable transfer. 120 2. As an identifier for the sequence of fragments to allow 121 reassembly. 123 3. As a sequence number allowing to have up to 2**16 - 1 Stream 124 Sequence Numbers (SSNs) outstanding. 126 The protocol requires all fragments of a user message to have 127 consecutive TSNs. Therefore it is impossible for the sender to 128 interleave different user messages. 130 This document also defines several stream schedulers for general SCTP 131 associations. If support for user message interleaving has been 132 negotiated, several more schedulers are available. 134 The following Figure 1 illustrates the behaviour of a round robin 135 stream scheduler using DATA chunks. Please note that the use of such 136 an scheduler implies late TSN assignment but it can be used with an 137 [RFC4960] compliant implementation not supporting user message 138 interleaving. 140 +---+---+---+ 141 | 0/0 |-+ 142 +---+---+---+ | 143 | +---+---+---+---+---+---+---+---+---+ 144 +---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0| 145 |1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---| 146 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 147 | +---+---+---+---+---+---+---+---+---+ 148 +---+---+---+ | 149 | 2/0 |-+ 150 +---+---+---+ 151 +-------+ 152 +-------+ |SID/SSN| 153 |SID/SSN| |-------| 154 +-------+ | TSN | 155 +-------+ 157 Figure 1: Round Robin Scheduler without User Message Interleaving 159 This document describes a new Data chunk called I-DATA. This chunk 160 incorporates all the flags and fields except the Stream Sequence 161 Number (SSN) and properties of the current SCTP Data chunk but also 162 adds two new fields in its chunk header, the Fragment Sequence Number 163 (FSN) and the Message Identifier (MID). Then the FSN is only used 164 for reassembling all fragments having the same MID and ordering 165 property. The TSN is used only for the reliable transfer in 166 combination with SACK chunks. 168 The MID is also used for ensuring ordered delivery, therefore 169 replacing the stream sequence number. Therefore, the head of line 170 blocking caused by the original design is avoided. 172 The following Figure 2 illustrates the behaviour of an interleaving 173 round robin stream scheduler using I-DATA chunks. 175 +---+---+---+ 176 | 0/0 |-+ 177 +---+---+---+ | 178 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 179 +---+---+---+ +->|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| 180 |1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----| 181 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 182 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 183 +---+---+---+ | 184 | 2/0 |-+ 185 +---+---+---+ 186 +-----------+ 187 +-------+ |SID/MID/FSN| 188 |SID/MID| |-----------| 189 +-------+ | TSN | 190 +-----------+ 192 Figure 2: Round Robin Scheduler with User Message Interleaving 194 The support of the I-DATA chunk is negotiated during the association 195 setup using the Supported Extensions Parameter as defined in 196 [RFC5061]. If I-DATA support has been negotiated for an association 197 I-DATA chunks are used for all user-messages and no DATA chunks. It 198 should be noted, that an SCTP implementation needs to support the 199 coexistence of associations using DATA chunks and associations using 200 I-DATA chunks. 202 1.2. Conventions 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 2. User Message Interleaving 210 The interleaving of user messages is required for WebRTC Datachannels 211 as specified in [I-D.ietf-rtcweb-data-channel]. 213 2.1. The I-DATA Chunk supporting User Message Interleaving 215 The following Figure 3 shows the new I-DATA chunk allowing user 216 messages interleaving. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type = 64 | Res |I|U|B|E| Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | TSN | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Stream Identifier | Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Message Identifier | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Payload Protocol Identifier / Fragment Sequence Number | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 \ \ 232 / User Data / 233 \ \ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 3: I-DATA chunk format 238 The only differences between the I-DATA chunk in Figure 3 and the 239 DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the 240 new Message Identifier (MID) and Fragment Sequence Number (FSN) and 241 the removal of the Stream Sequence Number (SSN). The length of the 242 I-DATA chunk header is 20 bytes, which is 4 bytes more than the 243 length of the DATA chunk header defined in [RFC4960]. 245 The new fields are: 247 Reserved: 16 bits (unsigned integer) 248 This field is reserved. It MUST be set to 0 by the sender and 249 MUST be ignored by the receiver. 251 Message Identifier (MID): 32 bits (unsigned integer) 252 The MID is the same for all fragments of a user message, it is 253 used to determine which fragments (enumerated by the FSN) belong 254 to the same user message. For ordered user messages, the MID is 255 also used by the SCTP receiver to deliver the user messages in the 256 correct order to the upper layer (similar to the SSN of the DATA 257 chunk defined in [RFC4960]). The sender uses two counters for 258 each outgoing stream, one for ordered messages, one for unordered 259 messages. All counters are independent and initially 0. They are 260 incremented by 1 for each user message. Please note that the 261 serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 262 32 applies. Therefore the sender MUST NOT have more than 2**31 - 263 1 ordered messages for each outgoing stream in flight and MUST NOT 264 have more than 2**31 - 1 unordered messages for each outgoing 265 stream in flight. Please note that the MID is in "network byte 266 order", a.k.a. Big Endian. 268 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 269 32 bits (unsigned integer) 270 If the B bit is set, this field contains the PPID of the user 271 message. Note that in this case, this field is NOT touched by an 272 SCTP implementation; therefore, its byte order is not necessarily 273 in network byte order. The upper layer is responsible for any 274 byte order conversions to this field, similar to the PPID of DATA 275 chunks. In this case the FSN is implicitly considered to be 0. 276 If the B bit is not set, this field contains the FSN. The FSN is 277 used to enumerate all fragments of a single user message, starting 278 from 0 and incremented by 1. The last fragment of a message MUST 279 have the 'E' bit set. Note that the FSN MAY wrap completely 280 multiple times allowing arbitrary large user messages. For the 281 FSN the serial number arithmetic defined in [RFC1982] applies with 282 SERIAL_BITS = 32. Therefore a sender MUST NOT have more than 283 2**31 - 1 fragments of a single user message in flight. Please 284 note that the FSN is in "network byte order", a.k.a. Big Endian. 286 2.2. Procedures 288 This subsection describes how the support of the I-DATA chunk is 289 negotiated and how the I-DATA chunk is used by the sender and 290 receiver. 292 2.2.1. Negotiation 294 A sender MUST NOT send a I-DATA chunk unless both peers have 295 indicated its support of the I-DATA chunk type within the Supported 296 Extensions Parameter as defined in [RFC5061]. If I-DATA support has 297 been negotiated on an association, I-DATA chunks MUST be used for all 298 user messages and DATA-chunk MUST NOT be used. If I-DATA support has 299 not been negotiated on an association, DATA chunks MUST be used for 300 all user messages and I-DATA chunks MUST NOT be used. 302 A sender MUST NOT use the I-DATA chunk unless the user has requested 303 that use (e.g. via the socket API, see Section 4). This constraint 304 is made since usage of this chunk requires that the application be 305 willing to interleave messages upon reception within an association. 306 This is not the default choice within the socket API (see [RFC6458]) 307 thus the user MUST indicate support to the protocol of the reception 308 of completely interleaved messages. Note that for stacks that do not 309 implement [RFC6458] they may use other methods to indicate 310 interleaved message support and thus enable the usage of the I-DATA 311 chunk, the key is that the stack MUST know the application has 312 indicated its choice in wanting to use the extension. 314 2.2.2. Sender Side Considerations 316 Sender side usage of the I-DATA chunk is quite simple. Instead of 317 using the TSN for fragmentation purposes, the sender uses the new FSN 318 field to indicate which fragment number is being sent. The first 319 fragment MUST have the 'B' bit set. The last fragment MUST have the 320 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 321 set. All other properties of the existing SCTP DATA chunk also apply 322 to the I-DATA chunk, i.e. congestion control as well as receiver 323 window conditions MUST be observed as defined in [RFC4960]. 325 Note that the usage of this chunk implies the late assignment of the 326 actual TSN to any chunk being sent. Each I-DATA chunk uses a single 327 TSN. This way messages from other streams may be interleaved with 328 the fragmented message. Please note that this is the only form of 329 interleaving support. For example, it is not possible to interleave 330 multiple ordered or unordered user messages from the same stream. 332 The sender MUST NOT be fragmenting more than one user message in any 333 given stream at any time. At any time, a sender MAY fragment 334 multiple user message, each of them on different streams. 336 The sender MUST assign TSN's in a way that the receiver can make 337 progress. One way to achieve this is to assign the later fragments 338 of a user message a higher TSN and send out the TSNs in sequence. 340 2.2.3. Receiver Side Considerations 342 Upon reception of an SCTP packet containing a I-DATA chunk if the 343 message needs to be reassembled, then the receiver MUST use the FSN 344 for reassembly of the message and not the TSN. The receiver MUST NOT 345 make any assumption about the TSN assignments of the sender. Note 346 that a non-fragmented message is indicated by the fact that both the 347 'E' and 'B' bits are set. An ordered or unordered fragmented message 348 is thus identified by not having both bits set. 350 2.3. Interaction with other SCTP Extensions 352 The usage of the I-DATA chunk might interfere with other SCTP 353 extensions. Future SCTP extensions MUST describe if and how they 354 interfere with the usage of I-DATA chunks. For the SCTP extensions 355 already defined when this document was published, the details are 356 given in the following subsections. 358 2.3.1. SCTP Partial Reliability Extension 360 When the SCTP extension defined in [RFC3758] is used in combination 361 with the user message interleaving extension, the new I-FORWARD-TSN 362 chunk MUST be used instead of the FORWARD-TSN chunk. The difference 363 between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 364 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit 365 Message Identifier (MID) and the largest skipped MID can also be 366 provided for unordered messages. Therefore the principle applied to 367 ordered message when using FORWARD-TSN chunks is applied to ordered 368 and unordered messages when using I-FORWARD-TSN chunks. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type = 194 | Flags = 0x00 | Length = Variable | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | New Cumulative TSN | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Stream Identifier | Reserved |U| 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Message Identifier | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 \ \ 382 / / 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Stream Identifier | Reserved |U| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Message Identifier | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 4: I-FORWARD-TSN chunk format 391 The relevant new fields are: 393 Stream Identifier (SID): 16-bits (unsigned integer) 394 This field holds the stream number this entry refers to. 396 Reserved: 15 bits 397 This field is reserved. It MUST be set to 0 by the sender and 398 MUST be ignored by the receiver. 400 U bit: 1 bit 401 The U bit specifies if the Message Identifier of this entry refers 402 unordered messages (U bit is set) or ordered messages (U bit is 403 not set). 405 Message Identifier (MID): 32 bits (unsigned integer) 406 This field holds the largest Message Identifier for ordered or 407 unordered messages indicated by the U-bit that was skipped for the 408 stream specified by the Stream Identifier. For ordered messages 409 this is similar to the FORWARD-TSN chunk, just replacing the 410 16-bit SSN by the 32-bit MID. 412 The FORWARD-TSN chunk MUST be used in combination with the DATA chunk 413 and MUST NOT be used in combination with the I-DATA chunk. The I- 414 FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk 415 and MUST NOT be used in combination with the DATA chunk. 417 Support for the I-FORWARD-TSN chunk is negotiated during the SCTP 418 association setup via the Supported Extensions Parameter as defined 419 in [RFC5061]. Only if both end points support the I-DATA chunk and 420 the I-FORWARD-TSN chunk, the partial reliability extension can be 421 used in combination with user message interleaving. 423 2.3.2. SCTP Stream Reconfiguration Extension 425 When an association resets the SSN using the SCTP extension defined 426 in [RFC6525], the two counters (one for the ordered messages, one for 427 the unordered messages) used for the MID MUST be reset to 0 428 correspondingly. 430 Since most schedulers, especially all schedulers when supporting user 431 message interleaving, require late TSN assignment, it should be noted 432 that the implementation of [RFC6525] needs to handle this. 434 3. Stream Schedulers 436 This section defines several stream schedulers. The streams 437 schedulers may behave differently depending on whether user message 438 interleaving has been negotiated for the association or not. The set 439 of schedulers being implemented is implementation dependent. 441 3.1. First Come First Serve (SCTP_SS_FCFS) 443 The simple first-come, first-serve scheduler of user messages is 444 used. It just passes through the messages in the order in which they 445 have been delivered by the application. No modification of the order 446 is done at all. The usage of user message interleaving does not 447 affect the sending of the chunks, except that I-DATA chunks are used 448 instead of DATA chunks. 450 3.2. Round Robin Scheduler (SCTP_SS_RR) 452 When not using user message interleaving, this scheduler provides a 453 fair scheduling based on the number of user messages by cycling 454 around non-empty stream queues. When using user message 455 interleaving, this scheduler provides a fair scheduling based on the 456 number of I-DATA chunks by cycling around non-empty stream queues. 458 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) 460 This is a round-robin scheduler but bundles only DATA or I-DATA 461 chunks referring to the same stream in a packet. This minimizes 462 head-of-line blocking when a packet is lost because only a single 463 stream is affected. 465 3.4. Priority Based Scheduler (SCTP_SS_PRIO) 467 Scheduling of user messages with strict priorities is used. The 468 priority is configurable per outgoing SCTP stream. Streams having a 469 higher priority will be scheduled first and when multiple streams 470 have the same priority, the scheduling between them is implementation 471 specific. When using user message interleaving, the sending of lower 472 priority user messages will not block the sending of higher priority 473 user messages. 475 3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) 477 A fair bandwidth distribution between the streams is used. This 478 scheduler considers the lengths of the messages of each stream and 479 schedules them in a certain way to maintain an equal bandwidth for 480 all streams. The details are implementation specific. Using user 481 message interleaving allows for a better realization of the fair 482 bandwidth usage. 484 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 486 A weighted fair queueing scheduler between the streams is used. The 487 weight is configurable per outgoing SCTP stream. This scheduler 488 considers the lengths of the messages of each stream and schedules 489 them in a certain way to use the bandwidth according to the given 490 weights. The details are implementation specific. Using user 491 message interleaving allows for a better realization of the bandwidth 492 usage according to the given weights. 494 This scheduler in combination with user message interleaving is used 495 for WebRTC Datachannels as specified in 496 [I-D.ietf-rtcweb-data-channel]. 498 4. Socket API Considerations 500 This section describes how the socket API defined in [RFC6458] is 501 extended to allow applications to use the extension described in this 502 document. 504 Please note that this section is informational only. 506 4.1. Exposition of the Stream Sequence Number (SSN) 508 The socket API defined in [RFC6458] defines several structures in 509 which the SSN of a received user message is exposed to the 510 application. The list of these structures includes: 512 struct sctp_sndrcvinfo 513 Specified in Section 5.3.2 of [RFC6458] and being deprecated. 515 struct sctp_extrcvinfo 516 Specified in Section 5.3.3 of [RFC6458] and being deprecated. 518 struct sctp_rcvinfo 519 Specified in Section 5.3.5 of [RFC6458]. 521 If user message interleaving is used, the lower order 16 bits of the 522 MID are used as the SSN when filling out these structures. 524 4.2. SCTP_ASSOC_CHANGE Notification 526 When an SCTP_ASSOC_CHANGE notification is delivered indicating a 527 sac_state of SCTP_COMM_UP or SCTP_RESTART for an SCTP association 528 where both peers support the I-DATA chunk, 529 SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in the sac_info 530 field. 532 4.3. Socket Options 534 +-----------------------------+-------------------------+-----+-----+ 535 | option name | data type | get | set | 536 +-----------------------------+-------------------------+-----+-----+ 537 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 538 | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | 539 | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | 540 | | sctp_stream_value | | | 541 +-----------------------------+-------------------------+-----+-----+ 543 4.3.1. Enable or Disable the Support of User Message Interleaving 544 (SCTP_INTERLEAVING_SUPPORTED) 546 This socket option allows the enabling or disabling of the 547 negotiation of user message interleaving support for future 548 associations. For existing associations it allows to query whether 549 user message interleaving support was negotiated or not on a 550 particular association. 552 User message interleaving is disabled per default. 554 This socket option uses IPPROTO_SCTP as its level and 555 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 556 getsockopt() and setsockopt(). The socket option value uses the 557 following structure defined in [RFC6458]: 559 struct sctp_assoc_value { 560 sctp_assoc_t assoc_id; 561 uint32_t assoc_value; 562 }; 564 assoc_id: This parameter is ignored for one-to-one style sockets. 565 For one-to-many style sockets, this parameter indicates upon which 566 association the user is performing an action. The special 567 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 568 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 570 assoc_value: A non-zero value encodes the enabling of user message 571 interleaving whereas a value of 0 encodes the disabling of user 572 message interleaving. 574 sctp_opt_info() needs to be extended to support 575 SCTP_INTERLEAVING_SUPPORTED. 577 An application using user message interleaving should also set the 578 fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE 579 socket option specified in Section 8.1.20 of [RFC6458]. This allows 580 the interleaving of user messages from different streams. Please 581 note that it does not allow the interleaving of ordered and unordered 582 user messages on the same stream. Failure to set this option can 583 possibly lead to application deadlock. Some implementations might 584 therefore put some restrictions on setting combinations of these 585 values. 587 4.3.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) 589 A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER 590 option for setsockopt(). The struct sctp_assoc_value is used to 591 specify the association for which the scheduler should be changed and 592 the value of the desired algorithm. 594 The definition of struct sctp_assoc_value is the same as in 595 [RFC6458]: 597 struct sctp_assoc_value { 598 sctp_assoc_t assoc_id; 599 uint32_t assoc_value; 600 }; 602 assoc_id: Holds the identifier for the association of which the 603 scheduler should be changed. The special 604 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 605 is ignored for one-to-one style sockets. 607 assoc_value: This specifies which scheduler is used. The following 608 constants can be used: 610 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 611 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 613 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1. 615 SCTP_SS_RR: Use the scheduler specified in Section 3.2. 617 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3. 619 SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The 620 priority can be assigned with the sctp_stream_value struct. 621 The higher the assigned value, the lower the priority, that is 622 the default value 0 is the highest priority and therefore the 623 default scheduling will be used if no priorities have been 624 assigned. 626 SCTP_SS_FB: Use the scheduler specified in Section 3.5. 628 SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The 629 weight can be assigned with the sctp_stream_value struct. 631 4.3.3. Get or Set the Stream Scheduler Parameter 632 (SCTP_STREAM_SCHEDULER_VALUE) 634 Some schedulers require additional information to be set for 635 individual streams as shown in the following table: 637 +-----------------+-----------------+ 638 | name | per stream info | 639 +-----------------+-----------------+ 640 | SCTP_SS_DEFAULT | n/a | 641 | SCTP_SS_FCFS | no | 642 | SCTP_SS_RR | no | 643 | SCTP_SS_RR_PKT | no | 644 | SCTP_SS_PRIO | yes | 645 | SCTP_SS_FB | no | 646 | SCTP_SS_WFQ | yes | 647 +-----------------+-----------------+ 649 This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the 650 corresponding struct sctp_stream_value. The definition of struct 651 sctp_stream_value is as follows: 653 struct sctp_stream_value { 654 sctp_assoc_t assoc_id; 655 uint16_t stream_id; 656 uint16_t stream_value; 657 }; 659 assoc_id: Holds the identifier for the association of which the 660 scheduler should be changed. The special 661 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 662 is ignored for one-to-one style sockets. 664 stream_id: Holds the stream id for the stream for which additional 665 information has to be provided. 667 stream_value: The meaning of this field depends on the scheduler 668 specified. It is ignored when the scheduler does not need 669 additional information. 671 4.4. Explicit EOR Marking 673 Using explicit EOR marking for an SCTP association supporting user 674 message interleaving allows the user to interleave the sending of 675 user messages on different streams. 677 5. IANA Considerations 679 [NOTE to RFC-Editor: 681 "RFCXXXX" is to be replaced by the RFC number you assign this 682 document. 684 ] 686 [NOTE to RFC-Editor: 688 The suggested values for the chunk type and the chunk flags are 689 tentative and to be confirmed by IANA. 691 ] 693 This document (RFCXXXX) is the reference for all registrations 694 described in this section. 696 A new chunk type has to be assigned by IANA. IANA should assign this 697 value from the pool of chunks with the upper two bits set to '01'. 698 This requires an additional line in the "Chunk Types" registry for 699 SCTP: 701 +----------+-------------------------+-----------+ 702 | ID Value | Chunk Type | Reference | 703 +----------+-------------------------+-----------+ 704 | 64 | New DATA chunk (I-DATA) | [RFCXXXX] | 705 +----------+-------------------------+-----------+ 707 The registration table as defined in [RFC6096] for the chunk flags of 708 this chunk type is initially given by the following table: 710 +------------------+-----------------+-----------+ 711 | Chunk Flag Value | Chunk Flag Name | Reference | 712 +------------------+-----------------+-----------+ 713 | 0x01 | E bit | [RFCXXXX] | 714 | 0x02 | B bit | [RFCXXXX] | 715 | 0x04 | U bit | [RFCXXXX] | 716 | 0x08 | I bit | [RFCXXXX] | 717 | 0x10 | Unassigned | | 718 | 0x20 | Unassigned | | 719 | 0x40 | Unassigned | | 720 | 0x80 | Unassigned | | 721 +------------------+-----------------+-----------+ 723 6. Security Considerations 725 This document does not add any additional security considerations in 726 addition to the ones given in [RFC4960] and [RFC6458]. 728 7. Acknowledgments 730 The authors wish to thank Christer Holmberg, Marcelo Ricardo Leitner, 731 Karen E. Egede Nielsen, Irene Ruengeler, Felix Weinrank, and Lixia 732 Zhang for her invaluable comments. 734 This work has received funding from the European Union's Horizon 2020 735 research and innovation programme under grant agreement No. 644334 736 (NEAT). The views expressed are solely those of the author(s). 738 8. References 740 8.1. Normative References 742 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 743 DOI 10.17487/RFC1982, August 1996, 744 . 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, 748 DOI 10.17487/RFC2119, March 1997, 749 . 751 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 752 Conrad, "Stream Control Transmission Protocol (SCTP) 753 Partial Reliability Extension", RFC 3758, 754 DOI 10.17487/RFC3758, May 2004, 755 . 757 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 758 RFC 4960, DOI 10.17487/RFC4960, September 2007, 759 . 761 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 762 Kozuka, "Stream Control Transmission Protocol (SCTP) 763 Dynamic Address Reconfiguration", RFC 5061, 764 DOI 10.17487/RFC5061, September 2007, 765 . 767 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 768 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 769 DOI 10.17487/RFC6096, January 2011, 770 . 772 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 773 Transmission Protocol (SCTP) Stream Reconfiguration", 774 RFC 6525, DOI 10.17487/RFC6525, February 2012, 775 . 777 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 778 IMMEDIATELY Extension for the Stream Control Transmission 779 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 780 . 782 8.2. Informative References 784 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 785 A., Peterson, J., Sparks, R., Handley, M., and E. 786 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 787 DOI 10.17487/RFC3261, June 2002, 788 . 790 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 791 Yasevich, "Sockets API Extensions for the Stream Control 792 Transmission Protocol (SCTP)", RFC 6458, 793 DOI 10.17487/RFC6458, December 2011, 794 . 796 [I-D.ietf-rtcweb-data-channel] 797 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 798 Channels", draft-ietf-rtcweb-data-channel-13 (work in 799 progress), January 2015. 801 Authors' Addresses 803 Randall R. Stewart 804 Netflix, Inc. 805 Chapin, SC 29036 806 United States 808 Email: randall@lakerest.net 810 Michael Tuexen 811 Muenster University of Applied Sciences 812 Stegerwaldstrasse 39 813 48565 Steinfurt 814 Germany 816 Email: tuexen@fh-muenster.de 817 Salvatore Loreto 818 Ericsson 819 Hirsalantie 11 820 Jorvas 02420 821 Finland 823 Email: Salvatore.Loreto@ericsson.com 825 Robin Seggelmann 826 Metafinanz Informationssysteme GmbH 827 Leopoldstrasse 146 828 80804 Muenchen 829 Germany 831 Email: rfc@robin-seggelmann.com