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