This chapter is from the book
This chapter is from the book
This chapter is from the book
1.3 Motivation for Developing SCTP
One particular application that best exemplifies many of the shortcomings of TCP and UDP and directly motivated the development of SCTP is the transportation of telephony signaling messages over IP networks.
Telephony signaling has rigid timing and reliability requirements that are often set forth through government regulations and must be met in order for the phone service provider to be qualified.
1.3.1 TCP Limitations
The following limitations of TCP make it hard to meet the rigid timing and reliability requirements of telephony signaling:
TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Telephony signaling applications often need reliable message transfer but not a globally strict sequence maintenance. What is often more desirable for telephony signaling is a partial ordering of the data, such as maintaining ordering only within some subflows of the data.
The strict sequence maintenance in TCP not only makes such type of partial ordering of the data impossible, it can also potentially introduce unnecessary delay to the overall data delivery service. Loss of a single TCP segment can block delivery of all subsequent data in a TCP stream until the lost TCP segment is delivered. This is sometimes called head-of-line blocking. Excessive delays in telephony signaling may cause various types of service failure and hence must be closely controlled.
The byte-oriented nature of TCP is often an inconvenience to the message-based telephony signaling. Applications must add their own record marking to delineate their messages, and they must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time.
TCP has no built-in support for multi-homed IP hosts. This brings an immense challenge to the system designers who want to build link or path-level redundancy. Without link or path-level redundancy, the data transfer service in a network can become vulnerable to link failures. This is often unacceptable for a telephony signaling network, because providing highly available data transfer capability is one of its primary requirements.
For telephony applications, especially commercial phone services, security against malicious attacks intended to cause failure or interruptions to the services is often a top priority. But TCP is known to be relatively vulnerable to some denial of service attacks, such as the SYN flooding attack.6
1.3.2 UDP Limitations
UDP has its own shortcomings when it is being considered for carrying telephony signaling data. First, UDP only provides an unreliable data transfer service to the application; in other words, an application using UDP cannot know whether data sent to a peer application is received by the other end or not. Moreover, for those that reach the destination, there is no guarantee on the ordering of the data, and the receiver may get duplicated copies of the same data. Secondly, UDP has no built-in congestion management mechanism to detect path congestion and consequently to throttle back its data transmission. This can have two very undesirable effects:
Injecting more data into an already congested network is unfriendly to the network; it often will worsen the network congestion and adversely affect other applications communicating using the same network.
Data sent over an already congested network will likely be discarded by the network. This in turn makes UDP data transfer service more unreliable when the network is congested.
By itself, due to the above shortcomings, UDP cannot meet the data reliability requirements and thus is unsuitable for telephony signaling applications. However, because UDP is message-oriented and generally considered a lightweight protocol that has a relatively small overhead, there have been attempts to make up in the application itself what is lacking in UDP in order to meet more stringent timing and data reliability requirements. This normally means that the application will need to build its own mechanisms to do the following:
- Detect and retransmit any lost messages
- Correct out-of-order and duplicated messages
- Detect and deal properly with network congestion
This may not always be a good solution though, because the added complexity to the application may be considered excessive, and the mechanisms needed are not trivial to design and implement correctly.
1.3.3 SCTP Enhancements over TCP and UDP
Two major new capabilities are designed into SCTP: the support for multi-homed hosts and the support for multiple streams in a single SCTP association.
The built-in support for multi-homed hosts allows a single SCTP association to run across multiple links or paths, hence achieving link/path redundancy. With this capability, an SCTP association can be made to achieve fast failover from one link/path to another with little interruption to the data transfer service.
The multiple stream mechanism is designed to solve the head-of-the-line blocking problem of TCP. This feature gives the user of SCTP the ability to define subflows inside the overall SCTP message flow and to enforce message ordering only within each of the subflows. Therefore, messages from different subflows will not block one another.
Besides the two major new features just described, there are other enhancements designed into SCTP. Table 1–1 gives a more detailed feature comparison between SCTP and TCP and UDP.