idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 6, 2015) is 3211 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 626, 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 7, 2016 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 July 6, 2015 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-04.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 7, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. User Message Interleaving . . . . . . . . . . . . . . . . . . 4 67 2.1. The I-DATA Chunk supporting User Message Interleaving . . 4 68 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 6 70 2.2.2. Sender Side Considerations . . . . . . . . . . . . . 6 71 2.2.3. Receiver Side Considerations . . . . . . . . . . . . 7 72 2.3. Interaction with other SCTP Extensions . . . . . . . . . 7 73 2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 7 74 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 8 75 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 8 76 3.1. Stream Scheduler without User Message Interleaving 77 Support . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.1.1. First Come First Serve (SCTP_SS_FCFS) . . . . . . . . 8 79 3.1.2. User Message Based Round Robin Scheduler (SCTP_SS_RR) 9 80 3.1.3. Packet Based Round Robin Scheduler (SCTP_SS_RR_PKT) . 9 81 3.1.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . 9 82 3.1.5. Fair Bandwidth Scheduler (SCTP_SS_FB) . . . . . . . . 9 83 3.1.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . 9 84 3.2. Stream Scheduler with User Message Interleaving Support . 9 85 3.2.1. User Message Based Round Robin Scheduler 86 (SCTP_SS_RR_INTER) . . . . . . . . . . . . . . . . . 9 87 3.2.2. Packet Based Round Robin Scheduler 88 (SCTP_SS_RR_PKT_INTER) . . . . . . . . . . . . . . . 9 89 3.2.3. Priority Based Scheduler (SCTP_SS_PRIO_INTER) . . . . 10 90 3.2.4. Fair Bandwidth Scheduler (SCTP_SS_FB_INTER) . . . . . 10 91 3.2.5. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ_INTER) 10 92 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 10 93 4.1. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 10 94 4.2. Socket Options . . . . . . . . . . . . . . . . . . . . . 10 95 4.2.1. Enable or Disable the Support of User Message 96 Interleaving . . . . . . . . . . . . . . . . . . . . 11 97 4.2.2. Get or Set the Stream Scheduler (SCTP_PLUGGABLE_SS) . 11 98 4.2.3. Get or Set the Stream Scheduler Parameter 99 (SCTP_SS_VALUE) . . . . . . . . . . . . . . . . . . . 13 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 105 8.2. Informative References . . . . . . . . . . . . . . . . . 16 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 108 1. Introduction 110 1.1. Overview 112 When SCTP [RFC4960] was initially designed it was mainly envisioned 113 for transport of small signaling messages. Late in the design stage 114 it was decided to add support for fragmentation and reassembly of 115 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 two 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 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 describes a new Data chunk called I-DATA. This chunk 135 incorporates all the flags and fields except the Stream Sequence 136 Number (SSN) and properties of the current SCTP Data chunk but also 137 adds two new fields in its chunk header, the Fragment Sequence Number 138 (FSN) and the Message Identifier (MID). Then the FSN is only used 139 for reassembling all fragments with the same MID and the TSN only for 140 the reliability. The MID is also used for ensuring ordered delivery, 141 therefore replacing the stream sequence number. Therefore, the head 142 of line blocking caused by the original design is avoided. 144 The support of the I-DATA chunk is negotiated during the association 145 setup using the Supported Extensions Parameter as defined in 146 [RFC5061]. If I-DATA support has been negotiated for an association 147 I-DATA chunks are used for all user-messages and no DATA chunks. It 148 should be noted, that an SCTP implementation needs to support the 149 coexistence of associations using DATA chunks and associations using 150 I-DATA chunks. 152 This document also defines several stream schedulers for general SCTP 153 associations. If I-DATA support has been negotiated, several more 154 schedulers are available. 156 1.2. Conventions 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. User Message Interleaving 164 The interleaving of user messages is required for WebRTC Datachannels 165 as specified in [I-D.ietf-rtcweb-data-channel]. 167 2.1. The I-DATA Chunk supporting User Message Interleaving 169 The following Figure 1 shows the new I-DATA chunk allowing user 170 messages interleaving. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type = 64 | Res |I|U|B|E| Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | TSN | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Stream Identifier | Reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Message Identifier | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Payload Protocol Identifier / Fragment Sequence Number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 \ \ 186 / User Data / 187 \ \ 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: I-DATA chunk format 192 The only differences between the I-DATA chunk in Figure 1 and the 193 DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the 194 new Message Identifier (MID) and Fragment Sequence Number (FSN) and 195 the removal of the Stream Sequence Number (SSN). However, the lower 196 16-bit of the MID can be used as the SSN if necessary. The length of 197 the I-DATA chunk header is 20 bytes, which is 4 bytes more than the 198 length of the DATA chunk header defined in [RFC4960]. 200 Reserved: 16 bits (unsigned integer) 201 This field is reserved. It MUST be set to 0 by the sender and 202 MUST be ignored by the receiver. 204 Message Identifier (MID): 32 bits (unsigned integer) 205 The MID is the same for all fragments of a user message, it is 206 used to determine which fragments (enumerated by the FSN) belong 207 to the same user message. For ordered user messages, the MID is 208 also used by the SCTP receiver to deliver the user messages in the 209 correct order to the upper layer (similar to the SSN of the DATA 210 chunk defined in [RFC4960]). The sender uses two counters, one 211 for ordered messages, one for unordered messages, for each 212 outgoing streams. All counters are independent and initially 0. 213 They are incremented by 1 for each user message. Please note that 214 the serial number arithmetic defined in [RFC1982] using 215 SERIAL_BITS = 32 applies. Therefore the sender MUST NOT have more 216 than 2**31 - 1 ordered messages for each outgoing stream in flight 217 and MUST NOT have more than 2**31 - 1 unordered messages for each 218 outgoing stream in flight. Please note that the MID is in 219 "network byte order", a.k.a. Big Endian. 221 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 222 32 bits (unsigned integer) 223 If the B bit is set, this field contains the PPID of the user 224 message. In this case the FSN is implicitly considered to be 0. 225 If the B bit is not set, this field contains the FSN. The FSN is 226 used to enumerate all fragments of a single user message, starting 227 from 0 and incremented by 1. The last fragment of a message MUST 228 have the 'E' bit set. Note that the FSN MAY wrap completely 229 multiple times allowing arbitrary large user messages. For the 230 FSN the serial number arithmetic defined in [RFC1982] applies with 231 SERIAL_BITS = 32. Therefore a sender MUST NOT have more than 232 2**31 - 1 fragments of a single user message in flight. Please 233 note that the FSN is in "network byte order", a.k.a. Big Endian. 235 2.2. Procedures 237 This subsection describes how the support of the I-DATA chunk is 238 negotiated and how the I-DATA chunk is used by the sender and 239 receiver. 241 2.2.1. Negotiation 243 A sender MUST NOT send a I-DATA chunk unless both peers have 244 indicated its support of the I-DATA chunk type within the Supported 245 Extensions Parameter as defined in [RFC5061]. If I-DATA support has 246 been negotiated on an association, I-DATA chunks MUST be used for all 247 user messages and DATA-chunk MUST NOT be used. If I-DATA support has 248 not been negotiated on an association, DATA chunks MUST be used for 249 all user messages and I-DATA chunks MUST NOT be used. 251 A sender MUST NOT use the I-DATA chunk unless the user has requested 252 that use (e.g. via the socket API, see Section 4). This constraint 253 is made since usage of this chunk requires that the application be 254 willing to interleave messages upon reception within an association. 255 This is not the default choice within the socket API (see [RFC6458]) 256 thus the user MUST indicate support to the protocol of the reception 257 of completely interleaved messages. Note that for stacks that do not 258 implement [RFC6458] they may use other methods to indicate 259 interleaved message support and thus enable the usage of the I-DATA 260 chunk, the key is that the the stack MUST know the application has 261 indicated its choice in wanting to use the extension. 263 2.2.2. Sender Side Considerations 265 Sender side usage of the I-DATA chunk is quite simple. Instead of 266 using the TSN for fragmentation purposes, the sender uses the new FSN 267 field to indicate which fragment number is being sent. The first 268 fragment MUST have the 'B' bit set. The last fragment MUST have the 269 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 270 set. All other properties of the existing SCTP DATA chunk also apply 271 to the I-DATA chunk, i.e. congestion control as well as receiver 272 window conditions MUST be observed as defined in [RFC4960]. 274 Note that the usage of this chunk should also imply late binding of 275 the actual TSN to any chunk being sent. This way other messages from 276 other streams may be interleaved with the fragmented message. 278 The sender MUST NOT have more than one ordered fragmented message 279 being produced in any one stream. The sender MUST NOT have more than 280 one un-ordered fragmented message being produced in any one stream. 281 The sender MAY have one ordered and one unordered fragmented message 282 being produced within a single stream. At any time multiple streams 283 MAY be producing an ordered or unordered fragmented message. 285 2.2.3. Receiver Side Considerations 287 Upon reception of an SCTP packet containing a I-DATA chunk if the 288 message needs to be reassembled, then the receiver MUST use the FSN 289 for reassembly of the message and not the TSN. Note that a non- 290 fragmented messages is indicated by the fact that both the 'E' and 291 'B' bits are set. An ordered or unordered fragmented message is thus 292 identified with any message not having both bits set. 294 2.3. Interaction with other SCTP Extensions 296 The usage of the I-DATA chunk might interfere with other SCTP 297 extensions. Future SCTP extensions MUST describe if and how they 298 interfere with the usage of I-DATA chunks. For the SCTP extensions 299 already defined when this document was published, the details are 300 given in the following subsections. 302 2.3.1. SCTP Partial Reliability Extension 304 When the SCTP extension defined in [RFC3758] is used, the the I- 305 FORWARD-TSN chunk MUST be used instead of the FORWARD-TSN chunk. The 306 only difference is that the 16-bit Stream Sequence Number (SSN) has 307 been replaced by the 32-bit Message Identifier (MID). 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type = 194 | Flags = 0x00 | Length = Variable | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | New Cumulative TSN | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Stream 1 | Reserved | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Message Identifier 1 | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 \ \ 321 / / 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Stream N | Reserved | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Message Identifier N | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: I-FORWARD-TSN chunk format 330 2.3.2. SCTP Stream Reconfiguration Extension 332 When an association resets the SSN using the SCTP extension defined 333 in [RFC6525], the two counters (one for the ordered messages, one for 334 the unordered messages) used for the MID MUST be reset to 0 335 correspondingly. 337 3. Stream Schedulers 339 This section defines several stream schedulers. The stream 340 schedulers which can be used even without the user message 341 interleaving support as defined in Section 2 are described in 342 Section 3.1. In Section 3.2 stream schedulers requiring user message 343 interleaving defined in Section 2 are described. 345 3.1. Stream Scheduler without User Message Interleaving Support 347 3.1.1. First Come First Serve (SCTP_SS_FCFS) 349 The simple first-come, first-serve scheduler of user messages is 350 used. It just passes through the messages in the order in which they 351 have been delivered by the application. No modification of the order 352 is done at all. 354 3.1.2. User Message Based Round Robin Scheduler (SCTP_SS_RR) 356 This scheduler provides a fair scheduling based on the number of user 357 messages by cycling around non-empty stream queues. 359 3.1.3. Packet Based Round Robin Scheduler (SCTP_SS_RR_PKT) 361 This is a round-robin scheduler but only bundles user messages of the 362 same stream in one packet. This minimizes head-of-line blocking when 363 a packet is lost because only a single stream is affected. 365 3.1.4. Priority Based Scheduler (SCTP_SS_PRIO) 367 Scheduling of user messages with strict priorities is used. The 368 priority is configurable per outgoing SCTP stream. Streams having a 369 higher priority will be scheduled first and when multiple streams 370 have the same priority, the default scheduling should be used for 371 them. 373 3.1.5. Fair Bandwidth Scheduler (SCTP_SS_FB) 375 A fair bandwidth distribution between the streams is used. This 376 scheduler considers the lengths of the messages of each stream and 377 schedules them in a certain way to maintain an equal bandwidth for 378 all streams. 380 3.1.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 382 A weighted fair queueing scheduler between the streams is used. The 383 weight is configurable per outgoing SCTP stream. This scheduler 384 considers the lengths of the messages of each stream and schedules 385 them in a certain way to use the bandwidth according to the given 386 weights. 388 3.2. Stream Scheduler with User Message Interleaving Support 390 3.2.1. User Message Based Round Robin Scheduler (SCTP_SS_RR_INTER) 392 This scheduler is similar to the one described in Section 3.1.2, but 393 based on I-DATA chunks instead of user messages. 395 3.2.2. Packet Based Round Robin Scheduler (SCTP_SS_RR_PKT_INTER) 397 This scheduler is similar to the one described in Section 3.1.3, but 398 based on I-DATA chunks instead of user messages. 400 3.2.3. Priority Based Scheduler (SCTP_SS_PRIO_INTER) 402 This scheduler is similar to the one described in Section 3.1.4, but 403 based on I-DATA chunks instead of user messages. 405 3.2.4. Fair Bandwidth Scheduler (SCTP_SS_FB_INTER) 407 This scheduler is similar to the one described in Section 3.1.5, but 408 based on I-DATA chunks instead of user messages. 410 3.2.5. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ_INTER) 412 This scheduler is similar to the one described in Section 3.1.6, but 413 based on I-DATA chunks instead of user messages. This scheduler is 414 used for WebRTC Datachannels as specified in 415 [I-D.ietf-rtcweb-data-channel]. 417 4. Socket API Considerations 419 This section describes how the socket API defined in [RFC6458] is 420 extended to allow applications to use the extension described in this 421 document. 423 Please note that this section is informational only. 425 4.1. SCTP_ASSOC_CHANGE Notification 427 When an SCTP_ASSOC_CHANGE notification is delivered indicating a 428 sac_state of SCTP_COMM_UP or SCTP_RESTART for an SCTP association 429 where both peers support the I-DATA chunk, 430 SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listen in the sac_info 431 field. 433 4.2. Socket Options 435 +-----------------------------+-------------------------+-----+-----+ 436 | option name | data type | get | set | 437 +-----------------------------+-------------------------+-----+-----+ 438 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 439 | SCTP_PLUGGABLE_SS | struct sctp_assoc_value | X | X | 440 | SCTP_SS_VALUE | struct | X | X | 441 | | sctp_stream_value | | | 442 +-----------------------------+-------------------------+-----+-----+ 444 4.2.1. Enable or Disable the Support of User Message Interleaving 446 This socket option allows the enabling or disabling of the 447 negotiation of user message interleaving support for future 448 associations. For existing associations it allows to query whether 449 user message interleaving support was negotiated or not on a 450 particular association. 452 User message interleaving is disabled per default. 454 This socket option uses IPPROTO_SCTP as its level and 455 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 456 getsockopt() and setsockopt(). The socket option value uses the 457 following structure defined in [RFC6458]: 459 struct sctp_assoc_value { 460 sctp_assoc_t assoc_id; 461 uint32_t assoc_value; 462 }; 464 assoc_id: This parameter is ignored for one-to-one style sockets. 465 For one-to-many style sockets, this parameter indicates upon which 466 association the user is performing an action. The special 467 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 468 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 470 assoc_value: A non-zero value encodes the enabling of user message 471 interleaving whereas a value of 0 encodes the disabling of user 472 message interleaving. 474 sctp_opt_info() needs to be extended to support 475 SCTP_INTERLEAVING_SUPPORTED. 477 An application using user message interleaving should also set the 478 fragment interleave level to 2. This allows the reception from 479 multiple streams simultaneously. Failure to set this option can 480 possibly lead to application deadlock. 482 4.2.2. Get or Set the Stream Scheduler (SCTP_PLUGGABLE_SS) 484 A stream scheduler can be selected with the SCTP_PLUGGABLE_SS option 485 for setsockopt(). The struct sctp_assoc_value is used to specify the 486 association for which the scheduler should be changed and the value 487 of the desired algorithm. 489 The definition of struct sctp_assoc_value is the same as in 490 [RFC6458]: 492 struct sctp_assoc_value { 493 sctp_assoc_t assoc_id; 494 uint32_t assoc_value; 495 }; 497 assoc_id: Holds the identifier for the association of which the 498 scheduler should be changed. The special 499 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 500 is ignored for one-to-one style sockets. 502 assoc_value: This specifies which scheduler is used. The following 503 constants can be used: 505 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 506 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 508 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1.1. 510 SCTP_SS_RR: Use the scheduler specified in Section 3.1.2. 512 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.1.3. 514 SCTP_SS_PRIO: Use the scheduler specified in Section 3.1.4. The 515 priority can be assigned with the sctp_stream_value struct. 516 The higher the assigned value, the lower the priority, that is 517 the default value 0 is the highest priority and therefore the 518 default scheduling will be used if no priorities have been 519 assigned. 521 SCTP_SS_FB: Use the scheduler specified in Section 3.1.5. 523 SCTP_SS_WFQ: Use the scheduler specified in Section 3.1.6. The 524 weight can be assigned with the sctp_stream_value struct. 526 SCTP_SS_RR_INTER: Use the scheduler specified in Section 3.2.1. 528 SCTP_SS_RR_PKT_INTER: Use the scheduler specified in 529 Section 3.2.2. 531 SCTP_SS_PRIO_inter: Use the scheduler specified in Section 3.2.3. 532 The priority can be assigned with the sctp_stream_value struct. 533 The higher the assigned value, the lower the priority, that is 534 the default value 0 is the highest priority and therefore the 535 default scheduling will be used if no priorities have been 536 assigned. 538 SCTP_SS_FB_INTER: Use the scheduler specified in Section 3.2.4. 540 SCTP_SS_WFQ_INTER: Use the scheduler specified in Section 3.2.5. 541 The weight can be assigned with the sctp_stream_value struct. 543 4.2.3. Get or Set the Stream Scheduler Parameter (SCTP_SS_VALUE) 545 Some schedulers require additional information to be set for single 546 streams as shown in the following table: 548 +----------------------+-----------------+ 549 | name | per stream info | 550 +----------------------+-----------------+ 551 | SCTP_SS_DEFAULT | no | 552 | SCTP_SS_FCFS | no | 553 | SCTP_SS_RR | no | 554 | SCTP_SS_RR_PKT | no | 555 | SCTP_SS_PRIO | yes | 556 | SCTP_SS_FB | no | 557 | SCTP_SS_WFQ | yes | 558 | SCTP_SS_RR_INTER | no | 559 | SCTP_SS_RR_PKT_INTER | no | 560 | SCTP_SS_PRIO_INTER | yes | 561 | SCTP_SS_FB_INTER | no | 562 | SCTP_SS_WFQ_INTER | yes | 563 +----------------------+-----------------+ 565 This is achieved with the SCTP_SS_VALUE option and the corresponding 566 struct sctp_stream_value. The definition of struct sctp_stream_value 567 is as follows: 569 struct sctp_stream_value { 570 sctp_assoc_t assoc_id; 571 uint16_t stream_id; 572 uint16_t stream_value; 573 }; 575 assoc_id: Holds the identifier for the association of which the 576 scheduler should be changed. The special 577 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 578 is ignored for one-to-one style sockets. 580 stream_id: Holds the stream id for the stream for which additional 581 information has to be provided. 583 stream_value: The meaning of this field depends on the scheduler 584 specified. It is ignored when the scheduler does not need 585 additional information. 587 5. IANA Considerations 589 [NOTE to RFC-Editor: 591 "RFCXXXX" is to be replaced by the RFC number you assign this 592 document. 594 ] 596 [NOTE to RFC-Editor: 598 The suggested values for the chunk type and the chunk flags are 599 tentative and to be confirmed by IANA. 601 ] 603 This document (RFCXXXX) is the reference for all registrations 604 described in this section. 606 A new chunk type has to be assigned by IANA. IANA should assign this 607 value from the pool of chunks with the upper two bits set to '01'. 608 This requires an additional line in the "Chunk Types" registry for 609 SCTP: 611 +----------+-------------------------+-----------+ 612 | ID Value | Chunk Type | Reference | 613 +----------+-------------------------+-----------+ 614 | 64 | New DATA chunk (I-DATA) | [RFCXXXX] | 615 +----------+-------------------------+-----------+ 617 The registration table as defined in [RFC6096] for the chunk flags of 618 this chunk type is initially given by the following table: 620 +------------------+-----------------+-----------+ 621 | Chunk Flag Value | Chunk Flag Name | Reference | 622 +------------------+-----------------+-----------+ 623 | 0x01 | E bit | [RFCXXXX] | 624 | 0x02 | B bit | [RFCXXXX] | 625 | 0x04 | U bit | [RFCXXXX] | 626 | 0x08 | I bit | [RFCXXXX] | 627 | 0x10 | Unassigned | | 628 | 0x20 | Unassigned | | 629 | 0x40 | Unassigned | | 630 | 0x80 | Unassigned | | 631 +------------------+-----------------+-----------+ 633 6. Security Considerations 635 This document does not add any additional security considerations in 636 addition to the ones given in [RFC4960] and [RFC6458]. 638 7. Acknowledgments 640 The authors wish to thank Christer Holmberg, Karen E. Egede Nielsen, 641 Irene Ruengeler, and Lixia Zhang for her invaluable comments. 643 8. References 645 8.1. Normative References 647 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 648 August 1996. 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, March 1997. 653 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 654 Conrad, "Stream Control Transmission Protocol (SCTP) 655 Partial Reliability Extension", RFC 3758, May 2004. 657 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 658 4960, September 2007. 660 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 661 Kozuka, "Stream Control Transmission Protocol (SCTP) 662 Dynamic Address Reconfiguration", RFC 5061, September 663 2007. 665 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 666 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 667 January 2011. 669 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 670 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 671 6525, February 2012. 673 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 674 IMMEDIATELY Extension for the Stream Control Transmission 675 Protocol", RFC 7053, November 2013. 677 8.2. Informative References 679 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 680 A., Peterson, J., Sparks, R., Handley, M., and E. 681 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 682 June 2002. 684 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 685 Yasevich, "Sockets API Extensions for the Stream Control 686 Transmission Protocol (SCTP)", RFC 6458, December 2011. 688 [I-D.ietf-rtcweb-data-channel] 689 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 690 Channels", draft-ietf-rtcweb-data-channel-13 (work in 691 progress), January 2015. 693 Authors' Addresses 695 Randall R. Stewart 696 Netflix, Inc. 697 Chapin, SC 29036 698 United States 700 Email: randall@lakerest.net 702 Michael Tuexen 703 Muenster University of Applied Sciences 704 Stegerwaldstrasse 39 705 48565 Steinfurt 706 Germany 708 Email: tuexen@fh-muenster.de 710 Salvatore Loreto 711 Ericsson 712 Hirsalantie 11 713 Jorvas 02420 714 Finland 716 Email: Salvatore.Loreto@ericsson.com 717 Robin Seggelmann 718 Metafinanz Informationssysteme GmbH 719 Leopoldstrasse 146 720 80804 Muenchen 721 Germany 723 Email: rfc@robin-seggelmann.com