Mastering TCP: How SACK, Delayed ACK, and RTT Boost Performance Testing

SACK: Enhancing Retransmission Efficiency

In traditional TCP, when a packet loss is detected the receiver can only acknowledge the last in‑order byte, forcing the sender to retransmit the entire window, which is inefficient in high‑loss or high‑BDP networks. Selective Acknowledgment (SACK) allows the receiver to inform the sender about specific ranges of out‑of‑order data that have arrived, so only the missing segments are retransmitted.

How It Works

The receiver includes SACK options in the ACK packet, listing the blocks of data that were received out of order. The sender then retransmits only the gaps.

Practical Use Cases

When a server sends packets 1‑100 and the receiver loses 51‑60 but receives 61‑100, the SACK‑enabled ACK will indicate that 61‑100 is present, prompting the sender to retransmit only 51‑60, dramatically reducing unnecessary traffic.

Testing Recommendations

Performance engineers should enable SACK (e.g., verify net.ipv4.tcp_sack is on) and use tools like tc or netem to simulate loss, then confirm that SACK options appear in captured packets.

Delayed ACK: Balancing Efficiency and Latency

TCP normally sends an ACK for every received segment, but this can waste bandwidth and CPU. Delayed ACK postpones the ACK for a short interval (typically 100‑200 ms) to allow it to be piggybacked on outgoing data, reducing the number of packets.

How It Works

The receiver waits up to the delay window; if it has data to send within that time, the ACK is combined with the data. Otherwise, an ACK is sent after the timeout.

Potential Issues

Interactive workloads : In latency‑sensitive protocols like Redis or gRPC, delayed ACK can add extra waiting time and degrade responsiveness.

Small packet traffic : Frequent tiny messages in micro‑service architectures may suffer from increased latency due to delayed ACK.

Testing Recommendations

Disable delayed ACK by adjusting TCP_NODELAY or tcp_delack_min, and compare performance. Capture ACK timing with Wireshark to verify behavior.

RTT: The Rhythm Controller of TCP

Round‑Trip Time (RTT) measures the time for a packet to travel to the receiver and back. It drives timeout (RTO) calculations, congestion control, and window scaling, directly affecting throughput.

Measurement and Calculation

TCP records the send timestamp of each segment and the receipt timestamp of its ACK to compute RTT, then maintains a smoothed RTT (SRTT) and RTT variance (RTTVAR) for adaptive RTO.

// FunTester example pseudo-code: RTT calculation logic
long rttSample = currentTime - packet.sendTime; // calculate single RTT
srtt = (1 - α) * srtt + α * rttSample; // smooth RTT, α usually 1/8
rttvar = (1 - β) * rttvar + β * |rttSample - srtt|; // update RTT variance, β usually 1/4
rto = srtt + 4 * rttvar; // compute retransmission timeout

Performance Impact

High RTT scenarios : Satellite or cross‑continent links increase RTT, slowing window growth and limiting throughput.

RTT jitter : Fluctuating RTT can cause TCP to misinterpret network conditions, leading to unnecessary retransmissions or window reductions.

Testing Recommendations

Use ping or tc to emulate different RTTs, observe TCP window dynamics and RTO behavior, and analyze packet captures to ensure RTT measurements and timeout calculations are reasonable, especially under chaos‑engineering conditions.