Skip to main content

6. User Data Transfer

This chapter describes the user data transfer mechanism between SCTP endpoints.

6.1. Transmission of DATA Chunks​

SCTP endpoints exchange user messages through DATA chunks on an established association.

6.1.1. Payload Data​

The sender SHOULD use "Path MTU Discovery" (as defined in [RFC4821]) to determine the appropriate fragmentation size for the destination.

The sender MAY fragment a user message into multiple DATA chunks, each carrying a portion of the user message. The receiver will use the Stream Sequence Number (SSN) and fragmentation flags (B bit and E bit) to reassemble the message.

When a user message is fragmented into multiple DATA chunks:

  • The first fragment MUST set the B bit to 1 and E bit to 0
  • Middle fragments MUST set the B bit to 0 and E bit to 0
  • The last fragment MUST set the B bit to 0 and E bit to 1
  • An unfragmented message MUST set the B bit to 1 and E bit to 1

All DATA chunks carrying fragments of the same user message MUST have the same Stream Identifier (SI) and Stream Sequence Number (SSN).

6.1.2. Transmission Sequence Number (TSN)​

Each DATA chunk MUST contain a valid TSN. The TSN is a 32-bit sequence number that starts with the Initial TSN value exchanged during association initialization and increments by 1 for each DATA chunk sent.

The TSN space is circular, with comparisons using Serial Number Arithmetic (as defined in [RFC1982]).

The sender MUST NOT use reserved TSN values (i.e., TSNs outside the receiver window announced by its peer) in DATA chunks.

6.1.3. Congestion Control​

SCTP endpoints MUST implement congestion control to avoid network congestion. SCTP uses congestion control mechanisms similar to TCP.

Each SCTP association maintains the following congestion control parameters:

  • cwnd (Congestion Window): The upper limit of data that can be sent without acknowledgement
  • ssthresh (Slow Start Threshold): The threshold that determines when to switch from slow start to congestion avoidance
  • rwnd (Receiver Window): The available buffer space announced by the peer

The amount of unacknowledged data the sender can transmit at any time MUST NOT exceed min(cwnd, rwnd).

Slow Start:

  • At the start of an association or after a timeout, set cwnd to no more than 2*MTU
  • Each time a SACK is received and all acknowledged data was sent during slow start, increase cwnd by no more than the number of bytes acknowledged, but the increase MUST NOT exceed MTU

Congestion Avoidance:

  • When cwnd > ssthresh, increase cwnd by at most 1*MTU per RTT
  • Implementations SHOULD use "Appropriate Byte Counting" (as defined in [RFC3465])

Fast Retransmit and Fast Recovery:

  • When 4 consecutive SACKs report the same TSN as missing, the sender SHOULD immediately retransmit that TSN without waiting for the retransmission timer to expire

6.1.4. Bundling​

SCTP endpoints MAY bundle multiple DATA chunks and control chunks in a single SCTP packet, as long as the total size does not exceed the current path MTU.

Benefits of bundling include:

  • Reduced packet header overhead
  • Improved network efficiency
  • Reduced number of system calls

The sender SHOULD attempt to bundle as much data as possible in a single packet, but MUST NOT delay DATA chunk transmission solely to wait for more data for bundling.

6.2. Acknowledgement on Reception of DATA Chunks​

Receiving SCTP endpoints MUST use SACK (Selective Acknowledgement) chunks to acknowledge received DATA chunks.

6.2.1. SACK Generation Rules​

The receiver SHOULD use the following rules to generate SACKs:

  1. Delayed Acknowledgement:

    • The receiver SHOULD NOT send a SACK immediately for each received packet
    • The receiver SHOULD delay sending a SACK for up to 200ms
    • If a second packet is received, a SACK MUST be sent immediately (no more delay)

  2. Immediate Acknowledgement Situations:

    • When a gap is detected (out-of-order DATA chunk received)
    • When received DATA chunk fills a previous gap
    • When a duplicate TSN is received

  3. SACK Content:

    • Cumulative TSN Ack: The highest consecutively received TSN
    • Gap Ack Blocks: Indicating ranges of consecutive TSNs received after the cumulative point
    • Duplicate TSNs: Listing duplicately received TSNs

6.2.2. SACK Processing​

Upon receiving a SACK, the sender MUST:

  1. Update its cumulative acknowledgement point to the Cumulative TSN Ack indicated in the SACK
  2. Mark DATA chunks acknowledged in Gap Ack Blocks as acknowledged
  3. Update congestion window and slow start threshold
  4. Schedule retransmissions as needed

6.2.3. Receiver Window Update​

The SACK chunk includes the advertised receiver window credit (a_rwnd), indicating the receiver's available buffer space.

The receiver SHOULD accurately report its available buffer space in the SACK. The receiver MUST NOT reduce an already announced window size unless it has consumed the corresponding buffer space.

6.3. Management of Retransmission Timer​

SCTP uses retransmission timers to ensure reliable transmission. Each destination transport address maintains its own retransmission timer.

6.3.1. RTO Calculation​

The Retransmission Timeout (RTO) is calculated using an algorithm similar to TCP:

SRTT = Smoothed Round-Trip Time
RTTVAR = Round-Trip Time Variation

Initial values:
RTO.Initial = 3 seconds (recommended value)
RTO.Min = 1 second
RTO.Max = 60 seconds

First RTT measurement (R):
SRTT = R
RTTVAR = R/2
RTO = SRTT + 4 * RTTVAR

Subsequent RTT measurements (R'):
RTTVAR = (1 - Beta) * RTTVAR + Beta * |SRTT - R'|
SRTT = (1 - Alpha) * SRTT + Alpha * R'
RTO = SRTT + 4 * RTTVAR

Where: Alpha = 1/8, Beta = 1/4

Upon each retransmission, the RTO SHOULD be doubled (exponential backoff) until RTO.Max is reached.

6.3.2. Timer Rules​

T3-rtx Timer (Retransmission Timer):

  • When a DATA chunk is first sent to a destination and the T3-rtx timer for that destination is not running, it MUST be started
  • When all unacknowledged DATA chunks sent to a destination are acknowledged, the T3-rtx timer for that destination MUST be stopped
  • When the T3-rtx timer expires, the earliest unacknowledged DATA chunk on that destination MUST be retransmitted

T3-rtx Timeout Handling:

  1. Mark destination as inactive (if applicable)
  2. Set ssthresh to max(cwnd/2, 4*MTU)
  3. Set cwnd to 1*MTU
  4. Retransmit the earliest unacknowledged DATA chunk
  5. Double the RTO

6.3.3. Heartbeat Mechanism​

To monitor destination reachability, SCTP endpoints SHOULD periodically send HEARTBEAT chunks to each idle destination.

The HEARTBEAT interval SHOULD be configurable, with a recommended default of 30 seconds.

When a HEARTBEAT is sent:

  • Start the Heartbeat timer
  • Include sending timestamp and destination address information in the HEARTBEAT

When a HEARTBEAT ACK is received:

  • Calculate RTT
  • Update RTO
  • Mark destination as active

If HEARTBEAT times out (no HEARTBEAT ACK received):

  • Increment destination's error count
  • If error count exceeds threshold, mark destination as inactive

6.4. Multi-Homed SCTP Endpoints​

SCTP supports multi-homed endpoints, i.e., endpoints with multiple IP addresses.

6.4.1. Primary and Alternate Paths​

Each SCTP endpoint maintains:

  • Primary Path: The preferred path for normal data transmission
  • Alternate Paths: Paths used when the primary path fails

The endpoint SHOULD preferentially send data through the primary path, using alternate paths only when the primary path is unavailable.

6.4.2. Path Selection​

The sender SHOULD:

  • Use the primary path to send new data
  • Use alternate paths for retransmissions (if primary path has failed)
  • Periodically probe all paths using HEARTBEAT

When the primary path is determined to be inactive, the sender SHOULD select an active alternate path as the new primary path.

6.4.3. Path Failure Detection​

A path is considered failed when:

  • Multiple consecutive transmission failures occur (reaching Path.Max.Retrans)
  • Multiple consecutive HEARTBEAT timeouts occur

When all paths fail, the association SHOULD be reported to the upper layer and may be terminated.

6.5. Stream Identifier and Stream Sequence Number​

SCTP supports multiple concurrent streams, each uniquely identified by a Stream Identifier (SI).

Stream Identifier (SI):

  • 16-bit value, range 0 to 65535
  • Number of streams negotiated during association initialization
  • Each stream independently delivers user messages

Stream Sequence Number (SSN):

  • 16-bit value, maintained independently per stream
  • Used to reorder and reassemble messages at the receiver
  • Incremented per stream

Streams provide logical separation of messages, allowing multiple independent data flows to be transmitted concurrently on the same association, avoiding Head-of-Line Blocking.

6.6. Ordered and Unordered Delivery​

SCTP supports two message delivery modes:

6.6.1. Ordered Delivery​

Default mode. Messages are delivered to the upper layer in the order they were sent within each stream.

  • U bit of DATA chunk set to 0
  • Stream sequence number ensures ordering
  • Messages on the same stream delivered in SSN order

6.6.2. Unordered Delivery​

Messages are delivered to the upper layer immediately upon reception, regardless of order.

  • U bit of DATA chunk set to 1
  • Stream sequence number is ignored
  • Delivered immediately upon reception, without waiting for previous messages

Unordered delivery is suitable for real-time data that doesn't require ordering guarantees (e.g., video streams).

6.7. Report Gaps in Received DATA TSNs​

When the receiver detects gaps in the received sequence (i.e., receives out-of-order data), it MUST report these gaps in the SACK.

Gap Ack Block Format:

Gap Ack Block Start: Offset relative to Cumulative TSN Ack
Gap Ack Block End: Offset relative to Cumulative TSN Ack

For example, if Cumulative TSN Ack = 100, and TSNs 102-105 are received:

Gap Ack Block Start = 2  (102 - 100)
Gap Ack Block End = 5    (105 - 100)

The receiver MAY report multiple gap blocks in a single SACK.

6.8. CRC32c Checksum Calculation​

SCTP uses CRC32c (Castagnoli) as its checksum algorithm, providing stronger error detection capability than simple checksums.

6.8.1. Checksum Calculation Steps​

  1. Set the checksum field of the SCTP packet to all zeros
  2. Calculate CRC32c over the entire SCTP packet (including SCTP common header and all chunks)
  3. Place the calculated CRC32c value in the checksum field

CRC32c Polynomial:

x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + 
x^18 + x^14 + x^13 + x^11 + x^10 + x^9 + x^8 + x^6 + x^0

The receiver MUST verify the CRC32c checksum of each received SCTP packet. If the checksum doesn't match, the packet MUST be silently discarded.

This chapter comprehensively covers the core mechanisms of SCTP user data transfer, including reliable transmission, congestion control, multi-homing support, and stream multiplexing.

Last updated on