SCTP needed given TCP and UDP are widely available

Definition

Stream Control Transmission Protocol (SCTP) [RFC2960] is an end-to-end transport protocol that provides services heretofore unavailable from either of the workhorse transport protocols that have supported the Internet for more than twenty years: reliable, connection-oriented TCP [RFC793], or unreliable, connectionless UDP [RFC768].

Why is SCTP needed given TCP and UDP are widely available?

In 1998 an IETF working group (SIGTRAN) was formed to design a mechanism for reliably transporting call control signaling over the Internet. SIGTRAN's goal was to create an IP complement to the telephone switching's SS7 network. During SIGTRAN's work, two key problems surfaced in the use of TCP:

• Head-of-line blocking - a problem where sending independent messages over an order-preserving TCP connection causes delivery of messages sent later to be delayed within a receiver's transport layer buffers until an earlier lost message is retransmitted and arrives. These later messages often establish independent telephone calls. For call control signaling, the delay on later messages caused critical call control timers to expire thus resulting in undesirable call setup failures.
• Multihoming - where a host with multiple points of attachment to the Internet, for redundancy purposes, does not want to wait for a routing convergence (often on the order of minutes) to communicate critical messages to its peer communication endpoint. For call control signaling, such delay is unacceptable when an alternate available path exists. A TCP connection only binds a single point of attachment at either end point.

SCTP vs TCP vs UDP

Services/Features	SCTP	TCP	UDP
Connection-oriented	yes	yes	no
Full duplex	yes	yes	yes
Reliable data transfer	yes	yes	no
Partial-reliable data transfer	optional	no	no
Ordered data delivery	yes	yes	no
Unordered data delivery	yes	no	yes
Flow control	yes	yes	no
Congestion control	yes	yes	no
ECN capable	yes	yes	no
Selective ACKs	yes	optional	no
Preservation of message boundaries	yes	no	yes
Path MTU discovery	yes	yes	no
Application PDU fragmentation	yes	yes	no
Application PDU bundling	yes	yes	no
Multistreaming	yes	no	no
Multihoming	yes	no	no
Protection against SYN flooding attacks	yes	no	n/a
Allows half-closed connections	no	yes	n/a
Reachability check	yes	yes	no
Psuedo-header for checksum	no (uses vtags)	yes	yes
Time wait state	for vtags	for 4-tuple	n/a

Considering these problems, SIGTRAN began work on a new transport protocol to carry its call control signaling over IP. Simultaneously, the IETF transport Area Directors (Scott Bradner and Vern Paxson) recognized the value of solving these problems for a wider audience. They expanded the scope of the work from a small, dedicated protocol for a specific task (SIGTRAN) to a general-purpose transport protocol that other applications could use as well. Within this larger scope, SCTP was born. SCTP also includes the following enhancements:

Multistreaming - SCTP supports multiple, independent logical streams of messages within an SCTP association¹. Each message sent over an SCTP association is assigned to a particular stream. All data within a stream is delivered in order with respect to other data in that stream. Data in different streams have no order constraints. SCTP's resulting parallel ordered streams provide a specific instance of 'partial ordered' delivery. It is SCTP's multistreaming service that circumvents the head-of-line blocking problem discussed above. Multistreaming has been found to facilitate FTP'ing multiple files, say for system backups or mirror site downloads. Multistreaming also is appropriate for applications that wish to multiplex related, yet independent data streams (e.g., voice, text, video) over a single end-to-end association rather than open multiple TCP connections, one for each stream.

• SCTP's solution for Multihoming - each of the two endpoints during an SCTP association setup can specify multiple points of attachment. Having multiple interfaces allows data to be automatically sent to alternate addresses when failures occur, and most importantly, without the application even knowing a lower level failure occurred. Such fault tolerance is unavailable for TCP, which binds each endpoint to a single interface. Should either endpoint interface or the link to the interface fail, all TCP connections bound to that interface would need to timeout and abort, thus forcing the application(s) to reestablish the connection(s), and accurately pick up from where the aborted connection(s) left off.
• Message Orientation - In TCP, data sent between two endpoints is a stream of bytes. If needed, an application must provide message framing. In SCTP, message boundaries are preserved. If an application sends a 100-byte message, the peer application will receive all 100 bytes in a single read: no more, no less. UDP provides a message-oriented service, but without SCTP's reliability.
• Un-Ordered Service - In TCP, all messages are reliably delivered to a receiving application in exactly the order used by the sending application. In addition to ordered message service (and parallel ordered service discussed above), SCTP offers the reliable delivery of messages with no order constraints. UDP provides unordered service, but again without SCTP's reliability. Unordered reliable delivery will be useful for many applications, in particular disk over LAN services (iSCSI, RDMA, etc.) where the application already provides ordering, and does not want TCP's overhead (and performance penalty) to preserve order.
• Extensibility - a TCP packet is limited to 40 bytes for options. In contrast, SCTP packets can be expanded through the use of Tag-Length-Value (TLV) fields. Embedded within SCTP's TLV structures are compatibility handling procedures so that implementations remain interoperable even when one supports a more advanced feature set than another.
• Heartbeat/Keep-alive - SCTP has a default keep-alive function. Regular heartbeats validate reachability of peer addresses, and help maintain a Round Trip Time (RTT) estimate for each alternate address.
• Message Time-to-Live - SCTP has an option to specify a message's time-to-live. This feature allows a sending application to specify how long a message is useful. If this time expires before the message can be reliably communicated to the receiver, the sending SCTP entity can stop trying, effectively 'undo'ing or skipping the message. This type of reliability is called "partial reliability". Partial reliability is of interest, for example, to the mobile community (military and commercial) and the online gaming community where the current "location or environment" status is only good for a short period, and then outdated by a revised status. In this situation, being able to discard the stale data will save on bandwidth utilization, while providing the application with better service in the face of loss or congestion.
• Syn cookies - SCTP uses a four-way handshake with a signed cookie. A receiver of a new SCTP association setup message maintains no state (i.e., reserves no resources) until after the initiator proves it is at the IP address from which it claims to be setting up the association. Syn cookies thus prevent using IP spoofing for the known denial of service attack termed SYN flooding [RFC2827].
• Stronger checksum - SCTP uses a 32-bit end-to-end checksum (CRC32C) proven to be mathematically stronger than the 16-bit ones-complement sum used by TCP and UDP. SCTP's better checksum provides stronger verification that a message passes end-to-end without bit errors going undetected.
• Advanced TCP services - Recent advances in TCP, such as SACK [RFC2018], Appropriate Byte Counting [RFC3465], and Explicit Congestion Notification [RFC3168], have been built into SCTP by design instead of retrofitting. The user of SCTP is assured these features are present as compared to TCP versions where one must validate that both sides of a connection have implemented all appropriate RFCs.

Deployment

SCTP became an RFC in October 2000. As with any new Internet technology, ease of deployment becomes the barrier to widespread use. Currently, all major operating systems have an SCTP implementation. For some, such as BSD Unix, Linux, and Solaris, SCTP comes as part of the OS, or has a patch (or package) that can be added. For other platforms, such as Windows, a third party package must be purchased to add SCTP's advanced feature set. A comprehensive list of SCTP implementations can be found at Six workshops since June 2000 have been organized to test interoperability of these implementations.

The authors predict increased demand and use of SCTP as more applications find benefits from SCTP's richer set of services. Eventually all OS vendors will respond to customer demands, and supply SCTP out of the box. Until such time, many applications may hesitate to move to SCTP.

Summary

SCTP offers several advantages. Most important at the application level are SCTP's multistreaming of boundary-preserved messages, and multihoming's added fault tolerance. For example, SCTP is a natural candidate to support telephone signaling over the Internet as well as other message-oriented applications. Applications that require high degrees of fault tolerance, such as online banking and stock market transaction exchanges, will benefit from SCTP's multihoming.

A subtle advantage of SCTP's multihoming is that, if widely used by applications where redundancy is critical, multihoming can reduce the widespread routing table growth discussed in ISOC brief #3. Organizations that move their mission critical applications to SCTP can take advantage of multihoming, and not cross-advertise routes (i.e., effectively creating hosts routes in IP routing tables). Using SCTP would thereby yield significant reduction to current Internet routing table sizes.

Multihoming within an SCTP association has another interesting side effect in that an association simultaneously spans both IPv6 and IPv4 addresses. Thus SCTP facilitates the transition of the Internet from IPv4 to IPv6. The wider implications of SCTP's "dual stack" nature are undetermined.

By its design, SCTP provides for extensibility, which when used judiciously, will provide SCTP with years of usefulness to the Internet community. Enhancements will be easier to introduce while still maintaining inter-operability amongst prior implementations. The authors expect SCTP's many new features will attract current and as yet undiscovered applications as wider scale deployment occurs. Any hesitancy to use SCTP will be overcome by market pressure and the profitable engineering practice of choosing the right transport layer tool for the job.

[1] SCTP uses the term association to refer to a connection between two endpoints. A new term was introduced because an SCTP association is broader in scope than a TCP connection. An SCTP association may bind multiple IP addresses at each endpoint whereas TCP binds precisely one address for each endpoint.