BBR-TAS: A TSQ-Adaptive Pacing Shift Design for BBR-v3 over Wi-Fi 6 Networks

1. Introduction

The rapid growth of Wi-Fi usage has pushed IEEE 802.11 standards to rely on frame aggregation [1] to maintain higher throughputs. Sending multiple frames in the same transmission opportunity window increases spectral efficiency. The same was introduced in IEEE 802.11n and is available in 802.11ac/ax as well. At the same time, work on mitigating bufferbloat [2] is ongoing, which is the excessive queuing that inflates end-to-end latency without any throughput gains in return. To reduce this undue latency, TCP Small Queues (TSQ) and TCP Pacing (TP) were introduced to limit the number of packets that may be enqueued in the TCP socket, with pacing ensuring that they are spaced out in time at regular intervals to avoid bursts and to achieve a smooth traffic outflow [3]. On wired links, this backpressure mechanism achieves its latency goal at no cost, but on Wi-Fi networks it can starve the driver of the packets needed to build large aggregates, directly limiting the throughput gains that frame aggregation was meant to provide [4]. Google’s BBR congestion control algorithm [5] further aggravates the situation, as it has its own pacing mechanism rather than relying on the Linux kernel’s default pacing rates for the STARTUP and Congestion Avoidance (CA) phases.

The introduction of IEEE 802.11ax (Wi-Fi 6) has brought a new paradigm shift with its enhanced radio capacity, as the bottleneck no longer resides at the client side but has shifted towards the wired uplink that connects the access point to the Internet Service Provider (ISP). This shift gives rise to what has been termed a hybrid bottleneck, in which throughput is initially constrained by the Wi-Fi frame aggregation size and, once a sufficient aggregation threshold is reached, by the fixed capacity of the wired segment [6]. Under this hybrid model, the interaction between congestion control algorithms and TSQ becomes more important, because if enough frames are not available at the client wireless side, Wi-Fi 6 will not reach its maximum aggregation and, as a result, throughput will suffer. Prior modeling work has shown that this migration point can be characterized analytically as a function of packet size, aggregation limits, and bitrate, but the practical implications for BBR-family congestion controls operating under Linux kernel TSQ and pacing constraints remain comparatively underexplored.

A series of experimental studies have explored these facts. Controlled TSQ (CoTSQ) demonstrated that relaxing the default 1 ms TSQ limit on 802.11n/ac links can double, or in some cases improve by an order of magnitude, throughput with only a modest latency cost, and the resulting patch was subsequently merged into the Linux kernel mainline series 5 [7]. BBR-n [8] extended this work to BBR-v3 and Linux kernel series 6, showing that BBR’s inability to benefit from TSQ relaxation stems from its conservative internal pacing gain, and that tuning this gain allows BBR to aggregate packets and reach three-to-six-times higher throughput on legacy Wi-Fi technologies. Subsequent work on TSQ and BBR validated these hybrid-bottleneck dynamics using several loss-based and model-based congestion control algorithms but did not extend the analysis to BBR-v3 or propose an integrated TSQ-pacing design tailored to the newer algorithm [9]. To date, no study has combined BBR-v3-based congestion control with a TSQ-adaptive pacing shift strategy specifically evaluated under Wi-Fi 6 hybrid bottleneck conditions.

This paper addresses this gap by proposing BBR-TAS, a BBR-v3-based congestion control that adapts the TCP Small Queues pacing shift across the STARTUP and steady-state phases to better match the frame aggregation requirements of Wi-Fi 6 networks. Unlike prior BBR variants that mostly focused on tuning the pacing gains during the bandwidth-probing (ProbeBW) phase, BBR-TAS adjusts the sender-side queue occupancy by adjusting the bit-shift parameter that governs the TSQ limit; this allows more packets to be enqueued for the frame aggregation necessary to keep the Wi-Fi 6 link fully utilized, while ensuring that BBR’s bandwidth and RTT estimation logic is not disturbed. We evaluated BBR-TAS against generic BBR (BBR-v3) and CUBIC on a physical Wi-Fi-6-based testbed running a Linux kernel, using a factorial sweep of STARTUP and steady-state pacing shift values while holding ProbeBW gain parameters and the Minimum Segments (MIN_SEGS) floor constant to isolate the effect of TSQ tuning from other confounding design choices. Experiments were conducted using the Flent [10] network testing tool under both single-flow upload and Real-Time Response Under Load (RRUL) conditions, measuring throughput, induced ICMP latency, and TCP RTT across all configurations. To the best of our knowledge, this is the first study to propose a TSQ-adaptive pacing shift mechanism explicitly designed for BBR-v3 and validated on real Wi-Fi 6 hardware, offering practical guidance on kernel-level parameter tuning for BBR-family congestion controls in frame-aggregating wireless environments.

The remainder of this paper is organized as follows. Section 2 reviews related work on TCP Small Queues, TCP Pacing, and BBR variants proposed for wireless and hybrid bottleneck environments. Section 3 presents the methodology, describing the BBR-TAS design, the kernel-level modifications implementing the adaptive pacing shift, and the experimental testbed and Flent-based evaluation setup. Section 4 reports the results and discussion, comparing BBR-TAS against stock BBR-v3 and TCP CUBIC across the tested pacing shift configurations. Finally, Section 5 concludes the paper and outlines directions for future work.

2. Related Work

Increased end-to-end latency caused by deep buffers on the internet is a well-known problem, and the scientific community has worked hard to resolve it with solutions at both the transport and network layers. It was first identified by Gettys and Nichols [2], and active research has since been conducted to mitigate it. At the queuing layer, Controlled Delay (CoDel) [11] and then its successor FlowQueue-CoDel (FQ-CoDel) [12] were introduced to combat this issue. FQ-CoDel has now become the default queuing discipline on most Linux distributions. At the transport layer, Google’s Bottleneck Bandwidth and Round-trip propagation time (BBR) has gained momentum; it is built on a different model-based approach and departs from the traditional loss-based approach that CUBIC [13] follows. It tries to build a complete picture of the network path through its bandwidth and Round-Trip Time (RTT) probing mechanisms, so that the link operates near Kleinrock’s optimal operating point [14]. Google already uses BBR for its YouTube traffic and internal WAN. Both BBR and CUBIC stand out today as two of the most consequential congestion control algorithms (CCAs) in contemporary use.

Figure 1 shows TCP Small Queues, TCP pacing, and congestion control closely interacting with the TCP socket. It is Linux that introduced these two algorithms (TSQ and TP), which bound the amount of data a socket may enqueue and the rate at which it does so, mitigating local bufferbloat at the sender’s network interface; in this, they complement queuing-layer solutions. Grazia et al. [7] were the first to demonstrate that TSQ’s default limit of 1 ms, while good for wired links, was not suitable for IEEE 802.11n/ac Wi-Fi links, as it starved the intrinsic frame aggregation capability present from IEEE 802.11n onwards.

BBR’s Wi-Fi inefficiency motivated a series of targeted patches. Google’s own BBR-DEV RFC instructed the sender to place extra data in flight to keep a remote wireless bottleneck utilized, while Grazia et al. proposed BBRp [15], which exposes the ProbeBW pacing gain cycle as a tunable parameter and demonstrated three-to-six-times throughput gains over IEEE 802.11n/ac by allowing controlled frame aggregation without excessively bloating the bottleneck queue. These pacing-oriented fixes directly informed Google’s BBR-v2 and, subsequently, BBR-v3, both of which incorporate a more Wi-Fi-aware pacing model than the original BBR. The present authors’ own prior work [4] evaluated a modified BBR variant (BBR-n) against modern Active Queue Management disciplines—Fair Queuing (FQ), CoDel, Proportional Integral Controller Enhanced (PIE), Common Applications Kept Enhanced (CAKE) [16], and FQ-CoDel—on a physical IEEE 802.11n/ac testbed using the Flent measurement tool, identifying CAKE as the AQM best matched to BBR-n’s pacing behavior for minimizing latency [17,18]. That study, however, addressed the network-layer (AQM) side of the throughput-latency tradeoff; it did not examine the sender-side TSQ/pacing-shift mechanism that is the focus of the present work, nor did it extend to IEEE 802.11ax (Wi-Fi 6) or the now-standard BBR-v3 implementation.

Since BBR-v3’s public release, several independent evaluations have characterized its behavior. Gomez et al. [19] benchmarked BBR-v3 against loss-based algorithms in a wired broadband topology, while Zeynali et al. [20] examined its fairness and deployment characteristics on the public internet. Most relevant to this work, Shrestha et al. [21] and a concurrent cross-layer study [22] specifically evaluated BBR-v3 over Wi-Fi 6 under modern AQM disciplines (CAKE, FQ-CoDel), finding that BBR-v3’s model-based pacing benefits from, but does not by itself compensate for, unmanaged queueing at the wireless bottleneck, and that its ProbeBW pacing gain interacts sensitively with AQM queue-draining behavior. Separately, Du et al. [23] argued more broadly for revisiting congestion control design assumptions specifically for Wi-Fi networks, given how poorly wired-network-derived models capture frame-aggregation dynamics. Han and Hasegawa proposed BBR-ES, which targets the RTT-fairness weakness of stock BBR through an extended-state optimization, validated on emulated Mininet topologies and real-world internet paths via Amazon EC2 [24]. Despite this growing body of work, no existing study combines BBR-v3—now the de facto deployed successor to the original BBR—with an adaptive, phase-aware TSQ pacing-shift mechanism validated experimentally on physical IEEE 802.11ax hardware under the hybrid bottleneck conditions modeled in [6]. This gap is precisely what BBR-TAS is designed to close.

Algorithm 1: BBR-TAS: TSQ-Adaptive Pacing Shift Input: TCP_SOCKET sk, int startup_shift, int steady_shift Output: updated TSQ limit enforced on socket sk 1: state = get_bbr_state(sk)   // state is one of STARTUP, DRAIN, PROBE_BW, PROBE_RTT 2: pacing_rate = get_bbr_pacing_rate(sk) 3: if state equals STARTUP or state equals DRAIN then 4:   shift = startup_shift 5: else 6:   shift = steady_shift 7: end if 8: dynamic_limit = pacing_rate right shift by shift bits   // amount of data transmittable in the time window set by   // shift, at the current paced rate 9: min_limit = 2 * sk.pktsize 10: limit = max(min_limit, dynamic_limit) 11: limit = min(limit, tcp_limit_output_bytes) 12: sk.tsq_limit = limit 13: return sk.tsq_limit

BBR-TAS, as shown in Algorithm 1, keeps the standard BBR-v3 ProbeBW gain cycle and MIN_SEGS floor unchanged and instead adapts only the TSQ pacing shift as a function of the current BBR phase. During STARTUP and DRAIN, a smaller shift value (startup_shift) permits a larger dynamic TSQ limit, allowing more packets to reach the network interface card for frame aggregation while bandwidth is being probed. Once the flow reaches steady state (ProbeBW or ProbeRTT), a larger shift value (steady_shift) tightens the queue occupancy bound, limiting the latency contribution of the sender-side queue once the bottleneck bandwidth has already been discovered. This selective relaxation targets the frame aggregation bottleneck identified for Wi-Fi 6 hybrid bottlenecks without altering BBR’s core bandwidth and round-trip time estimation logic.

3. Methodology

Figure 2 illustrates the physical testbed topology, encompassing all clients, servers, and networking devices deployed in this study. The client and server nodes ran on Ubuntu 24, equipped with a customized Linux kernel (v6.13.7+v3). Wireless connectivity to the client was established via an IEEE 802.11ax (Wi-Fi 6) Archer 230 router configured in the 5 GHz band only. To leverage wider channel bandwidths (40/80 MHz), the 5 GHz band was explicitly selected across all experimental runs, with automatic channel selection enabled.

On the infrastructure side, the AP was connected through a Fast Ethernet (FE) link to a Huawei Optical Network Terminal (ONT) and tethered to the local server via its Gigabit Ethernet port using a Realtek USB Gigabit Ethernet adapter. Although the fiber-optic connection provided a provisioned 25 Mbps symmetric capacity reaching external public Bufferbloat test servers in Europe and Fremont, California, all reported experiments were conducted locally to eliminate WAN noise and guarantee strict repeatability. Network throughput and latency were benchmarked using Netperf, hosted on the local server and listening on port 12865. A comprehensive breakdown of the hardware specifications, software builds, and configuration parameters is summarized in Table 1.

Figure 3 represents a modified version of the testbed with public internet access through the fiber ONT. Public Bufferbloat test servers in Europe and Fremont, California were selected to perform round-trip-time (RTT) analysis for the three congestion controls under evaluation. This testbed is a classic representation of wired local/public, as well as wireless, connectivity at the network edge.

Figure 2 and Figure 3 were generated using Google Gemini AI (Gemini 3.6 Flash) to visually depict the testbed topology, using a custom prompt provided in the GitHub repository referenced in the Data Availability Statement. The authors reviewed and edited the resulting figures and take full responsibility for their content.

To ensure consistency and reproducibility, all tests were driven by a purpose-built automation script rather than executed manually. The script runs the complete sweep across both baseline congestion controls—BBR-v3 and CUBIC—and the nine BBR-TAS pacing-shift combinations (startup shifts 7, 8, 9 and steady-state shifts 8, 9, 10), coordinating the client and server over SSH so that both endpoints run the same congestion control for every test. This is necessary because the RRUL test sends four streams in upload along with four streams in download, so the congestion control must remain the same on both the client and server side, preventing fairness confounds unrelated to the mechanism under study. Flent (the Flexible Network Tester) was used to run the single-flow TCP upload, RRUL, and RTT-fair test suites, each repeated ten times per configuration with a 60-second test duration and --socket-stats enabled to capture per-socket TCP internals (congestion window, RTT, delivery rate) alongside the standard throughput and latency metrics. The script also supports resuming an interrupted sweep from its last completed configuration, allowing the full experiment to proceed unattended over multiple sessions without risk of silently reusing stale or partially written results. All test results, scripts, and code are available in our GitHub repository [25] for validation and reproducibility.

4. Results and Discussion

This section consists of three subsections. The first covers the Flent upload tests (both single-flow and multi-flow upload) and presents results via box-and-whisker, Ping Cumulative Distribution Function (CDF), and Internet Control Message Protocol (ICMP) CDF plots. The second covers the more strenuous RRUL test, which sends four streams in upload and four in download for each of the three congestion controls under evaluation; box-and-whisker plots, CDF plots, an ellipsis plot for BBR-TAS and BBR-v3, and a Quantile-Quantile (Q-Q) plot are used to further analyze the data gathered from our physical Wi-Fi-6-based testbed. The ellipsis and Q-Q plots focus specifically on the comparison between the two BBR variants. The third subsection covers the RTT-fairness test. All tests were carried out via our custom Python script, which ensures automated data-integrity validation and resume support, allowing the full experiment to proceed safely across multiple sessions.

4.1. TCP Upload Test

Figure 4 presents box-and-whisker distributions of upload throughput and ping latency for the single-flow test. All three algorithms’ throughput medians are nearly the same; the same pattern was observed across all five test runs carried out via our script. The latency panel on the right shows a different pattern, where BBR-TAS (12 ms) ping latency is lower than both CUBIC (13.5 ms) and BBR-v3 (13.2 ms). This was an expected outcome, as a single stream offers limited opportunity for TSQ-based frame aggregation to influence achievable throughput.

Unlike the quartile-based box plot in Figure 4, which can only anchor comparisons at the 25th, 50th, and 75th percentiles, the Ping CDF in Figure 5 reveals the specific range over which BBR-TAS’s benefit is concentrated and where it dissipates. The three curves converge above approximately the 95th percentile, indicating that BBR-TAS’s latency improvement, while consistent and substantial across most of the distribution, does not extend to the rarest worst-case latency events—a distinction the box plot’s summary statistic alone cannot reveal.

Figure 6 shows the three algorithms’ throughput and latency distributions under eight streams in upload. BBR-TAS’s median is marginally above both CUBIC and BBR-v3, consistent with the statistically significant aggregate throughput gains measured across the full five-run sample. BBR-TAS’s mean throughput of 267.14 Mbps is ~3% higher than both BBR-v3 (259.81 Mbps) and CUBIC (259.97 Mbps). BBR-TAS’s ping latency is 17.4% and 10.7% lower compared to CUBIC and BBR-v3, respectively. This indicates that under multi-flow contention, where competition for TSQ-limited queue space is stronger than under a single flow, BBR-TAS achieves a genuine joint improvement in both throughput and latency rather than the tradeoff typically associated with relaxed queue limits.

Figure 7 provides a more detailed latency distribution; between 20 and 60 ms, the BBR-TAS curve is visibly separated from both BBR-v3 and CUBIC towards the left side, showing a decreased-latency trend. This further suggests that BBR-TAS’s benefit under contention is consistent across the great majority of samples rather than driven by a reduction in rare worst-case events alone.

4.2. RRUL Test

The asymmetric pattern in Figure 8 follows from the BBR-TAS TSQ implementation. In RRUL, the client sends four streams in upload while the server simultaneously sends four streams in upload; both client and server run the same congestion control at the same time. This is important, because different congestion controls at each end can create an algorithm-based cross-traffic confound that can overshadow the results attributable to the client’s congestion control. The results show that BBR-TAS, with its adaptive pacing shift algorithm, provides better throughput in upload (234 Mbps mean) than both CUBIC (165 Mbps mean) and BBR-v3 (220 Mbps mean). In the download path, BBR-TAS also outperforms BBR-v3, but CUBIC performs well too, owing to its aggressive bandwidth-filling logic, at the expense of increased latency—evident from the elongated box-and-whisker ping plot on the right side of the same figure.

Figure 9 shows the detailed ping box plot for the Differentiated Services (DS) RRUL streams. If BBR-TAS’s latency benefit stems from reduced channel-access overhead rather than an effect specific to one traffic pattern, it should appear uniformly across independently scheduled traffic classes—and the ping box plot confirms this. It shows a different class of periodic, small-packet data traffic (three UDP marking classes plus ICMP) competing for channel access. Because BBR-TAS’s aggregation improvement operates at the shared MAC layer rather than within any single flow, its effect propagates identically to all traffic sharing that channel, which is exactly the uniform ordering (CUBIC highest and widest; BBR-v3 and BBR-TAS both lower, with BBR-TAS consistently at or below BBR-v3) visible in every panel of Figure 9. The CUBIC loss-based phenomenon is visible, as it tries to fill the bottleneck until packet loss occurs regardless of TSQ size. This produces a classic sawtooth pattern that creates bufferbloat and inflates latency for every class of competing traffic simultaneously.

The two-cluster structure in Figure 10 visualizes the qualitative distinction between the two families of algorithms under test. CUBIC’s cluster (right-hand region, ~150–450 ms) reflects sustained queue occupancy close to the bottleneck buffer limit, typical of a loss-based congestion control operating close to the point at which packet drop occurs. The model-based cluster (BBR-v3 and BBR-TAS, left-hand region, ~50–200 ms) instead reflects both algorithms’ shared design goal of estimating and pacing to the bottleneck bandwidth without deliberately filling the queue, consistent with BBR’s core goal of operating at Kleinrock’s optimal operating point. BBR-TAS, with its adaptive pacing shift algorithm, operates in a regime that further decreases latency. Within the shared cluster, the difference between the two dotted black lines—the leftmost for BBR-TAS and a slightly delayed one underneath for BBR-v3—marks their respective average ping latencies. This difference is attributable to frame aggregation being exploited by BBR-TAS with the help of an improved TSQ pacing shift.

The size and shape of each confidence ellipse in Figure 11 reflect the joint variability of latency and upload throughput sampled throughout the run, with a smaller ellipse indicating more consistent, predictable behavior and a larger one indicating wider swings around the mean. The ellipse shapes can be traced directly to the steady-state pacing shift specified in Algorithm 1. Once a BBR-TAS flow reaches the steady-state phase, BBR-TAS applies a steady-state shift of 8, computing a dynamic TSQ limit that permits larger, aggregated traffic compared to the fixed limit BBR-v3 uses for its entire connection lifetime. The larger buffer this pacing-shift change affords BBR-TAS acts as a shock absorber against the momentary bandwidth-estimate fluctuations characteristic of a typical contended Wi-Fi 6 channel. The higher centroid of BBR-TAS shows not only increased throughput but, being positioned to the left of the BBR-v3 centroid, also clearly exhibits lower latency. Lacking a TSQ pacing shift mechanism, BBR-v3 fails to react to instantaneous rate-estimate dips; its tightly limited socket has almost no already-enqueued data to draw on, forcing packets to wait for the next pacing-timer release and manifesting as a discrete latency spike—precisely the mechanism producing the wider vertical spread of BBR-v3’s ellipse.

Figure 12 is the ellipsis plot in SUM—i.e., upload and download throughputs combined. To evaluate the joint throughput–delay tradeoff under saturated conditions, the Flent ellipsis plot from a 60-second total RRUL run compares BBR-TAS (tas_s8_st8) against generic BBR-v3. The centroid of each ellipse represents the total throughput and round-trip delay, where an optimal protocol shifts the operational center toward the top-left quadrant (maximizing throughput while minimizing delay). BBR-TAS successfully shifts the operational centroid upward to 315 Mbit/s at a 110 ms mean latency, achieving higher aggregate throughput and lower average delay than BBR-v3, which centers at 280 Mbit/s and 126 ms. Furthermore, the horizontal footprint highlights the superior bufferbloat control of BBR-TAS: while BBR-v3 exhibits prolonged queueing delay stretching to ~208 ms, the adaptive TSQ pacing shift mechanism caps maximum delay near ~188 ms, with a lower bound reaching ~18 ms. This confirms that dynamic TSQ sizing effectively curbs transient buffer accumulation, preserving low delay without compromising high link utilization under heavy concurrent load.

To evaluate latency performance across the entire empirical distribution, the Flent Quantile-Quantile (Q-Q) plot in Figure 13 compares ICMP ping round-trip times between BBR-TAS (tas_s8_st8) on the y-axis and generic BBR-v3 on the x-axis during the RRUL test. Because the scatter points lie consistently below the reference line (y = x) across nearly the entire spectrum, BBR-TAS demonstrates strict stochastic dominance in delay reduction over BBR-v3. In the low-to-median latency regime (below 125 ms), BBR-TAS maintains substantially lower quantiles; for instance, when BBR-v3 reaches 125 ms, BBR-TAS restricts round-trip delay to approximately 105 ms. This advantage is preserved into the heavy-tail distribution region: as BBR-v3 latency escalates past 200 ms, BBR-TAS caps peak queueing delay near ~185–190 ms. These empirical findings confirm that adaptive TSQ pacing shifts systematically suppress bottleneck queue accumulation, delivering lower median latency and significantly mitigating tail-latency inflation compared to stock BBR-v3 under saturated link conditions.

4.3. RTT-Fair RRUL Test

In this subsection, further testing was performed on the three CCAs under evaluation. The RTT-fairness test is important because it isolates a dimension of congestion control performance that the other Flent tests do not consider: how fairly a congestion control allocates bandwidth on a shared bottleneck among concurrent flows of varying RTTs. The RRUL test is indeed a strenuous test that saturates the link with four streams in each of the uplink and downlink paths, but it targets a single host, so the RTT remains constant and fairness across differing RTTs is not measured. RTT-fair addresses this gap by sending traffic to different hosts and measuring the corresponding throughput and latency simultaneously. The testbed in Figure 3 depicts the ubiquitous network connectivity present in today’s homes and offices; the network was capped at 25 Mbps in upload/download per the ISP-purchased subscription for internet access. This network may be carrying a local file transfer (with a very low RTT) alongside a distant video stream (tens to hundreds of milliseconds of RTT). A loss-based CCA such as CUBIC favors flows with shorter RTTs, since shorter flows with faster acknowledgements (ACKs) trigger congestion window (CWND) growth more rapidly and so obtain more bandwidth. Model-based algorithms such as BBR-v3 and BBR-TAS take a different approach and decouple rate control from ACK timing. By providing direct, reproducible evidence of whether a given CCA converges toward equitable bandwidth sharing or systematically favors flows based on their distance from the bottleneck, the RTT-fairness test is directly relevant to evaluating whether a design like BBR-TAS improves on stock BBR’s fairness characteristics under realistic, mixed-RTT Wi-Fi 6 conditions—a property that RRUL’s single-RTT, high-load design is not set up to expose.

Figure 14, Figure 15 and Figure 16 show three plots generated from the data collected in the RTT-fair test. Figure 14 shows the ping results for both local and remote servers: BBR-TAS achieves an average ping latency of 153.75 ms compared with CUBIC (180 ms) and BBR-v3 (261.5 ms), a latency improvement attributable to the pacing shift algorithm.

Figure 15 provides a more detailed picture via a ping CDF plot, in which the dotted black line for BBR-TAS lies to the left of the average lines for both CUBIC and BBR-v3 and rises more steeply, indicating substantially improved latency.

Figure 16 reports the throughput achieved for flows to the local and public remote servers: CUBIC achieved 24 Mbps in TCP download average, BBR-v3 achieved 18 Mbps, and BBR-TAS achieved 21.8 Mbps. BBR-TAS performed better in latency amongst all three algorithms and better than BBR-v3 in TCP download throughput in this important testbed scenario. CUBIC’s download average was higher, but at the cost of increased latency, as expected from a typical loss-based congestion control that fills buffers aggressively until packet loss occurs. BBR-TAS, with its adaptive TSQ mechanism, not only provides good throughput relative to BBR-v3 but also delivers superior latency performance against both baselines.

5. Conclusions

This paper tackled the issue of TCP Small Queues, sender-side pacing, and the frame aggregation inherent to IEEE 802.11ax, which together produce latency due to bufferbloat across all traffic conditions and constrain achievable throughput as more flows join the network path. We propose BBR-TAS, a BBR-v3-derived congestion control that adapts its TSQ pacing shift according to BBR’s own internal state, applying a distinct shift during the STARTUP and DRAIN phases and a separate shift once the connection reaches steady state (Algorithm 1, lines 3–7). We evaluated it on a Wi-Fi 6 physical testbed across a factorial sweep of nine (startup shift, steady-state shift) combinations against generic BBR-v3 and CUBIC. BBR-TAS delivered significant improvements that grew further as contention increased. In the single-flow upload test, latency improved significantly against both CUBIC (11.1%) and BBR-v3 (9%), showing that even a single flow benefits from bounded, phase-aware queue occupancy rather than the unbounded queue growth that produces bufferbloat. With increased contention, as in the eight-stream upload test, BBR-TAS achieved a 2.8% throughput improvement against both CUBIC and BBR-v3, paired with latency reductions of 17.4% and 10.7%, respectively. The RRUL test, which more strenuously tests bufferbloat, identified the (startup=8, steady-state=8) configuration as the strongest-performing point in the sweep: a 13% throughput gain over BBR-v3 with a ~15% latency improvement over BBR-v3 and ~59% over CUBIC. These results demonstrate that BBR-TAS mitigates the bufferbloat that arises when the default TSQ starves Wi-Fi 6’s frame aggregation logic. BBR-TAS’s bounded, phase-triggered adjustment sustains a higher throughput operating point (RRUL: 309.53 Mbps mean) while keeping latency lower than both generic BBR-v3 and loss-based CUBIC.

The RTT-fair test, which measures fairness and performance across concurrent flows to hosts at differing round-trip times rather than the single-host, single-RTT design of RRUL, showed the clearest latency separation of any test in this study: BBR-TAS achieved an average ping latency of 153.75 ms, a 14.6% reduction over CUBIC (180 ms) and a 41.2% reduction over BBR-v3 (261.5 ms), with the corresponding ping CDF confirming that this improvement holds consistently across the distribution rather than being driven by a few low-latency samples. In throughput, BBR-TAS outperformed BBR-v3 (21.8 Mbps vs. 18 Mbps, a 21.1% gain) but trailed CUBIC (24 Mbps), which favors shorter-RTT flows at the cost of the substantially higher latency shown above—consistent with CUBIC’s loss-based design filling buffers aggressively until packet loss occurs. This indicates that BBR-TAS’s pacing-shift mechanism improves on stock BBR-v3 on both throughput and latency under mixed-RTT conditions, while trading a modest amount of raw throughput for substantially lower latency relative to loss-based CUBIC.

Future work will extend this design toward a fully runtime-adaptive variant that infers the contention level directly from BBR’s own bandwidth-growth signal rather than relying on a pre-configured pair of shift values, removing the need for the offline sweep presented in this paper while preserving the bounded, phase-aware behavior shown here to mitigate bufferbloat on Wi-Fi 6 hybrid bottlenecks.