Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol
Extracted elements (25)
SCTP's original design used the TSN for three purposes: reliable transfer identification, fragment reassembly sequencing, and stream sequence numbering. This overloading required all fragments of a user message to have consecutive TSNs, causing sender-side head-of-line blocking when large messages occupied consecutive TSN space and prevented interleaving.
Stream scheduler selection is exclusively a sender-side decision; no mechanism is provided for signaling the chosen scheduler to the receiver or for allowing the receiver to influence the sender's choice. This keeps the protocol simple and avoids additional negotiation overhead.
Future SCTP extensions MUST describe if and how they interfere with the usage of I-DATA chunks. The document provides interaction details for the Partial Reliability extension (RFC 3758) and the Stream Reconfiguration extension (RFC 6525).
I-DATA support is negotiated via the Supported Extensions Parameter (RFC 5061) during association setup. Both endpoints must indicate I-DATA support for it to be used. Implementations must coexist with both DATA-only and I-DATA associations simultaneously.
An endpoint implementing the RFC 6458 socket API MUST NOT indicate user message interleaving support unless the user has explicitly requested it, because the application must be capable of handling interleaved messages upon reception.
An SCTP implementation supporting user message interleaving MUST support coexistence of associations using DATA chunks and associations using I-DATA chunks.
FORWARD-TSN MUST be used with DATA chunks and MUST NOT be used with I-DATA chunks. I-FORWARD-TSN MUST be used with I-DATA chunks and MUST NOT be used with DATA chunks. Reception of the wrong variant MUST cause the receiver to abort the association.
If I-DATA support has been negotiated and a DATA chunk is received (or vice versa), the receiver MUST abort the association by sending an ABORT chunk; the ABORT chunk MAY include the 'Protocol Violation' error cause.
If the implementation is used for WebRTC data channels, it MUST implement the Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) defined in Section 3.6.
If user message interleaving support has been negotiated, I-DATA chunks MUST be used for all user messages and DATA chunks MUST NOT be used. If not negotiated, DATA chunks MUST be used and I-DATA chunks MUST NOT be used.
The sender MUST NOT have more than 2**31 - 1 ordered messages or more than 2**31 - 1 unordered messages for each outgoing stream in flight, and MUST NOT have more than 2**31 - 1 fragments of a single user message in flight, per serial number arithmetic constraints.
The sender MUST NOT process more than one user message in any given stream at any time. At any time, a sender MAY process multiple user messages each on different streams.
Upon receiving an I-DATA chunk for reassembly, the receiver MUST use SID to identify the stream, the U bit to determine ordered/unordered, the MID to identify the user message, and the FSN for reassembly — not the TSN. The receiver MUST NOT make any assumption about the sender's TSN assignments.
When an association resets the SSN using the SCTP Stream Reconfiguration extension (RFC 6525), the two MID counters (ordered and unordered) for that stream MUST be reset to 0.
Six stream schedulers are defined: SCTP_SS_FCFS (first-come first-served), SCTP_SS_RR (round-robin by message or chunk), SCTP_SS_RR_PKT (round-robin per packet), SCTP_SS_PRIO (strict priority per stream), SCTP_SS_FC (fair capacity), and SCTP_SS_WFQ (weighted fair queueing). An implementation MAY implement any subset.
The Fragment Sequence Number (FSN) is a 32-bit unsigned integer stored at the PPID field location when the B bit is not set. It enumerates fragments of a single user message starting from 0. When the B bit is set, the PPID occupies this field and FSN is implicitly 0. Serial number arithmetic (RFC 1982, SERIAL_BITS=32) applies.
The I-DATA chunk (Type=64) is a new SCTP chunk for payload data supporting user message interleaving. It replaces the SSN field of DATA chunks with a 32-bit Message Identifier (MID) and adds a Fragment Sequence Number (FSN) field shared with the PPID location, with the B bit determining which value is present. The chunk header is 20 bytes, 4 bytes more than DATA.
The I-FORWARD-TSN chunk (Type=194) replaces FORWARD-TSN when user message interleaving is used with the Partial Reliability extension. It replaces the 16-bit SSN with a 32-bit MID and adds a U bit to distinguish ordered from unordered messages, applying the same skipping principle to both.
The Message Identifier (MID) is a 32-bit unsigned integer, the same for all fragments of a user message. For ordered messages it replaces the SSN for in-order delivery. Two independent counters per outgoing stream (one for ordered, one for unordered) start at 0 and increment by 1 per message, using serial number arithmetic (RFC 1982, SERIAL_BITS=32).
The SCTP_SS_RR_PKT scheduler switches streams only at packet boundaries and bundles only chunks from a single stream per packet, minimizing head-of-line blocking impact when a packet is lost to a single stream.
IANA assigned chunk type 194 (upper two bits '11') to the I-FORWARD-TSN chunk in the SCTP Chunk Types registry. The chunk flags registration table is initially empty.
IANA assigned chunk type 64 (upper two bits '01') to the I-DATA chunk ('Payload Data supporting Interleaving') in the SCTP Chunk Types registry, with flags E(0x01), B(0x02), U(0x04), I(0x08) registered and 0x10–0x80 unassigned.
When user message interleaving is used, an application must provide a reassembly buffer for each incoming stream rather than a single buffer per association, and must protect itself against excessive resource consumption from these per-stream buffers. Applications must explicitly consent to support the more complex reassembly required.
The I-DATA chunk format contains: Type (8 bits, value 64), Res/I/U/B/E flags (8 bits), Length (16 bits), TSN (32 bits), Stream Identifier (16 bits), Reserved (16 bits), Message Identifier/MID (32 bits), PPID or FSN (32 bits, disambiguated by B bit), and variable-length User Data.
The I-FORWARD-TSN chunk (Type=194, Flags=0x00) contains: New Cumulative TSN (32 bits), followed by one or more entries each comprising Stream Identifier (16 bits), Reserved/U bit (16 bits), and Message Identifier (32 bits).