he limitations present in TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) for transporting signaling traffic led to the design of a new transport protocol within the IETF (Internet Engineering Task Force). The SIGTRAN working group developed the Stream Control Transmission Protocol (SCTP) [1, 2] . SCTP was first intended to transport telephony signaling over an unreliable network such as an IP network [3] . However, the protocol has been designed so that SCTP can be used as a general-purpose message-based transport protocol. We compare the behavior and performance of SCTP with existing transport protocols. Our simulations show that Head of the Line (HOL) blocking, widely believed to be TCP's major limitation when carrying signaling traffic, does not introduce a significant performance decrease even under heavy load. We also discovered some issues regarding transport-layer fragmentation. In order to perform a fair comparison, we needed an application-layer protocol that could run on top of all the different transport protocols we wanted to analyze, namely SCTP, UDP, and TCP. We chose the Session Initiation Protocol (SIP) [4] . SIP is an application-layer protocol for creating, modifying, and terminating sessions. The basic operation of SIP does not depend on the lower-layer transport protocol, which makes it an ideal choice to compare the performance of different transports. The SIP specification [4] describes how the protocol operates over TCP [5] and over UDP [6] . TCP provides reliable in-order transfer of bytes, while UDP does not ensure either reliability or in-order delivery. We defined in [7] how SIP can run on top of SCTP. Although there are already implementations of telephony signaling protocols such as ISUP on top of SCTP, we know of no SIP implementations that use SCTP. The remainder of this article is organized as follows. We introduce SCTP and SIP, respectively. We also introduce the simulation environment. Using simulations, we compare SCTP, UDP, and TCP as transport protocols for SIP. Finally, we outline some conclusions. The Stream Control Transmission Protocol (SCTP) [1] is a transport protocol tailored to transport signaling traffic. SCTP inherits all its congestion and flow control mechanisms from TCP, but includes a number of improvements intended to make it a more efficient signaling transport than TCP. SCTP is a connection-oriented transport protocol. In SCTP terminology, a connection is referred to as an association. An association is established through a four-way handshake as opposed to the three-way handshake implemented by TCP. Having an additional message in the SCTP handshake, shown in Fig. 1 , protects servers against Denial of Service (DoS) attacks with spoofed IP addresses. In TCP, the SYN flood attack exploits the lack of a stateless return-routability confirmation. The SCTP receiver, after receiving an INIT message, sends back a random number, called a cookie, in an INIT ACK message. This receiver does not allocate any resources for this SCTP association until it receives the same cookie in the COOKIE ECHO message. Thus, resources are allocated only when it is ensured that the party supposedly sending the INIT message is really willing to establish an SCTP association. The COOKIE ACK message simply informs the sender that the COOKIE ECHO massage has been successfully received and that it contained a valid cookie. The last two messages of the four-way handshake can already carry user data. With this data piggybacking, SCTP has the same connection-establishment delay as TCP, namely one roundtrip time. To increase robustness, servers are often equipped with multiple network interfaces. Such servers are said to be multihomed. SCTP was designed with multihoming in mind. During association establishment, an SCTP end-point can provide its  IEEE Network • September/October 2003 41 peer with a list of IP addresses or host names. One destination address is marked as the primary, and is used by the SCTP end-point to send data to the peer under normal circumstances. Should the primary destination address become unavailable, the end-point starts sending traffic to another address on the list provided by the peer. This feature allows SCTP associations to survive certain network failures that would make a TCP connection collapse. Like UDP, SCTP is a message-oriented protocol while TCP is stream-oriented. SCTP delivers messages to the application, whereas TCP delivers a stream of bytes. Message-oriented protocols such as SCTP and UDP simplify application parsers. When these transport protocols deliver a message to the application, it contains a single signaling message. Conversely, in order to extract a signaling message from the stream of bytes received over TCP, it is necessary to implement application-level framing. Every application-layer message transported by SCTP is referred to as a DATA chunk. SCTP bundles DATA chunks so that a single IP datagram can carry several DATA chunks, increasing network efficiency. Figure 2 shows the format of an SCTP message when bundling is performed. SCTP provides multiplexing and demultiplexing of DATA chunks within an association. A single association can contain several streams, where each stream is identified by its stream id. The number of streams in both directions is determined during the four-way handshake (Fig. 1) . Every DATA chunk belongs to one stream; streams are delivered to the application independent of one another. This independent delivery of streams resolves the Head of the Line (HOL) blocking problem present in TCP. HOL blocking occurs when the data associated with multiple logical sessions is interleaved over a single TCP connection. This problem is common in HTTP/1.1, where images and HTML from a single server are retrieved in one TCP connection. If a segment for one of the images gets lost, the delivery of messages for the HTML text has to wait until the image segment has been retransmitted. Thus, a logical session blocks because of loss in another, unrelated one. Similar problems occur if multiple signaling sessions are multiplexed onto a single TCP session between two signaling servers. With SCTP, each applicationlevel session would be assigned its own stream, so that the loss of a packet in one stream does not affect progress in other streams. An SCTP association can contain several types of streams, each offering a different service. The base SCTP specification [1] defines two services: reliable ordered delivery and reliable unordered delivery. Extensions to SCTP [8] describe an unreliable delivery service. In the ordered service, the receiver receives messages in the same order as they were sent by the sender. The unordered service delivers messages to the receiver as soon as they are received from the network, regardless of the order in which the sender produced them. It is important to note that a particular service is provided to each DATA chunk. Therefore, one DATA chunk within a stream might be delivered in order, whereas another DATA chunk within the same stream uses unordered delivery. Even if an association contains several streams, SCTP performs flow and congestion control for the whole association. This allows us to use the behavior of all the traffic within the association as input to the flow and congestion control mechanisms, which are based on the ones used by TCP. SCTP flow control is based on TCP SACK [9] . SACK is an extension to TCP that uses selective ACKs in addition to the cumulative ACKs. The cumulative ACK acknowledges the reception of all the data within a connection with a sequence number less than a certain number, whereas the selective ACK acknowledges the reception of non-contiguous ranges of sequence numbers. The cumulative ACK is the main mechanism to detect packet losses in TCP. If a TCP end-point receives packets 1, 2, 3, 5, and 7, it will send ACK (1), ACK (2), ACK (3), ACK (3), and ACK (3) again. When the sender receives ACK (3) multiple times, it knows that packet 4 was lost and thus has to be retransmitted. However, the sender does not know which packets with a higher sequence number than 4 arrived successfully at the peer and which ones were lost as well. If the receiver had used the SACK TCP option it would have returned ACK (3)-SACK (5) and (7). With this information the sender is able to retransmit not only packet 4, but also packet 6. Performance measurements [10] show that TCP SACK recovers better than TCP Reno and New Reno from multiple losses in a single TCP window. There are only two differences between TCP SACK and SCTP. The 40 bytes available for TCP options can only carry a maximum of four SACK blocks per TCP segment, while SCTP does not impose any limit on the number of SACK chunks in a packet. Secondly, TCP SACK uses the information in SACKs only to retransmit lost segments, while SCTP uses this information to perform both flow and congestion control. SCTP uses SACKed DATA chunks to increase its congestion window, whereas TCP SACK does not. In this way SCTP achieves a slightly higher window growth rate than TCP SACK under congestion when both DATA chunks and SACKs get lost. SCTP is "TCP-friendly," that is, it uses about the same amount of bandwidth as a TCP connection under the same network conditions. This is not surprising since SCTP and TCP both use the same window-based congestion control. The sender implements a congestion window (cwnd) that limits the number of bytes that can be injected into the network at a given point of time. The rate at which cwnd grows depends on the state of the connection. If no congestion is detected, the slow start algorithm doubles cwnd every time a whole window of data is acknowledged. Under packet loss, the congestion avoidance algorithm increases cwnd more slowly, namely, linearly rather than exponentially.  SIP is a text-based application-layer protocol used to establish multimedia sessions. SIP can use any transport protocol. Currently, UDP is most widely used, but most implementations are now supporting both UDP and TCP. SIP endpoints negotiate the parameters of a particular multimedia session using an offer/answer model. One end-point provides a session description -typically using the Session Description Protocol (SDP) [11] -that contains the network address and port number where it wants to receive media and the media format, described by the voice and video codecs to be used. SIP delivers this offer to the peer, who then responds with its own session description, the answer, in another SIP message. Once both endpoints have exchanged their session descriptions, they can send media to each other. SIP messages carry session descriptions in the same way as email messages carry attachments, using MIME [12] . SIP establishes sessions between user agents. Besides user agents, SIP defines intermediate network entities called SIP proxies. A SIP proxy receives a message from a user agent or from another proxy and relays it to the next SIP hop, which can be yet another proxy or the destination user agent. Figure 3 shows the typical SIP message exchange to establish a session. The figure contains two user agents, caller and callee, and a proxy. The caller sends an INVITE request indicating that the caller is willing to establish a session with the callee. The caller then receives two responses, a "100 Trying" response followed, if the callee answers, by a "200 OK" response. The former indicates that the request has been received; the callee uses the "200 OK" to indicate that she is willing to join this multimedia session. (The callee has a list of error status codes to indicate various failures.) SIP is based on an HTTP-like request/response transaction model and therefore SIP responses follow the same format used in HTTP. Upon reception of the "200 OK" response, the caller sends an ACK request to acknowledge receiving this response. SIP uses two two-way handshakes to establish a session: "INVITE-100 Trying" and "200 OK-ACK". The first handshake is between neighboring SIP nodes, with each response generated by the next hop. The second handshake is between the request origin and its final destination, i.e., two user agents. The "200 OK" response still traverses all hops, while the ACK request may bypass intermediate hops and go straight from caller to callee or proxy servers may ask to be in its path. In Fig. 3 , the proxy responds to the INVITE request received from the caller. Therefore, a single transport protocol is used for this type of handshake. In the second handshake, the response is generated by the remote SIP user agent; proxies in the path simply relay the response. Thus, end-to-end handshakes can involve multiple transport protocols. In the example of Fig. 3 , the "200 OK-ACK" handshake uses two different transport protocols: TCP from caller to proxy and UDP from proxy to callee. This article focuses on the "INVITE-100 Trying" hop-byhop handshake. We have chosen this handshake because the traffic behavior between two particular nodes only depends on a single transport protocol. Implementing different transport protocols between the same nodes under the same network conditions shows how efficient each transport protocol is. However, in the end-to-end handshake, different transport protocols affect the traffic behavior. A packet drop by UDP, for instance, may trigger an application-layer retransmission over a TCP connection. We will have this situation in Fig. 3 if the ACK request is dropped in the UDP leg. The caller would have to resend the same ACK over its TCP connection. These interactions between application-layer and transport-layer reliability are outside the scope of this article. For unreliable transport protocols, the hop-by-hop handshake is implemented using timeouts and application-layer retransmissions. The client retransmits the INVITE until the "100 Trying" response is received. The server retransmits the "100 Trying" each time it receives a retransmission of the INVITE. INVITE requests are retransmitted first after 500 ms, with the interval doubling after that. Clients typically consider the next hop unreachable if no response has been received after the sixth retransmission. If the hop-by-hop SIP handshake traverses a reliable transport connection such as TCP, the client sends the INVITE over the transport connection and the server returns the "100 Trying" response over the same connection. The transport layer undertakes the task of delivering the message to the next hop, so that no application-layer retransmissions are needed. SIP over SCTP -SIP over SCTP follows the rules for TCP, so that requests and responses are sent over the same association [7] . We map all SIP traffic onto a single stream using the SCTP unordered service, so that incoming SIP messages are delivered to the application in the same order as they arrive from the network, regardless of the order in which they were sent. This helps avoid the HOL blocking problem present in TCP. (An alternative discussed in [7] is to assign each SIP session its own SCTP stream. This also avoids HOL blocking and may speed up matching requests to state entries, but requires more stream resources.)
Several simulation-based studies have compared end-to-end delays of TCP and SCTP, but their results are ambiguous: REF compares the delay of SIP messages transported over UDP, TCP, or SCTP, respectively.
Evaluation of transport protocols for the session initiation protocol
IEEE Network
Computer Science