idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-05.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 21, 2016) is 2956 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 690, 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 22, 2016 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 March 21, 2016 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-05.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 September 22, 2016. 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 . . . . . . . . . . . . . 7 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 . . . . . . . . . 8 74 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 9 75 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1. Stream Scheduler without User Message Interleaving 77 Support . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.1.1. First Come First Serve (SCTP_SS_FCFS) . . . . . . . . 9 79 3.1.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . 10 80 3.1.3. Round Robin Scheduler per Packet(SCTP_SS_RR_PKT) . . 10 81 3.1.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . 10 82 3.1.5. Fair Bandwidth Scheduler (SCTP_SS_FB) . . . . . . . . 10 83 3.1.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . 10 84 3.2. Stream Scheduler with User Message Interleaving Support . 10 85 3.2.1. Round Robin Scheduler (SCTP_SS_RR_INTER) . . . . . . 10 86 3.2.2. Round Robin Scheduler per Packet 87 (SCTP_SS_RR_PKT_INTER) . . . . . . . . . . . . . . . 10 88 3.2.3. Priority Based Scheduler (SCTP_SS_PRIO_INTER) . . . . 11 89 3.2.4. Fair Bandwidth Scheduler (SCTP_SS_FB_INTER) . . . . . 11 90 3.2.5. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ_INTER) 11 91 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 11 92 4.1. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 11 93 4.2. Socket Options . . . . . . . . . . . . . . . . . . . . . 11 94 4.2.1. Enable or Disable the Support of User Message 95 Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 12 96 4.2.2. Get or Set the Stream Scheduler 97 (SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 12 98 4.2.3. Get or Set the Stream Scheduler Parameter 99 (SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 14 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 105 8.2. Informative References . . . . . . . . . . . . . . . . . 17 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 1.1. Overview 112 When SCTP [RFC4960] was initially designed it was mainly envisioned 113 for the transport of small signaling messages. Late in the design 114 stage it was decided to add support for fragmentation and reassembly 115 of larger messages with the thought that someday Session Initiation 116 Protocol (SIP) [RFC3261] style signaling messages may also need to 117 use SCTP and a single MTU sized message would be too small. 118 Unfortunately this design decision, though valid at the time, did not 119 account for other applications which might send very large messages 120 over SCTP. When such large messages are now sent over SCTP a form of 121 sender side head of line blocking becomes created within the 122 protocol. This head of line blocking is caused by the use of the 123 Transmission Sequence Number (TSN) for three different purposes: 125 1. As an identifier for DATA chunks to provide a reliable transfer. 127 2. As an identifier for the sequence of fragments to allow 128 reassembly. 130 3. As a sequence number allowing to have up to 2**16 - 1 SSNs 131 outstanding. 133 The protocol requires all fragments of a user message to have 134 consecutive TSNs. Therefore it is impossible for the sender to 135 interleave different user messages. 137 This document also defines several stream schedulers for general SCTP 138 associations. If support for user message interleaving has been 139 negotiated, several more schedulers are available. 141 The following Figure 1 illustrates the behaviour of a round robin 142 stream scheduler using DATA chunks. Please note that the use of such 143 an 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 Data chunk called I-DATA. This chunk 167 incorporates all the flags and fields except the Stream Sequence 168 Number (SSN) and properties of the current SCTP Data chunk but also 169 adds two new fields in its chunk header, the Fragment Sequence Number 170 (FSN) and the Message Identifier (MID). Then the FSN is only used 171 for reassembling all fragments having the same MID and ordering 172 property. The TSN is only for the reliable transfer in combination 173 with SACK chunks. 175 The MID is also used for ensuring ordered delivery, therefore 176 replacing the stream sequence number. Therefore, the head of line 177 blocking caused by the original design is avoided. 179 The following Figure 2 illustrates the behaviour of an interleaving 180 round robin 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 and no DATA chunks. It 205 should be noted, that an SCTP implementation needs to support the 206 coexistence of associations using DATA chunks and associations using 207 I-DATA chunks. 209 1.2. Conventions 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 2. User Message Interleaving 217 The interleaving of user messages is required for WebRTC Datachannels 218 as specified in [I-D.ietf-rtcweb-data-channel]. 220 2.1. The I-DATA Chunk supporting User Message Interleaving 222 The following Figure 3 shows the new I-DATA chunk allowing user 223 messages interleaving. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type = 64 | Res |I|U|B|E| Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | TSN | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Stream Identifier | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Message Identifier | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Payload Protocol Identifier / Fragment Sequence Number | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 \ \ 239 / User Data / 240 \ \ 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 3: I-DATA chunk format 245 The only differences between the I-DATA chunk in Figure 3 and the 246 DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the 247 new Message Identifier (MID) and Fragment Sequence Number (FSN) and 248 the removal of the Stream Sequence Number (SSN). However, the lower 249 16-bit of the MID can be used as the SSN if necessary. The length of 250 the I-DATA chunk header is 20 bytes, which is 4 bytes more than the 251 length of the DATA chunk header defined in [RFC4960]. 253 Reserved: 16 bits (unsigned integer) 254 This field is reserved. It MUST be set to 0 by the sender and 255 MUST be ignored by the receiver. 257 Message Identifier (MID): 32 bits (unsigned integer) 258 The MID is the same for all fragments of a user message, it is 259 used to determine which fragments (enumerated by the FSN) belong 260 to the same user message. For ordered user messages, the MID is 261 also used by the SCTP receiver to deliver the user messages in the 262 correct order to the upper layer (similar to the SSN of the DATA 263 chunk defined in [RFC4960]). The sender uses two counters for 264 each outgoing streams, one for ordered messages, one for unordered 265 messages. All counters are independent and initially 0. They are 266 incremented by 1 for each user message. Please note that the 267 serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 268 32 applies. Therefore the sender MUST NOT have more than 2**31 - 269 1 ordered messages for each outgoing stream in flight and MUST NOT 270 have more than 2**31 - 1 unordered messages for each outgoing 271 stream in flight. Please note that the MID is in "network byte 272 order", a.k.a. Big Endian. 274 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 275 32 bits (unsigned integer) 276 If the B bit is set, this field contains the PPID of the user 277 message. In this case the FSN is implicitly considered to be 0. 278 If the B bit is not set, this field contains the FSN. The FSN is 279 used to enumerate all fragments of a single user message, starting 280 from 0 and incremented by 1. The last fragment of a message MUST 281 have the 'E' bit set. Note that the FSN MAY wrap completely 282 multiple times allowing arbitrary large user messages. For the 283 FSN the serial number arithmetic defined in [RFC1982] applies with 284 SERIAL_BITS = 32. Therefore a sender MUST NOT have more than 285 2**31 - 1 fragments of a single user message in flight. Please 286 note that the FSN is in "network byte order", a.k.a. Big Endian. 288 2.2. Procedures 290 This subsection describes how the support of the I-DATA chunk is 291 negotiated and how the I-DATA chunk is used by the sender and 292 receiver. 294 2.2.1. Negotiation 296 A sender MUST NOT send a I-DATA chunk unless both peers have 297 indicated its support of the I-DATA chunk type within the Supported 298 Extensions Parameter as defined in [RFC5061]. If I-DATA support has 299 been negotiated on an association, I-DATA chunks MUST be used for all 300 user messages and DATA-chunk MUST NOT be used. If I-DATA support has 301 not been negotiated on an association, DATA chunks MUST be used for 302 all user messages and I-DATA chunks MUST NOT be used. 304 A sender MUST NOT use the I-DATA chunk unless the user has requested 305 that use (e.g. via the socket API, see Section 4). This constraint 306 is made since usage of this chunk requires that the application be 307 willing to interleave messages upon reception within an association. 308 This is not the default choice within the socket API (see [RFC6458]) 309 thus the user MUST indicate support to the protocol of the reception 310 of completely interleaved messages. Note that for stacks that do not 311 implement [RFC6458] they may use other methods to indicate 312 interleaved message support and thus enable the usage of the I-DATA 313 chunk, the key is that the the stack MUST know the application has 314 indicated its choice in wanting to use the extension. 316 2.2.2. Sender Side Considerations 318 Sender side usage of the I-DATA chunk is quite simple. Instead of 319 using the TSN for fragmentation purposes, the sender uses the new FSN 320 field to indicate which fragment number is being sent. The first 321 fragment MUST have the 'B' bit set. The last fragment MUST have the 322 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 323 set. All other properties of the existing SCTP DATA chunk also apply 324 to the I-DATA chunk, i.e. congestion control as well as receiver 325 window conditions MUST be observed as defined in [RFC4960]. 327 Note that the usage of this chunk implies the late assignment of the 328 actual TSN to any chunk being sent. Each I-DATA chunk uses a single 329 TSN. This way messages from other streams may be interleaved with 330 the fragmented message. Please note that this is the only form of 331 interleaving support. For example, it is not possible to interleave 332 multiple ordered or unordered user messages from the same stream. 334 The sender MUST NOT be fragmenting more than one ordered message in 335 any one stream at any time. The sender MUST NOT be fragmenting more 336 than one un-ordered user message in any one stream at any time. The 337 sender MAY fragment one ordered and one unordered user message within 338 a single stream. At any time a sender MAY fragment an ordered and an 339 unordered user message each off them on different streams. 341 2.2.3. Receiver Side Considerations 343 Upon reception of an SCTP packet containing a I-DATA chunk if the 344 message needs to be reassembled, then the receiver MUST use the FSN 345 for reassembly of the message and not the TSN. Note that a non- 346 fragmented messages is indicated by the fact that both the 'E' and 347 'B' bits are set. An ordered or unordered fragmented message is thus 348 identified with any message 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, the the I- 361 FORWARD-TSN chunk MUST be used instead of the FORWARD-TSN chunk. The 362 only difference is that the 16-bit Stream Sequence Number (SSN) has 363 been replaced by the 32-bit Message Identifier (MID). 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type = 194 | Flags = 0x00 | Length = Variable | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | New Cumulative TSN | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Stream 1 | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Message Identifier 1 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 \ \ 377 / / 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Stream N | Reserved | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Message Identifier N | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 4: I-FORWARD-TSN chunk format 386 2.3.2. SCTP Stream Reconfiguration Extension 388 When an association resets the SSN using the SCTP extension defined 389 in [RFC6525], the two counters (one for the ordered messages, one for 390 the unordered messages) used for the MID MUST be reset to 0 391 correspondingly. 393 Since most schedulers require late TSN assignment, it should be noted 394 that the implementation of [RFC6525] needs to handle this. 396 3. Stream Schedulers 398 This section defines several stream schedulers. The stream 399 schedulers which can be used even without the user message 400 interleaving support as defined in Section 2 are described in 401 Section 3.1. In Section 3.2 stream schedulers requiring user message 402 interleaving defined in Section 2 are described. 404 3.1. Stream Scheduler without User Message Interleaving Support 406 3.1.1. First Come First Serve (SCTP_SS_FCFS) 408 The simple first-come, first-serve scheduler of user messages is 409 used. It just passes through the messages in the order in which they 410 have been delivered by the application. No modification of the order 411 is done at all. 413 3.1.2. Round Robin Scheduler (SCTP_SS_RR) 415 This scheduler provides a fair scheduling based on the number of user 416 messages by cycling around non-empty stream queues. 418 3.1.3. Round Robin Scheduler per Packet(SCTP_SS_RR_PKT) 420 This is a round-robin scheduler but only bundles user messages of the 421 same stream in one packet. This minimizes head-of-line blocking when 422 a packet is lost because only a single stream is affected. 424 3.1.4. Priority Based Scheduler (SCTP_SS_PRIO) 426 Scheduling of user messages with strict priorities is used. The 427 priority is configurable per outgoing SCTP stream. Streams having a 428 higher priority will be scheduled first and when multiple streams 429 have the same priority, the default scheduling should be used for 430 them. 432 3.1.5. Fair Bandwidth Scheduler (SCTP_SS_FB) 434 A fair bandwidth distribution between the streams is used. This 435 scheduler considers the lengths of the messages of each stream and 436 schedules them in a certain way to maintain an equal bandwidth for 437 all streams. The details are implementation specific. 439 3.1.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 441 A weighted fair queueing scheduler between the streams is used. The 442 weight is configurable per outgoing SCTP stream. This scheduler 443 considers the lengths of the messages of each stream and schedules 444 them in a certain way to use the bandwidth according to the given 445 weights. The details are implementation specific. 447 3.2. Stream Scheduler with User Message Interleaving Support 449 3.2.1. Round Robin Scheduler (SCTP_SS_RR_INTER) 451 This scheduler is similar to the one described in Section 3.1.2, but 452 based on I-DATA chunks instead of user messages. 454 3.2.2. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT_INTER) 456 This scheduler is similar to the one described in Section 3.1.3, but 457 based on I-DATA chunks instead of user messages. 459 3.2.3. Priority Based Scheduler (SCTP_SS_PRIO_INTER) 461 This scheduler is similar to the one described in Section 3.1.4, but 462 based on I-DATA chunks instead of user messages. 464 3.2.4. Fair Bandwidth Scheduler (SCTP_SS_FB_INTER) 466 This scheduler is similar to the one described in Section 3.1.5, but 467 based on I-DATA chunks instead of user messages. 469 3.2.5. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ_INTER) 471 This scheduler is similar to the one described in Section 3.1.6, but 472 based on I-DATA chunks instead of user messages. This scheduler is 473 used for WebRTC Datachannels as specified in 474 [I-D.ietf-rtcweb-data-channel]. 476 4. Socket API Considerations 478 This section describes how the socket API defined in [RFC6458] is 479 extended to allow applications to use the extension described in this 480 document. 482 Please note that this section is informational only. 484 4.1. SCTP_ASSOC_CHANGE Notification 486 When an SCTP_ASSOC_CHANGE notification is delivered indicating a 487 sac_state of SCTP_COMM_UP or SCTP_RESTART for an SCTP association 488 where both peers support the I-DATA chunk, 489 SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listen in the sac_info 490 field. 492 4.2. Socket Options 494 +-----------------------------+-------------------------+-----+-----+ 495 | option name | data type | get | set | 496 +-----------------------------+-------------------------+-----+-----+ 497 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 498 | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | 499 | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | 500 | | sctp_stream_value | | | 501 +-----------------------------+-------------------------+-----+-----+ 503 4.2.1. Enable or Disable the Support of User Message Interleaving 504 (SCTP_INTERLEAVING_SUPPORTED) 506 This socket option allows the enabling or disabling of the 507 negotiation of user message interleaving support for future 508 associations. For existing associations it allows to query whether 509 user message interleaving support was negotiated or not on a 510 particular association. 512 User message interleaving is disabled per default. 514 This socket option uses IPPROTO_SCTP as its level and 515 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 516 getsockopt() and setsockopt(). The socket option value uses the 517 following structure defined in [RFC6458]: 519 struct sctp_assoc_value { 520 sctp_assoc_t assoc_id; 521 uint32_t assoc_value; 522 }; 524 assoc_id: This parameter is ignored for one-to-one style sockets. 525 For one-to-many style sockets, this parameter indicates upon which 526 association the user is performing an action. The special 527 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 528 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 530 assoc_value: A non-zero value encodes the enabling of user message 531 interleaving whereas a value of 0 encodes the disabling of user 532 message interleaving. 534 sctp_opt_info() needs to be extended to support 535 SCTP_INTERLEAVING_SUPPORTED. 537 An application using user message interleaving should also set the 538 fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE 539 socket option specified in Section 8.1.20 of [RFC6458]. This allows 540 the reception from multiple streams simultaneously. Failure to set 541 this option can possibly lead to application deadlock. Some 542 implementations might therefore put some restrictions on setting 543 combinations of these values. 545 4.2.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) 547 A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER 548 option for setsockopt(). The struct sctp_assoc_value is used to 549 specify the association for which the scheduler should be changed and 550 the value of the desired algorithm. 552 The definition of struct sctp_assoc_value is the same as in 553 [RFC6458]: 555 struct sctp_assoc_value { 556 sctp_assoc_t assoc_id; 557 uint32_t assoc_value; 558 }; 560 assoc_id: Holds the identifier for the association of which the 561 scheduler should be changed. The special 562 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 563 is ignored for one-to-one style sockets. 565 assoc_value: This specifies which scheduler is used. The following 566 constants can be used: 568 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 569 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 571 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1.1. 573 SCTP_SS_RR: Use the scheduler specified in Section 3.1.2. 575 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.1.3. 577 SCTP_SS_PRIO: Use the scheduler specified in Section 3.1.4. The 578 priority can be assigned with the sctp_stream_value struct. 579 The higher the assigned value, the lower the priority, that is 580 the default value 0 is the highest priority and therefore the 581 default scheduling will be used if no priorities have been 582 assigned. 584 SCTP_SS_FB: Use the scheduler specified in Section 3.1.5. 586 SCTP_SS_WFQ: Use the scheduler specified in Section 3.1.6. The 587 weight can be assigned with the sctp_stream_value struct. 589 SCTP_SS_RR_INTER: Use the scheduler specified in Section 3.2.1. 591 SCTP_SS_RR_PKT_INTER: Use the scheduler specified in 592 Section 3.2.2. 594 SCTP_SS_PRIO_INTER: Use the scheduler specified in Section 3.2.3. 595 The priority can be assigned with the sctp_stream_value struct. 596 The higher the assigned value, the lower the priority, that is 597 the default value 0 is the highest priority and therefore the 598 default scheduling will be used if no priorities have been 599 assigned. 601 SCTP_SS_FB_INTER: Use the scheduler specified in Section 3.2.4. 603 SCTP_SS_WFQ_INTER: Use the scheduler specified in Section 3.2.5. 604 The weight can be assigned with the sctp_stream_value struct. 606 4.2.3. Get or Set the Stream Scheduler Parameter 607 (SCTP_STREAM_SCHEDULER_VALUE) 609 Some schedulers require additional information to be set for single 610 streams as shown in the following table: 612 +----------------------+-----------------+ 613 | name | per stream info | 614 +----------------------+-----------------+ 615 | SCTP_SS_DEFAULT | n/a | 616 | SCTP_SS_FCFS | no | 617 | SCTP_SS_RR | no | 618 | SCTP_SS_RR_PKT | no | 619 | SCTP_SS_PRIO | yes | 620 | SCTP_SS_FB | no | 621 | SCTP_SS_WFQ | yes | 622 | SCTP_SS_RR_INTER | no | 623 | SCTP_SS_RR_PKT_INTER | no | 624 | SCTP_SS_PRIO_INTER | yes | 625 | SCTP_SS_FB_INTER | no | 626 | SCTP_SS_WFQ_INTER | yes | 627 +----------------------+-----------------+ 629 This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the 630 corresponding struct sctp_stream_value. The definition of struct 631 sctp_stream_value is as follows: 633 struct sctp_stream_value { 634 sctp_assoc_t assoc_id; 635 uint16_t stream_id; 636 uint16_t stream_value; 637 }; 639 assoc_id: Holds the identifier for the association of which the 640 scheduler should be changed. The special 641 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 642 is ignored for one-to-one style sockets. 644 stream_id: Holds the stream id for the stream for which additional 645 information has to be provided. 647 stream_value: The meaning of this field depends on the scheduler 648 specified. It is ignored when the scheduler does not need 649 additional information. 651 5. IANA Considerations 653 [NOTE to RFC-Editor: 655 "RFCXXXX" is to be replaced by the RFC number you assign this 656 document. 658 ] 660 [NOTE to RFC-Editor: 662 The suggested values for the chunk type and the chunk flags are 663 tentative and to be confirmed by IANA. 665 ] 667 This document (RFCXXXX) is the reference for all registrations 668 described in this section. 670 A new chunk type has to be assigned by IANA. IANA should assign this 671 value from the pool of chunks with the upper two bits set to '01'. 672 This requires an additional line in the "Chunk Types" registry for 673 SCTP: 675 +----------+-------------------------+-----------+ 676 | ID Value | Chunk Type | Reference | 677 +----------+-------------------------+-----------+ 678 | 64 | New DATA chunk (I-DATA) | [RFCXXXX] | 679 +----------+-------------------------+-----------+ 681 The registration table as defined in [RFC6096] for the chunk flags of 682 this chunk type is initially given by the following table: 684 +------------------+-----------------+-----------+ 685 | Chunk Flag Value | Chunk Flag Name | Reference | 686 +------------------+-----------------+-----------+ 687 | 0x01 | E bit | [RFCXXXX] | 688 | 0x02 | B bit | [RFCXXXX] | 689 | 0x04 | U bit | [RFCXXXX] | 690 | 0x08 | I bit | [RFCXXXX] | 691 | 0x10 | Unassigned | | 692 | 0x20 | Unassigned | | 693 | 0x40 | Unassigned | | 694 | 0x80 | Unassigned | | 695 +------------------+-----------------+-----------+ 697 6. Security Considerations 699 This document does not add any additional security considerations in 700 addition to the ones given in [RFC4960] and [RFC6458]. 702 7. Acknowledgments 704 The authors wish to thank Christer Holmberg, Karen E. Egede Nielsen, 705 Irene Ruengeler, Felix Weinrank, and Lixia Zhang for her invaluable 706 comments. 708 This work has received funding from the European Union's Horizon 2020 709 research and innovation programme under grant agreement No. 644334 710 (NEAT). The views expressed are solely those of the author(s). 712 8. References 714 8.1. Normative References 716 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 717 DOI 10.17487/RFC1982, August 1996, 718 . 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 726 Conrad, "Stream Control Transmission Protocol (SCTP) 727 Partial Reliability Extension", RFC 3758, 728 DOI 10.17487/RFC3758, May 2004, 729 . 731 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 732 RFC 4960, DOI 10.17487/RFC4960, September 2007, 733 . 735 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 736 Kozuka, "Stream Control Transmission Protocol (SCTP) 737 Dynamic Address Reconfiguration", RFC 5061, 738 DOI 10.17487/RFC5061, September 2007, 739 . 741 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 742 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 743 DOI 10.17487/RFC6096, January 2011, 744 . 746 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 747 Transmission Protocol (SCTP) Stream Reconfiguration", 748 RFC 6525, DOI 10.17487/RFC6525, February 2012, 749 . 751 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 752 IMMEDIATELY Extension for the Stream Control Transmission 753 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 754 . 756 8.2. Informative References 758 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 759 A., Peterson, J., Sparks, R., Handley, M., and E. 760 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 761 DOI 10.17487/RFC3261, June 2002, 762 . 764 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 765 Yasevich, "Sockets API Extensions for the Stream Control 766 Transmission Protocol (SCTP)", RFC 6458, 767 DOI 10.17487/RFC6458, December 2011, 768 . 770 [I-D.ietf-rtcweb-data-channel] 771 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 772 Channels", draft-ietf-rtcweb-data-channel-13 (work in 773 progress), January 2015. 775 Authors' Addresses 777 Randall R. Stewart 778 Netflix, Inc. 779 Chapin, SC 29036 780 United States 782 Email: randall@lakerest.net 784 Michael Tuexen 785 Muenster University of Applied Sciences 786 Stegerwaldstrasse 39 787 48565 Steinfurt 788 Germany 790 Email: tuexen@fh-muenster.de 792 Salvatore Loreto 793 Ericsson 794 Hirsalantie 11 795 Jorvas 02420 796 Finland 798 Email: Salvatore.Loreto@ericsson.com 800 Robin Seggelmann 801 Metafinanz Informationssysteme GmbH 802 Leopoldstrasse 146 803 80804 Muenchen 804 Germany 806 Email: rfc@robin-seggelmann.com