SCTP Features

The Signaling Transport (SIGTRAN) Working Group in IETF developed SCTP to address the limitations in TCP and UDP. Though the development of SCTP was directly motivated by the need to transfer Public Switched Telephone Network (PSTN) signaling messages across the IP network, SIGTRAN ensured that the design meets the requirements of other applications with similar requirements.

Table 1-2 compares features of SCTP, TCP, and UDP.

Table 1-2 Comparison Between SCTP, TCP, and UDP

Feature	SCTP	TCP	UDP
State required at each endpoint	yes	yes	no^[1]
Reliable data transfer	yes	yes	no
Congestion control and avoidance	yes	yes	no
Message boundary conservation	yes	no^[2]	yes
Path MTU discovery and message fragmentation	yes	yes^[2]	no
Message bundling	yes	yes^[2]	no
Multi-homed hosts support	yes	no	no
Multi-stream support	yes	no	no
Unordered data delivery	yes	no	yes
Security cookie against `SYN` flood attack	yes	no	no
Built-in heartbeat (reachability check)	yes	no^[3]
^[1]In UDP, a node can communicate with another node without going through a setup procedure, or without changing any state information. However, each UDP packet contains the required state information to form a connection, so that an ongoing state need not be maintained at each endpoint. ^[2]TCP does not preserve any message boundaries. It treats all the data passed from its upper layer as a formatless stream of data bytes. However, because TCP transfers data in sequence of bytes, it can automatically resize all the data into new TCP segments that are suitable for the Path MTU, before transmitting them. ^[3] TCP implements a keep-alive mechanism, which is similar to the SCTP `HEARTBEAT` chunk. In TCP, however, the keep-alive interval is, by default, set to two hours for state cleanup. In SCTP, the `HEARTBEAT` chunk is used to facilitate fast failover.

This section addresses the following topics:

Multihoming

Multihoming is the ability of a single SCTP endpoint to contain multiple interfaces with different IP addresses. In a single-homed connection, an endpoint contains only one network interface and one IP address.

Figure 1-5 illustrates the single-homed connection in TCP.

Figure 1-5 A Single-Homed Connection

In Figure 1-5, Host A contains a single network interface (NI_A1) and Host B contains a single network interface (NI_B1). NI_A1 is the only interface for Host A to interact with Host B.

When a network or path failure occurs, the endpoint is completely isolated from the network. Multihoming in SCTP ensures better chances of survival if a network failure occurs, when compared to TCP. The built-in support for multi-homed hosts in SCTP enables a single SCTP association to run across multiple links or paths, to achieve link or path redundancy. This enables an SCTP association to achieve faster failover from one link or path to another, with minimum interruption in the data transfer service.

Figure 1-6 illustrates the mutli-homed connection in SCTP.

Figure 1-6 A Multihomed Connection

In this figure, Host A contains multiple network interfaces to interact with Host B, which also has multiple interfaces.

SCTP selects a single address as the "primary" address and uses it as the destination for all DATA chunks for normal transmission. All the other addresses are considered as alternate IP addresses. SCTP uses these alternate IP addresses to retransmit DATA chunks and to improve the probability of reaching the remote endpoint. Retransmission may occur because of continued failure to send DATA to the primary address. As a result, all DATA chunks are transmitted to the alternate address until the HEARTBEAT chunks have re-established contact with the primary address

During the initiation of an association, the SCTP endpoints exchange the list of IP addresses, so that each endpoint can receive messages from any of the addresses associated with the remote endpoint. For security reasons, SCTP sends response messages to the source address in the message that prompted the response.

An endpoint can receive messages that are out of sequence or with different address pairs, because multi-homing supports multiple IP addresses. To overcome this problem, SCTP incorporates procedures to resolve parallel initiation attempts into a single association.

Multistreaming

Multistreaming enables data to be sent in multiple, independent streams in parallel, so that data loss in one stream does not affect or stop the delivery of data in other streams. Each stream in an SCTP association uses two sets of sequence numbers, namely a Transmission Sequence Number (TSN) that governs the transmission of messages and the detection of message loss, and the Stream ID/Stream Sequence Number (SID/SSN) pair that determines the sequence of delivery of the received data.

TCP transmits data sequentially in the form of bytes in a single stream and ensures that all the bytes are delivered in a particular order. Therefore, a second byte is sent only after the first byte has safely reached the destination. The sequential delivery of data causes delay when a message loss or sequence error occurs within the network. An additional delay occurs when TCP stops sending data until the correct sequencing is restored, either upon receiving an out-of-sequence message or by retransmitting a lost message.

The strict preservation of message sequence in TCP poses a limitation for certain applications. These applications require sequencing of messages that affect the same resource (such as the same call or the same channel), so that messages are loosely correlated and delivered without maintaining the overall sequence integrity.

The multistreaming feature in an SCTP, in which reliable data transmission and data delivery are independent of each other, overcomes this problem. This feature also avoids HOL blocking. This independence improves the flexibility of an application, by allowing it to define semantically different streams of data inside the overall SCTP message flow, and by enforcing message ordering only within each of the streams. As a result, message loss in one particular stream does not affect the delivery of messages in a different stream. The receiver can immediately determine if there is a gap in the transmission sequence (for example, caused by message loss), and also can determine whether messages received following the gap are within the affected stream. If SCTP receives a message that belongs to the affected stream, a corresponding gap occurs in SSN. The sender can continue to deliver messages to the unaffected streams while buffering messages in the affected stream until retransmission occurs.

Figure 1-7 illustrates how multi-streaming works in an SCTP association.

Figure 1-7 Multistreaming in an SCTP Association




	NOTE: By default, SCTP contains two streams. SCTP uses stream `0` as the default stream to transmit data. Applications can modify the number of streams through which SCTP transmits data.

Conservation of Data Boundaries

In SCTP, a sending application can construct a message out of a block of data bytes and instruct SCTP to transport the message to a receiving application. SCTP guarantees the delivery of this message (data block) in its entirety. It also indicates to the receiver about both the beginning and end of the data block. This is called conservation of message boundaries. TCP does not conserve data boundaries. It treats all the data passed to it from the sending application as a sequence or stream of data bytes. It delivers all the data bytes to the receiver in the same sequential order as they were passed from the application. TCP does not conserve data boundaries when packets arrive out of sequence. As a result, the receiver cannot rearrange the packets. It has to wait till the packets arrive in sequence, starting from the last unreceived packet to the received out-of-sequence packet.

SCTP Graceful Shutdown Feature

SCTP does not support a "half-open" connection, which can occur in TCP. In a half-open connection, even though an endpoint indicates that it has no more data to send, the other endpoint continues to send data indefinitely. SCTP, on the other hand, assumes that when the shutdown procedure begins, both the endpoints will stop sending new data across the association. It also assumes that it needs only to clear up acknowledgements of the previously sent data.

The SCTP shutdown feature uses a three-message procedure to gracefully shutdown the association, in which each endpoint has confirmed the receipt of the DATA chunks before completing the shutdown process. When an immediate shutdown is required, SCTP sends an ABORT message to an endpoint.

Figure 1-8 illustrates graceful shutdown in SCTP and the half-closed state in TCP.

Figure 1-8 Shutdown in TCP and SCTP

SCTP Support for IPv4 and IPv6 Addresses

SCTP supports both IPv4 and IPv6 address parameters in an SCTP packet, as defined in RFC 2960 (Stream Control Transmission Protocol). When an association is set up, the SCTP endpoints exchange the list of addresses of the endpoints in the INIT and INIT-ACK chunks. The address of the endpoint is represented by the following parameters: an IPv4 address parameter with value 5 and an IPv6 address parameter with value 6. The INIT chunks can contain multiple addresses, which can be an IPv4 or IPv6 address.

SCTP Data Exchange Features

This section discusses the enhanced features in SCTP that ensures reliable data exchange between endpoints.

Following are the data exchange features in SCTP:

In SCTP, data is transmitted in the form of packets. Each packet contains a DATA chunk and a control chunk. An SCTP endpoint acknowledges the receipt of a DATA chunk by sending a SACK chunk to the other endpoint. The SACK chunk indicates the range of cumulative TSNs and non-cumulative TSNs, if any. The non-cumulative TSNs indicate gaps in the received TSN sequence. When SCTP identifies gaps in the TSN sequence, it resends the missing DATA chunks to the other endpoint. SCTP uses the “delayed ack” method to send the SACK chunks. In this method, SACK is sent for every second packet, but with an upper limit on the delay between SACKs. The frequency of sending SACKs increases to one per received packet if gaps are detected in the TSN sequence.
For information on an SCTP packet, see “SCTP Packet”.
SCTP contains various congestion control algorithms, such as slow start, congestion avoidance, fast recovery, and fast retransmit, to control the flow and retransmission of data. For information on these congestion control algorithms see, “Congestion Control in SCTP”. In these algorithms, the receiver advertises the receive window and a sender advertises a per-path congestion window to handle congestion. The receiver window indicates buffer occupancy of the receiver. The per-path congestion window manages the packets in flight. The congestion control algorithms in SCTP are similar to that of TCP, except that the endpoints in an SCTP connection manages the conversion between bytes sent and received, and TSNs sent and received. This is because a TSN is attached only to a chunk.
An HP-UX application can specify a lifetime for the data to be transmitted. If the lifetime of the data has expired and the data has not been transmitted, the data, such as time-sensitive signalling messages, can be discarded. If the lifetime of the data has expired and the data has been transmitted, data must be delivered to avoid a hole in the TSN sequence.

Support for Dynamic Address Reconfiguration

SCTP enables an endpoint to reconfigure the IP address information dynamically for an existing association. When the endpoints exchange information during association startup, the usability of SCTP also improves without modifying the SCTP protocol. This feature is useful in computational and networking applications that add or remove physical interface cards dynamically and need the IP address of the interface to be changed dynamically. This feature also enables an endpoint to set the primary destination address of a remote peer so that when the primary address of an endpoint is deleted, the remote peer is informed of the address to which the data must be sent.

To enable SCTP to reconfigure IP addresses dynamically, an SCTP packet contains the following chunk types:

Address Configuration Change Chunk (ASCONF): The ASCONF chunk communicates the configuration change requests that must be acknowledged, to the remote endpoint.
Address Configuration Acknowledgment (ASCONF-ACK): The ASCONF-ACK chunk is used by the receiver of an ASCONF chunk to acknowledge the reception of the ASCONF chunk.

Reporting Packet Drops to an Endpoint

When a packet drop occurs because of an error other than congestion, an endpoint can mistakenly interpret the packet drop as an indication of congestion in the network. The misinterpretation can cause an SCTP sender to stop sending packets. This results in under-utilization of the network link. Depending on the severity of the error, the sender can remain in a state of congestion, which affects the performance of the association.

SCTP contains the PKTDROP chunk that discovers packets that are dropped because of errors other than congestion. After receiving the PKTDROP chunk, an SCTP endpoint can inform its peer that it has received an SCTP packet with an incorrect CRC32C or Adler-32 checksum. The peer can then retransmit the SCTP packet without modifying the congestion window.

For information on packet drop scenarios, see draft-stewart-sctp-pktdrprep-02.txt (Stream Control Transmission Protocol (SCTP) Packet Drop Reporting) at:

http://tools.ietf.org/html/draft-stewart-sctp-pktdrprep-02

Support for ECN-Nonces in SCTP

With the increased deployment of real-time applications and transport services that are sensitive to the delay and loss of packets, relying on packet loss alone as indicative of congestion is not sufficient. SCTP's congestion management algorithms have built-in techniques, such as Fast Retransmit and Fast Recovery, to minimize the impact of losses. These mechanisms consider the network as a black box and continue to send packets till packets are dropped because of congestion. However, these mechanisms are not intended to help applications that are sensitive to the delay or loss of one or more individual packets.

With the inclusion of active queue management techniques in the Internet infrastructure, routers can assist in managing congestion. When a congestion occurs and the sender continues to send packets, the number of packets in the queue in the router increases and causes a bottleneck in the router. In such a case, the router marks the packets with congestion experienced (CE) bits and sends them to the receiver to indicate congestion, instead of dropping the packets. Explicit Congestion Notification (ECN) is a congestion management algorithm that uses a similar method to handle congestion. ECN uses the ECN field and the congestion experienced (CE) field in the IP header to mark the packets. The ECN field contains the ECN-Capable Transport (ECT) field, which is set by the data sender to indicate that the endpoints are ECN-capable. The CE bit is set by the router to indicate congestion. The ECT code points range from 00 to 01. Senders use the ECT (0) or ECT(1) code point to indicate ECT for each packet.

ECN uses the following information to provide congestion notifications:

Negotiation between the endpoints during connection setup to determine whether they are both ECN-capable.
An ECN-Echo (ECNE) flag in the the IP header, which enables the data receiver to inform the data sender when a CE packet is received.
A congestion window reduced (cwr) flag in the IP header, which enables the data sender to inform the data receiver that the congestion window has been reduced.

The drawback in ECN is that a poorly implemented receiver or an intermediate network element, such as router, firewall, intrusion detection system, can erase the ECNE flag that provides congestion signal to the sender. This is because ECN does not contain mechanisms to avoid network elements from clearing the ECNE flag. Moreover, ECN requires the cooperation of the receiver to return congestion experienced signals to the sender. If the receiver erases the congestion signals to conceal congestion and does not send these signals to the sender, the sender gains a performance advantage at the expense of competing connections that do not experience congestion.

SCTP supports the ECN method and is exposed to misbehaving receivers that conceal congestion signals. The misbehavior includes concealment of ECNE signals that may cause an SCTP sender to be aggressive and unfair to compliant flows. SCTP supports ECN-nonce to avoid misbehaving receivers from concealing congestion signals. ECN-nonce also protects senders from other forms of misbehavior, such as optimistic acknowledgements and false duplicate TSN notifications.

The ECN-nonce is a modification of the ECN signaling mechanism. It improves the congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. ECN-nonce improves the robustness of ECN by preventing receivers from concealing marked or dropped packets. Like ECN, ECN-nonce uses the ECT(0) and ECT(1) code points, the IP header flag, the cwr, and the ECNE bits.

The ECN-nonce uses two bits of the IP header called the ECT bits. The sender randomly generates a single bit nonce and encodes it in the ECT codepoints, ECT(0) or ECT(1). To indicate congestion in the network, routers overwrite the ECT codepoints with the CE bit. The nonce sum (NS) is a cumulative one bit addition of the nonces received from the receiver. The receiver calculates the nonce sum and returns it in the NS flag of the SACK chunk. The sender verifies the value of the NS flag in the SACK chunk. An incorrect nonce sum implies that one or more nonces are missing at the receiver, because all the nonces are required to calculate the correct nonce sum. If an incorrect nonce sum is received by the sender without ECNE signals, the sender can infer that the receiver is concealing congestion notifications.

The ECN-nonce support in SCTP includes the following:

A single nonce-supported parameter in the INIT or INIT-ACK chunk that is exchanged during the association establishment, to indicate to the peer whether ECN-nonce is supported at both endpoints.
A single bit flag in the SACK chunk called the Nonce Sum (NS).

SCTP Support for Partially Reliable Data Transmission

SCTP supports partially reliable data transmission service (PR-SCTP) that enables an SCTP sender to signal the receiver that it must not expect data from the SCTP sender. PR-SCTP enables ordered and unreliable data transfer service between endpoints, in addition to unordered and unreliable data transfer (similar to UDP). PR-SCTP employs similar congestion control and congestion avoidance algorithms as SCTP, for both reliable or partially reliable data traffic.

The communication failure detection and protection capabilities of reliable SCTP data traffic are also applicable to partially reliable data traffic. PR-SCTP enables an endpoint to detect a failure destination address quickly and to failover to an alternate destination address. It also notifies when the destination address becomes unreachable.

The chunk bundling capability in SCTP enables reliable and unreliable messages to be multiplexed over a single PR-SCTP association. Multiplexing enables a single protocol (that is SCTP) to be used to transmit different types of messages, instead of using separate protocols.

SCTP includes the following parameter and chunk to support the partially reliable data transmission service:

The Forward-TSN-Supported parameter: This is an optional parameter in the INIT and INIT ACK chunks. When an association is initialized, the SCTP sender must include this parameter in the INIT or INIT ACK chunk to inform its peer that it supports partially reliable data service.
The Forward Cumulative TSN (FORWARD TSN) chunk: The receiver sends this chunk to a sender to inform its support for PR-SCTP. An SCTP sender uses this chunk to inform the receiver to move its cumulative received TSN forward, because the missing TSNs are associated with data chunks that must not be transmitted or retransmitted by the sender.

The timed-reliability service is an example of a partially reliable service that SCTP provides to the upper layer using PR-SCTP. This service enables the service user to indicate a limit on the duration of time that the sender must try to transmit or retransmit the message.

If an SCTP endpoint supports the FORWARD TSN chunk, it can include the Forward-TSN-supported parameter in the INIT chunk to indicate support for FORWARD TSN chunk to its peer. If an endpoint chooses not to include the Forward-TSN-Supported parameter, it cannot send or process a FORWARD TSN chunk anytime during the lifetime of an association. Instead, it must pretend as if it does not support the FORWARD TSN chunk and return an error to the peer upon the receipt of any FORWARD TSN chunk.

When a receiver of an INIT or INIT ACK chunk detects a Forward-TSN-Supported parameter and does not support the Forward-TSN chunk type, the receiver may optionally respond with the Unsupported Parameters parameter, as defined in Section 3.3.3 of RFC 2960.

A receiver can perform the following tasks if it receives an INIT chunk that does not contain the Forward-TSN-Supported parameter:

Include the Forward-TSN-Supported parameter in INIT-ACK.
Record the information that the peer does not support the FORWARD TSN chunk.
Restrain from sending a FORWARD TSN chunk at any time during the lifetime of an association.
Check with the upper layer if it has requested a notification on whether the peer endpoint supports the Forward-TSN-Supported parameter.