The network traffic in the Internet is unpredictable. Sudden
network failures and traffic surges can occur, which result in non-reachability
of an endpoint. Such a network is error prone and a sending application
must be cautious while transmitting or retransmitting data, because
the receiving endpoint may be unavailable to receive data. The unavailability
of the endpoint is caused either by a path failure or an endpoint
failure.
SCTP offers appropriate error handling methods, to overcome
this problem. Before transmitting data, SCTP sends chunks of information
to verify whether a destination is active. Even before using a different
path to reach a destination or closing an association, SCTP ensures
that the destination address is not reachable or inactive.
SCTP uses the following error handling methods:
Retransmission of DATA chunks
HEARTBEATs to identify path failures
HEARTBEATs to identify endpoint
failures
This section addresses the following topics:
Retransmission of DATA Chunks |
 |
SCTP uses DATA chunks to exchange information
between two addresses. Upon receiving a DATA chunk, the receiving address sends
an acknowledgement to the sending address. If the receiving address
does not receive the DATA chunk properly, it sends
a SACK packet that triggers the sending address to retransmit the DATA chunk. The sending address also retransmits the DATA chunk when the retransmission timer times out.
SCTP limits the rate of retransmission of DATA chunks, to reduce chances of congestion. It modifies the retransmission timeout
(RTO) value, based on the estimates of the round trip delay and reduces
the transmission rate exponentially when the message loss increases.
In an active SCTP association with constant DATA transmission, SACKs are more likely to cause
retransmission than the retransmission timeout. To reduce unnecessary
retransmission of data, SCTP uses the four SACK rule, so that SCTP retransmits a DATA chunk only
after receiving the fourth SACK, which indicates
a missing DATA chunk. SCTP also uses the four SACK
rule to avoid retransmission caused by normal occurrences, such as
packets received out of sequence.
HEARTBEATs to Identify Path Failures |
|
SCTP periodically sends HEARTBEAT chunks to idle destinations,
or alternate addresses to identify a path failure. SCTP maintains
a counter to store the number of heartbeats that are sent to the inactive
destination, without receiving a corresponding Heartbeat
Ack chunk. When the counter reaches the specified maximum
value, SCTP also declares the destination address as inactive. SCTP
notifies the application about the inactive destination address and
starts using an alternate address for sending the DATA chunks.
However, SCTP continues to send heartbeats to the inactive destination
address until it receives an ACK chunk. On receipt
of an ACK chunk, SCTP considers the destination
address as active again. The rate at which SCTP sends heartbeats depends
on the sum of the RTO value and the delay parameter, which allow Heartbeat
traffic to be tailored per the needs of the user application.
HEARTBEATs to Identify Endpoint Failure |
|
SCTP identifies an endpoint failure in a way that is similar to path failure
discussed in “HEARTBEATs to Identify Path Failures”
SCTP maintains a counter across all destination addresses, to
store the number of retransmits or Heartbeats sent to the remote endpoint
without a successful ACK. When the value of the
counter exceeds a preconfigured maximum value, SCTP declares the endpoint
as unreachable and closes the association.
Printable version
