In this lesson, you will learn how to diagnose how specific TCP congestion control algorithms (CCAs) react to varying network path conditions like jitter, packet loss, and bandwidth-delay product (BDP) fluctuations.
Understanding CCA Dynamics
Congestion Control Algorithms like cubic, reno, or bbr manage the rate at which data is injected into the network. While cubic is loss-based—interpreting packet drops as a signal to shrink the congestion window (cwnd)—bbr (Bottleneck Bandwidth and Round-trip propagation time) models the network path to maintain high throughput even on lossy links. Profiling these behaviors allows you to identify whether your application’s performance bottlenecks are caused by inefficient window scaling or an inappropriate CCA choice for your specific link characteristics.
Observability with ss and nstat
To profile these behaviors in real-time, you need to observe the evolution of the congestion window and the smoothed round-trip time (SRTT). The ss utility provides a snapshot of these kernel parameters for active connections:
# Monitor the congestion window and RTT for a specific connection
ss -ti 'dport = :443'
In the output, look for cwnd (the current window size), rtt (round-trip time), and bbr_info if you are using the BBR algorithm. If you see cwnd plummeting repeatedly while rtt remains stable, your CCA might be overreacting to minor packet loss (common with cubic on high-latency paths). Conversely, if cwnd remains large but throughput is low, you may be experiencing bufferbloat, where the qdisc is holding too many packets, leading to increased latency.
Tracing with tcpretrans
When profiling, it is essential to correlate congestion events with packet retransmissions. Use the tcpretrans tool from the BCC toolkit to see exactly when and where retransmissions occur:
# Trace retransmits with TCP info
/usr/share/bcc/tools/tcpretrans -c
If you see retransmissions spiking during periods of high bandwidth, it indicates that the CCA is likely pushing past the bottleneck capacity, causing tail-drops at the network switch. By observing these patterns, you can tune sysctl parameters like net.ipv4.tcp_congestion_control or net.core.rmem_max to better match your infrastructure's physical constraints.
Key Takeaway: Network congestion profiling is the process of correlating TCP window dynamics and retransmission frequency with path-specific RTT and loss characteristics to ensure your chosen congestion control algorithm matches your network's reality.