idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-12.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 (August 9, 2017) is 2444 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 827, 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: February 10, 2018 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 Metafinanz Informationssysteme GmbH 10 August 9, 2017 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-12.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. A stream 28 scheduler can choose to either implement, or not implement, user 29 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 February 10, 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 . . . . . . . . . . . . . . . . . . . . . 8 72 2.2.2. Sender Side Considerations . . . . . . . . . . . . . 8 73 2.2.3. Receiver Side Considerations . . . . . . . . . . . . 9 74 2.3. Interaction with other SCTP Extensions . . . . . . . . . 9 75 2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 9 76 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 11 77 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 11 78 3.1. First Come First Served Scheduler (SCTP_SS_FCFS) . . . . 11 79 3.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 12 80 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 12 81 3.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 12 82 3.5. Fair Capacity Scheduler (SCTP_SS_FC) . . . . . . . . . . 12 83 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 12 84 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 13 85 4.1. Exposure of the Stream Sequence Number (SSN) . . . . . . 13 86 4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 13 87 4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 14 88 4.3.1. Enable or Disable the Support of User Message 89 Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 14 90 4.3.2. Get or Set the Stream Scheduler 91 (SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 15 92 4.3.3. Get or Set the Stream Scheduler Parameter 93 (SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 16 94 4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 17 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 5.1. I-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . 17 97 5.2. I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . . 18 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 102 8.2. Informative References . . . . . . . . . . . . . . . . . 20 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 an urgent 120 message is blocked from transmission because the sender has started 121 the transmission of another, possibly large, message). This head of 122 line blocking is caused by the use of the Transmission Sequence 123 Number (TSN) for three different purposes: 125 1. As an identifier for DATA chunks to provide a reliable transfer. 127 2. As an identifier for the sequence of fragments to allow 128 reassembly. 130 3. As a sequence number allowing 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. The stream schedulers may behave differently depending 139 on whether user message interleaving has been negotiated for the 140 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 | 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 new fields are: 287 Reserved: 16 bits (unsigned integer) 288 This field is reserved. It MUST be set to 0 by the sender and 289 MUST be ignored by the receiver. 291 Message Identifier (MID): 32 bits (unsigned integer) 292 The MID is the same for all fragments of a user message, it is 293 used to determine which fragments (enumerated by the FSN) belong 294 to the same user message. For ordered user messages, the MID is 295 also used by the SCTP receiver to deliver the user messages in the 296 correct order to the upper layer (similar to the SSN of the DATA 297 chunk defined in [RFC4960]). The sender uses two counters for 298 each outgoing stream, one for ordered messages, one for unordered 299 messages. All counters are independent and initially 0. They are 300 incremented by 1 for each user message. Please note that the 301 serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 302 32 applies. Therefore, the sender MUST NOT have more than 2**31 - 303 1 ordered messages for each outgoing stream in flight and MUST NOT 304 have more than 2**31 - 1 unordered messages for each outgoing 305 stream in flight. A message is considered in flight, if at least 306 on of its I-DATA chunks is not acknowledged in a non-renegable way 307 (i.e. acknowledged by the cumulative TSN Ack). Please note that 308 the MID is in "network byte order", a.k.a. Big Endian. 310 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 311 32 bits (unsigned integer) 312 If the B bit is set, this field contains the PPID of the user 313 message. Note that in this case, this field is not touched by an 314 SCTP implementation; therefore, its byte order is not necessarily 315 in network byte order. The upper layer is responsible for any 316 byte order conversions to this field, similar to the PPID of DATA 317 chunks. In this case the FSN is implicitly considered to be 0. 318 If the B bit is not set, this field contains the FSN. The FSN is 319 used to enumerate all fragments of a single user message, starting 320 from 0 and incremented by 1. The last fragment of a message MUST 321 have the E bit set. Note that the FSN MAY wrap completely 322 multiple times allowing arbitrarily large user messages. For the 323 FSN the serial number arithmetic defined in [RFC1982] applies with 324 SERIAL_BITS = 32. Therefore, a sender MUST NOT have more than 325 2**31 - 1 fragments of a single user message in flight. A 326 fragment is considered in flight, if it is not acknowledged in a 327 non-renegable way (i.e. acknowledged by the cumulative TSN Ack). 328 Please note that the FSN is in "network byte order", a.k.a. Big 329 Endian. 331 2.2. Procedures 333 This subsection describes how the support of the I-DATA chunk is 334 negotiated and how the I-DATA chunk is used by the sender and 335 receiver. 337 2.2.1. Negotiation 339 An SCTP end point indicates user message interleaving support by 340 listing the I-DATA Chunk within the Supported Extensions Parameter as 341 defined in [RFC5061]. User message interleaving has been negotiated 342 for an association if both end points have indicated I-DATA support. 344 If user message interleaving support has been negotiated for an 345 association, I-DATA chunks MUST be used for all user messages and 346 DATA-chunks MUST NOT be used. If user message interleaving support 347 has not been negotiated for an association, DATA chunks MUST be used 348 for all user messages and I-DATA chunks MUST NOT be used. 350 An end point implementing the socket API specified in [RFC6458] MUST 351 NOT indicate user message interleaving support unless the user has 352 requested its use (e.g. via the socket API, see Section 4.3). This 353 constraint is made since the usage of this chunk requires that the 354 application is capable of handling interleaved messages upon 355 reception within an association. This is not the default choice 356 within the socket API (see the SCTP_FRAGMENT_INTERLEAVE socket option 357 in Section 8.1.20 of [RFC6458]) thus the user MUST indicate to the 358 SCTP implementation its support for receiving completely interleaved 359 messages. 361 Note that stacks that do not implement [RFC6458] may use other 362 methods to indicate interleaved message support and thus indicate the 363 support of user message interleaving. The crucial point is that the 364 SCTP stack MUST know that the application can handle interleaved 365 messages before indicating the I-DATA support. 367 2.2.2. Sender Side Considerations 369 The sender side usage of the I-DATA chunk is quite simple. Instead 370 of using the TSN for fragmentation purposes, the sender uses the new 371 FSN field to indicate which fragment number is being sent. The first 372 fragment MUST have the B bit set. The last fragment MUST have the E 373 bit set. All other fragments MUST NOT have the B bit or E bit set. 374 All other properties of the existing SCTP DATA chunk also apply to 375 the I-DATA chunk, i.e. congestion control as well as receiver window 376 conditions MUST be observed as defined in [RFC4960]. 378 Note that the usage of this chunk implies the late assignment of the 379 actual TSN to any chunk being sent. Each I-DATA chunk uses a single 380 TSN. This way messages from other streams may be interleaved with 381 the fragmented message. Please note that this is the only form of 382 interleaving support. For example, it is not possible to interleave 383 multiple ordered or unordered user messages from the same stream. 385 The sender MUST NOT fragment more than one user message in any given 386 stream at any time. At any time, a sender MAY fragment multiple user 387 messages, each of them on different streams. 389 The sender MUST assign TSNs in a way that the receiver can make 390 progress. One way to achieve this is to assign a higher TSN to the 391 later fragments of a user message and send out the TSNs in sequence. 393 2.2.3. Receiver Side Considerations 395 Upon reception of an SCTP packet containing an I-DATA chunk whose 396 user message needs to be reassembled, the receiver MUST first use the 397 SID to identify the stream, consider the U bit to determine if it is 398 part of an ordered or unordered message, find the user message 399 identified by the MID and finally use the FSN for reassembly of the 400 message and not the TSN. The receiver MUST NOT make any assumption 401 about the TSN assignments of the sender. Note that a non-fragmented 402 message is indicated by the fact that both the E and B bits are set. 403 A message (either ordered or unordered) may be identified as being 404 fragmented whose E and B bits are not both set. 406 If I-DATA support has been negotiated for an association, the 407 reception of a DATA chunk is a violation of the above rules and 408 therefore the receiver of the DATA chunk MUST abort the association 409 by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol 410 Violation' error cause. The same applies if I-DATA support has not 411 been negotiated for an association and an I-DATA chunk is received. 413 2.3. Interaction with other SCTP Extensions 415 The usage of the I-DATA chunk might interfere with other SCTP 416 extensions. Future SCTP extensions MUST describe if and how they 417 interfere with the usage of I-DATA chunks. For the SCTP extensions 418 already defined when this document was published, the details are 419 given in the following subsections. 421 2.3.1. SCTP Partial Reliability Extension 423 When the SCTP extension defined in [RFC3758] is used in combination 424 with the user message interleaving extension, the new I-FORWARD-TSN 425 chunk MUST be used instead of the FORWARD-TSN chunk. The difference 426 between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 427 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit 428 Message Identifier (MID) and the largest skipped MID can also be 429 provided for unordered messages. Therefore, the principle applied to 430 ordered message when using FORWARD-TSN chunks is applied to ordered 431 and unordered messages when using I-FORWARD-TSN chunks. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type = 194 | Flags = 0x00 | Length = Variable | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | New Cumulative TSN | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Stream Identifier | Reserved |U| 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Message Identifier | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 \ \ 445 / / 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Stream Identifier | Reserved |U| 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Message Identifier | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 4: I-FORWARD-TSN chunk format 454 The relevant new fields are: 456 Stream Identifier (SID): 16-bits (unsigned integer) 457 This field holds the stream number this entry refers to. 459 Reserved: 15 bits 460 This field is reserved. It MUST be set to 0 by the sender and 461 MUST be ignored by the receiver. 463 U bit: 1 bit 464 The U bit specifies if the Message Identifier of this entry refers 465 to unordered messages (U bit is set) or ordered messages (U bit is 466 not set). 468 Message Identifier (MID): 32 bits (unsigned integer) 469 This field holds the largest Message Identifier for ordered or 470 unordered messages indicated by the U bit that was skipped for the 471 stream specified by the Stream Identifier. For ordered messages 472 this is similar to the FORWARD-TSN chunk, just replacing the 473 16-bit SSN by the 32-bit MID. 475 Support for the I-FORWARD-TSN chunk is negotiated during the SCTP 476 association setup via the Supported Extensions Parameter as defined 477 in [RFC5061]. Only if both end points indicated their support of 478 user message interleaving and the I-FORWARD-TSN chunk, the partial 479 reliability extension is negotiated and can be used in combination 480 with user message interleaving. 482 The FORWARD-TSN chunk MUST be used in combination with the DATA chunk 483 and MUST NOT be used in combination with the I-DATA chunk. The I- 484 FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk 485 and MUST NOT be used in combination with the DATA chunk. 487 If I-FORWARD-TSN support has been negotiated for an association, the 488 reception of a FORWARD-TSN chunk is a violation of the above rules 489 and therefore the receiver of the FORWARD-TSN chunk MUST abort the 490 association by sending an ABORT chunk. The ABORT chunk MAY include 491 the 'Protocol Violation' error cause. The same applies if I-FORWARD- 492 TSN support has not been negotiated for an association and a FORWARD- 493 TSN chunk is received. 495 2.3.2. SCTP Stream Reconfiguration Extension 497 When an association resets the SSN using the SCTP extension defined 498 in [RFC6525], the two counters (one for the ordered messages, one for 499 the unordered messages) used for the MIDs MUST be reset to 0. 501 Since most schedulers, especially all schedulers supporting user 502 message interleaving, require late TSN assignment, it should be noted 503 that the implementation of [RFC6525] needs to handle this. 505 3. Stream Schedulers 507 This section defines several stream schedulers. The stream 508 schedulers may behave differently depending on whether user message 509 interleaving has been negotiated for the association or not. An 510 implementation MAY implement any subset of them. 512 The selection of the stream scheduler is done at the sender side. 513 There is no mechanism provided for signalling the stream scheduler 514 being used to the receiver side or even let the receiver side 515 influence the selection of the stream scheduler used at the sender 516 side. 518 3.1. First Come First Served Scheduler (SCTP_SS_FCFS) 520 The simple first-come, first-served scheduler of user messages is 521 used. It just passes through the messages in the order in which they 522 have been delivered by the application. No modification of the order 523 is done at all. The usage of user message interleaving does not 524 affect the sending of the chunks, except that I-DATA chunks are used 525 instead of DATA chunks. 527 3.2. Round Robin Scheduler (SCTP_SS_RR) 529 When not using user message interleaving, this scheduler provides a 530 fair scheduling based on the number of user messages by cycling 531 around non-empty stream queues. When using user message 532 interleaving, this scheduler provides a fair scheduling based on the 533 number of I-DATA chunks by cycling around non-empty stream queues. 535 3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) 537 This is a round-robin scheduler, which only switches streams when 538 starting to fill a new packet. It bundles only DATA or I-DATA chunks 539 referring to the same stream in a packet. This scheduler minimizes 540 head-of-line blocking when a packet is lost because only a single 541 stream is affected. 543 3.4. Priority Based Scheduler (SCTP_SS_PRIO) 545 Scheduling of user messages with strict priorities is used. The 546 priority is configurable per outgoing SCTP stream. Streams having a 547 higher priority will be scheduled first and when multiple streams 548 have the same priority, the scheduling between them is implementation 549 dependent. When using user message interleaving, the sending of 550 large lower priority user messages will not delay the sending of 551 higher priority user messages. 553 3.5. Fair Capacity Scheduler (SCTP_SS_FC) 555 A fair capacity distribution between the streams is used. This 556 scheduler considers the lengths of the messages of each stream and 557 schedules them in a specific way to maintain an equal capacity for 558 all streams. The details are implementation dependent. Using user 559 message interleaving allows for a better realization of the fair 560 capacity usage. 562 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) 564 A weighted fair queueing scheduler between the streams is used. The 565 weight is configurable per outgoing SCTP stream. This scheduler 566 considers the lengths of the messages of each stream and schedules 567 them in a specific way to use the capacity according to the given 568 weights. If the weight of stream S1 is n times the weight of stream 569 S2, the scheduler should assign to stream S1 n times the capacity it 570 assigns to stream S2. The details are implementation dependent. 572 Using user message interleaving allows for a better realization of 573 the capacity usage according to the given weights. 575 This scheduler in combination with user message interleaving is used 576 for WebRTC Datachannels as specified in 577 [I-D.ietf-rtcweb-data-channel]. 579 4. Socket API Considerations 581 This section describes how the socket API defined in [RFC6458] is 582 extended to allow applications to use the extension described in this 583 document. 585 Please note that this section is informational only. 587 4.1. Exposure of the Stream Sequence Number (SSN) 589 The socket API defined in [RFC6458] defines several structures in 590 which the SSN of a received user message is exposed to the 591 application. The list of these structures includes: 593 struct sctp_sndrcvinfo 594 Specified in Section 5.3.2 SCTP Header Information Structure 595 (SCTP_SNDRCV) of [RFC6458] and marked as deprecated. 597 struct sctp_extrcvinfo 598 Specified in Section 5.3.3 Extended SCTP Header Information 599 Structure (SCTP_EXTRCV)of [RFC6458] and marked as deprecated. 601 struct sctp_rcvinfo 602 Specified in Section 5.3.5 SCTP Receive Information Structure 603 (SCTP_RCVINFO) of [RFC6458]. 605 If user message interleaving is used, the lower order 16 bits of the 606 MID are used as the SSN when filling out these structures. 608 4.2. SCTP_ASSOC_CHANGE Notification 610 When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of 611 [RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or 612 SCTP_RESTART for an SCTP association where both peers support the 613 I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in 614 the sac_info field. 616 4.3. Socket Options 618 +-----------------------------+-------------------------+-----+-----+ 619 | option name | data type | get | set | 620 +-----------------------------+-------------------------+-----+-----+ 621 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 622 | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | 623 | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | 624 | | sctp_stream_value | | | 625 +-----------------------------+-------------------------+-----+-----+ 627 4.3.1. Enable or Disable the Support of User Message Interleaving 628 (SCTP_INTERLEAVING_SUPPORTED) 630 This socket option allows the enabling or disabling of the 631 negotiation of user message interleaving support for future 632 associations. For existing associations it allows to query whether 633 user message interleaving support was negotiated or not on a 634 particular association. 636 This socket option uses IPPROTO_SCTP as its level and 637 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 638 getsockopt() and setsockopt(). The socket option value uses the 639 following structure defined in [RFC6458]: 641 struct sctp_assoc_value { 642 sctp_assoc_t assoc_id; 643 uint32_t assoc_value; 644 }; 646 assoc_id: This parameter is ignored for one-to-one style sockets. 647 For one-to-many style sockets, this parameter indicates upon which 648 association the user is performing an action. The special 649 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 650 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 652 assoc_value: A non-zero value encodes the enabling of user message 653 interleaving whereas a value of 0 encodes the disabling of user 654 message interleaving. 656 sctp_opt_info() needs to be extended to support 657 SCTP_INTERLEAVING_SUPPORTED. 659 An application using user message interleaving should also set the 660 fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE 661 socket option specified in Section 8.1.20 of [RFC6458]. This allows 662 the interleaving of user messages from different streams. Please 663 note that it does not allow the interleaving of user messages 664 (ordered or unordered) on the same stream. Failure to set this 665 option can possibly lead to application deadlock. Some 666 implementations might therefore put some restrictions on setting 667 combinations of these values. Setting the interleaving level to at 668 least 2 before enabling the negotiation of user message interleaving 669 should work on all platforms. Since the default fragment interleave 670 level is not 2, user message interleaving is disabled per default. 672 4.3.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) 674 A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER 675 option for setsockopt(). The struct sctp_assoc_value is used to 676 specify the association for which the scheduler should be changed and 677 the value of the desired algorithm. 679 The definition of struct sctp_assoc_value is the same as in 680 [RFC6458]: 682 struct sctp_assoc_value { 683 sctp_assoc_t assoc_id; 684 uint32_t assoc_value; 685 }; 687 assoc_id: Holds the identifier for the association of which the 688 scheduler should be changed. The special 689 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 690 is ignored for one-to-one style sockets. 692 assoc_value: This specifies which scheduler is used. The following 693 constants can be used: 695 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 696 implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. 698 SCTP_SS_FCFS: Use the scheduler specified in Section 3.1. 700 SCTP_SS_RR: Use the scheduler specified in Section 3.2. 702 SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3. 704 SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The 705 priority can be assigned with the sctp_stream_value struct. 706 The higher the assigned value, the lower the priority, that is 707 the default value 0 is the highest priority and therefore the 708 default scheduling will be used if no priorities have been 709 assigned. 711 SCTP_SS_FB: Use the scheduler specified in Section 3.5. 713 SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The 714 weight can be assigned with the sctp_stream_value struct. 716 sctp_opt_info() needs to be extended to support 717 SCTP_STREAM_SCHEDULER. 719 4.3.3. Get or Set the Stream Scheduler Parameter 720 (SCTP_STREAM_SCHEDULER_VALUE) 722 Some schedulers require additional information to be set for 723 individual streams as shown in the following table: 725 +-----------------+-----------------+ 726 | name | per stream info | 727 +-----------------+-----------------+ 728 | SCTP_SS_DEFAULT | n/a | 729 | SCTP_SS_FCFS | no | 730 | SCTP_SS_RR | no | 731 | SCTP_SS_RR_PKT | no | 732 | SCTP_SS_PRIO | yes | 733 | SCTP_SS_FB | no | 734 | SCTP_SS_WFQ | yes | 735 +-----------------+-----------------+ 737 This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the 738 corresponding struct sctp_stream_value. The definition of struct 739 sctp_stream_value is as follows: 741 struct sctp_stream_value { 742 sctp_assoc_t assoc_id; 743 uint16_t stream_id; 744 uint16_t stream_value; 745 }; 747 assoc_id: Holds the identifier for the association of which the 748 scheduler should be changed. The special 749 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 750 is ignored for one-to-one style sockets. 752 stream_id: Holds the stream id of the stream for which additional 753 information has to be provided. 755 stream_value: The meaning of this field depends on the scheduler 756 specified. It is ignored when the scheduler does not need 757 additional information. 759 sctp_opt_info() needs to be extended to support 760 SCTP_STREAM_SCHEDULER_VALUE. 762 4.4. Explicit EOR Marking 764 Using explicit End of Record (EOR) marking for an SCTP association 765 supporting user message interleaving allows the user to interleave 766 the sending of user messages on different streams. 768 5. IANA Considerations 770 [NOTE to RFC-Editor: 772 "RFCXXXX" is to be replaced by the RFC number you assign this 773 document. 775 ] 777 [NOTE to RFC-Editor: 779 The suggested values for the chunk types and the chunk flags are 780 tentative and to be confirmed by IANA. 782 ] 784 This document (RFCXXXX) is the reference for all registrations 785 described in this section. 787 Two new chunk types have to be assigned by IANA. 789 5.1. I-DATA Chunk 791 IANA should assign the chunk type for this chunk from the pool of 792 chunks with the upper two bits set to '01'. This requires an 793 additional line in the "Chunk Types" registry for SCTP: 795 +----------+--------------------------------------------+-----------+ 796 | ID Value | Chunk Type | Reference | 797 +----------+--------------------------------------------+-----------+ 798 | 64 | Payload Data supporting Interleaving | [RFCXXXX] | 799 | | (I-DATA) | | 800 +----------+--------------------------------------------+-----------+ 802 The registration table as defined in [RFC6096] for the chunk flags of 803 this chunk type is initially given by the following table: 805 +------------------+-----------------+-----------+ 806 | Chunk Flag Value | Chunk Flag Name | Reference | 807 +------------------+-----------------+-----------+ 808 | 0x01 | E bit | [RFCXXXX] | 809 | 0x02 | B bit | [RFCXXXX] | 810 | 0x04 | U bit | [RFCXXXX] | 811 | 0x08 | I bit | [RFCXXXX] | 812 | 0x10 | Unassigned | | 813 | 0x20 | Unassigned | | 814 | 0x40 | Unassigned | | 815 | 0x80 | Unassigned | | 816 +------------------+-----------------+-----------+ 818 5.2. I-FORWARD-TSN Chunk 820 IANA should assign the chunk type for this chunk from the pool of 821 chunks with the upper two bits set to '11'. This requires an 822 additional line in the "Chunk Types" registry for SCTP: 824 +----------+---------------+-----------+ 825 | ID Value | Chunk Type | Reference | 826 +----------+---------------+-----------+ 827 | 194 | I-FORWARD-TSN | [RFCXXXX] | 828 +----------+---------------+-----------+ 830 The registration table as defined in [RFC6096] for the chunk flags of 831 this chunk type is initially empty. 833 6. Security Considerations 835 This document does not add any additional security considerations in 836 addition to the ones given in [RFC4960] and [RFC6458]. 838 It should be noted that the application has to consent that it is 839 willing to do the more complex reassembly support required for user 840 message interleaving. When doing so, an application has to provide 841 up to two reassembly buffers (one for ordered messages, one for 842 unordered messages) for each incoming stream. It has to protect 843 itself against these buffers taking too many resources. If user 844 message interleaving is not used, only a single reassembly buffer 845 needs to be provided for each association. But the application has 846 to protect itself for excessive resource usages there too. 848 7. Acknowledgments 850 The authors wish to thank Julian Cordes, Spencer Dawkins, Gorry 851 Fairhurst, Lennart Grahl, Christer Holmberg, Marcelo Ricardo Leitner, 852 Karen E. Egede Nielsen, Maksim Proshin, Irene Ruengeler, Felix 853 Weinrank, Michael Welzl, Magnus Westerlund, and Lixia Zhang for their 854 invaluable comments. 856 This work has received funding from the European Union's Horizon 2020 857 research and innovation programme under grant agreement No. 644334 858 (NEAT). The views expressed are solely those of the author(s). 860 8. References 862 8.1. Normative References 864 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 865 DOI 10.17487/RFC1982, August 1996, 866 . 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, 870 DOI 10.17487/RFC2119, March 1997, 871 . 873 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 874 Conrad, "Stream Control Transmission Protocol (SCTP) 875 Partial Reliability Extension", RFC 3758, 876 DOI 10.17487/RFC3758, May 2004, 877 . 879 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 880 RFC 4960, DOI 10.17487/RFC4960, September 2007, 881 . 883 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 884 Kozuka, "Stream Control Transmission Protocol (SCTP) 885 Dynamic Address Reconfiguration", RFC 5061, 886 DOI 10.17487/RFC5061, September 2007, 887 . 889 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 890 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 891 DOI 10.17487/RFC6096, January 2011, 892 . 894 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 895 Transmission Protocol (SCTP) Stream Reconfiguration", 896 RFC 6525, DOI 10.17487/RFC6525, February 2012, 897 . 899 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 900 IMMEDIATELY Extension for the Stream Control Transmission 901 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 902 . 904 8.2. Informative References 906 [I-D.ietf-rtcweb-data-channel] 907 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 908 Channels", draft-ietf-rtcweb-data-channel-13 (work in 909 progress), January 2015. 911 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 912 A., Peterson, J., Sparks, R., Handley, M., and E. 913 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 914 DOI 10.17487/RFC3261, June 2002, 915 . 917 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 918 Yasevich, "Sockets API Extensions for the Stream Control 919 Transmission Protocol (SCTP)", RFC 6458, 920 DOI 10.17487/RFC6458, December 2011, 921 . 923 Authors' Addresses 925 Randall R. Stewart 926 Netflix, Inc. 927 Chapin, SC 29036 928 United States 930 Email: randall@lakerest.net 932 Michael Tuexen 933 Muenster University of Applied Sciences 934 Stegerwaldstrasse 39 935 48565 Steinfurt 936 Germany 938 Email: tuexen@fh-muenster.de 939 Salvatore Loreto 940 Ericsson 941 Torshamnsgatan 21 942 164 80 Stockholm 943 Sweden 945 Email: Salvatore.Loreto@ericsson.com 947 Robin Seggelmann 948 Metafinanz Informationssysteme GmbH 949 Leopoldstrasse 146 950 80804 Muenchen 951 Germany 953 Email: rfc@robin-seggelmann.com