idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-11.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 (June 21, 2017) is 2493 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 817, 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: December 23, 2017 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 June 21, 2017 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-11.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 December 23, 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 Scheduler (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 Capacity Scheduler (SCTP_SS_FC) . . . . . . . . . . 12 82 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 12 83 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 13 84 4.1. Exposure 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 . . . . . . . . . . . . . . . . . . 17 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 up to 2**16 - 1 Stream Sequence 130 Numbers (SSNs) outstanding. 132 The protocol requires all fragments of a user message to have 133 consecutive TSNs. This document allows an SCTP sender to interleave 134 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. Each queue for SID 0 and SID 2 contains 143 a single user message requiring three chunks, the queue for SID 1 144 contains three user messages each requiring a single chunk. It is 145 shown how these user messages are encapsulated in chunk using TSN 0 146 to TSN 8. Please note that the use of such a scheduler implies late 147 TSN assignment but it can be used with an [RFC4960] compliant 148 implementation that does not support user message interleaving. 150 +---+---+---+ 151 | 0/0 |-+ 152 +---+---+---+ | 153 | +---+---+---+---+---+---+---+---+---+ 154 +---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0| 155 |1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---| 156 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 157 | +---+---+---+---+---+---+---+---+---+ 158 +---+---+---+ | 159 | 2/0 |-+ 160 +---+---+---+ 161 +-------+ 162 +-------+ |SID/SSN| 163 |SID/SSN| |-------| 164 +-------+ | TSN | 165 +-------+ 167 Figure 1: Round Robin Scheduler without User Message Interleaving 169 This document describes a new chunk carrying payload data called 170 I-DATA. This chunk incorporates the properties of the current SCTP 171 DATA chunk, all the flags and fields except the Stream Sequence 172 Number (SSN), but also adds two new fields in its chunk header, the 173 Fragment Sequence Number (FSN) and the Message Identifier (MID). The 174 FSN is only used for reassembling all fragments having the same MID 175 and ordering property. The TSN is only used for the reliable 176 transfer in combination with Selective Acknowledgment (SACK) chunks. 178 In addition, the MID is also used for ensuring ordered delivery 179 instead of using the stream sequence number (The I-DATA chunk omits a 180 SSN.). 182 Figure 2 illustrates the behaviour of an interleaving round robin 183 stream scheduler using I-DATA chunks. 185 +---+---+---+ 186 | 0/0 |-+ 187 +---+---+---+ | 188 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 189 +---+---+---+ +->|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| 190 |1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----| 191 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 192 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 193 +---+---+---+ | 194 | 2/0 |-+ 195 +---+---+---+ 196 +-----------+ 197 +-------+ |SID/MID/FSN| 198 |SID/MID| |-----------| 199 +-------+ | TSN | 200 +-----------+ 202 Figure 2: Round Robin Scheduler with User Message Interleaving 204 The support of the I-DATA chunk is negotiated during the association 205 setup using the Supported Extensions Parameter as defined in 206 [RFC5061]. If I-DATA support has been negotiated for an association 207 I-DATA chunks are used for all user-messages. DATA chunks are not 208 permitted when I-DATA support has been negotiated. It should be 209 noted that an SCTP implementation supporting I-DATA chunks needs to 210 allow the coexistence of associations using DATA chunks and 211 associations using I-DATA chunks. 213 In Section 2 this document specifies the user message interleaving by 214 defining the I-DATA chunk, the procedures to use it and its 215 interactions with other SCTP extensions. Multiple stream schedulers 216 are defined in Section 3 followed in Section 4 by describing an 217 extension to the socket API for using what is specified in this 218 document. 220 1.2. Conventions 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 2. User Message Interleaving 228 The protocol mechanisms described in this document allow the 229 interleaving of user messages sent on different streams. They do not 230 support the interleaving of multiple messages (ordered or unordered) 231 sent on the same stream. 233 The interleaving of user messages is required for WebRTC Datachannels 234 as specified in [I-D.ietf-rtcweb-data-channel]. 236 An SCTP implementation supporting user message interleaving is 237 REQUIRED to support the coexistence of associations using DATA chunks 238 and associations using I-DATA chunks. If an SCTP implementation 239 supports user message interleaving and the extension described in 240 [RFC3758] or [RFC6525], it is REQUIRED to implement the corresponding 241 changes specified in Section 2.3. 243 2.1. The I-DATA Chunk Supporting User Message Interleaving 245 The following Figure 3 shows the new I-DATA chunk allowing user 246 message interleaving. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type = 64 | Res |I|U|B|E| Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | TSN | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Stream Identifier | Reserved | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Message Identifier | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Payload Protocol Identifier / Fragment Sequence Number | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 \ \ 262 / User Data / 263 \ \ 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 3: I-DATA chunk format 268 The only differences between the I-DATA chunk in Figure 3 and the 269 DATA chunk defined in [RFC4960] and [RFC7053] are the addition of the 270 new Message Identifier (MID) and the new Fragment Sequence Number 271 (FSN) and the removal of the Stream Sequence Number (SSN). The 272 Payload Protocol Identifier (PPID) and the FSN are stored at the same 273 location of the packet using the B-bit to determine which value is 274 stored at the location. The length of the I-DATA chunk header is 20 275 bytes, which is 4 bytes more than the length of the DATA chunk header 276 defined in [RFC4960] and [RFC7053]. 278 The new fields are: 280 Reserved: 16 bits (unsigned integer) 281 This field is reserved. It MUST be set to 0 by the sender and 282 MUST be ignored by the receiver. 284 Message Identifier (MID): 32 bits (unsigned integer) 285 The MID is the same for all fragments of a user message, it is 286 used to determine which fragments (enumerated by the FSN) belong 287 to the same user message. For ordered user messages, the MID is 288 also used by the SCTP receiver to deliver the user messages in the 289 correct order to the upper layer (similar to the SSN of the DATA 290 chunk defined in [RFC4960]). The sender uses two counters for 291 each outgoing stream, one for ordered messages, one for unordered 292 messages. All counters are independent and initially 0. They are 293 incremented by 1 for each user message. Please note that the 294 serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 295 32 applies. Therefore, the sender MUST NOT have more than 2**31 - 296 1 ordered messages for each outgoing stream in flight and MUST NOT 297 have more than 2**31 - 1 unordered messages for each outgoing 298 stream in flight. A message is considered in flight, if at least 299 on of its I-DATA chunks is not acknowledged in a non-renegable 300 way. Please note that the MID is in "network byte order", a.k.a. 301 Big Endian. 303 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 304 32 bits (unsigned integer) 305 If the B bit is set, this field contains the PPID of the user 306 message. Note that in this case, this field is not touched by an 307 SCTP implementation; therefore, its byte order is not necessarily 308 in network byte order. The upper layer is responsible for any 309 byte order conversions to this field, similar to the PPID of DATA 310 chunks. In this case the FSN is implicitly considered to be 0. 311 If the B bit is not set, this field contains the FSN. The FSN is 312 used to enumerate all fragments of a single user message, starting 313 from 0 and incremented by 1. The last fragment of a message MUST 314 have the 'E' bit set. Note that the FSN MAY wrap completely 315 multiple times allowing arbitrarily large user messages. For the 316 FSN the serial number arithmetic defined in [RFC1982] applies with 317 SERIAL_BITS = 32. Therefore, a sender MUST NOT have more than 318 2**31 - 1 fragments of a single user message in flight. A 319 fragment is considered in flight, if it is not acknowledged in a 320 non-renegable way. Please note that the FSN is in "network byte 321 order", a.k.a. Big Endian. 323 2.2. Procedures 325 This subsection describes how the support of the I-DATA chunk is 326 negotiated and how the I-DATA chunk is used by the sender and 327 receiver. 329 2.2.1. Negotiation 331 An SCTP end point indicates user message interleaving support by 332 listing the I-DATA Chunk within the Supported Extensions Parameter as 333 defined in [RFC5061]. User message interleaving has been negotiated 334 for an association if both end points have indicated I-DATA support. 336 If user message interleaving support has been negotiated for an 337 association, I-DATA chunks MUST be used for all user messages and 338 DATA-chunks MUST NOT be used. If user message interleaving support 339 has not been negotiated for an association, DATA chunks MUST be used 340 for all user messages and I-DATA chunks MUST NOT be used. 342 An end point implementing the socket API specified in [RFC6458] MUST 343 NOT indicate user message interleaving support unless the user has 344 requested its use (e.g. via the socket API, see Section 4.3). This 345 constraint is made since the usage of this chunk requires that the 346 application is capable of handling interleaved messages upon 347 reception within an association. This is not the default choice 348 within the socket API (see the SCTP_FRAGMENT_INTERLEAVE socket option 349 in Section 8.1.20 of [RFC6458]) thus the user MUST indicate to the 350 SCTP implementation its support for receiving completely interleaved 351 messages. 353 Note that stacks that do not implement [RFC6458] may use other 354 methods to indicate interleaved message support and thus indicate the 355 support of user message interleaving. The crucial point is that the 356 SCTP stack MUST know that the application can handle interleaved 357 messages before indicating the I-DATA support. 359 2.2.2. Sender Side Considerations 361 The sender side usage of the I-DATA chunk is quite simple. Instead 362 of using the TSN for fragmentation purposes, the sender uses the new 363 FSN field to indicate which fragment number is being sent. The first 364 fragment MUST have the 'B' bit set. The last fragment MUST have the 365 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 366 set. All other properties of the existing SCTP DATA chunk also apply 367 to the I-DATA chunk, i.e. congestion control as well as receiver 368 window conditions MUST be observed as defined in [RFC4960]. 370 Note that the usage of this chunk implies the late assignment of the 371 actual TSN to any chunk being sent. Each I-DATA chunk uses a single 372 TSN. This way messages from other streams may be interleaved with 373 the fragmented message. Please note that this is the only form of 374 interleaving support. For example, it is not possible to interleave 375 multiple ordered or unordered user messages from the same stream. 377 The sender MUST NOT be fragmenting more than one user message in any 378 given stream at any time. At any time, a sender MAY fragment 379 multiple user messages, each of them on different streams. 381 The sender MUST assign TSNs in a way that the receiver can make 382 progress. One way to achieve this is to assign a higher TSN to the 383 later fragments of a user message and send out the TSNs in sequence. 385 2.2.3. Receiver Side Considerations 387 Upon reception of an SCTP packet containing an I-DATA chunk whose 388 user message needs to be reassembled, the receiver MUST first use the 389 SID to identify the stream, consider the U bit to determine if it is 390 part of an ordered or unordered message, find the user message 391 identified by the MID and finally use the FSN for reassembly of the 392 message and not the TSN. The receiver MUST NOT make any assumption 393 about the TSN assignments of the sender. Note that a non-fragmented 394 message is indicated by the fact that both the 'E' and 'B' bits are 395 set. A message (either ordered or unordered) may be identified as 396 being fragmented whose 'E' and 'B' bits are not set both. 398 If I-DATA support has been negotiated for an association, the 399 reception of a DATA chunk is a violation of the above rules and 400 therefore the receiver of the DATA chunk MUST abort the association 401 by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol 402 Violation' error cause. The same applies if I-DATA support has not 403 be negotiated for an association and an I-DATA chunk is received. 405 2.3. Interaction with other SCTP Extensions 407 The usage of the I-DATA chunk might interfere with other SCTP 408 extensions. Future SCTP extensions MUST describe if and how they 409 interfere with the usage of I-DATA chunks. For the SCTP extensions 410 already defined when this document was published, the details are 411 given in the following subsections. 413 2.3.1. SCTP Partial Reliability Extension 415 When the SCTP extension defined in [RFC3758] is used in combination 416 with the user message interleaving extension, the new I-FORWARD-TSN 417 chunk MUST be used instead of the FORWARD-TSN chunk. The difference 418 between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 419 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit 420 Message Identifier (MID) and the largest skipped MID can also be 421 provided for unordered messages. Therefore, the principle applied to 422 ordered message when using FORWARD-TSN chunks is applied to ordered 423 and unordered messages when using I-FORWARD-TSN chunks. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type = 194 | Flags = 0x00 | Length = Variable | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | New Cumulative TSN | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Stream Identifier | Reserved |U| 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Message Identifier | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 \ \ 437 / / 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Stream Identifier | Reserved |U| 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Message Identifier | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 4: I-FORWARD-TSN chunk format 446 The relevant new fields are: 448 Stream Identifier (SID): 16-bits (unsigned integer) 449 This field holds the stream number this entry refers to. 451 Reserved: 15 bits 452 This field is reserved. It MUST be set to 0 by the sender and 453 MUST be ignored by the receiver. 455 U bit: 1 bit 456 The U bit specifies if the Message Identifier of this entry refers 457 to unordered messages (U bit is set) or ordered messages (U bit is 458 not set). 460 Message Identifier (MID): 32 bits (unsigned integer) 461 This field holds the largest Message Identifier for ordered or 462 unordered messages indicated by the U-bit that was skipped for the 463 stream specified by the Stream Identifier. For ordered messages 464 this is similar to the FORWARD-TSN chunk, just replacing the 465 16-bit SSN by the 32-bit MID. 467 Support for the I-FORWARD-TSN chunk is negotiated during the SCTP 468 association setup via the Supported Extensions Parameter as defined 469 in [RFC5061]. Only if both end points indicated their support of 470 user message interleaving and the I-FORWARD-TSN chunk, the partial 471 reliability extension is negotiated and can be used in combination 472 with user message interleaving. 474 The FORWARD-TSN chunk MUST be used in combination with the DATA chunk 475 and MUST NOT be used in combination with the I-DATA chunk. The I- 476 FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk 477 and MUST NOT be used in combination with the DATA chunk. 479 If I-FORWARD-TSN support has been negotiated for an association, the 480 reception of a FORWARD-TSN chunk is a violation of the above rules 481 and therefore the receiver of the FORWARD-TSN chunk MUST abort the 482 association by sending an ABORT chunk. The ABORT chunk MAY include 483 the 'Protocol Violation' error cause. The same applies if I-FORWARD- 484 TSN support has not be negotiated for an association and a FORWARD- 485 TSN chunk is received. 487 2.3.2. SCTP Stream Reconfiguration Extension 489 When an association resets the SSN using the SCTP extension defined 490 in [RFC6525], the two counters (one for the ordered messages, one for 491 the unordered messages) used for the MIDs MUST be reset to 0. 493 Since most schedulers, especially all schedulers supporting user 494 message interleaving, require late TSN assignment, it should be noted 495 that the implementation of [RFC6525] needs to handle this. 497 3. Stream Schedulers 499 This section defines several stream schedulers. The stream 500 schedulers may behave differently depending on whether user message 501 interleaving has been negotiated for the association or not. An 502 implementation MAY implement any subset of them. 504 The selection of the stream scheduler is done at the sender side. 505 There is no mechanism provided for signalling the stream scheduler 506 being used to the receiver side or even let the receiver side 507 influence the selection of the stream scheduler used at the sender 508 side. 510 3.1. First Come First Served Scheduler (SCTP_SS_FCFS) 512 The simple first-come, first-served scheduler of user messages is 513 used. It just passes through the messages in the order in which they 514 have been delivered by the application. No modification of the order 515 is done at all. The usage of user message interleaving does not 516 affect the sending of the chunks, except that I-DATA chunks are used 517 instead of DATA chunks. 519 3.2. Round Robin Scheduler (SCTP_SS_RR) 521 When not using user message interleaving, this scheduler provides a 522 fair scheduling based on the number of user messages by cycling 523 around non-empty stream queues. When using user message 524 interleaving, this scheduler provides a fair scheduling based on the 525 number of I-DATA chunks by cycling around non-empty stream queues. 527 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) 529 This is a round-robin scheduler, which only switches streams when 530 starting to fill a new packet. It bundles only DATA or I-DATA chunks 531 referring to the same stream in a packet. This scheduler minimizes 532 head-of-line blocking when a packet is lost because only a single 533 stream is affected. 535 3.4. Priority Based Scheduler (SCTP_SS_PRIO) 537 Scheduling of user messages with strict priorities is used. The 538 priority is configurable per outgoing SCTP stream. Streams having a 539 higher priority will be scheduled first and when multiple streams 540 have the same priority, the scheduling between them is implementation 541 dependent. When using user message interleaving, the sending of 542 lower priority user messages will not block the sending of higher 543 priority user messages. 545 3.5. Fair Capacity Scheduler (SCTP_SS_FC) 547 A fair capacity distribution between the streams is used. This 548 scheduler considers the lengths of the messages of each stream and 549 schedules them in a specific way to maintain an equal capacity for 550 all streams. The details are implementation dependent. Using user 551 message interleaving allows for a better realization of the fair 552 capacity usage. 554 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 556 A weighted fair queueing scheduler between the streams is used. The 557 weight is configurable per outgoing SCTP stream. This scheduler 558 considers the lengths of the messages of each stream and schedules 559 them in a specific way to use the capacity according to the given 560 weights. If the weight of stream S1 is n times the weight of stream 561 S2, the scheduler should assign to stream S1 n times the capacity it 562 assigns to stream S2. The details are implementation dependent. 563 Using user message interleaving allows for a better realization of 564 the capacity usage according to the given weights. 566 This scheduler in combination with user message interleaving is used 567 for WebRTC Datachannels as specified in 568 [I-D.ietf-rtcweb-data-channel]. 570 4. Socket API Considerations 572 This section describes how the socket API defined in [RFC6458] is 573 extended to allow applications to use the extension described in this 574 document. 576 Please note that this section is informational only. 578 4.1. Exposure of the Stream Sequence Number (SSN) 580 The socket API defined in [RFC6458] defines several structures in 581 which the SSN of a received user message is exposed to the 582 application. The list of these structures includes: 584 struct sctp_sndrcvinfo 585 Specified in Section 5.3.2 SCTP Header Information Structure 586 (SCTP_SNDRCV) of [RFC6458] and marked as deprecated. 588 struct sctp_extrcvinfo 589 Specified in Section 5.3.3 Extended SCTP Header Information 590 Structure (SCTP_EXTRCV)of [RFC6458] and marked as deprecated. 592 struct sctp_rcvinfo 593 Specified in Section 5.3.5 SCTP Receive Information Structure 594 (SCTP_RCVINFO) of [RFC6458]. 596 If user message interleaving is used, the lower order 16 bits of the 597 MID are used as the SSN when filling out these structures. 599 4.2. SCTP_ASSOC_CHANGE Notification 601 When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of 602 [RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or 603 SCTP_RESTART for an SCTP association where both peers support the 604 I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in 605 the sac_info field. 607 4.3. Socket Options 608 +-----------------------------+-------------------------+-----+-----+ 609 | option name | data type | get | set | 610 +-----------------------------+-------------------------+-----+-----+ 611 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 612 | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | 613 | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | 614 | | sctp_stream_value | | | 615 +-----------------------------+-------------------------+-----+-----+ 617 4.3.1. Enable or Disable the Support of User Message Interleaving 618 (SCTP_INTERLEAVING_SUPPORTED) 620 This socket option allows the enabling or disabling of the 621 negotiation of user message interleaving support for future 622 associations. For existing associations it allows to query whether 623 user message interleaving support was negotiated or not on a 624 particular association. 626 This socket option uses IPPROTO_SCTP as its level and 627 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 628 getsockopt() and setsockopt(). The socket option value uses the 629 following structure defined in [RFC6458]: 631 struct sctp_assoc_value { 632 sctp_assoc_t assoc_id; 633 uint32_t assoc_value; 634 }; 636 assoc_id: This parameter is ignored for one-to-one style sockets. 637 For one-to-many style sockets, this parameter indicates upon which 638 association the user is performing an action. The special 639 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 640 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 642 assoc_value: A non-zero value encodes the enabling of user message 643 interleaving whereas a value of 0 encodes the disabling of user 644 message interleaving. 646 sctp_opt_info() needs to be extended to support 647 SCTP_INTERLEAVING_SUPPORTED. 649 An application using user message interleaving should also set the 650 fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE 651 socket option specified in Section 8.1.20 of [RFC6458]. This allows 652 the interleaving of user messages from different streams. Please 653 note that it does not allow the interleaving of user messages 654 (ordered or unordered) on the same stream. Failure to set this 655 option can possibly lead to application deadlock. Some 656 implementations might therefore put some restrictions on setting 657 combinations of these values. Setting the interleaving level to at 658 least 2 before enabling the negotiation of user message interleaving 659 should work on all platforms. Since the default fragment interleave 660 level is not 2, user message interleaving is disabled per default. 662 4.3.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) 664 A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER 665 option for setsockopt(). The struct sctp_assoc_value is used to 666 specify the association for which the scheduler should be changed and 667 the value of the desired algorithm. 669 The definition of struct sctp_assoc_value is the same as in 670 [RFC6458]: 672 struct sctp_assoc_value { 673 sctp_assoc_t assoc_id; 674 uint32_t assoc_value; 675 }; 677 assoc_id: Holds the identifier for the association of which the 678 scheduler should be changed. The special 679 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 680 is ignored for one-to-one style sockets. 682 assoc_value: This specifies which scheduler is used. The following 683 constants can be used: 685 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 686 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 688 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1. 690 SCTP_SS_RR: Use the scheduler specified in Section 3.2. 692 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3. 694 SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The 695 priority can be assigned with the sctp_stream_value struct. 696 The higher the assigned value, the lower the priority, that is 697 the default value 0 is the highest priority and therefore the 698 default scheduling will be used if no priorities have been 699 assigned. 701 SCTP_SS_FB: Use the scheduler specified in Section 3.5. 703 SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The 704 weight can be assigned with the sctp_stream_value struct. 706 sctp_opt_info() needs to be extended to support 707 SCTP_STREAM_SCHEDULER. 709 4.3.3. Get or Set the Stream Scheduler Parameter 710 (SCTP_STREAM_SCHEDULER_VALUE) 712 Some schedulers require additional information to be set for 713 individual streams as shown in the following table: 715 +-----------------+-----------------+ 716 | name | per stream info | 717 +-----------------+-----------------+ 718 | SCTP_SS_DEFAULT | n/a | 719 | SCTP_SS_FCFS | no | 720 | SCTP_SS_RR | no | 721 | SCTP_SS_RR_PKT | no | 722 | SCTP_SS_PRIO | yes | 723 | SCTP_SS_FB | no | 724 | SCTP_SS_WFQ | yes | 725 +-----------------+-----------------+ 727 This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the 728 corresponding struct sctp_stream_value. The definition of struct 729 sctp_stream_value is as follows: 731 struct sctp_stream_value { 732 sctp_assoc_t assoc_id; 733 uint16_t stream_id; 734 uint16_t stream_value; 735 }; 737 assoc_id: Holds the identifier for the association of which the 738 scheduler should be changed. The special 739 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 740 is ignored for one-to-one style sockets. 742 stream_id: Holds the stream id of the stream for which additional 743 information has to be provided. 745 stream_value: The meaning of this field depends on the scheduler 746 specified. It is ignored when the scheduler does not need 747 additional information. 749 sctp_opt_info() needs to be extended to support 750 SCTP_STREAM_SCHEDULER_VALUE. 752 4.4. Explicit EOR Marking 754 Using explicit End of Record (EOR) marking for an SCTP association 755 supporting user message interleaving allows the user to interleave 756 the sending of user messages on different streams. 758 5. IANA Considerations 760 [NOTE to RFC-Editor: 762 "RFCXXXX" is to be replaced by the RFC number you assign this 763 document. 765 ] 767 [NOTE to RFC-Editor: 769 The suggested values for the chunk types and the chunk flags are 770 tentative and to be confirmed by IANA. 772 ] 774 This document (RFCXXXX) is the reference for all registrations 775 described in this section. 777 Two new chunk types have to be assigned by IANA. 779 5.1. I-DATA Chunk 781 IANA should assign the chunk type for this chunk from the pool of 782 chunks with the upper two bits set to '01'. This requires an 783 additional line in the "Chunk Types" registry for SCTP: 785 +----------+--------------------------------------------+-----------+ 786 | ID Value | Chunk Type | Reference | 787 +----------+--------------------------------------------+-----------+ 788 | 64 | Payload Data supporting Interleaving | [RFCXXXX] | 789 | | (I-DATA) | | 790 +----------+--------------------------------------------+-----------+ 792 The registration table as defined in [RFC6096] for the chunk flags of 793 this chunk type is initially given by the following table: 795 +------------------+-----------------+-----------+ 796 | Chunk Flag Value | Chunk Flag Name | Reference | 797 +------------------+-----------------+-----------+ 798 | 0x01 | E bit | [RFCXXXX] | 799 | 0x02 | B bit | [RFCXXXX] | 800 | 0x04 | U bit | [RFCXXXX] | 801 | 0x08 | I bit | [RFCXXXX] | 802 | 0x10 | Unassigned | | 803 | 0x20 | Unassigned | | 804 | 0x40 | Unassigned | | 805 | 0x80 | Unassigned | | 806 +------------------+-----------------+-----------+ 808 5.2. I-FORWARD-TSN Chunk 810 IANA should assign the chunk type for this chunk from the pool of 811 chunks with the upper two bits set to '11'. This requires an 812 additional line in the "Chunk Types" registry for SCTP: 814 +----------+---------------+-----------+ 815 | ID Value | Chunk Type | Reference | 816 +----------+---------------+-----------+ 817 | 194 | I-FORWARD-TSN | [RFCXXXX] | 818 +----------+---------------+-----------+ 820 The registration table as defined in [RFC6096] for the chunk flags of 821 this chunk type is initially empty. 823 6. Security Considerations 825 This document does not add any additional security considerations in 826 addition to the ones given in [RFC4960] and [RFC6458]. 828 It should be noted that the application has to consent that it is 829 willing to do the more complex reassembly support required for user 830 message interleaving. When doing so, an application has to provide 831 up to two reassembly buffers (one for ordered messages, one for 832 unordered messages) for each incoming stream. It has to protect 833 itself against these buffers taking too many resources. If user 834 message interleaving is not used, only a single reassembly buffer 835 needs to be provided for each association. But the application has 836 to protect itself for excessive resource usages there too. 838 7. Acknowledgments 840 The authors wish to thank Julian Cordes, Gorry Fairhurst, Lennart 841 Grahl, Christer Holmberg, Marcelo Ricardo Leitner, Karen E. Egede 842 Nielsen, Maksim Proshin, Irene Ruengeler, Felix Weinrank, Michael 843 Welzl, Magnus Westerlund, and Lixia Zhang for their invaluable 844 comments. 846 This work has received funding from the European Union's Horizon 2020 847 research and innovation programme under grant agreement No. 644334 848 (NEAT). The views expressed are solely those of the author(s). 850 8. References 852 8.1. Normative References 854 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 855 DOI 10.17487/RFC1982, August 1996, 856 . 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, 860 DOI 10.17487/RFC2119, March 1997, 861 . 863 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 864 Conrad, "Stream Control Transmission Protocol (SCTP) 865 Partial Reliability Extension", RFC 3758, 866 DOI 10.17487/RFC3758, May 2004, 867 . 869 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 870 RFC 4960, DOI 10.17487/RFC4960, September 2007, 871 . 873 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 874 Kozuka, "Stream Control Transmission Protocol (SCTP) 875 Dynamic Address Reconfiguration", RFC 5061, 876 DOI 10.17487/RFC5061, September 2007, 877 . 879 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 880 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 881 DOI 10.17487/RFC6096, January 2011, 882 . 884 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 885 Transmission Protocol (SCTP) Stream Reconfiguration", 886 RFC 6525, DOI 10.17487/RFC6525, February 2012, 887 . 889 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 890 IMMEDIATELY Extension for the Stream Control Transmission 891 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 892 . 894 8.2. Informative References 896 [I-D.ietf-rtcweb-data-channel] 897 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 898 Channels", draft-ietf-rtcweb-data-channel-13 (work in 899 progress), January 2015. 901 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 902 A., Peterson, J., Sparks, R., Handley, M., and E. 903 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 904 DOI 10.17487/RFC3261, June 2002, 905 . 907 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 908 Yasevich, "Sockets API Extensions for the Stream Control 909 Transmission Protocol (SCTP)", RFC 6458, 910 DOI 10.17487/RFC6458, December 2011, 911 . 913 Authors' Addresses 915 Randall R. Stewart 916 Netflix, Inc. 917 Chapin, SC 29036 918 United States 920 Email: randall@lakerest.net 922 Michael Tuexen 923 Muenster University of Applied Sciences 924 Stegerwaldstrasse 39 925 48565 Steinfurt 926 Germany 928 Email: tuexen@fh-muenster.de 929 Salvatore Loreto 930 Ericsson 931 Torshamnsgatan 21 932 164 80 Stockholm 933 Sweden 935 Email: Salvatore.Loreto@ericsson.com 937 Robin Seggelmann 938 Metafinanz Informationssysteme GmbH 939 Leopoldstrasse 146 940 80804 Muenchen 941 Germany 943 Email: rfc@robin-seggelmann.com