TCP Congestion Control Algorithms: Network Engineering Guide

1. Introduction and Core Concepts

TCP congestion control algorithms are the fundamental mechanisms that prevent the internet from collapsing under its own traffic. While flow control prevents a fast sender from overwhelming a slow receiver, congestion control prevents a collection of senders from overwhelming the network itself. Without these algorithms, routers would be flooded with packets they cannot forward, leading to catastrophic buffer overflows, massive packet loss, retransmissions, and ultimately congestion collapse.

At its core, tcp congestion control algorithms address a deceptively simple question: how fast should a sender transmit data without causing congestion? The challenge is that the sender has no direct, centralized view of network state. It must infer congestion implicitly from signals like packet loss, round-trip time (RTT) variations, and explicit congestion notifications (ECN). The algorithm must probe for available bandwidth, gracefully back off when congestion is detected, and fairly share bottleneck capacity with competing flows.

Every TCP connection maintains a critical state variable called the congestion window (cwnd), which limits how much unacknowledged data the sender can have in flight. This is distinct from the receiver-advertised window (rwnd). The effective sending window is min(cwnd, rwnd). Congestion control algorithms dynamically adjust cwnd based on network feedback. The goal is to keep cwnd as large as possible for high throughput, but small enough to avoid loss and queuing delay. This balancing act is what makes tcp congestion control algorithms one of the most studied areas in networking algorithms.

Why it matters today more than ever is scale. Modern networks carry everything from 4K video streaming and cloud backups to microsecond-sensitive high-frequency trading and massive data center replication. A poorly chosen or misconfigured congestion control algorithm can mean the difference between utilizing 95% of a 100 Gbps link versus 30%, or between 20ms and 200ms of latency for interactive applications. Understanding these algorithms is essential for network engineers, backend developers, SREs, and anyone building performance-critical distributed systems.

2. How It Works

The classic TCP congestion control framework, established by Van Jacobson in 1988, consists of four interlocking mechanisms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. Together they define the Additive Increase Multiplicative Decrease (AIMD) paradigm that ensures both efficiency and fairness.

Slow Start is used to quickly discover available bandwidth when a connection starts or after a severe congestion event. Despite its name, it is actually aggressive. The sender starts with a small cwnd (typically 10 MSS - Maximum Segment Size in modern Linux) and doubles it every RTT. For every ACK received, cwnd is increased by one MSS. This results in exponential growth until cwnd reaches a threshold called ssthresh (slow start threshold) or packet loss is detected. The exponential probe allows a new flow to rapidly ramp up without prior knowledge of path capacity.

Once cwnd exceeds ssthresh, the connection enters Congestion Avoidance, where growth becomes linear and conservative. In the standard Reno implementation, cwnd is increased by approximately one MSS per RTT (specifically, cwnd += MSS * MSS / cwnd for each ACK). This additive increase gently probes for extra bandwidth. If congestion is signaled by packet loss (detected via timeout or three duplicate ACKs), the algorithm reacts with multiplicative decrease: ssthresh is set to half of the current cwnd (or flight size), and cwnd is drastically reduced. This AIMD behavior is mathematically proven to converge to a fair share when multiple flows compete for a bottleneck.

Loss Detection and Recovery

TCP relies on two primary signals for congestion. A Retransmission Timeout (RTO) indicates severe congestion - no ACKs have arrived, so the network is likely heavily congested. In this case, ssthresh is halved, cwnd is reset to 1 MSS, and Slow Start restarts. The second signal is three duplicate ACKs, which indicates a packet was lost but subsequent packets got through, implying mild congestion. This triggers Fast Retransmit: the lost segment is retransmitted immediately without waiting for the timeout, and Fast Recovery adjusts cwnd without dropping to Slow Start.

Modern algorithms extend this loss-based model. Delay-based algorithms like TCP Vegas measure RTT inflation to detect queue buildup before loss occurs. Hybrid algorithms like BBR (Bottleneck Bandwidth and Round-trip propagation time) model the network pipe explicitly, estimating bottleneck bandwidth (BtlBw) and round-trip propagation time (RTprop) to operate at the optimal Kleinrock point where throughput is maximized and delay is minimized. This shift from loss-based to model-based control represents the biggest evolution in tcp congestion control algorithms in the last decade.

3. Implementation

While real TCP congestion control is implemented in the OS kernel (in C), we can accurately simulate its core state machine in Python to understand the window dynamics. The following examples model the sender-side logic for educational purposes.

class TCPReno:
    """
    Simplified TCP Reno congestion control state machine.
    Simulates cwnd evolution in MSS units.
    """
    def __init__(self, init_cwnd=1, init_ssthresh=64):
        self.cwnd = init_cwnd  # congestion window in MSS
        self.ssthresh = init_ssthresh
        self.dup_ack_count = 0
        self.state = "SLOW_START"

    def on_ack(self, is_duplicate=False):
        if is_duplicate:
            self.dup_ack_count += 1
            if self.dup_ack_count == 3:
                # Fast Retransmit / Fast Recovery
                self.ssthresh = max(self.cwnd // 2, 2)
                self.cwnd = self.ssthresh + 3  # inflate for dup ACKs
                self.state = "FAST_RECOVERY"
                return "RETRANSMIT"
            elif self.state == "FAST_RECOVERY":
                self.cwnd += 1  # inflate window
            return None

        # New ACK - reset dup counter
        self.dup_ack_count = 0

        if self.state == "SLOW_START":
            self.cwnd += 1  # exponential: +1 per ACK
            if self.cwnd >= self.ssthresh:
                self.state = "CONGESTION_AVOIDANCE"
        elif self.state == "CONGESTION_AVOIDANCE":
            # Additive increase: +1 MSS per RTT
            # Approximate as 1/cwnd per ACK
            self.cwnd += 1 / self.cwnd
        elif self.state == "FAST_RECOVERY":
            self.cwnd = self.ssthresh
            self.state = "CONGESTION_AVOIDANCE"
        return None

    def on_timeout(self):
        # Severe congestion
        self.ssthresh = max(self.cwnd // 2, 2)
        self.cwnd = 1
        self.dup_ack_count = 0
        self.state = "SLOW_START"
        return "RETRANSMIT"

import math

def cubic_window(cwnd, ssthresh, time_since_loss, C=0.4, beta=0.7):
    """
    CUBIC window growth function (RFC 8312).
    CUBIC is the default in Linux since 2.6.19.
    W(t) = C*(t-K)^3 + W_max
    where K = cubic_root(W_max * (1-beta) / C)
    Provides better scalability on high-BDP paths.
    """
    W_max = ssthresh / beta  # window before last reduction
    K = (W_max * (1 - beta) / C) ** (1/3)

    # CUBIC window at time t
    W_cubic = C * (time_since_loss - K) ** 3 + W_max

    # TCP-friendly region: ensure at least Reno-like growth
    W_reno = cwnd + (1 / cwnd)  # Reno increase per ACK

    # Use max of CUBIC and Reno for fairness
    next_cwnd = max(W_cubic, W_reno)
    return next_cwnd

# Example: 100ms after loss, W_max=100
# K ~ 4.3s for typical params, window grows cubically
for t in [0, 1, 2, 5, 10]:
    w = cubic_window(cwnd=40, ssthresh=70, time_since_loss=t)
    print(f"t={t}s -> cwnd={w:.2f} MSS")

class BBRState:
    """
    Simplified BBR (Bottleneck Bandwidth and RTT) model.
    BBR estimates BtlBw and RTprop to control pacing rate
    instead of cwnd directly. This is a conceptual sketch.
    """
    def __init__(self):
        self.btl_bw = 0.0  # bottleneck bandwidth (bytes/sec)
        self.rt_prop = float('inf')  # min RTT observed
        self.pacing_gain = 2.77  # Startup gain
        self.cwnd_gain = 2.0
        self.state = "STARTUP"

    def update_model(self, delivery_rate, rtt):
        # Update max bandwidth and min RTT filters
        # In real BBR, these are windowed max/min filters (10 RTTs)
        if delivery_rate > self.btl_bw:
            self.btl_bw = delivery_rate
        if rtt < self.rt_prop:
            self.rt_prop = rtt

        # BDP = BtlBw * RTprop
        bdp = self.btl_bw * self.rt_prop
        return bdp

    def get_pacing_rate(self):
        return self.btl_bw * self.pacing_gain

    def get_cwnd(self, bdp):
        return bdp * self.cwnd_gain

    def on_ack(self, acked_bytes, rtt, interval):
        delivery_rate = acked_bytes / interval if interval > 0 else 0
        bdp = self.update_model(delivery_rate, rtt)

        # State machine transitions (highly simplified)
        if self.state == "STARTUP" and delivery_rate < self.btl_bw * 1.25:
            # Bandwidth plateau detected, exit startup
            self.state = "DRAIN"
            self.pacing_gain = 0.75
        return self.get_pacing_rate(), self.get_cwnd(bdp)

def simulate_transfer(algorithm, rtts=20, loss_events=None):
    """
    Simulate cwnd evolution over a series of RTTs.
    loss_events: set of RTT indices where loss occurs
    """
    if loss_events is None:
        loss_events = {8, 15}
    
    cwnd_history = []
    tcp = TCPReno(init_cwnd=1, init_ssthresh=16)

    for rtt in range(rtts):
        cwnd_history.append(round(tcp.cwnd, 2))
        
        if rtt in loss_events:
            # Simulate triple duplicate ACK
            tcp.on_ack(is_duplicate=True)
            tcp.on_ack(is_duplicate=True)
            tcp.on_ack(is_duplicate=True)
            print(f"RTT {rtt}: LOSS -> cwnd={tcp.cwnd:.2f}, ssthresh={tcp.ssthresh}")
        else:
            # Simulate successful RTT: ack all packets in window
            # Need to ack 'cwnd' packets to get RTT worth of growth
            num_acks = int(tcp.cwnd)
            for _ in range(num_acks):
                tcp.on_ack(is_duplicate=False)
            print(f"RTT {rtt}: ACK -> cwnd={tcp.cwnd:.2f} state={tcp.state}")
    
    return cwnd_history

# Run simulation
history = simulate_transfer(TCPReno, rtts=12, loss_events={5, 9})

4. Step-by-Step Example

Let us walk through a concrete example of TCP Reno with an initial cwnd = 1 MSS and ssthresh = 8 MSS. Assume MSS = 1460 bytes and no receiver window limitation. We will trace cwnd and ssthresh across 10 RTTs with a packet loss at RTT 6.

RTT 1 (Slow Start): cwnd=1. Sender sends 1 segment. ACK arrives. cwnd +=1 → cwnd=2. The window has doubled.

RTT 2 (Slow Start): cwnd=2. Sender sends 2 segments. 2 ACKs arrive. After first ACK cwnd=3, after second cwnd=4. Exponential growth continues.

RTT 3 (Slow Start): cwnd=4. Sender sends 4 segments. 4 ACKs arrive → cwnd becomes 5,6,7,8. Now cwnd (8) equals ssthresh (8), so next ACK will transition to Congestion Avoidance.

RTT 4 (Congestion Avoidance): cwnd=8. Sender sends 8 segments. Each ACK increases cwnd by 1/cwnd ≈ 0.125. After 8 ACKs, cwnd ≈ 9.0. Growth is now linear (+1 per RTT).

RTT 5 (Congestion Avoidance): cwnd=9. After 9 ACKs, cwnd ≈ 10.0. The sender is gently probing for more bandwidth.

RTT 6 (Loss Event): cwnd=10. Sender sends 10 segments, but segment 3 is lost. The receiver sends duplicate ACKs for segments 4-10. After 3 duplicate ACKs, sender triggers Fast Retransmit. ssthresh = cwnd/2 = 5. cwnd = ssthresh + 3 = 8 (inflated). The lost segment is retransmitted and the sender enters Fast Recovery.

RTT 7 (Fast Recovery → Congestion Avoidance): An ACK for the retransmitted segment arrives (a “recovery ACK” that acknowledges all data up to segment 10). cwnd is deflated to ssthresh = 5. State returns to Congestion Avoidance. The window was halved, not reset to 1, so throughput degrades gracefully.

RTT 8-10 (Congestion Avoidance): cwnd grows linearly again: 5 → 5.2 → 5.4 → 5.6 etc., probing upward until the next loss event. This sawtooth pattern—linear increase until loss, then multiplicative decrease—is the signature of AIMD and is visible in any TCP throughput graph.

This example illustrates why ssthresh is critical. It is the memory of the last congestion point. By setting ssthresh to half the window that caused loss, the algorithm assumes the network’s capacity is roughly half of what was just attempted, and cautiously grows from there.

5. Complexity Analysis

Unlike classic data structure algorithms, tcp congestion control algorithms are evaluated not just by computational complexity but by network efficiency metrics: throughput, latency, convergence time, and fairness. However, the per-packet computational overhead is crucial because the algorithm runs on every ACK at line rate (millions of packets per second on high-speed links).

The core operations—updating cwnd, checking for duplicate ACKs, and computing the next window—are all O(1) time and O(1) space. The sender maintains only a handful of state variables: cwnd, ssthresh, RTT estimators (srtt, rttvar), and a few counters. This constant overhead is essential for scalability. No per-flow data structures grow with the number of packets or bytes transferred.

Where complexity matters is in convergence and control loop dynamics. Slow Start converges to the operating point in O(log W) RTTs where W is the bandwidth-delay product (BDP). Congestion Avoidance converges linearly in O(W) RTTs, which is why high-BDP paths (e.g., 10 Gbps with 100ms RTT → BDP ≈ 83,333 MSS) take a very long time to fully utilize with Reno, motivating CUBIC’s cubic growth function which is O(1) in terms of RTTs to reach large windows.

* BBR maintains max/min filters over a window of ~10 RTTs, requiring a small bounded buffer, but amortized per-ACK cost remains O(1). The key takeaway is that all tcp congestion control algorithms are designed to be computationally trivial on the fast path; the complexity is in the control theory, not the CPU cycles. Memory overhead per connection is typically < 100 bytes for Reno/CUBIC and < 1KB for BBR, allowing servers to handle millions of concurrent flows.

6. Variations and Optimizations

Over four decades, dozens of variants have been proposed to handle different network environments. Each optimizes for a specific tradeoff between throughput, latency, fairness, and loss resilience.

Tahoe (1988): The original Jacobson implementation. On any loss (timeout or 3 dup ACKs), it sets ssthresh = cwnd/2, resets cwnd=1, and re-enters Slow Start. Simple but inefficient because it always pays the cost of Slow Start after mild congestion.

Reno (1990): Added Fast Recovery to avoid Slow Start after triple duplicate ACKs. This was a major improvement and became the baseline for many years. NewReno further improved Reno by handling multiple losses in a single window without repeatedly halving cwnd.

CUBIC (2006, RFC 8312): The current Linux and Windows default. Instead of linear growth, its window follows a cubic function W(t) = C*(t-K)^3 + W_max. This has three advantages: it grows quickly when far from W_max, slows near W_max to probe gently, and is independent of RTT (improving fairness between flows with different RTTs). CUBIC also uses a more gentle multiplicative decrease (beta=0.7 instead of 0.5), keeping more throughput after loss. It excels on high-BDP, high-speed long-distance paths.

BBR (2016, Google): A radical departure. Rather than reacting to loss, BBR explicitly estimates bottleneck bandwidth and RTT and paces packets to keep the pipe full but not fuller. It cycles through pacing gains (1.25x to probe, 0.75x to drain) to measure capacity. BBR achieves higher throughput with lower queuing delay and is less sensitive to random (non-congestion) loss, making it ideal for lossy wireless and intercontinental links. BBRv2 adds loss and ECN awareness to improve fairness with loss-based flows.

Other Notable Variants

• Vegas (1994): Delay-based. Uses RTT increase as early congestion signal before loss. Provides lower delay but competes poorly with loss-based flows that fill buffers.
• DCTCP (Data Center TCP): Uses ECN marks from switches to get multi-bit feedback about queue length. Reacts proportionally to the fraction of marked packets, achieving ultra-low latency and high throughput in data centers. Widely deployed in Azure and other clouds.
• Compound TCP (CTCP): Windows default before CUBIC. Maintains both loss-based and delay-based windows, summing them. Good for high-BDP paths while keeping RTT fairness.
• Illinois, YeAH, H-TCP: High-speed variants that adapt increase/decrease factors based on RTT or loss rate.

Choosing an optimization depends on the environment. There is no single best tcp congestion control algorithm; the optimal choice is workload and topology dependent, which is why modern OSes allow pluggable congestion control (e.g., `sysctl net.ipv4.tcp_congestion_control` on Linux).

7. Real-World Applications

TCP congestion control algorithms are not theoretical curiosities—they are running on every internet-connected device, shaping user experience in real time.

In Content Delivery Networks and Web Servers, the choice directly impacts page load time. Netflix, which serves ~15% of global internet traffic, extensively tuned its congestion control (using BBR and custom pacing) to reduce rebuffering. A video chunk delivered with Reno over a 50ms transatlantic link might take 3 seconds to ramp up, while CUBIC or BBR can fill the pipe in under a second. Cloudflare and Google have published data showing BBR improves throughput by 2-25x on lossy paths and reduces median RTT by 30%.

In Data Centers, the requirements invert: bandwidth is plentiful (25-100 Gbps) but latency must be microseconds and incast congestion is common (many senders to one receiver, e.g., MapReduce shuffle). Standard algorithms cause buffer bloat and throughput collapse. DCTCP is purpose-built here: by reacting to ECN marks from shallow switch buffers, it keeps queues small (≈ 1-2 packets) while maintaining near-line-rate throughput. Without DCTCP, a 10:1 incast can cause timeouts and 10x latency spikes.

In Databases and Storage Systems, replication traffic (e.g., MySQL binlog shipping, Cassandra gossip, S3 replication) traverses WAN links. Using CUBIC or BBR for inter-region replication maximizes utilization of expensive dedicated links. Inside the data center, kernel bypass stacks (like DPDK) often implement their own congestion control tuned for NVMe-over-Fabrics.

In Mobile and Satellite Networks, random packet loss from radio interference is not congestion, but loss-based algorithms misinterpret it as such and halve throughput. BBR and Westwood (which estimates bandwidth via ACK rate) are far more robust because they do not overreact to non-congestion loss. SpaceX Starlink and 5G stacks heavily rely on BBR-like pacing.

8. Comparison with Alternatives

TCP congestion control does not exist in a vacuum. It is one approach to the broader problem of congestion management, and it competes with alternative transport and control strategies.

The most direct alternatives are other TCP variants themselves. Understanding their tradeoffs is essential for tuning. Beyond TCP, there are UDP-based transports that implement their own congestion control (like QUIC, which can evolve faster than kernel TCP), rate-based versus window-based control, and explicit network-assisted schemes like ECN and XCP.

Window-based control (classic TCP) limits outstanding bytes; rate-based control (BBR, QUIC pacing) limits bytes per second. Rate-based is smoother and avoids burstiness that can overflow shallow buffers. Explicit schemes require router support but provide more accurate feedback than implicit loss inference.

For new applications, also consider QUIC. QUIC implements congestion control in user space (often BBR or CUBIC) and encrypts transport headers, preventing middlebox ossification. It also separates congestion control from loss recovery more cleanly and supports connection migration. If you are building a new high-performance service, evaluating QUIC with BBR may outperform kernel TCP with CUBIC, especially on mobile networks.

9. Common Mistakes and Best Practices

Even experienced engineers misconfigure or misunderstand tcp congestion control algorithms, leading to subtle performance pathologies.

Mistake 1: Using the wrong algorithm for the environment. Leaving the default CUBIC on a data center fabric with ECN-capable switches wastes the opportunity for DCTCP’s microsecond queues. Conversely, using DCTCP on the public internet (where switches don’t mark ECN) provides no benefit. Best practice: profile your path. Measure BDP (bandwidth * RTT), loss rate, and switch ECN support. On Linux, test with `iperf3` and `ss -i` to observe cwnd and retransmits, then select via `sysctl -w net.ipv4.tcp_congestion_control=bbr`.

Mistake 2: Buffer bloat from oversized buffers. Many routers have excessively large buffers (megabytes) that loss-based algorithms will fill completely before detecting loss, adding seconds of queuing delay. This is buffer bloat. Best practice: use algorithms that keep queues small (BBR, DCTCP) or enable Active Queue Management (AQM) like FQ-CoDel or PIE on routers to signal congestion early via drops or ECN before buffers fill.

Mistake 3: Ignoring initial window and Slow Start. Short flows (typical web requests <100KB) never leave Slow Start, so throughput is dominated by initial cwnd (initcwnd). The old default of 3 MSS caused extra RTTs for every HTTP request. Modern best practice is initcwnd=10 (as per RFC 6928) and using TCP Fast Open (TFO) where possible. For microservices making many short RPCs, consider connection pooling to allow cwnd to warm up.

Mistake 4: Not pacing packets. Traditional TCP sends bursts of packets (e.g., entire cwnd at once after an ACK), causing bursty queue overflows even when average rate is below capacity. This is especially harmful at high speeds. Best practice: enable pacing. Linux’s FQ qdisc (`tc qdisc add dev eth0 root fq`) automatically paces TCP flows. BBR requires pacing to function correctly. Pacing smooths traffic and reduces loss by 5-10x.

Mistake 5: Misinterpreting loss as always congestion. On Wi-Fi, cellular, or virtualized networks, losses can be random. Halving cwnd on every loss underutilizes the link. Best practice: on lossy paths, prefer BBR or enable appropriate loss recovery like RACK/TLP. Monitor `retrans` vs `lost` counters; if loss is <1% but throughput is low, you may be overreacting.

Best Practices Checklist:

• Monitor cwnd, RTT, delivery rate, and retransmits via `ss -ti`, `tcp_info`, or eBPF tools.
• Enable ECN end-to-end (`net.ipv4.tcp_ecn=1`) and ensure switches support it for DCTCP/ECN benefits.
• Use pacing (FQ) and appropriate initcwnd for your workload.
• Test fairness: run multiple flows with different RTTs and verify they converge to fair shares.
• For new services, evaluate QUIC + BBR as an alternative to kernel TCP.
• Never hardcode ssthresh or cwnd in application code; let the algorithm adapt.

10. Interview Questions

TCP congestion control is a favorite in systems and networking interviews because it tests understanding of distributed algorithms, tradeoffs, and practical debugging. Here are common questions with concise answer frameworks.

Q1: What is the difference between flow control and congestion control? Why do we need both?

Flow control is receiver-driven and prevents the sender from overwhelming the receiver’s buffer (via rwnd). Congestion control is network-driven and prevents senders from overwhelming the network’s buffers (via cwnd). You need both because a fast network with a slow receiver still needs flow control, and a fast receiver on a congested network still needs congestion control. The sender’s effective window is min(cwnd, rwnd). An interviewer wants to hear you articulate the two different bottlenecks and the two different signals (rwnd vs loss/RTT).

Q2: Explain Slow Start and why it is exponential. How does it differ from Congestion Avoidance?

Slow Start starts with cwnd=1-10 MSS and doubles each RTT (cwnd +=1 per ACK) to quickly probe bandwidth without prior knowledge. It is exponential to rapidly reach the operating point; linear probing would take too long. It lasts until cwnd ≥ ssthresh or loss occurs. Congestion Avoidance then grows linearly (cwnd += MSS*MSS/cwnd per ACK, ≈1 MSS per RTT) to gently probe for extra capacity while maintaining fairness via AIMD. Mention that Slow Start is actually fast, and the name is historical.

Q3: What happens when three duplicate ACKs are received versus a timeout? Why the different reaction?

Three duplicate ACKs indicate a single packet loss but the network is still delivering data (mild congestion), so Reno does Fast Retransmit and Fast Recovery: ssthresh=cwnd/2, cwnd=ssthresh (or ssthresh+3), and stays in Congestion Avoidance. A timeout indicates severe congestion (no ACKs at all, possibly entire window lost), so ssthresh=cwnd/2, cwnd=1, and re-enter Slow Start. The different reactions reflect the severity inference: dup ACKs = light congestion, timeout = heavy congestion. NewReno and SACK improve handling of multiple losses in one window.

Q4: Why does TCP Reno perform poorly on high bandwidth-delay product (BDP) networks? How does CUBIC fix this?

Reno’s linear increase of 1 MSS per RTT means it takes O(W) RTTs to recover after a loss, where W is the BDP. On a 10 Gbps, 100ms path, W≈83k MSS, so recovery takes hours, leaving the link underutilized. CUBIC fixes this with a cubic function that grows quickly when far from W_max and slowly near W_max, making recovery time O(W^1/3) and RTT-independent. It also uses beta=0.7 (less aggressive cut) to keep utilization higher. BBR solves it differently by modeling bandwidth directly and not relying on loss.

Q5: Your service shows high throughput but high tail latency (p99). `ss` shows large cwnd and RTT spikes. What congestion control issue might this be and how would you fix it?

This is classic buffer bloat: a loss-based algorithm (Reno/CUBIC) filling deep router buffers, causing queuing delay. Throughput looks good because buffers are full, but latency suffers. Fix options: switch to BBR (which keeps queues small), enable pacing with FQ, enable ECN + AQM (FQ-CoDel) on routers, or if in a data center, deploy DCTCP with ECN. Also check for oversized socket buffers (`net.core.rmem_max/wmem_max`) and reduce them. Mention measuring queue occupancy and RTT variance to confirm.