Skip to main content

7. Congestion Control

SCTP uses congestion control mechanisms similar to TCP to avoid network congestion and ensure fair sharing of network resources.

7.1. SCTP Differences from TCP Congestion Control​

While SCTP's congestion control is based on TCP mechanisms, there are the following key differences:

7.1.1. Multi-Homing and Multi-Path​

SCTP supports multi-homed endpoints, with each destination transport address maintaining independent congestion control parameters:

  • Per-destination cwnd: Each path has its own congestion window
  • Per-destination ssthresh: Each path has its own slow start threshold
  • Per-destination RTO: Each path has its own retransmission timeout

This allows SCTP to perform congestion control independently on different paths.

7.1.2. TSN-Based Acknowledgement​

SCTP uses TSNs rather than byte sequence numbers for acknowledgement. This means:

  • Congestion window is maintained in bytes
  • SACK acknowledges TSN ranges
  • cwnd updates are based on acknowledged bytes, not TSN counts

7.1.3. Multi-Stream Transmission​

SCTP's multiple streams share the same association's congestion control parameters. There is no separate congestion control between streams, which ensures:

  • All streams fairly share bandwidth
  • Prevents a single stream from monopolizing resources

7.2. SCTP Slow-Start and Congestion Avoidance​

SCTP's congestion control algorithm follows TCP's slow start and congestion avoidance principles.

7.2.1. Initialization and Restart​

When an association is first established or a path restarts after being idle:

cwnd = min(4*MTU, max(2*MTU, 4380 bytes))
ssthresh = peer's a_rwnd

Note: The initial cwnd calculation ensures at least 2 full packets can be sent, but not more than 4 MTU-sized packets.

7.2.2. Slow Start Phase​

During slow start (cwnd <= ssthresh):

When a SACK for new data is received:

cwnd = cwnd + min(acknowledged bytes, MTU)

Rules:

  • cwnd increases by at most one MTU at a time
  • Only increase when all acknowledged data was sent under the current cwnd
  • When cwnd reaches or exceeds ssthresh, enter congestion avoidance phase

7.2.3. Congestion Avoidance Phase​

When cwnd > ssthresh:

Using Appropriate Byte Counting (ABC):

Per RTT:
partial_bytes_acked = partial_bytes_acked + acknowledged bytes

When partial_bytes_acked >= cwnd:
    cwnd = cwnd + MTU
    partial_bytes_acked = partial_bytes_acked - cwnd

Goal: Increase cwnd by approximately 1 MTU per RTT.

7.2.4. Congestion Detection and Response​

Signals of congestion:

  1. Retransmission timeout (RTO expires)
  2. Fast retransmit (4 duplicate SACKs received)

Response to RTO timeout:

ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0

Response to fast retransmit:

ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
partial_bytes_acked = 0

7.2.5. Handling After Idle Period​

If a destination has no data transmission for an RTO period (idle):

Option 1 (Recommended):

cwnd = max(cwnd/2, 4*MTU)

Option 2 (Conservative):

cwnd = min(4*MTU, max(2*MTU, 4380 bytes))

This prevents suddenly sending large amounts of data after a long idle period.

7.3. Path MTU Discovery​

SCTP endpoints SHOULD use Path MTU Discovery (Packetization Layer PMTUD as defined in [RFC4821]) to:

  • Determine the maximum available MTU to the destination
  • Avoid IP fragmentation
  • Optimize data transmission efficiency

7.3.1. PMTU Discovery Process​

  1. Initial MTU: Use a conservative initial value (typically 576 bytes for IPv4, 1280 bytes for IPv6)

  2. Probe for larger MTU:

    • Send packets with "Don't Fragment" flag set
    • If successful, try larger MTU
    • If failed (receive ICMP "Packet Too Big"), use smaller MTU

  3. Periodic re-probing: Periodically try larger MTU to adapt to path changes

7.3.2. Impact of MTU Updates on Congestion Control​

When PMTU increases:

cwnd = (cwnd / old_MTU) * new_MTU
ssthresh = (ssthresh / old_MTU) * new_MTU

When PMTU decreases:

cwnd = (cwnd / old_MTU) * new_MTU
ssthresh = (ssthresh / old_MTU) * new_MTU
partial_bytes_acked = min(partial_bytes_acked, cwnd)

This ensures congestion control parameters maintain a consistent relationship with MTU size.

7.3.3. Failure Handling​

If PMTU discovery fails or is unavailable:

  • Use conservative MTU value
  • Do not use "Don't Fragment" flag
  • Allow IP layer to perform fragmentation

Summary​

SCTP's congestion control design considers the following key factors:

  1. Multi-path support: Independent congestion control per path
  2. TCP-friendliness: Fair sharing of network bandwidth with TCP
  3. Multi-stream efficiency: Avoid head-of-line blocking while maintaining congestion control
  4. Path adaptation: Optimize transmission through PMTU discovery

These mechanisms ensure SCTP can efficiently utilize network resources while coexisting fairly with other traffic.

Last updated on