The congestion control algorithm (CCA) selected for a TCP connection fundamentally determines how the sliding window evolves in response to network conditions, and the choice of CCA is the single most impactful performance tuning parameter for long-haul and data center TCP flows. CUBIC (the default CCA in Linux since kernel 2.6.19) is a window-based congestion control that uses a cubic function of the time elapsed since the last congestion event to grow the congestion window (cwnd). The cwnd growth function is: W(t) = C × (t - K)³ + W_max, where C is a scaling constant (0.4), t is the time since the last loss event, W_max is the cwnd size at the last loss, and K = ³√(W_max × (1 - β) / C) determines the plateau duration. The key property of CUBIC is that the window growth rate is independent of RTT, making it fair across flows with different RTTs—a significant improvement over BIC-TCP and Reno. The window reduction on a loss event (detected via duplicate ACKs or timeout) is multiplicative: cwnd = β × W_max where β = 0.7 (multiplicative decrease factor), meaning the window is reduced by 30% on each congestion event. For a 400 Gbps link with 100 ms RTT (transcontinental link), the BDP is 400 × 10⁹ × 0.1 / 8 = 5 GB (40 Gb). To achieve full utilization, CUBIC requires approximately 150-250 ms of loss-free transmission after a congestion event to grow back to the BDP-scale cwnd, during which the link utilization is below 100%.

BBR (Bottleneck Bandwidth and Round-trip propagation time), developed by Google and deployed on their B4 WAN and YouTube infrastructure, is a model-based congestion control that does not rely on packet loss as a congestion signal. Instead, BBR continuously estimates two parameters: the BtlBw (bottleneck bandwidth) using the maximum observed delivery rate over a 6-10 RTT window, and the RTprop (round-trip propagation time) using the minimum observed RTT over a 10-second window. The pacing rate is set to BtlBw, and the cwnd is set to 2 × BtlBw × RTprop to accommodate the typical 2× BDP of a window-based sender. The pacing architecture is the critical difference from CUBIC: BBR sends data at the estimated bottleneck rate rather than in bursts at line rate, reducing buffer occupancy at the bottleneck link. In BBR's steady-state (BBR Phase 3, ProbeBW), the algorithm cycles between: (1) probing for more bandwidth by pacing at 1.25× BtlBw for one RTT, (2) draining the additional queue by pacing at 0.75× BtlBw for one RTT, and (3) cruising at BtlBw for several RTTs. This probe-drain cycle creates a periodic queue depth oscillation of approximately 0.25 × BDP, compared to CUBIC's reactive queue growth that can reach multiple BDPs before a loss event triggers reduction. For a deep-buffered data center switch (e.g., 32 MB shared buffer per 400 Gbps port), CUBIC can fill 50-80% of the buffer before experiencing ECN-marked or tail-drop loss, adding 200-400 μs of queuing delay per hop, while BBR's probe-drain cycle keeps queuing delay below 50 μs per hop—an 80% reduction in buffer-induced latency.

The fairness and coexistence properties of BBR and CUBIC have been the subject of extensive research and operational friction. BBR flows, because they measure BtlBw from the maximum delivery rate (which can be influenced by the presence of other flows), tend to over-estimate the available bandwidth when sharing a bottleneck with loss-based CCAs like CUBIC. In a shared bottleneck experiment at CERN, a single BBR flow sharing a 10 Gbps link with 8 CUBIC flows resulted in BBR capturing 65% of the bandwidth while the 8 CUBIC flows shared the remaining 35%—a severe unfairness ratio of 15:1 (BBR per-flow to CUBIC per-flow). The root cause is that CUBIC increases cwnd until the switch buffer overflows or ECN marking occurs, during which the delivery rate measured by BBR includes the buffer bloat-induced delivery bursts, causing BBR to incorrectly estimate a higher BtlBw than the actual link capacity. Our sliding window model includes a CCA fairness surface that plots the Jain fairness index (J = (Σxᵢ)² / (n×Σxᵢ²)) across the parameter space of flow count, buffer size (in units of BDP), and RTT distribution. For a data center ToR switch with 8 MB shared buffer and 10 Gbps uplinks, the fairness index for a mixed BBR+CUBIC deployment with 20 flows is 0.78 (below the 0.95 threshold considered "fair"), indicating that BBR must be deployed fleet-wide (all flows use BBR) or isolated per-class via QoS queuing to avoid starvation of CUBIC flows.

BBRv3 (released in Linux 6.2, 2024) introduces three key improvements that make it more suitable for data center deployment: ECN-aware probing, in-flight cwnd cap, and loss-responsive convergence. The ECN-aware probing modifies BBR's ProbeBW phase to monitor the ECN-marking ratio (ECN fraction) during the 1.25× pacing phase; if the marking exceeds 2% of packets, BBR reduces its pacing multiplier from 1.25× to 1.05× to avoid overshooting the shallow-buffer ECN threshold. The in-flight cwnd cap limits the maximum in-flight data to 2.5× BDP (rather than the unbounded max in BBRv1), preventing buffer occupancy from exceeding 1.5× BDP even in the probe phase. The loss-responsive convergence mechanism reduces BBR's BtlBw estimate by 20% when two consecutive ProbeBW cycles (total 2 RTTs) show persistent loss rates above 0.5%, bringing BBR's behavior closer to CUBIC's loss-triggered reduction. These modifications improve the Jain fairness index in mixed-CCA environments from 0.78 (BBRv1) to 0.91 (BBRv3) in head-to-head tests at 100 Gbps link speeds with 32 KB-per-flow buffer allocation at the bottleneck. Our tool models the sliding window dynamics for both BBRv3 and CUBIC, allowing operators to compare the expected flow completion time (FCT) for their specific data distribution under each CCA, using the Flow Size CDF (cumulative distribution function) of the production workload as the input distribution for the FCT simulation—enabling a data-driven CCA selection rather than a heuristic default.

The TCP delayed ACK mechanism (RFC 1122, RFC 5681) allows the receiver to delay sending an ACK for up to 500 ms or until every second segment arrives, reducing the ACK processing overhead on both the sender and receiver. For a bulk transfer at 400 Gbps with 1,500-byte segments, the inter-segment arrival time at the receiver is 1,500 × 8 / (400 × 10⁹) = 30 ns. A delayed ACK (every 2 segments) means the receiver sends an ACK every 60 ns, generating 16.7 million ACKs per second per flow. With 64 flows (8 NICs × 8 QPs per NIC), the total ACK rate is 1.07 billion ACKs per second—far exceeding the receiver's ability to process them (a single Xeon core can handle approximately 5-10 million ACKs per second in software). The delayed ACK mechanism reduces the ACK rate by 50% (to 8.3 million ACKs per second per flow), but at 64 flows the aggregate is still 533 million ACKs per second, requiring the NIC's hardware ACK generation engine to handle the majority. Modern RDMA NICs (ConnectX-7, CX8) implement hardware ACK generation that can sustain up to 200 million ACKs per second per port, which still leaves a gap of 333 million ACKs per second that must be handled by software coalescing. The counter-productivity arises when the delayed ACK timer interacts with the sender's congestion window: if the delayed ACK interval exceeds the sender's retransmission timeout (RTO), the sender will retransmit segments that were already successfully received, wasting bandwidth on duplicate data.

In data center networks with sub-100 μs RTTs, the 500 ms delayed ACK maximum interval (RFC 1122's allowance for "unspecified delayed ACK interval") causes catastrophic throughput collapse. Consider a 400 Gbps flow with 100 μs RTT and cwnd = 6,250 segments (BW × RTT / MSS = 400 Gbps × 100 μs / 12 Kb = 3.33 GB / 1.5 KB ≈ 2.2M segments, but bounded by the sender's buffer). If the receiver delays ACKs for 500 ms, the sender's ACK clock (the stream of incoming ACKs that pace the sending rate) stalls for 500 ms, during which no new segments can be sent. The throughput over the 500 ms window is zero for the first 500 ms of each ACK cycle, resulting in an average throughput of only 50% of line rate for a 1-second measurement interval. The Linux kernel's tcp_delack_min parameter (default 40 ms) and tcp_delack_max (default 200 ms for non-interactive flows) are the effective limits for data center TCP. At 200 ms maximum delay, the throughput loss is 200 ms / (100 μs RTT + 200 ms) × 100% ≈ 99.95%—effectively zero throughput. Our sliding window model computes the effective goodput as a function of the delayed ACK interval, the RTT, and the sender's cwnd, and alerts the operator when the ratio of delayed ACK interval to RTT exceeds 0.01 (1% throughput loss threshold). For a 100 μs RTT, the maximum viable delayed ACK interval is 1 μs—requiring the receiver to disable delayed ACK entirely and use the "immediate ACK" mode (ACK every other segment, no extra delay) controlled by the TCP_NODELAY socket option.

The ACK prioritization in PFC-enabled fabrics presents a secondary interaction between the sliding window and the lossless fabric's flow control loops. In a RoCE fabric with PFC (Priority Flow Control, IEEE 802.1Qbb), ACK frames are typically assigned to the highest priority class (Priority 3, the lossless class) alongside RDMA data. When the switch's Priority 3 buffer reaches the XOFF threshold, it sends a Pause frame to the upstream sender, stopping all Priority 3 traffic—including ACK frames. The sender stops receiving ACKs, its ACK clock stalls, and it stops transmitting data even though the network congestion may have already cleared. The PFC deadlock for ACK frames can last for multiple PFC pause quanta (up to 10 × pause_frame_quanta = 655 µs in standard operation, or longer under severe congestion). During this deadlock window, the sliding window sender briefly enters "ACK starvation"—no new segments can be transmitted because no old segments are acknowledged. The throughput loss from ACK-PFC interaction is proportional to the frequency of PFC pause events: for a fabric experiencing 100 PFC pause events per second per port, each lasting 200 µs (the typical XOFF-to-XON recovery time for a 32 MB buffer at 400 Gbps), the total ACK stall time is 100 × 200 µs = 20 ms/s, or 2% throughput loss. Our sliding window model integrates the PFC pause statistics from the fabric telemetry (via the switch's PFC counter registers) to compute the effective throughput reduction and recommends ACK isolation to a lower priority class (Priority 1) when ACK-PFC interaction exceeds 1% throughput impact.

The selective ACK (SACK) option scalability in high-BDP sliding window environments is a final overhead consideration. When large numbers of segments are lost in a single RTT (burst losses common in PFC tail-drop events), the SACK option (RFC 2883, RFC 6675) must report up to 4 non-contiguous block boundaries (each block is a 32-bit left edge and 32-bit right edge, consuming 8 bytes per block plus 2 bytes for the SACK option header). For a burst loss of 1,000 segments out of cwnd = 10,000, the SACK option cannot represent the loss pattern because it can describe at most 4 non-contiguous blocks. The TCP sender must fall back to the slow, heuristic "retransmit a segment per duplicate ACK" algorithm, which wastes one RTT per retransmitted segment. The RACK-TLP loss detection algorithm (RFC 8985, Linux kernel 5.0+) addresses this by time-based detection rather than SACK block counting: the sender times the tail loss probe (TLP) using the RTT estimate and retransmits the most recent unacknowledged segment after 1 RTT without new ACKs, without waiting for the SACK option to report the exact loss pattern. Our model quantifies the efficiency improvement of RACK-TLP over the SACK-based sliding window in high-BDP environments, showing that RACK-TLP reduces the retransmission recovery time by approximately 50% (from 4× RTT for SACK-based recovery to 2× RTT for RACK-TLP).