23.12 When to Use SCTP Instead of TCP

SCTP was originally developed for call control signaling to allow the transport of telephony signals across the Internet. However, during its development, its scope was expanded beyond that into a general-purpose transport protocol. It provides most of the features of TCP, and adds to those a wide range of new transport-layer services. There are few applications that could not benefit by the use of SCTP. So when should we use SCTP? Let's start by listing the benefits of SCTP:

1. SCTP is a protocol that directly supports multihoming. An endpoint can take advantage of multiple networks on a host to gain additional reliability. An added bonus is that the application does not need to take any action, other than moving to SCTP, to automatically take advantage of SCTP's multihomed service. For further details on SCTP's multihoming, see Section 7.4 of [Stewart and Xie 2001].

2. Head-of-line blocking can be eliminated. An application can use a single SCTP association and transport multiple data elements in parallel. A loss in one stream of information will not influence any of the other parallel streams of information flowing through the association (we discussed this concept in Section 10.5).

3. Application layer message boundaries are preserved. Many applications do not send streams of bytes; instead, they send messages. SCTP preserves message boundaries sent by an application and thus simplifies the application writer's task. No longer is it necessary to mark message boundaries within a stream of bytes and provide special handling code to deal with reconstructing messages from the information flow at the receiver.

4. An unordered message service is provided. For some applications, no ordering is needed. In the past, such an application may have used TCP for its reliability with the drawback that all data, even though unordered, would have to be delivered in order. Any loss would cause head-of-line blocking for all subsequent messages flowing through the connection. With SCTP, an unordered service is available that avoids this issue and allows an application to match its needs directly to the transport.

5. A partially reliable service is available in some SCTP implementations. This feature allows an SCTP sender to specify a lifetime on each message, using the sinfo_timetolive field of the struct sctp_sndrcvinfo. (This is different from the IPv4 TTL or the IPv6 hop limit; it is actually a length of time.) When both endpoints support this feature, time-sensitive data can be discarded by the transport instead of the application, even if it has been transmitted and lost, thus optimizing data transport in the face of congestion.

6. An easy migration path from TCP is provided by SCTP with its one-to-one-style interface. This interface duplicates a typical TCP interface so that with one or two slight changes, a TCP application can be migrated to SCTP.

7. Many of the features of TCP, such as positive acknowledgment, retransmission of lost data, resequencing of data, windowed flow control, slow-start and congestion avoidance, and selective acknowledgments, are included in SCTP with two notable exceptions (the half-closed state and urgent data).

8. SCTP provides many hooks (as seen in this chapter and in Section 7.10) for an application to configure and tune the transport to match its needs on an association-by-association basis. This flexibility, along with a general set of good defaults (for the application that does not wish to tune the transport), provide the application with controls unavailable in TCP.

SCTP does not provide two features that TCP does provide. One is the half-closed state. This state is entered when an application closes its half of the connection but still allows the peer to send data to it (we discussed this in Section 6.6). An application enters the half-closed state to signal to the peer that it is finished transmitting data. Very few applications use this feature, so during SCTP development, it was considered not worth adding to the protocol. Applications that need this feature and want to move to SCTP will need to change their application-layer protocol to provide this signal in the application data stream. In some instances, this change may not be trivial.

Another TCP feature that SCTP does not provide is urgent data. Using a separate SCTP stream for urgent data has somewhat similar semantics, but cannot replicate the feature exactly.

Another type of application that may not benefit from SCTP is one that is truly byte stream-oriented, like telnet, rlogin, rsh, and ssh. For such an application, TCP can segment the stream of bytes into IP packets more efficiently than SCTP. SCTP will faithfully preserve the message boundaries, which may equate to a size that does not fit efficiently into IP datagrams, and thus may cause somewhat more overhead.

In summary, many applications could consider using SCTP as it becomes available on their Unix platform. However, it takes an eye toward SCTP's special features to truly benefit from them; until SCTP is ubiquitous, it could be advantageous to simply stick with TCP.