diff options
Diffstat (limited to 'doc/rfc/rfc8260.txt')
| -rw-r--r-- | doc/rfc/rfc8260.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc8260.txt b/doc/rfc/rfc8260.txt new file mode 100644 index 0000000..9144f7a --- /dev/null +++ b/doc/rfc/rfc8260.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Stewart +Request for Comments: 8260 Netflix, Inc. +Category: Standards Track M. Tuexen +ISSN: 2070-1721 Muenster Univ. of Appl. Sciences + S. Loreto + Ericsson + R. Seggelmann + Metafinanz Informationssysteme GmbH + November 2017 + + + Stream Schedulers and User Message Interleaving + for the Stream Control Transmission Protocol + +Abstract + + The Stream Control Transmission Protocol (SCTP) is a message-oriented + transport protocol supporting arbitrarily large user messages. This + document adds a new chunk to SCTP for carrying payload data. This + allows a sender to interleave different user messages that would + otherwise result in head-of-line blocking at the sender. The + interleaving of user messages is required for WebRTC data channels. + + Whenever an SCTP sender is allowed to send user data, it may choose + from multiple outgoing SCTP streams. Multiple ways for performing + this selection, called stream schedulers, are defined in this + document. A stream scheduler can choose to either implement, or not + implement, user message interleaving. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8260. + + + + + + + + + +Stewart, et al. Standards Track [Page 1] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stewart, et al. Standards Track [Page 2] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 + 2. User Message Interleaving . . . . . . . . . . . . . . . . . . 6 + 2.1. The I-DATA Chunk Supporting User Message Interleaving . . 7 + 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 10 + 2.2.2. Sender-Side Considerations . . . . . . . . . . . . . 10 + 2.2.3. Receiver-Side Considerations . . . . . . . . . . . . 11 + 2.3. Interaction with Other SCTP Extensions . . . . . . . . . 11 + 2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 11 + 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 13 + 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1. First-Come, First-Served Scheduler (SCTP_SS_FCFS) . . . . 14 + 3.2. Round-Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 14 + 3.3. Round-Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 14 + 3.4. Priority-Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 14 + 3.5. Fair Capacity Scheduler (SCTP_SS_FC) . . . . . . . . . . 15 + 3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 15 + 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 15 + 4.1. Exposure of the Stream Sequence Number (SSN) . . . . . . 15 + 4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 16 + 4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 16 + 4.3.1. Enable or Disable the Support of User Message + Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 16 + 4.3.2. Get or Set the Stream Scheduler + (SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 17 + 4.3.3. Get or Set the Stream Scheduler Parameter + (SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 18 + 4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 19 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 5.1. I-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2. I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . . 20 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 7.2. Informative References . . . . . . . . . . . . . . . . . 22 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + + + + + + + + + + +Stewart, et al. Standards Track [Page 3] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +1. Introduction + +1.1. Overview + + When SCTP [RFC4960] was initially designed, it was mainly envisioned + for the transport of small signaling messages. Late in the design + stage, it was decided to add support for fragmentation and reassembly + of larger messages with the thought that someday signaling messages + in the style of Session Initiation Protocol (SIP) [RFC3261] may also + need to use SCTP, and a message that is a single Maximum Transmission + Unit (MTU) would be too small. Unfortunately this design decision, + though valid at the time, did not account for other applications that + might send large messages over SCTP. The sending of such large + messages over SCTP, as specified in [RFC4960], can result in a form + of sender-side head-of-line blocking (e.g., when the transmission of + a message is blocked from transmission because the sender has started + the transmission of another, possibly large, message). This head-of- + line blocking is caused by the use of the Transmission Sequence + Number (TSN) for three different purposes: + + 1. As an identifier for DATA chunks to provide a reliable transfer. + + 2. As an identifier for the sequence of fragments to allow + reassembly. + + 3. As a sequence number allowing up to 2**16 - 1 Stream Sequence + Numbers (SSNs) outstanding. + + The protocol requires all fragments of a user message to have + consecutive TSNs. This document allows an SCTP sender to interleave + different user messages. + + This document also defines several stream schedulers for general SCTP + associations allowing different relative stream treatments. The + stream schedulers may behave differently depending on whether or not + user message interleaving has been negotiated for the association. + + Figure 1 illustrates the behavior of a round-robin stream scheduler + using DATA chunks when three streams with the Stream Identifiers + (SIDs) 0, 1, and 2 are used. Each queue for SID 0 and SID 2 contains + a single user message requiring three chunks. The queue for SID 1 + contains three user messages each requiring a single chunk. It is + shown how these user messages are encapsulated in chunks using TSN 0 + to TSN 8. Please note that the use of such a scheduler implies late + + + + + + + +Stewart, et al. Standards Track [Page 4] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + TSN assignment, but it can be used with an implementation that is + compliant with [RFC4960] and that does not support user message + interleaving. Late TSN assignment means that the sender generates + chunks from user messages and assigns the TSN as late as possible in + the process of sending the user messages. + + +---+---+---+ + | 0/0 |-+ + +---+---+---+ | + | +---+---+---+---+---+---+---+---+---+ + +---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0| + |1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---| + +---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | + | +---+---+---+---+---+---+---+---+---+ + +---+---+---+ | + | 2/0 |-+ + +---+---+---+ + +-------+ + +-------+ |SID/SSN| + |SID/SSN| |-------| + +-------+ | TSN | + +-------+ + + Figure 1: Round-Robin Scheduler without User Message Interleaving + + This document describes a new chunk carrying payload data called + I-DATA. This chunk incorporates the properties of the current SCTP + DATA chunk, all the flags and fields except the Stream Sequence + Number (SSN), and also adds two new fields in its chunk header -- the + Fragment Sequence Number (FSN) and the Message Identifier (MID). The + FSN is only used for reassembling all fragments that have the same + MID and the same ordering property. The TSN is only used for the + reliable transfer in combination with Selective Acknowledgment (SACK) + chunks. + + In addition, the MID is also used for ensuring ordered delivery + instead of using the stream sequence number (the I-DATA chunk omits + an SSN). + + Figure 2 illustrates the behavior of an interleaving round-robin + stream scheduler using I-DATA chunks. + + + + + + + + + + +Stewart, et al. Standards Track [Page 5] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + ++---+---+---+ +| 0/0 |-+ ++---+---+---+ | + | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ ++---+---+---+ +->|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| +|1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----| ++---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | + | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ ++---+---+---+ | +| 2/0 |-+ ++---+---+---+ + +-----------+ + +-------+ |SID/MID/FSN| + |SID/MID| |-----------| + +-------+ | TSN | + +-----------+ + + Figure 2: Round-Robin Scheduler with User Message Interleaving + + The support of the I-DATA chunk is negotiated during the association + setup using the Supported Extensions Parameter, as defined in + [RFC5061]. If I-DATA support has been negotiated for an association, + I-DATA chunks are used for all user messages. DATA chunks are not + permitted when I-DATA support has been negotiated. It should be + noted that an SCTP implementation supporting I-DATA chunks needs to + allow the coexistence of associations using DATA chunks and + associations using I-DATA chunks. + + In Section 2, this document specifies the user message interleaving + by defining the I-DATA chunk, the procedures to use it, and its + interactions with other SCTP extensions. Section 3 defines multiple + stream schedulers, and Section 4 describes an extension to the socket + API for using the mechanism specified in this document. + +1.2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. User Message Interleaving + + The protocol mechanisms described in this document allow the + interleaving of user messages sent on different streams. They do not + support the interleaving of multiple messages (ordered or unordered) + sent on the same stream. + + + +Stewart, et al. Standards Track [Page 6] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + The interleaving of user messages is required for WebRTC data + channels, as specified in [DATA-CHAN]. + + An SCTP implementation supporting user message interleaving is + REQUIRED to support the coexistence of associations using DATA chunks + and associations using I-DATA chunks. If an SCTP implementation + supports user message interleaving and the Partial Reliability + extension described in [RFC3758] or the Stream Reconfiguration + Extension described in [RFC6525], it is REQUIRED to implement the + corresponding changes specified in Section 2.3. + +2.1. The I-DATA Chunk Supporting User Message Interleaving + + The following Figure 3 shows the new I-DATA chunk allowing user + message interleaving. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 64 | Res |I|U|B|E| Length = Variable | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TSN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Stream Identifier | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload Protocol Identifier / Fragment Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / User Data / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: I-DATA Chunk Format + + The only differences between the I-DATA chunk in Figure 3 and the + DATA chunk defined in [RFC4960] and [RFC7053] are the addition of the + new Message Identifier (MID) and the new Fragment Sequence Number + (FSN) and the removal of the Stream Sequence Number (SSN). The + Payload Protocol Identifier (PPID), which is already defined for DATA + chunks in [RFC4960], and the new FSN are stored at the same location + of the packet using the B bit to determine which value is stored at + the location. The length of the I-DATA chunk header is 20 bytes, + which is 4 bytes more than the length of the DATA chunk header + defined in [RFC4960] and [RFC7053]. + + + + + +Stewart, et al. Standards Track [Page 7] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + The old fields are: + + Res: 4 bits + These bits are reserved. They MUST be set to 0 by the sender and + MUST be ignored by the receiver. + + I bit: 1 bit + The (I)mmediate Bit, if set, indicates that the receiver SHOULD + NOT delay the sending of the corresponding SACK chunk. Same as + the I bit for DATA chunks, as specified in [RFC7053]. + + U bit: 1 bit + The (U)nordered bit, if set, indicates the user message is + unordered. Same as the U bit for DATA chunks, as specified in + [RFC4960]. + + B bit: 1 bit + The (B)eginning fragment bit, if set, indicates the first fragment + of a user message. Same as the B bit for DATA chunks, as + specified in [RFC4960]. + + E bit: 1 bit + The (E)nding fragment bit, if set, indicates the last fragment of + a user message. Same as the E bit for DATA chunks, as specified + in [RFC4960]. + + Length: 16 bits (unsigned integer) + This field indicates the length in bytes of the DATA chunk from + the beginning of the Type field to the end of the User Data field, + excluding any padding. Similar to the Length for DATA chunks, as + specified in [RFC4960]. + + TSN: 32 bits (unsigned integer) + This value represents the TSN for this I-DATA chunk. Same as the + TSN for DATA chunks, as specified in [RFC4960]. + + Stream Identifier: 16 bits (unsigned integer) + Identifies the stream to which the user data belongs. Same as the + Stream Identifier for DATA chunks, as specified in [RFC4960]. + + The new fields are: + + Reserved: 16 bits (unsigned integer) + This field is reserved. It MUST be set to 0 by the sender and + MUST be ignored by the receiver. + + + + + + +Stewart, et al. Standards Track [Page 8] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + Message Identifier (MID): 32 bits (unsigned integer) + The MID is the same for all fragments of a user message; it is + used to determine which fragments (enumerated by the FSN) belong + to the same user message. For ordered user messages, the MID is + also used by the SCTP receiver to deliver the user messages in the + correct order to the upper layer (similar to the SSN of the DATA + chunk defined in [RFC4960]). The sender uses two counters for + each outgoing stream: one for ordered messages and one for + unordered messages. All of these counters are independent and + initially 0. They are incremented by 1 for each user message. + Please note that the serial number arithmetic defined in [RFC1982] + using SERIAL_BITS = 32 applies. Therefore, the sender MUST NOT + have more than 2**31 - 1 ordered messages for each outgoing stream + in flight and MUST NOT have more than 2**31 - 1 unordered messages + for each outgoing stream in flight. A message is considered in + flight if at least one of its I-DATA chunks is not acknowledged in + a way that cannot be reneged (i.e., not acknowledged by the + cumulative TSN Ack). Please note that the MID is in "network byte + order", a.k.a. Big Endian. + + Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): + 32 bits (unsigned integer) + If the B bit is set, this field contains the PPID of the user + message. Note that in this case, this field is not touched by an + SCTP implementation; therefore, its byte order is not necessarily + in network byte order. The upper layer is responsible for any + byte order conversions to this field, similar to the PPID of DATA + chunks. In this case, the FSN is implicitly considered to be 0. + If the B bit is not set, this field contains the FSN. The FSN is + used to enumerate all fragments of a single user message, starting + from 0 and incremented by 1. The last fragment of a message MUST + have the E bit set. Note that the FSN MAY wrap completely + multiple times, thus allowing arbitrarily large user messages. + For the FSN, the serial number arithmetic defined in [RFC1982] + applies with SERIAL_BITS = 32. Therefore, a sender MUST NOT have + more than 2**31 - 1 fragments of a single user message in flight. + A fragment is considered in flight if it is not acknowledged in a + way that cannot be reneged. Please note that the FSN is in + "network byte order", a.k.a. Big Endian. + +2.2. Procedures + + This subsection describes how the support of the I-DATA chunk is + negotiated and how the I-DATA chunk is used by the sender and + receiver. + + The handling of the I bit for the I-DATA chunk corresponds to the + handling of the I bit for the DATA chunk described in [RFC7053]. + + + +Stewart, et al. Standards Track [Page 9] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +2.2.1. Negotiation + + An SCTP endpoint indicates user message interleaving support by + listing the I-DATA chunk within the Supported Extensions Parameter, + as defined in [RFC5061]. User message interleaving has been + negotiated for an association if both endpoints have indicated I-DATA + support. + + If user message interleaving support has been negotiated for an + association, I-DATA chunks MUST be used for all user messages and + DATA chunks MUST NOT be used. If user message interleaving support + has not been negotiated for an association, DATA chunks MUST be used + for all user messages and I-DATA chunks MUST NOT be used. + + An endpoint implementing the socket API specified in [RFC6458] MUST + NOT indicate user message interleaving support unless the user has + requested its use (e.g., via the socket API; see Section 4.3). This + constraint is made since the usage of this chunk requires that the + application is capable of handling interleaved messages upon + reception within an association. This is not the default choice + within the socket API (see the SCTP_FRAGMENT_INTERLEAVE socket option + in Section 8.1.20 of [RFC6458]); thus, the user MUST indicate to the + SCTP implementation its support for receiving completely interleaved + messages. + + Note that stacks that do not implement [RFC6458] may use other + methods to indicate interleaved message support and thus indicate the + support of user message interleaving. The crucial point is that the + SCTP stack MUST know that the application can handle interleaved + messages before indicating the I-DATA support. + +2.2.2. Sender-Side Considerations + + The sender-side usage of the I-DATA chunk is quite simple. Instead + of using the TSN for fragmentation purposes, the sender uses the new + FSN field to indicate which fragment number is being sent. The first + fragment MUST have the B bit set. The last fragment MUST have the E + bit set. All other fragments MUST NOT have the B or E bit set. All + other properties of the existing SCTP DATA chunk also apply to the + I-DATA chunk, i.e., congestion control as well as receiver window + conditions MUST be observed, as defined in [RFC4960]. + + Note that the usage of this chunk implies the late assignment of the + actual TSN to any chunk being sent. Each I-DATA chunk uses a single + TSN. This way messages from other streams may be interleaved with + the fragmented message. Please note that this is the only form of + interleaving support. For example, it is not possible to interleave + multiple ordered or unordered user messages from the same stream. + + + +Stewart, et al. Standards Track [Page 10] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + The sender MUST NOT process (move user data into I-DATA chunks and + assign a TSN to it) more than one user message in any given stream at + any time. At any time, a sender MAY process multiple user messages, + each of them on different streams. + + The sender MUST assign TSNs to I-DATA chunks in a way that the + receiver can make progress. One way to achieve this is to assign a + higher TSN to the later fragments of a user message and send out the + I-DATA chunks such that the TSNs are in sequence. + +2.2.3. Receiver-Side Considerations + + Upon reception of an SCTP packet containing an I-DATA chunk whose + user message needs to be reassembled, the receiver MUST first use the + SID to identify the stream, consider the U bit to determine if it is + part of an ordered or unordered message, find the user message + identified by the MID, and use the FSN for reassembly of the message + and not the TSN. The receiver MUST NOT make any assumption about the + TSN assignments of the sender. Note that a non-fragmented message is + indicated by the fact that both the E and B bits are set. A message + (either ordered or unordered) whose E and B bits are not both set may + be identified as being fragmented. + + If I-DATA support has been negotiated for an association, the + reception of a DATA chunk is a violation of the above rules and + therefore the receiver of the DATA chunk MUST abort the association + by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol + Violation' error cause. The same applies if I-DATA support has not + been negotiated for an association and an I-DATA chunk is received. + +2.3. Interaction with Other SCTP Extensions + + The usage of the I-DATA chunk might interfere with other SCTP + extensions. Future SCTP extensions MUST describe if and how they + interfere with the usage of I-DATA chunks. For the SCTP extensions + already defined when this document was published, the details are + given in the following subsections. + +2.3.1. SCTP Partial Reliability Extension + + When the SCTP extension defined in [RFC3758] is used in combination + with the user message interleaving extension, the new I-FORWARD-TSN + chunk MUST be used instead of the FORWARD-TSN chunk. The difference + between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the + 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit + Message Identifier (MID), and the largest skipped MID can also be + + + + + +Stewart, et al. Standards Track [Page 11] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + provided for unordered messages. Therefore, the principle applied to + ordered messages when using FORWARD-TSN chunks is applied to ordered + and unordered messages when using I-FORWARD-TSN chunks. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 194 | Flags = 0x00 | Length = Variable | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Cumulative TSN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Stream Identifier | Reserved |U| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Stream Identifier | Reserved |U| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: I-FORWARD-TSN Chunk Format + + The old fields are: + + Flags: 8 bits (unsigned integer) + These bits are reserved. They MUST be set to 0 by the sender and + MUST be ignored by the receiver. Same as the Flags for FORWARD + TSN chunks, as specified in [RFC3758]. + + Length: 16 bits (unsigned integer) + This field holds the length of the chunk. Similar to the Length + for FORWARD TSN chunks, as specified in [RFC3758]. + + New Cumulative TSN: 32 bits (unsigned integer) + This indicates the New Cumulative TSN to the data receiver. Same + as the New Cumulative TSN for FORWARD TSN chunks, as specified in + [RFC3758]. + + The new fields are: + + Stream Identifier (SID): 16 bits (unsigned integer) + This field holds the stream number this entry refers to. + + + + + + +Stewart, et al. Standards Track [Page 12] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + Reserved: 15 bits + This field is reserved. It MUST be set to 0 by the sender and + MUST be ignored by the receiver. + + U bit: 1 bit + The U bit specifies if the Message Identifier of this entry refers + to unordered messages (U bit is set) or ordered messages (U bit is + not set). + + Message Identifier (MID): 32 bits (unsigned integer) + This field holds the largest Message Identifier for ordered or + unordered messages indicated by the U bit that was skipped for the + stream specified by the Stream Identifier. For ordered messages, + this is similar to the FORWARD-TSN chunk, just replacing the + 16-bit SSN by the 32-bit MID. + + Support for the I-FORWARD-TSN chunk is negotiated during the SCTP + association setup via the Supported Extensions Parameter, as defined + in [RFC5061]. The partial reliability extension is negotiated and + can be used in combination with user message interleaving only if + both endpoints indicated their support of user message interleaving + and the I-FORWARD-TSN chunk. + + The FORWARD-TSN chunk MUST be used in combination with the DATA chunk + and MUST NOT be used in combination with the I-DATA chunk. The + I-FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk + and MUST NOT be used in combination with the DATA chunk. + + If I-FORWARD-TSN support has been negotiated for an association, the + reception of a FORWARD-TSN chunk is a violation of the above rules + and therefore the receiver of the FORWARD-TSN chunk MUST abort the + association by sending an ABORT chunk. The ABORT chunk MAY include + the 'Protocol Violation' error cause. The same applies if + I-FORWARD-TSN support has not been negotiated for an association and + a FORWARD-TSN chunk is received. + +2.3.2. SCTP Stream Reconfiguration Extension + + When an association resets the SSN using the SCTP extension defined + in [RFC6525], the two counters (one for the ordered messages, one for + the unordered messages) used for the MIDs MUST be reset to 0. + + Since most schedulers, especially all schedulers supporting user + message interleaving, require late TSN assignment, it should be noted + that the implementation of [RFC6525] needs to handle this. + + + + + + +Stewart, et al. Standards Track [Page 13] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +3. Stream Schedulers + + This section defines several stream schedulers. The stream + schedulers may behave differently depending on whether or not user + message interleaving has been negotiated for the association. An + implementation MAY implement any subset of them. If the + implementation is used for WebRTC data channels, as specified in + [DATA-CHAN], it MUST implement the Weighted Fair Queueing Scheduler + defined in Section 3.6. + + The selection of the stream scheduler is done at the sender side. + There is no mechanism provided for signaling the stream scheduler + being used to the receiver side or even for letting the receiver side + influence the selection of the stream scheduler used at the sender + side. + +3.1. First-Come, First-Served Scheduler (SCTP_SS_FCFS) + + The simple first-come, first-served scheduler of user messages is + used. It just passes through the messages in the order in which they + have been delivered by the application. No modification of the order + is done at all. The usage of user message interleaving does not + affect the sending of the chunks, except that I-DATA chunks are used + instead of DATA chunks. + +3.2. Round-Robin Scheduler (SCTP_SS_RR) + + When not interleaving user messages, this scheduler provides a fair + scheduling based on the number of user messages by cycling around + non-empty stream queues. When interleaving user messages, this + scheduler provides a fair scheduling based on the number of I-DATA + chunks by cycling around non-empty stream queues. + +3.3. Round-Robin Scheduler per Packet (SCTP_SS_RR_PKT) + + This is a round-robin scheduler, which only switches streams when + starting to fill a new packet. It bundles only DATA or I-DATA chunks + referring to the same stream in a packet. This scheduler minimizes + head-of-line blocking when a packet is lost because only a single + stream is affected. + +3.4. Priority-Based Scheduler (SCTP_SS_PRIO) + + Scheduling of user messages with strict priorities is used. The + priority is configurable per outgoing SCTP stream. Streams having a + higher priority will be scheduled first and when multiple streams + have the same priority, the scheduling between them is implementation + + + + +Stewart, et al. Standards Track [Page 14] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + dependent. When the scheduler interleaves user messages, the sending + of large, lower-priority user messages will not delay the sending of + higher-priority user messages. + +3.5. Fair Capacity Scheduler (SCTP_SS_FC) + + A fair capacity distribution between the streams is used. This + scheduler considers the lengths of the messages of each stream and + schedules them in a specific way to maintain an equal capacity for + all streams. The details are implementation dependent. interleaving + user messages allows for a better realization of the fair capacity + usage. + +3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) + + A Weighted Fair Queueing scheduler between the streams is used. The + weight is configurable per outgoing SCTP stream. This scheduler + considers the lengths of the messages of each stream and schedules + them in a specific way to use the capacity according to the given + weights. If the weight of stream S1 is n times the weight of stream + S2, the scheduler should assign to stream S1 n times the capacity it + assigns to stream S2. The details are implementation dependent. + Interleaving user messages allows for a better realization of the + capacity usage according to the given weights. + + This scheduler, in combination with user message interleaving, is + used for WebRTC data channels, as specified in [DATA-CHAN]. + +4. Socket API Considerations + + This section describes how the socket API defined in [RFC6458] is + extended to allow applications to use the extension described in this + document. + + Please note that this section is informational only. + +4.1. Exposure of the Stream Sequence Number (SSN) + + The socket API defined in [RFC6458] defines several structures in + which the SSN of a received user message is exposed to the + application. The list of these structures includes: + + struct sctp_sndrcvinfo + Specified in Section 5.3.2 of [RFC6458] and marked as deprecated. + + struct sctp_extrcvinfo + Specified in Section 5.3.3 of [RFC6458] and marked as deprecated. + + + + +Stewart, et al. Standards Track [Page 15] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + struct sctp_rcvinfo + Specified in Section 5.3.5 of [RFC6458]. + + If user message interleaving is used, the lower-order 16 bits of the + MID are used as the SSN when filling out these structures. + +4.2. SCTP_ASSOC_CHANGE Notification + + When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of + [RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or + SCTP_RESTART for an SCTP association where both peers support the + I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in + the sac_info field. + +4.3. Socket Options + + +-----------------------------+-------------------------+-----+-----+ + | Option Name | Data Type | Get | Set | + +-----------------------------+-------------------------+-----+-----+ + | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | + | SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X | + | SCTP_STREAM_SCHEDULER_VALUE | struct | X | X | + | | sctp_stream_value | | | + +-----------------------------+-------------------------+-----+-----+ + +4.3.1. Enable or Disable the Support of User Message Interleaving + (SCTP_INTERLEAVING_SUPPORTED) + + This socket option allows the enabling or disabling of the + negotiation of user message interleaving support for future + associations. For existing associations, it allows for querying + whether or not user message interleaving support was negotiated on a + particular association. + + This socket option uses IPPROTO_SCTP as its level and + SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with + getsockopt() and setsockopt(). The socket option value uses the + following structure defined in [RFC6458]: + + struct sctp_assoc_value { + sctp_assoc_t assoc_id; + uint32_t assoc_value; + }; + + + + + + + + +Stewart, et al. Standards Track [Page 16] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + assoc_id: This parameter is ignored for one-to-one style sockets. + For one-to-many style sockets, this parameter indicates upon which + association the user is performing an action. The special + sctp_assoc_t SCTP_FUTURE_ASSOC can also be used; it is an error to + use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. + + assoc_value: A non-zero value encodes the enabling of user message + interleaving, whereas a value of zero encodes the disabling of + user message interleaving. + + sctp_opt_info() needs to be extended to support + SCTP_INTERLEAVING_SUPPORTED. + + An application using user message interleaving should also set the + fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE + socket option specified in Section 8.1.20 of [RFC6458]. This allows + the interleaving of user messages from different streams. Please + note that it does not allow the interleaving of user messages + (ordered or unordered) on the same stream. Failure to set this + option can possibly lead to application deadlock. Some + implementations might therefore put some restrictions on setting + combinations of these values. Setting the interleaving level to at + least 2 before enabling the negotiation of user message interleaving + should work on all platforms. Since the default fragment interleave + level is not 2, user message interleaving is disabled per default. + +4.3.2. Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER) + + A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER + option for setsockopt(). The struct sctp_assoc_value is used to + specify the association for which the scheduler should be changed and + the value of the desired algorithm. + + The definition of struct sctp_assoc_value is the same as in + [RFC6458]: + + struct sctp_assoc_value { + sctp_assoc_t assoc_id; + uint32_t assoc_value; + }; + + assoc_id: Holds the identifier of the association for which the + scheduler should be changed. The special + SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter + is ignored for one-to-one style sockets. + + + + + + +Stewart, et al. Standards Track [Page 17] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + assoc_value: This specifies which scheduler is used. The following + constants can be used: + + SCTP_SS_DEFAULT: The default scheduler used by the SCTP + implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR. + + SCTP_SS_FCFS: Use the scheduler specified in Section 3.1. + + SCTP_SS_RR: Use the scheduler specified in Section 3.2. + + SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3. + + SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The + priority can be assigned with the sctp_stream_value struct. + The higher the assigned value, the lower the priority. That + is, the default value 0 is the highest priority, and therefore + the default scheduling will be used if no priorities have been + assigned. + + SCTP_SS_FB: Use the scheduler specified in Section 3.5. + + SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The + weight can be assigned with the sctp_stream_value struct. + + sctp_opt_info() needs to be extended to support + SCTP_STREAM_SCHEDULER. + +4.3.3. Get or Set the Stream Scheduler Parameter + (SCTP_STREAM_SCHEDULER_VALUE) + + Some schedulers require additional information to be set for + individual streams as shown in the following table: + + +-----------------+-----------------+ + | Name | Per-Stream Info | + +-----------------+-----------------+ + | SCTP_SS_DEFAULT | n/a | + | SCTP_SS_FCFS | no | + | SCTP_SS_RR | no | + | SCTP_SS_RR_PKT | no | + | SCTP_SS_PRIO | yes | + | SCTP_SS_FB | no | + | SCTP_SS_WFQ | yes | + +-----------------+-----------------+ + + + + + + + +Stewart, et al. Standards Track [Page 18] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the + corresponding struct sctp_stream_value. The definition of struct + sctp_stream_value is as follows: + + struct sctp_stream_value { + sctp_assoc_t assoc_id; + uint16_t stream_id; + uint16_t stream_value; + }; + + assoc_id: Holds the identifier of the association for which the + scheduler should be changed. The special + SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter + is ignored for one-to-one style sockets. + + stream_id: Holds the identifier of the stream for which additional + information has to be provided. + + stream_value: The meaning of this field depends on the scheduler + specified. It is ignored when the scheduler does not need + additional information. + + sctp_opt_info() needs to be extended to support + SCTP_STREAM_SCHEDULER_VALUE. + +4.4. Explicit EOR Marking + + Using explicit End of Record (EOR) marking for an SCTP association + supporting user message interleaving allows the user to interleave + the sending of user messages on different streams. + +5. IANA Considerations + + Two new chunk types have been assigned by IANA. + +5.1. I-DATA Chunk + + IANA has assigned the chunk type for this chunk from the pool of + chunks with the upper two bits set to '01'. This appears in the + "Chunk Types" registry for SCTP as follows: + + +----------+--------------------------------------------+-----------+ + | ID Value | Chunk Type | Reference | + +----------+--------------------------------------------+-----------+ + | 64 | Payload Data supporting Interleaving | RFC 8260 | + | | (I-DATA) | | + +----------+--------------------------------------------+-----------+ + + + + +Stewart, et al. Standards Track [Page 19] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + + The registration table (as defined in [RFC6096]) for the chunk flags + of this chunk type is initially as follows: + + +------------------+-----------------+-----------+ + | Chunk Flag Value | Chunk Flag Name | Reference | + +------------------+-----------------+-----------+ + | 0x01 | E bit | RFC 8260 | + | 0x02 | B bit | RFC 8260 | + | 0x04 | U bit | RFC 8260 | + | 0x08 | I bit | RFC 8260 | + | 0x10 | Unassigned | | + | 0x20 | Unassigned | | + | 0x40 | Unassigned | | + | 0x80 | Unassigned | | + +------------------+-----------------+-----------+ + +5.2. I-FORWARD-TSN Chunk + + IANA has assigned the chunk type for this chunk from the pool of + chunks with the upper two bits set to '11'. This appears in the + "Chunk Types" registry for SCTP as follows: + + +----------+---------------+-----------+ + | ID Value | Chunk Type | Reference | + +----------+---------------+-----------+ + | 194 | I-FORWARD-TSN | RFC 8260 | + +----------+---------------+-----------+ + + The registration table (as defined in [RFC6096]) for the chunk flags + of this chunk type is initially empty. + +6. Security Considerations + + This document does not add any additional security considerations in + addition to the ones given in [RFC4960] and [RFC6458]. + + It should be noted that the application has to consent that it is + willing to do the more complex reassembly support required for user + message interleaving. When doing so, an application has to provide a + reassembly buffer for each incoming stream. It has to protect itself + against these buffers taking too many resources. If user message + interleaving is not used, only a single reassembly buffer needs to be + provided for each association. But the application has to protect + itself for excessive resource usages there too. + + + + + + + +Stewart, et al. Standards Track [Page 20] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +7. References + +7.1. Normative References + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + DOI 10.17487/RFC1982, August 1996, + <https://www.rfc-editor.org/info/rfc1982>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. + Conrad, "Stream Control Transmission Protocol (SCTP) + Partial Reliability Extension", RFC 3758, + DOI 10.17487/RFC3758, May 2004, + <https://www.rfc-editor.org/info/rfc3758>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. + Kozuka, "Stream Control Transmission Protocol (SCTP) + Dynamic Address Reconfiguration", RFC 5061, + DOI 10.17487/RFC5061, September 2007, + <https://www.rfc-editor.org/info/rfc5061>. + + [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission + Protocol (SCTP) Chunk Flags Registration", RFC 6096, + DOI 10.17487/RFC6096, January 2011, + <https://www.rfc-editor.org/info/rfc6096>. + + [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control + Transmission Protocol (SCTP) Stream Reconfiguration", + RFC 6525, DOI 10.17487/RFC6525, February 2012, + <https://www.rfc-editor.org/info/rfc6525>. + + [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- + IMMEDIATELY Extension for the Stream Control Transmission + Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, + <https://www.rfc-editor.org/info/rfc7053>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + + + +Stewart, et al. Standards Track [Page 21] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +7.2. Informative References + + [DATA-CHAN] + Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data + Channels", Work in Progress, + draft-ietf-rtcweb-data-channel-13, January 2015. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. + Yasevich, "Sockets API Extensions for the Stream Control + Transmission Protocol (SCTP)", RFC 6458, + DOI 10.17487/RFC6458, December 2011, + <https://www.rfc-editor.org/info/rfc6458>. + +Acknowledgments + + The authors wish to thank Benoit Claise, Julian Cordes, Spencer + Dawkins, Gorry Fairhurst, Lennart Grahl, Christer Holmberg, Mirja + Kuehlewind, Marcelo Ricardo Leitner, Karen E. Egede Nielsen, Maksim + Proshin, Eric Rescorla, Irene Ruengeler, Felix Weinrank, Michael + Welzl, Magnus Westerlund, and Lixia Zhang for their invaluable + comments. + + This work has received funding from the European Union's Horizon 2020 + research and innovation program under grant agreement No. 644334 + (NEAT). The views expressed are solely those of the authors. + + + + + + + + + + + + + + + + + + + + +Stewart, et al. Standards Track [Page 22] + +RFC 8260 Stream Schedulers and the I-DATA Chunk November 2017 + + +Authors' Addresses + + Randall R. Stewart + Netflix, Inc. + Chapin, SC 29036 + United States of America + + Email: randall@lakerest.net + + + Michael Tuexen + Muenster University of Applied Sciences + Stegerwaldstrasse 39 + 48565 Steinfurt + Germany + + Email: tuexen@fh-muenster.de + + + Salvatore Loreto + Ericsson + Torshamnsgatan 21 + 164 80 Stockholm + Sweden + + Email: Salvatore.Loreto@ericsson.com + + + Robin Seggelmann + Metafinanz Informationssysteme GmbH + Leopoldstrasse 146 + 80804 Muenchen + Germany + + Email: rfc@robin-seggelmann.com + + + + + + + + + + + + + + + + +Stewart, et al. Standards Track [Page 23] + |