idnits 2.17.00 (12 Aug 2021) /tmp/idnits57301/draft-ietf-tsvwg-sctp-ndata-13.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 (September 1, 2017) is 1716 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 889, but not defined == Outdated reference: draft-ietf-rtcweb-data-channel has been published as RFC 8831 Summary: 0 errors (**), 0 flaws (~~), 3 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: March 5, 2018 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 September 1, 2017 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-13.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. The 23 interleaving of user messages is required for WebRTC Datachannels. 25 Whenever an SCTP sender is allowed to send user data, it may choose 26 from multiple outgoing SCTP streams. Multiple ways for performing 27 this selection, called stream schedulers, are defined in this 28 document. A stream scheduler can choose to either implement, or not 29 implement, user message interleaving. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 5, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. User Message Interleaving . . . . . . . . . . . . . . . . . . 5 69 2.1. The I-DATA Chunk Supporting User Message Interleaving . . 6 70 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 71 2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 9 72 2.2.2. Sender Side Considerations . . . . . . . . . . . . . 9 73 2.2.3. Receiver Side Considerations . . . . . . . . . . . . 10 74 2.3. Interaction with other SCTP Extensions . . . . . . . . . 10 75 2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 10 76 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 12 77 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 12 78 3.1. First Come First Served Scheduler (SCTP_SS_FCFS) . . . . 13 79 3.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 13 80 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 13 81 3.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 13 82 3.5. Fair Capacity Scheduler (SCTP_SS_FC) . . . . . . . . . . 14 83 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 14 84 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 14 85 4.1. Exposure of the Stream Sequence Number (SSN) . . . . . . 14 86 4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 15 87 4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 15 88 4.3.1. Enable or Disable the Support of User Message 89 Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 15 90 4.3.2. Get or Set the Stream Scheduler 91 (SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 16 92 4.3.3. Get or Set the Stream Scheduler Parameter 93 (SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 17 94 4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 18 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 5.1. I-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . 18 97 5.2. I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . . 19 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 8.2. Informative References . . . . . . . . . . . . . . . . . 21 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 105 1. Introduction 107 1.1. Overview 109 When SCTP [RFC4960] was initially designed it was mainly envisioned 110 for the transport of small signaling messages. Late in the design 111 stage it was decided to add support for fragmentation and reassembly 112 of larger messages with the thought that someday Session Initiation 113 Protocol (SIP) [RFC3261] style signaling messages may also need to 114 use SCTP and a single Maximum Transmission Unit (MTU) sized message 115 would be too small. Unfortunately this design decision, though valid 116 at the time, did not account for other applications that might send 117 large messages over SCTP. The sending of such large messages over 118 SCTP as specified in [RFC4960] can result in a form of sender side 119 head of line blocking (e.g., when the transmission of a message is 120 blocked from transmission because the sender has started the 121 transmission of another, possibly large, message). This head of line 122 blocking is caused by the use of the Transmission Sequence Number 123 (TSN) for three different purposes: 125 1. As an identifier for DATA chunks to provide a reliable transfer. 127 2. As an identifier for the sequence of fragments to allow 128 reassembly. 130 3. As a sequence number allowing up to 2**16 - 1 Stream Sequence 131 Numbers (SSNs) outstanding. 133 The protocol requires all fragments of a user message to have 134 consecutive TSNs. This document allows an SCTP sender to interleave 135 different user messages. 137 This document also defines several stream schedulers for general SCTP 138 associations allowing different relative stream treatments. The 139 stream schedulers may behave differently depending on whether user 140 message interleaving has been negotiated for the association or not. 142 Figure 1 illustrates the behaviour of a round robin stream scheduler 143 using DATA chunks when three streams with the Stream Identifiers 144 (SIDs) 0, 1, and 2 are used. Each queue for SID 0 and SID 2 contains 145 a single user message requiring three chunks, the queue for SID 1 146 contains three user messages each requiring a single chunk. It is 147 shown how these user messages are encapsulated in chunk using TSN 0 148 to TSN 8. Please note that the use of such a scheduler implies late 149 TSN assignment but it can be used with an [RFC4960] compliant 150 implementation that does not support user message interleaving. Late 151 TSN assignment means that the sender generates chunks from user 152 messages and assigns the TSN as late as possible in the process of 153 sending the user messages. 155 +---+---+---+ 156 | 0/0 |-+ 157 +---+---+---+ | 158 | +---+---+---+---+---+---+---+---+---+ 159 +---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0| 160 |1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---| 161 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 162 | +---+---+---+---+---+---+---+---+---+ 163 +---+---+---+ | 164 | 2/0 |-+ 165 +---+---+---+ 166 +-------+ 167 +-------+ |SID/SSN| 168 |SID/SSN| |-------| 169 +-------+ | TSN | 170 +-------+ 172 Figure 1: Round Robin Scheduler without User Message Interleaving 174 This document describes a new chunk carrying payload data called 175 I-DATA. This chunk incorporates the properties of the current SCTP 176 DATA chunk, all the flags and fields except the Stream Sequence 177 Number (SSN), but also adds two new fields in its chunk header, the 178 Fragment Sequence Number (FSN) and the Message Identifier (MID). The 179 FSN is only used for reassembling all fragments having the same MID 180 and ordering property. The TSN is only used for the reliable 181 transfer in combination with Selective Acknowledgment (SACK) chunks. 183 In addition, the MID is also used for ensuring ordered delivery 184 instead of using the stream sequence number (The I-DATA chunk omits a 185 SSN.). 187 Figure 2 illustrates the behaviour of an interleaving round robin 188 stream scheduler using I-DATA chunks. 190 +---+---+---+ 191 | 0/0 |-+ 192 +---+---+---+ | 193 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 194 +---+---+---+ +->|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| 195 |1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----| 196 +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 197 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 198 +---+---+---+ | 199 | 2/0 |-+ 200 +---+---+---+ 201 +-----------+ 202 +-------+ |SID/MID/FSN| 203 |SID/MID| |-----------| 204 +-------+ | TSN | 205 +-----------+ 207 Figure 2: Round Robin Scheduler with User Message Interleaving 209 The support of the I-DATA chunk is negotiated during the association 210 setup using the Supported Extensions Parameter as defined in 211 [RFC5061]. If I-DATA support has been negotiated for an association, 212 I-DATA chunks are used for all user-messages. DATA chunks are not 213 permitted when I-DATA support has been negotiated. It should be 214 noted that an SCTP implementation supporting I-DATA chunks needs to 215 allow the coexistence of associations using DATA chunks and 216 associations using I-DATA chunks. 218 In Section 2 this document specifies the user message interleaving by 219 defining the I-DATA chunk, the procedures to use it and its 220 interactions with other SCTP extensions. Multiple stream schedulers 221 are defined in Section 3 followed in Section 4 by describing an 222 extension to the socket API for using what is specified in this 223 document. 225 1.2. Conventions 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in [RFC2119]. 231 2. User Message Interleaving 233 The protocol mechanisms described in this document allow the 234 interleaving of user messages sent on different streams. They do not 235 support the interleaving of multiple messages (ordered or unordered) 236 sent on the same stream. 238 The interleaving of user messages is required for WebRTC Datachannels 239 as specified in [I-D.ietf-rtcweb-data-channel]. 241 An SCTP implementation supporting user message interleaving is 242 REQUIRED to support the coexistence of associations using DATA chunks 243 and associations using I-DATA chunks. If an SCTP implementation 244 supports user message interleaving and the Partial Reliability 245 extension described in [RFC3758] or the Stream Reconfiguration 246 Extension described in [RFC6525], it is REQUIRED to implement the 247 corresponding changes specified in Section 2.3. 249 2.1. The I-DATA Chunk Supporting User Message Interleaving 251 The following Figure 3 shows the new I-DATA chunk allowing user 252 message interleaving. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type = 64 | Res |I|U|B|E| Length = Variable | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | TSN | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Stream Identifier | Reserved | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Message Identifier | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Payload Protocol Identifier / Fragment Sequence Number | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 \ \ 268 / User Data / 269 \ \ 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 3: I-DATA chunk format 274 The only differences between the I-DATA chunk in Figure 3 and the 275 DATA chunk defined in [RFC4960] and [RFC7053] are the addition of the 276 new Message Identifier (MID) and the new Fragment Sequence Number 277 (FSN) and the removal of the Stream Sequence Number (SSN). The 278 Payload Protocol Identifier (PPID) already defined for DATA chunks in 279 [RFC4960] and the new FSN are stored at the same location of the 280 packet using the B bit to determine which value is stored at the 281 location. The length of the I-DATA chunk header is 20 bytes, which 282 is 4 bytes more than the length of the DATA chunk header defined in 283 [RFC4960] and [RFC7053]. 285 The old fields are: 287 Res: 4 bits 288 These bits are reserved. They MUST be set to 0 by the sender and 289 MUST be ignored by the receiver. 291 I bit: 1 bit 292 The (I)mmediate Bit, if set, indicates that the receiver SHOULD 293 NOT delay the sending of the corresponding SACK chunk. Same as 294 the I bit for DATA chunks as specified in [RFC7053]. 296 U bit: 1 bit 297 The (U)nordered bit, if set, indicates the user message is 298 unordered. Same as the U bit for DATA chunks as specified in 299 [RFC4960]. 301 B bit: 1 bit 302 The (B)eginning fragment bit, if set, indicates the first fragment 303 of a user message. Same as the B bit for DATA chunks as specified 304 in [RFC4960]. 306 E bit: 1 bit 307 The (E)nding fragment bit, if set, indicates the last fragment of 308 a user message. Same as the E bit for DATA chunks as specified in 309 [RFC4960]. 311 Length: 16 bits (unsigned integer) 312 This field indicates the length of the DATA chunk in bytes from 313 the beginning of the type field to the end of the User Data field 314 excluding any padding. Similar to the Length for DATA chunks as 315 specified in [RFC4960]. 317 TSN: 32 bits (unsigned integer) 318 This value represents the TSN for this I-DATA chunk. Same as the 319 TSN for DATA chunks as specified in [RFC4960]. 321 Stream Identifier: 16 bits (unsigned integer) 322 Identifies the stream to which the user data belongs. Same as the 323 Stream Identifier for DATA chunks as specified in [RFC4960]. 325 The new fields are: 327 Reserved: 16 bits (unsigned integer) 328 This field is reserved. It MUST be set to 0 by the sender and 329 MUST be ignored by the receiver. 331 Message Identifier (MID): 32 bits (unsigned integer) 332 The MID is the same for all fragments of a user message, it is 333 used to determine which fragments (enumerated by the FSN) belong 334 to the same user message. For ordered user messages, the MID is 335 also used by the SCTP receiver to deliver the user messages in the 336 correct order to the upper layer (similar to the SSN of the DATA 337 chunk defined in [RFC4960]). The sender uses for each outgoing 338 stream two counters, one for ordered messages, one for unordered 339 messages. All of these counters are independent and initially 0. 340 They are incremented by 1 for each user message. Please note that 341 the serial number arithmetic defined in [RFC1982] using 342 SERIAL_BITS = 32 applies. Therefore, the sender MUST NOT have 343 more than 2**31 - 1 ordered messages for each outgoing stream in 344 flight and MUST NOT have more than 2**31 - 1 unordered messages 345 for each outgoing stream in flight. A message is considered in 346 flight, if at least on of its I-DATA chunks is not acknowledged in 347 a non-renegable way (i.e. not acknowledged by the cumulative TSN 348 Ack). Please note that the MID is in "network byte order", a.k.a. 349 Big Endian. 351 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 352 32 bits (unsigned integer) 353 If the B bit is set, this field contains the PPID of the user 354 message. Note that in this case, this field is not touched by an 355 SCTP implementation; therefore, its byte order is not necessarily 356 in network byte order. The upper layer is responsible for any 357 byte order conversions to this field, similar to the PPID of DATA 358 chunks. In this case the FSN is implicitly considered to be 0. 359 If the B bit is not set, this field contains the FSN. The FSN is 360 used to enumerate all fragments of a single user message, starting 361 from 0 and incremented by 1. The last fragment of a message MUST 362 have the E bit set. Note that the FSN MAY wrap completely 363 multiple times allowing arbitrarily large user messages. For the 364 FSN the serial number arithmetic defined in [RFC1982] applies with 365 SERIAL_BITS = 32. Therefore, a sender MUST NOT have more than 366 2**31 - 1 fragments of a single user message in flight. A 367 fragment is considered in flight, if it is not acknowledged in a 368 non-renegable way. Please note that the FSN is in "network byte 369 order", a.k.a. Big Endian. 371 2.2. Procedures 373 This subsection describes how the support of the I-DATA chunk is 374 negotiated and how the I-DATA chunk is used by the sender and 375 receiver. 377 The handling of the I bit for the I-DATA chunk corresponds to the 378 handling of the I bit for the DATA chunk described in [RFC7053]. 380 2.2.1. Negotiation 382 An SCTP end point indicates user message interleaving support by 383 listing the I-DATA Chunk within the Supported Extensions Parameter as 384 defined in [RFC5061]. User message interleaving has been negotiated 385 for an association if both end points have indicated I-DATA support. 387 If user message interleaving support has been negotiated for an 388 association, I-DATA chunks MUST be used for all user messages and 389 DATA-chunks MUST NOT be used. If user message interleaving support 390 has not been negotiated for an association, DATA chunks MUST be used 391 for all user messages and I-DATA chunks MUST NOT be used. 393 An end point implementing the socket API specified in [RFC6458] MUST 394 NOT indicate user message interleaving support unless the user has 395 requested its use (e.g. via the socket API, see Section 4.3). This 396 constraint is made since the usage of this chunk requires that the 397 application is capable of handling interleaved messages upon 398 reception within an association. This is not the default choice 399 within the socket API (see the SCTP_FRAGMENT_INTERLEAVE socket option 400 in Section 8.1.20 of [RFC6458]) thus the user MUST indicate to the 401 SCTP implementation its support for receiving completely interleaved 402 messages. 404 Note that stacks that do not implement [RFC6458] may use other 405 methods to indicate interleaved message support and thus indicate the 406 support of user message interleaving. The crucial point is that the 407 SCTP stack MUST know that the application can handle interleaved 408 messages before indicating the I-DATA support. 410 2.2.2. Sender Side Considerations 412 The sender side usage of the I-DATA chunk is quite simple. Instead 413 of using the TSN for fragmentation purposes, the sender uses the new 414 FSN field to indicate which fragment number is being sent. The first 415 fragment MUST have the B bit set. The last fragment MUST have the E 416 bit set. All other fragments MUST NOT have the B bit or E bit set. 417 All other properties of the existing SCTP DATA chunk also apply to 418 the I-DATA chunk, i.e. congestion control as well as receiver window 419 conditions MUST be observed as defined in [RFC4960]. 421 Note that the usage of this chunk implies the late assignment of the 422 actual TSN to any chunk being sent. Each I-DATA chunk uses a single 423 TSN. This way messages from other streams may be interleaved with 424 the fragmented message. Please note that this is the only form of 425 interleaving support. For example, it is not possible to interleave 426 multiple ordered or unordered user messages from the same stream. 428 The sender MUST NOT process (move user data into I-DATA chunks and 429 assign a TSN to it) more than one user message in any given stream at 430 any time. At any time, a sender MAY process multiple user messages, 431 each of them on different streams. 433 The sender MUST assign TSNs to I-DATA chunks in a way that the 434 receiver can make progress. One way to achieve this is to assign a 435 higher TSN to the later fragments of a user message and send out the 436 I-DATA chunks such that the TSNs are in sequence. 438 2.2.3. Receiver Side Considerations 440 Upon reception of an SCTP packet containing an I-DATA chunk whose 441 user message needs to be reassembled, the receiver MUST first use the 442 SID to identify the stream, consider the U bit to determine if it is 443 part of an ordered or unordered message, find the user message 444 identified by the MID and finally use the FSN for reassembly of the 445 message and not the TSN. The receiver MUST NOT make any assumption 446 about the TSN assignments of the sender. Note that a non-fragmented 447 message is indicated by the fact that both the E and B bits are set. 448 A message (either ordered or unordered) may be identified as being 449 fragmented whose E and B bits are not both set. 451 If I-DATA support has been negotiated for an association, the 452 reception of a DATA chunk is a violation of the above rules and 453 therefore the receiver of the DATA chunk MUST abort the association 454 by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol 455 Violation' error cause. The same applies if I-DATA support has not 456 been negotiated for an association and an I-DATA chunk is received. 458 2.3. Interaction with other SCTP Extensions 460 The usage of the I-DATA chunk might interfere with other SCTP 461 extensions. Future SCTP extensions MUST describe if and how they 462 interfere with the usage of I-DATA chunks. For the SCTP extensions 463 already defined when this document was published, the details are 464 given in the following subsections. 466 2.3.1. SCTP Partial Reliability Extension 468 When the SCTP extension defined in [RFC3758] is used in combination 469 with the user message interleaving extension, the new I-FORWARD-TSN 470 chunk MUST be used instead of the FORWARD-TSN chunk. The difference 471 between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 472 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit 473 Message Identifier (MID) and the largest skipped MID can also be 474 provided for unordered messages. Therefore, the principle applied to 475 ordered message when using FORWARD-TSN chunks is applied to ordered 476 and unordered messages when using I-FORWARD-TSN chunks. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type = 194 | Flags = 0x00 | Length = Variable | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | New Cumulative TSN | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Stream Identifier | Reserved |U| 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Message Identifier | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 \ \ 490 / / 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Stream Identifier | Reserved |U| 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Message Identifier | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 4: I-FORWARD-TSN chunk format 499 The old fields are: 501 Flags: 8-bits (unsigned integer) 502 These bits are reserved. They MUST be set to 0 by the sender and 503 MUST be ignored by the receiver. Same as the Flags for FORWARD 504 TSN chunks as specified in [RFC3758]. 506 Length: 16-bits (unsigned integer) 507 This field holds the length of the chunk. Similar to the Length 508 for FORWARD TSN chunks as specified in [RFC3758]. 510 New Cumulative TSN: 32-bits (unsigned integer) 511 This indicates the new cumulative TSN to the data receiver. Same 512 as the New Cumulative TSN for FORWARD TSN chunks as specified in 513 [RFC3758]. 515 The new fields are: 517 Stream Identifier (SID): 16-bits (unsigned integer) 518 This field holds the stream number this entry refers to. 520 Reserved: 15 bits 521 This field is reserved. It MUST be set to 0 by the sender and 522 MUST be ignored by the receiver. 524 U bit: 1 bit 525 The U bit specifies if the Message Identifier of this entry refers 526 to unordered messages (U bit is set) or ordered messages (U bit is 527 not set). 529 Message Identifier (MID): 32 bits (unsigned integer) 530 This field holds the largest Message Identifier for ordered or 531 unordered messages indicated by the U bit that was skipped for the 532 stream specified by the Stream Identifier. For ordered messages 533 this is similar to the FORWARD-TSN chunk, just replacing the 534 16-bit SSN by the 32-bit MID. 536 Support for the I-FORWARD-TSN chunk is negotiated during the SCTP 537 association setup via the Supported Extensions Parameter as defined 538 in [RFC5061]. Only if both end points indicated their support of 539 user message interleaving and the I-FORWARD-TSN chunk, the partial 540 reliability extension is negotiated and can be used in combination 541 with user message interleaving. 543 The FORWARD-TSN chunk MUST be used in combination with the DATA chunk 544 and MUST NOT be used in combination with the I-DATA chunk. The I- 545 FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk 546 and MUST NOT be used in combination with the DATA chunk. 548 If I-FORWARD-TSN support has been negotiated for an association, the 549 reception of a FORWARD-TSN chunk is a violation of the above rules 550 and therefore the receiver of the FORWARD-TSN chunk MUST abort the 551 association by sending an ABORT chunk. The ABORT chunk MAY include 552 the 'Protocol Violation' error cause. The same applies if I-FORWARD- 553 TSN support has not been negotiated for an association and a FORWARD- 554 TSN chunk is received. 556 2.3.2. SCTP Stream Reconfiguration Extension 558 When an association resets the SSN using the SCTP extension defined 559 in [RFC6525], the two counters (one for the ordered messages, one for 560 the unordered messages) used for the MIDs MUST be reset to 0. 562 Since most schedulers, especially all schedulers supporting user 563 message interleaving, require late TSN assignment, it should be noted 564 that the implementation of [RFC6525] needs to handle this. 566 3. Stream Schedulers 568 This section defines several stream schedulers. The stream 569 schedulers may behave differently depending on whether user message 570 interleaving has been negotiated for the association or not. An 571 implementation MAY implement any subset of them. If the 572 implementation is used for WebRTC Datachannels as specified in 573 [I-D.ietf-rtcweb-data-channel] it MUST implement the Weighted Fair 574 Queueing Scheduler defined in Section 3.6. 576 The selection of the stream scheduler is done at the sender side. 577 There is no mechanism provided for signalling the stream scheduler 578 being used to the receiver side or even let the receiver side 579 influence the selection of the stream scheduler used at the sender 580 side. 582 3.1. First Come First Served Scheduler (SCTP_SS_FCFS) 584 The simple first-come, first-served scheduler of user messages is 585 used. It just passes through the messages in the order in which they 586 have been delivered by the application. No modification of the order 587 is done at all. The usage of user message interleaving does not 588 affect the sending of the chunks, except that I-DATA chunks are used 589 instead of DATA chunks. 591 3.2. Round Robin Scheduler (SCTP_SS_RR) 593 When not using user message interleaving, this scheduler provides a 594 fair scheduling based on the number of user messages by cycling 595 around non-empty stream queues. When using user message 596 interleaving, this scheduler provides a fair scheduling based on the 597 number of I-DATA chunks by cycling around non-empty stream queues. 599 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) 601 This is a round-robin scheduler, which only switches streams when 602 starting to fill a new packet. It bundles only DATA or I-DATA chunks 603 referring to the same stream in a packet. This scheduler minimizes 604 head-of-line blocking when a packet is lost because only a single 605 stream is affected. 607 3.4. Priority Based Scheduler (SCTP_SS_PRIO) 609 Scheduling of user messages with strict priorities is used. The 610 priority is configurable per outgoing SCTP stream. Streams having a 611 higher priority will be scheduled first and when multiple streams 612 have the same priority, the scheduling between them is implementation 613 dependent. When using user message interleaving, the sending of 614 large lower priority user messages will not delay the sending of 615 higher priority user messages. 617 3.5. Fair Capacity Scheduler (SCTP_SS_FC) 619 A fair capacity distribution between the streams is used. This 620 scheduler considers the lengths of the messages of each stream and 621 schedules them in a specific way to maintain an equal capacity for 622 all streams. The details are implementation dependent. Using user 623 message interleaving allows for a better realization of the fair 624 capacity usage. 626 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 628 A weighted fair queueing scheduler between the streams is used. The 629 weight is configurable per outgoing SCTP stream. This scheduler 630 considers the lengths of the messages of each stream and schedules 631 them in a specific way to use the capacity according to the given 632 weights. If the weight of stream S1 is n times the weight of stream 633 S2, the scheduler should assign to stream S1 n times the capacity it 634 assigns to stream S2. The details are implementation dependent. 635 Using user message interleaving allows for a better realization of 636 the capacity usage according to the given weights. 638 This scheduler in combination with user message interleaving is used 639 for WebRTC Datachannels as specified in 640 [I-D.ietf-rtcweb-data-channel]. 642 4. Socket API Considerations 644 This section describes how the socket API defined in [RFC6458] is 645 extended to allow applications to use the extension described in this 646 document. 648 Please note that this section is informational only. 650 4.1. Exposure of the Stream Sequence Number (SSN) 652 The socket API defined in [RFC6458] defines several structures in 653 which the SSN of a received user message is exposed to the 654 application. The list of these structures includes: 656 struct sctp_sndrcvinfo 657 Specified in Section 5.3.2 SCTP Header Information Structure 658 (SCTP_SNDRCV) of [RFC6458] and marked as deprecated. 660 struct sctp_extrcvinfo 661 Specified in Section 5.3.3 Extended SCTP Header Information 662 Structure (SCTP_EXTRCV)of [RFC6458] and marked as deprecated. 664 struct sctp_rcvinfo 665 Specified in Section 5.3.5 SCTP Receive Information Structure 666 (SCTP_RCVINFO) of [RFC6458]. 668 If user message interleaving is used, the lower order 16 bits of the 669 MID are used as the SSN when filling out these structures. 671 4.2. SCTP_ASSOC_CHANGE Notification 673 When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of 674 [RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or 675 SCTP_RESTART for an SCTP association where both peers support the 676 I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in 677 the sac_info field. 679 4.3. Socket Options 681 +-----------------------------+-------------------------+-----+-----+ 682 | option name | data type | get | set | 683 +-----------------------------+-------------------------+-----+-----+ 684 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 685 | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | 686 | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | 687 | | sctp_stream_value | | | 688 +-----------------------------+-------------------------+-----+-----+ 690 4.3.1. Enable or Disable the Support of User Message Interleaving 691 (SCTP_INTERLEAVING_SUPPORTED) 693 This socket option allows the enabling or disabling of the 694 negotiation of user message interleaving support for future 695 associations. For existing associations it allows to query whether 696 user message interleaving support was negotiated or not on a 697 particular association. 699 This socket option uses IPPROTO_SCTP as its level and 700 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 701 getsockopt() and setsockopt(). The socket option value uses the 702 following structure defined in [RFC6458]: 704 struct sctp_assoc_value { 705 sctp_assoc_t assoc_id; 706 uint32_t assoc_value; 707 }; 709 assoc_id: This parameter is ignored for one-to-one style sockets. 710 For one-to-many style sockets, this parameter indicates upon which 711 association the user is performing an action. The special 712 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 713 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 715 assoc_value: A non-zero value encodes the enabling of user message 716 interleaving whereas a value of 0 encodes the disabling of user 717 message interleaving. 719 sctp_opt_info() needs to be extended to support 720 SCTP_INTERLEAVING_SUPPORTED. 722 An application using user message interleaving should also set the 723 fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE 724 socket option specified in Section 8.1.20 of [RFC6458]. This allows 725 the interleaving of user messages from different streams. Please 726 note that it does not allow the interleaving of user messages 727 (ordered or unordered) on the same stream. Failure to set this 728 option can possibly lead to application deadlock. Some 729 implementations might therefore put some restrictions on setting 730 combinations of these values. Setting the interleaving level to at 731 least 2 before enabling the negotiation of user message interleaving 732 should work on all platforms. Since the default fragment interleave 733 level is not 2, user message interleaving is disabled per default. 735 4.3.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) 737 A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER 738 option for setsockopt(). The struct sctp_assoc_value is used to 739 specify the association for which the scheduler should be changed and 740 the value of the desired algorithm. 742 The definition of struct sctp_assoc_value is the same as in 743 [RFC6458]: 745 struct sctp_assoc_value { 746 sctp_assoc_t assoc_id; 747 uint32_t assoc_value; 748 }; 750 assoc_id: Holds the identifier for the association of which the 751 scheduler should be changed. The special 752 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 753 is ignored for one-to-one style sockets. 755 assoc_value: This specifies which scheduler is used. The following 756 constants can be used: 758 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 759 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 761 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1. 763 SCTP_SS_RR: Use the scheduler specified in Section 3.2. 765 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3. 767 SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The 768 priority can be assigned with the sctp_stream_value struct. 769 The higher the assigned value, the lower the priority, that is 770 the default value 0 is the highest priority and therefore the 771 default scheduling will be used if no priorities have been 772 assigned. 774 SCTP_SS_FB: Use the scheduler specified in Section 3.5. 776 SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The 777 weight can be assigned with the sctp_stream_value struct. 779 sctp_opt_info() needs to be extended to support 780 SCTP_STREAM_SCHEDULER. 782 4.3.3. Get or Set the Stream Scheduler Parameter 783 (SCTP_STREAM_SCHEDULER_VALUE) 785 Some schedulers require additional information to be set for 786 individual streams as shown in the following table: 788 +-----------------+-----------------+ 789 | name | per stream info | 790 +-----------------+-----------------+ 791 | SCTP_SS_DEFAULT | n/a | 792 | SCTP_SS_FCFS | no | 793 | SCTP_SS_RR | no | 794 | SCTP_SS_RR_PKT | no | 795 | SCTP_SS_PRIO | yes | 796 | SCTP_SS_FB | no | 797 | SCTP_SS_WFQ | yes | 798 +-----------------+-----------------+ 800 This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the 801 corresponding struct sctp_stream_value. The definition of struct 802 sctp_stream_value is as follows: 804 struct sctp_stream_value { 805 sctp_assoc_t assoc_id; 806 uint16_t stream_id; 807 uint16_t stream_value; 808 }; 809 assoc_id: Holds the identifier for the association of which the 810 scheduler should be changed. The special 811 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 812 is ignored for one-to-one style sockets. 814 stream_id: Holds the stream id of the stream for which additional 815 information has to be provided. 817 stream_value: The meaning of this field depends on the scheduler 818 specified. It is ignored when the scheduler does not need 819 additional information. 821 sctp_opt_info() needs to be extended to support 822 SCTP_STREAM_SCHEDULER_VALUE. 824 4.4. Explicit EOR Marking 826 Using explicit End of Record (EOR) marking for an SCTP association 827 supporting user message interleaving allows the user to interleave 828 the sending of user messages on different streams. 830 5. IANA Considerations 832 [NOTE to RFC-Editor: 834 "RFCXXXX" is to be replaced by the RFC number you assign this 835 document. 837 ] 839 [NOTE to RFC-Editor: 841 The suggested values for the chunk types and the chunk flags are 842 tentative and to be confirmed by IANA. 844 ] 846 This document (RFCXXXX) is the reference for all registrations 847 described in this section. 849 Two new chunk types have to be assigned by IANA. 851 5.1. I-DATA Chunk 853 IANA should assign the chunk type for this chunk from the pool of 854 chunks with the upper two bits set to '01'. This requires an 855 additional line in the "Chunk Types" registry for SCTP: 857 +----------+--------------------------------------------+-----------+ 858 | ID Value | Chunk Type | Reference | 859 +----------+--------------------------------------------+-----------+ 860 | 64 | Payload Data supporting Interleaving | [RFCXXXX] | 861 | | (I-DATA) | | 862 +----------+--------------------------------------------+-----------+ 864 The registration table as defined in [RFC6096] for the chunk flags of 865 this chunk type is initially given by the following table: 867 +------------------+-----------------+-----------+ 868 | Chunk Flag Value | Chunk Flag Name | Reference | 869 +------------------+-----------------+-----------+ 870 | 0x01 | E bit | [RFCXXXX] | 871 | 0x02 | B bit | [RFCXXXX] | 872 | 0x04 | U bit | [RFCXXXX] | 873 | 0x08 | I bit | [RFCXXXX] | 874 | 0x10 | Unassigned | | 875 | 0x20 | Unassigned | | 876 | 0x40 | Unassigned | | 877 | 0x80 | Unassigned | | 878 +------------------+-----------------+-----------+ 880 5.2. I-FORWARD-TSN Chunk 882 IANA should assign the chunk type for this chunk from the pool of 883 chunks with the upper two bits set to '11'. This requires an 884 additional line in the "Chunk Types" registry for SCTP: 886 +----------+---------------+-----------+ 887 | ID Value | Chunk Type | Reference | 888 +----------+---------------+-----------+ 889 | 194 | I-FORWARD-TSN | [RFCXXXX] | 890 +----------+---------------+-----------+ 892 The registration table as defined in [RFC6096] for the chunk flags of 893 this chunk type is initially empty. 895 6. Security Considerations 897 This document does not add any additional security considerations in 898 addition to the ones given in [RFC4960] and [RFC6458]. 900 It should be noted that the application has to consent that it is 901 willing to do the more complex reassembly support required for user 902 message interleaving. When doing so, an application has to provide a 903 reassembly buffer for each incoming stream. It has to protect itself 904 against these buffers taking too many resources. If user message 905 interleaving is not used, only a single reassembly buffer needs to be 906 provided for each association. But the application has to protect 907 itself for excessive resource usages there too. 909 7. Acknowledgments 911 The authors wish to thank Benoit Claise, Julian Cordes, Spencer 912 Dawkins, Gorry Fairhurst, Lennart Grahl, Christer Holmberg, Mirja 913 Kuehlewind, Marcelo Ricardo Leitner, Karen E. Egede Nielsen, Maksim 914 Proshin, Eric Rescorla, Irene Ruengeler, Felix Weinrank, Michael 915 Welzl, Magnus Westerlund, and Lixia Zhang for their invaluable 916 comments. 918 This work has received funding from the European Union's Horizon 2020 919 research and innovation programme under grant agreement No. 644334 920 (NEAT). The views expressed are solely those of the author(s). 922 8. References 924 8.1. Normative References 926 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 927 DOI 10.17487/RFC1982, August 1996, . 930 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", BCP 14, RFC 2119, 932 DOI 10.17487/RFC2119, March 1997, . 935 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 936 Conrad, "Stream Control Transmission Protocol (SCTP) 937 Partial Reliability Extension", RFC 3758, 938 DOI 10.17487/RFC3758, May 2004, . 941 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 942 RFC 4960, DOI 10.17487/RFC4960, September 2007, 943 . 945 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 946 Kozuka, "Stream Control Transmission Protocol (SCTP) 947 Dynamic Address Reconfiguration", RFC 5061, 948 DOI 10.17487/RFC5061, September 2007, . 951 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 952 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 953 DOI 10.17487/RFC6096, January 2011, . 956 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 957 Transmission Protocol (SCTP) Stream Reconfiguration", 958 RFC 6525, DOI 10.17487/RFC6525, February 2012, 959 . 961 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 962 IMMEDIATELY Extension for the Stream Control Transmission 963 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 964 . 966 8.2. Informative References 968 [I-D.ietf-rtcweb-data-channel] 969 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 970 Channels", draft-ietf-rtcweb-data-channel-13 (work in 971 progress), January 2015. 973 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 974 A., Peterson, J., Sparks, R., Handley, M., and E. 975 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 976 DOI 10.17487/RFC3261, June 2002, . 979 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 980 Yasevich, "Sockets API Extensions for the Stream Control 981 Transmission Protocol (SCTP)", RFC 6458, 982 DOI 10.17487/RFC6458, December 2011, . 985 Authors' Addresses 987 Randall R. Stewart 988 Netflix, Inc. 989 Chapin, SC 29036 990 United States 992 Email: randall@lakerest.net 993 Michael Tuexen 994 Muenster University of Applied Sciences 995 Stegerwaldstrasse 39 996 48565 Steinfurt 997 Germany 999 Email: tuexen@fh-muenster.de 1001 Salvatore Loreto 1002 Ericsson 1003 Torshamnsgatan 21 1004 164 80 Stockholm 1005 Sweden 1007 Email: Salvatore.Loreto@ericsson.com 1009 Robin Seggelmann 1010 Metafinanz Informationssysteme GmbH 1011 Leopoldstrasse 146 1012 80804 Muenchen 1013 Germany 1015 Email: rfc@robin-seggelmann.com