Introduction: SCTP Transport Service
TCP provides a reliable ordered byte stream for applications such as web browsing and email, while UDP provides a connectionless datagram service commonly used by real-time applications without delivery guarantees. Applications that need message boundaries, independent streams, or multiple network paths require a different transport service. SCTP was designed for that combination of requirements.
The Stream Control Transmission Protocol (SCTP)was originally designed in 2000 for telecommunications signaling, including SS7 over IP, and later specified as a general-purpose transport protocol. It is message-oriented and supports reliable delivery, multiple streams, and multihoming within one association. Unlike a TCP connection, an SCTP association can represent both endpoints' lists of transport addresses.
SCTP is message-oriented like UDP, with reliable and ordered delivery available within each stream. Its multi-streaming limits head-of-line blocking between independent streams, while multi-homing allows an association to use alternative transport addresses. Preserving message boundaries lets the receiver distinguish application data units. This transport model supports telecommunications signaling as well as other application protocols.
The Problem SCTP Addresses: Cross-Stream Head-of-Line Blocking
TCP exposes one ordered byte stream. A missing byte prevents later bytes from being delivered to the application, a behavior known as Head-of-Line Blocking (HOLB).
One Ordered TCP Stream
Consider one TCP connection carrying independent application objects such as HTML, CSS style sheets, and images. TCP transmits them through one ordered byte sequence, even when the application treats them as separate messages.
Because TCP provides one strictly ordered stream, later bytes cannot be delivered before an earlier missing sequence range. Data corresponding to object #5 therefore waits for object #4, and #4 waits for #3 when their bytes share that order. TCP does not know that the objects are independent application messages; it only sees one byte sequence.
The problem appears when an earlier segment is lost. Suppose the packet carrying object #3 is dropped. Even if the segments carrying #4, #5, and #6 arrive, the TCP receiver retains their bytes until the missing sequence range is repaired. The sender detects the gap through a retransmission timeout or duplicate ACKs and retransmits the missing data. Only then can the receiver deliver the contiguous sequence to the application. This delay is present even when the later packets have already been checked and stored in the receive buffer.
This behavior is called Head-of-Line Blocking: one loss stalls later bytes in the same TCP stream, even when those bytes belong to independent application objects. The resulting delay limits applications that could otherwise process those objects independently.
SCTP Feature Set
SCTP was specified to address ordered-stream blocking and to provide message boundaries, multihoming, and a cookie-based association setup. The design also includes explicit acknowledgments, retransmission, congestion control, and shutdown procedures rather than delegating these functions to each application.
1. Multi-Streaming: Independent Streams
SCTP's association is not one application stream. It contains multiple parallel, independent streams, each identified by a stream identifier and carrying messages in one direction.
An application can assign independent data to different streams: HTML can use stream 1, CSS stream 2, one image stream 3, and another image stream 4. The association keeps these logical channels within one transport relationship. Stream identifiers are local to an endpoint, and each stream is unidirectional, so two-way application traffic normally uses streams in both directions.
SCTP provides ordered delivery within each stream by default, while streams have independent sequence spaces. If data for the image in stream 3 is lost, ordered delivery in stream 3 waits for recovery, but HTML in stream 1 and CSS in stream 2 can be delivered when their data is otherwise ready. Multi-streaming therefore avoids cross-stream HOLB; it does not remove ordering delay inside the affected stream. The application must still choose stream assignments that reflect its dependency structure.
2. Multi-Homing: Multiple Transport Addresses
TCP connections are defined by a strict 4-tuple of source IP, source port, destination IP, and destination port. If the network interface corresponding to one of those IP addresses fails (e.g., a network card dies or a cable is unplugged), the TCP connection breaks, even if both computers have other functional network interfaces and an alternate path exists between them.
SCTP supports multi-homing, so an endpoint can advertise multiple transport addresses for one association. Multihoming can be used by either endpoint or by both endpoints. A failure of one interface therefore need not destroy the association when another advertised address remains reachable.
- During setup, each side can provide a list of all its available IP addresses.
- The SCTP stack checks path reachability with HEARTBEAT procedures, normally on idle paths at configured intervals.
- One path is designated as the primary path for data transmission, while the other paths can serve as alternatives.
- If the primary path is marked inactive, SCTP can retransmit on a working alternative path and continue the association. The application can remain connected, subject to path failure detection and the available address set. The change is transport-level; it does not promise uninterrupted traffic during detection or recovery.
3. Reliable, Message-Oriented Transport
SCTP combines datagram-like message boundaries with transport-level reliability and ordering controls. A message can be fragmented into DATA chunks for transmission and reassembled before delivery.
- Message-Oriented (like UDP): Data is sent and received as distinct messages. If the application writes a 100-byte message and then a 200-byte message, the receiver will read a 100-byte message and then a 200-byte message. This preserves message boundaries, which is something application developers often have to build on top of TCP's byte-stream model. A message larger than the path permits can be fragmented and reassembled by SCTP.
- Reliable (like TCP): SCTP acknowledges DATA with SACK chunks and retransmits unacknowledged data according to its reliability policy. The base service is reliable, while extensions such as PR-SCTP can intentionally abandon selected messages. Reliability therefore applies to data that has not been abandoned by an enabled partial-reliability policy.
- Ordered and Unordered Delivery: SCTP provides ordered delivery of messages within a single stream by default. An application can request unordered delivery for a message, allowing it to bypass earlier ordered messages in that stream. The unordered message remains reliable in base SCTP; a partial-reliability policy can separately permit abandonment.
4. Cookie-Based Four-Way Handshake
To initiate an association, SCTP uses a four-way handshake that defers association-state commitment until the initiator returns a valid cookie. This reduces exposure to resource-exhaustion attacks such as SYN floods. The exchange is INIT, INIT-ACK, COOKIE-ECHO, and COOKIE-ACK.
- INIT: The initiator sends an 'INIT' chunk, proposing an association.
- INIT-ACK: The responding endpoint returns an 'INIT-ACK' chunk containing a state cookie. The cookie carries the required association state and a MAC computed with a secret key. The endpoint need not retain an association control block while waiting for the echo.
- COOKIE-ECHO: The initiator receives the 'INIT-ACK' and echoes the cookie back to the responding endpoint in a 'COOKIE-ECHO' chunk. The returned chunk demonstrates that the initiator received the response.
- COOKIE-ACK: The responding endpoint receives the echoed cookie and validates its MAC, lifetime, and state. Only after valid-cookie processing does it allocate association resources and confirm with a 'COOKIE-ACK'.
This mechanism limits SYN-flood-style resource use because the endpoint does not commit association state until the initiator has received and returned the cookie. Returning it also demonstrates reachability of the source path; it does not constitute a general validation of the claimed IP address.
Structure of an SCTP Packet
An SCTP packet contains a mandatory Common Header followed by one or more variable-length Chunks. This chunk-based architecture carries control and DATA information in a single packet.
| Component | Description |
|---|---|
| Common Header (12 bytes) | Contains the source and destination port numbers, a Verification Tag used to associate packets with the current association and reject many blind packets, and a 32-bit CRC32c checksum calculated over the SCTP packet with the checksum field cleared. |
| Chunks (Variable) | Following the header, the packet contains one or more chunks. Each chunk has its own Type, Flags, and Length fields. This allows control and DATA messages to be bundled in one packet. Representative chunk types include:
|
SCTP Applications and Deployment
SCTP is deployed in focused environments rather than as a general-purpose replacement for TCP or UDP. Native support is less uniform across consumer systems, and middleboxes such as NAT devices and firewalls may not pass the protocol without explicit support. These deployment conditions are separate from the protocol's transport features.
SCTP is therefore used in focused deployments:
- Telephony and Signaling: Its original use case includes transporting signaling systems such as SIGTRAN (SS7 over IP) in carrier networks, including 3G and 4G/LTE mobile networks. Reliable delivery and multihoming support the failure requirements of signaling paths.
- WebRTC Data Channels: WebRTC data channels use SCTP over DTLS over UDP for real-time data sessions between browsers, while audio and video use separate media transports. The mapping supports multiple streams and ordered, unordered, reliable, or partially reliable data channels for chat messages, game state, and file transfers. WebRTC does not expose SCTP multihoming; its SCTP association is carried through the DTLS/UDP transport.
- QUIC Comparison: QUIC is a separate secure transport carried in UDP. It provides bidirectional and unidirectional ordered byte streams with no ordering relationship between different streams, so a lost packet can still delay data in the affected stream. QUIC integrates TLS and has its own packet and congestion-control design; it should not be described as a reimplementation of SCTP.