Fact-checked by Grok 2 weeks ago

Bandwidth-delay product

The bandwidth-delay product (BDP) is a fundamental metric in computer networking that quantifies the maximum amount of data that can be outstanding (or "in flight") on a network link at any given time, calculated as the product of the link's bandwidth (typically in bits per second) and its round-trip time (RTT, in seconds).^[1] This value, expressed in bits, represents the volume of unacknowledged data that a sender can transmit before receiving confirmation from the receiver, ensuring efficient utilization of the link without unnecessary delays or buffering overflows.^[2] The concept was proposed in the early 1990s as a guideline for router buffer sizing in conjunction with congestion avoidance mechanisms.^[3] In transport protocols like TCP, the BDP plays a critical role in determining the optimal congestion window size, as a window smaller than the BDP leads to link underutilization, while a larger one risks congestion; this is particularly pronounced in "long fat networks" (LFNs) with high bandwidth and long delays, such as transcontinental fiber optics or satellite links.^[4] For instance, modern high-speed networks with bandwidths exceeding 10 Gbps and RTTs over 100 ms can yield BDPs in the gigabit range, necessitating TCP window scaling extensions to handle such capacities effectively.^[5] The concept is a key concept in the context of pipe capacity analysis and has influenced advancements in congestion control algorithms, enabling protocols to achieve near-full throughput in diverse environments from local area networks to wide-area internet backbones.

Core Concepts

Definition

In networking, bandwidth represents the maximum rate at which data can be transmitted over a link, typically measured in bits per second (bps).^[6] Delay, on the other hand, refers to the total time required for a bit to travel from source to destination, comprising propagation delay (the physical time for the signal to traverse the medium), queuing delay (time spent waiting in network buffers), and processing delay (time for nodes to handle the data).^[6] The bandwidth-delay product (BDP) defines the maximum amount of data that can be in flight—transmitted but unacknowledged—on a network path at any given time, equivalent to the product of the path's bandwidth and its round-trip time (RTT).^[2] This quantity indicates the volume of bits "pipelined" across the network before feedback, such as an acknowledgment, arrives from the receiver.^[2] In calculating BDP, round-trip time (RTT)—the duration for a packet to reach the destination and return—serves as the key delay metric, rather than one-way delay, because it accounts for the bidirectional exchange typical in full-duplex links where data flows simultaneously in both directions while relying on reverse-path acknowledgments.^[2] The concept of BDP was formalized in the late 1980s in the context of TCP extensions for paths with high bandwidth-delay products, such as satellite links.^[7] In practice, for protocols like TCP, the congestion window size must match or exceed the BDP to fully utilize available bandwidth without stalling.^[2]

Mathematical Formulation

The bandwidth-delay product (BDP) is mathematically defined as the product of a network link's capacity and its end-to-end round-trip time (RTT).^[8] Formally, this is expressed as

\text{BDP} = B \times \text{RTT},

where B denotes the bandwidth in bits per second (bps) and RTT is the round-trip time in seconds, yielding a BDP value in bits.^[8] This formulation captures the maximum amount of data that can be in transit on the link before an acknowledgment is received, assuming full utilization.^[4] To express the BDP in bytes, which is often relevant for protocol buffer sizing, divide the bit value by 8:

\text{BDP}_\text{bytes} = \frac{\text{BDP}_\text{bits}}{8}.

^[8] For bandwidth units other than bps, such as megabits per second (Mbps), first convert by multiplying by $10^6 to obtain bps before applying the formula; for example, a 100 Mbps link requires scaling B to $100 \times 10^6 bps.^[8] In certain contexts, such as half-duplex or unidirectional communication flows, a one-way BDP variant is employed, given by B \times D, where D is the one-way delay in seconds.^[9] The total RTT in the core formula typically encompasses multiple delay components, including propagation, queuing, and serialization delay—the latter being the transmission time for a packet, calculated as packet size in bits divided by B.^[10] This formulation relies on assumptions of constant bandwidth and delay, which may not hold in real networks with variable queuing, packet loss, or fluctuating link capacities, potentially requiring adjustments for accuracy.^[11]

Network Performance Implications

Role in TCP Throughput

The bandwidth-delay product (BDP) plays a critical role in determining the efficiency of TCP's sliding window mechanism, which controls the amount of unacknowledged data in transit to prevent network congestion while maximizing throughput. In TCP, the receive window (RWND) advertised by the receiver specifies the maximum amount of data the sender can transmit without receiving an acknowledgment. To fully utilize the available bandwidth and "fill the pipe" without idle periods waiting for acknowledgments, the RWND must be at least equal to the BDP of the path, ensuring that data packets are continuously in flight during the round-trip time (RTT).^[8]^[5] The achievable TCP throughput is fundamentally limited by the window size and RTT, approximated by the formula:

\text{Throughput (bps)} \approx \frac{\text{RWND (bytes)} \times 8}{\text{RTT (seconds)}}

This equation shows that for a given RTT, throughput scales linearly with the RWND until it reaches the path's bandwidth capacity; thus, setting RWND \geq BDP (in bytes) is necessary to saturate the link and achieve full utilization under ideal conditions.^[8] Vanilla TCP implementations are constrained by a 16-bit window field in the TCP header, limiting the maximum RWND to 65,535 bytes regardless of network capabilities. This cap becomes insufficient for paths where the BDP exceeds this value—for instance, on a link with 100 ms RTT, it restricts effective throughput to approximately 5.24 Mbps, as higher bandwidths would require a larger window to avoid underutilization.^[5]^[5] To address this limitation, the TCP window scaling option, introduced in RFC 1323 and updated in RFC 7323, allows negotiation of a scaling multiplier during connection setup. This option uses a shift count (0–14) as a power-of-two factor applied to the 16-bit window field, effectively extending the maximum RWND to 1 GB (2^{30} bytes) while maintaining backward compatibility with non-scaling endpoints.^[5]^[12]

Long Fat Networks

Long fat networks (LFNs), also known as "long, fat pipes," are network paths with a significantly high bandwidth-delay product (BDP), defined as exceeding 10^5 bits (approximately 12.5 KB).^[7] This threshold identifies paths where the product of available bandwidth and round-trip time demands more data in flight than standard configurations can efficiently handle without adjustments.^[7] The rationale for this 10^5 bit benchmark originates from early TCP implementations, where default window sizes—limited to around 64 KB—began to constrain throughput on paths surpassing this BDP level, as seen in original ARPANET and initial satellite links.^[7] While modern TCP extensions support much larger windows, the threshold persists as a conventional reference for classifying LFNs in networking literature and tuning guidelines.^[5] LFNs typically emerge from pairings of high-bandwidth transmission media, such as fiber-optic cables capable of gigabit speeds, with extended propagation delays inherent to long-distance routes like transoceanic undersea cables (often 100-200 ms round-trip) or geostationary satellite links (around 500-600 ms round-trip).^[7] For instance, a 1 Gbps fiber link across the Atlantic might yield a BDP of over 10^8 bits, far exceeding the classic threshold.^[7] These characteristics introduce key performance challenges, including underutilization of bandwidth when TCP receive windows remain untuned, as the protocol cannot keep the pipe fully filled with unacknowledged data during the extended delay.^[7] The requirement for oversized buffers to match the high BDP heightens bufferbloat risks, where accumulated queues inflate latency during congestion, degrading interactive applications despite ample capacity. Head-of-line blocking is also amplified, as TCP's strict packet ordering over long delays stalls subsequent data upon losses or reordering, prolonging recovery times.^[13] TCP window scaling addresses some underutilization by extending effective window sizes up to 1 GB.^[5]

Practical Examples

Traditional Broadband Connections

Traditional broadband connections, such as digital subscriber line (DSL) and cable modems, emerged in the late 1990s and early 2000s as primary means for consumer and small enterprise internet access, typically offering asymmetric bandwidth with higher downstream rates to support web browsing and file downloads. These technologies often featured modest bandwidth-delay products (BDPs) that aligned with the default TCP receive window size of up to 65,535 bytes, allowing efficient data transfer without extensive tuning in many cases. However, as speeds increased through the 2010s, BDPs grew, occasionally necessitating TCP window scaling to achieve full throughput, particularly on links with moderate round-trip times (RTTs).^[14] A representative DSL connection in the mid-2000s provided approximately 2 Mbps downstream bandwidth with an RTT of around 50 ms, resulting in a BDP of $2 \times 10^6 bit/s \times 0.05 s = 100,000 bits, or about 12.5 KB. This value comfortably fit within the unscaled TCP window, enabling near-full utilization for bulk transfers without additional configuration. In contrast, cable modem services evolved more rapidly; by the early 2010s, downstream speeds reached 50 Mbps with typical RTTs of 25-35 ms, yielding a BDP of approximately $50 \times 10^6 bit/s \times 0.03 s = 1,500,000 bits, or 187.5 KB—exceeding the default window and often requiring the TCP window scale option for optimal performance.^[14]^[15] Variants like asymmetric DSL (ADSL) and high-speed downlink packet access (HSDPA) further illustrated BDP growth with technological upgrades. For instance, ADSL2+ connections commonly delivered 7-20 Mbps downstream with RTTs of 40-60 ms, producing BDPs in the 35-150 KB range, still manageable without scaling but highlighting the need for buffer adjustments in asymmetric setups where upstream bottlenecks could delay acknowledgments. Similarly, early HSDPA deployments in mobile broadband offered up to 7.2 Mbps with RTTs around 100 ms, calculating to a BDP of $7.2 \times 10^6 bit/s \times 0.1 s = 720,000 bits, or roughly 90 KB, which underscored early requirements for larger windows and selective acknowledgments (SACK) to mitigate underutilization on variable wireless paths.^[16]^[17] These examples reveal that while traditional broadband BDPs generally remained below thresholds demanding advanced TCP adaptations, asymmetric link characteristics—such as limited upstream capacity in DSL (e.g., 256-640 Kbps) and shared contention in cable—frequently introduced ACK compression or loss, reducing effective throughput and prompting tuning like path MTU discovery or header compression for better efficiency. Overall, such connections demonstrated the practical transition from BDP-limited to bandwidth-limited regimes as infrastructure matured.^[18]

High-Speed Research and Backbone Networks

In high-speed backbone networks, the bandwidth-delay product (BDP) becomes particularly significant due to the combination of ultra-high capacities and substantial propagation delays over long distances. For instance, transatlantic links operating at 100 Gbps with a round-trip time (RTT) of approximately 100 ms yield a BDP of $100 \times 10^9 bit/s \times 0.1 s = 10 Gbit, or roughly 1.25 GB when accounting for byte conversions (8 bits per byte). This scale requires extensive buffer tuning to maintain full pipe utilization, as standard TCP windows often fall short without extensions like window scaling.^[19] Satellite networks exemplify extreme BDP challenges in backbone contexts, especially geostationary Earth orbit (GEO) systems where signal travel distance imposes high latency. A GEO link providing up to 500 Mbps bandwidth with a typical 600 ms RTT results in a BDP of approximately $500 \times 10^6 bit/s \times 0.6 s = 300 Mbit, or 37.5 MB, classifying it as a classic long fat network (LFN) that demands specialized acceleration techniques to avoid underutilization.^[20]^[21] Research networks such as ESnet and Internet2 push BDP boundaries further with multi-terabit infrastructure for scientific data transfer. These networks deploy 400 Gbps links, and in scenarios with 200 ms RTT—common for international paths—the BDP reaches up to $400 \times 10^9 bit/s \times 0.2 s = 80 Gbit, or 10 GB, necessitating advanced tuning of transport parameters to achieve sustained throughput for large-scale simulations and datasets.^[22]^[23]^[24] Post-2020, the BDP in backbone networks has seen exponential growth driven by the shift to terabit-era capacities, with international bandwidth demand tripling to over 6.4 Pbps by 2024 at a 32% compound annual growth rate, and provisioned capacity reaching 1,835 Tbps as of 2025 amid continued 23-29% annual growth, amplifying scaling challenges for data-intensive applications like AI training and climate modeling.^[25]^[26]^[27]

Advanced Topics

TCP Congestion Control Adaptations

Standard TCP implementations, such as Reno and its successors like Cubic, adjust the congestion window during slow-start and congestion avoidance phases to estimate and scale with the bandwidth-delay product (BDP) primarily through round-trip time (RTT) measurements. In slow start, the window increases exponentially by up to one segment per acknowledgment until it reaches the slow-start threshold, allowing rapid filling of the pipe up to the BDP; congestion avoidance then linearly increments the window by approximately one segment per RTT to probe for additional bandwidth without inducing loss.^[28] Reno, as defined in RFC 5681, relies on loss signals to trigger these adjustments, which can lead to underutilization in high-BDP paths where buffers are shallow, as the algorithm conservatively backs off on packet drops.^[28] Cubic extends this by using a cubic function for window growth in congestion avoidance, W(t) = C(t - K)^3 + W_{\max}, where C = 0.4 and K is derived from the time since last congestion, enabling more aggressive scaling in large BDP environments while remaining TCP-friendly for smaller windows.^[29] This approach allows Cubic to achieve higher throughput in fast long-distance networks compared to Reno, as the convex growth phase probes beyond the previous maximum window to better match the BDP.^[29] HighSpeed TCP, proposed in RFC 3649, introduces a more aggressive response function for connections with large congestion windows, specifically targeting BDPs exceeding 80 MB, such as those in high-speed grid computing environments. It modifies the increase parameter a(w) and decrease parameter b(w) based on the current window size w, using a(w) = 0.24 w^{1.165} / (1 + 0.24 w^{1.165}) for windows above 38 segments, allowing faster ramp-up to fill high-BDP pipes while reducing to standard TCP behavior for smaller windows.^[30] This design improves utilization in scenarios like 10 Gbps links with 100 ms RTT, where standard TCP might only achieve partial throughput due to infrequent loss signals at low drop rates around $10^{-7}.^[30] HighSpeed TCP has been particularly useful in grid applications, enabling efficient data transfers over wide-area networks with large BDPs.^[30] Compound TCP (CTCP), developed by Microsoft, combines loss-based and delay-based signals to better handle long fat networks (LFNs) with high BDPs. It maintains two windows—a standard loss-based congestion window cwnd and a delay-based window dwnd—with the effective sending window as \min(awnd, cwnd + dwnd), where awnd is the advertised window; the delay component aggressively increases when queuing delay is low (below \gamma = 30 packets) and reduces multiplicatively on congestion detection.^[31] This synergy allows CTCP to scale more efficiently than pure loss-based TCP in high-BDP paths, achieving up to 93% link utilization at 625 Mbps over 100 ms RTT, while remaining fair to standard TCP flows by stealing less than 10% bandwidth.^[31] TCP BBR, introduced by Google in 2016, directly models the BDP as the product of estimated bottleneck bandwidth (BtlBw) and round-trip propagation time (RTprop), using recent samples filtered over multiple RTTs to pace sends and avoid reliance on packet loss. Subsequent versions, BBRv2 (2018) and BBRv3 (deployed around 2023), introduce refinements such as improved loss detection, adjustable pacing gains, and better handling of varying network conditions to enhance performance in high-BDP environments.^[32] ^[33] BBR operates in phases like startup, drain, and probe bandwidth, maintaining approximately one BDP in flight to maximize utilization while minimizing queue buildup, which contrasts with loss-based methods that induce bufferbloat.^[32] By sampling bandwidth during low-queue periods and pacing at the estimated rate, BBR achieves low latency and high throughput in varied conditions, including high-BDP networks.^[32] Evaluations in high-BDP environments demonstrate significant throughput gains for these adaptations over standard loss-based TCP. For instance, BBR delivers 2-25 times higher throughput than Cubic on Google's wide-area networks, such as achieving 2 Gbps versus 15 Mbps in bottleneck-limited paths, often reaching over 90% utilization compared to 50% or less for Reno and Cubic due to their sensitivity to loss.^[32] HighSpeed TCP and CTCP also show improvements, with CTCP attaining 93% utilization in LFNs where Reno plateaus at lower rates, and HighSpeed TCP enabling near-full pipe usage in grid transfers with BDPs over 80 MB.^[31]^[30] These adaptations collectively enhance TCP's ability to utilize high-BDP links without excessive congestion.^[32]

Modern Protocols and Emerging Technologies

QUIC, standardized in RFC 9000 in 2021, incorporates built-in flow control mechanisms with scalable receive windows to manage the bandwidth-delay product (BDP) effectively in environments with variable latency, such as mobile and cloud-based web traffic.^[34] These windows adjust dynamically based on receiver feedback, preventing buffer overflow while allowing senders to utilize available bandwidth without explicit configuration for high BDP paths.^[35] QUIC's congestion control, detailed in RFC 9002, supports integration with algorithms like NewReno or BBR to probe for bandwidth while respecting delay constraints, enabling robust performance over lossy links common in web applications.^[36] In 5G networks, ultra-reliable low-latency communication (URLLC) addresses BDP challenges through edge computing integrations that minimize propagation delays and adapt to variable channel conditions.^[37] For instance, a 1 Gbps link with 10 ms round-trip time yields a BDP of 1.25 MB, but mmWave bands introduce variability due to beamforming and mobility, necessitating adaptive pacing mechanisms like the UPF-SDAP Pacer to throttle transmission rates and maintain low latency.^[38] The enhanced 5G BDP approach further optimizes radio link control queues to align with these dynamics, supporting URLLC use cases in industrial automation and vehicular networks.^[38] Cloud computing environments, such as those using AWS Direct Connect, handle large BDPs in virtualized paths by emulating high-capacity links, for example, up to 100 Gbps with 50 ms RTT resulting in a 625 MB BDP.^[39] To achieve low-latency transfers, RDMA over Converged Ethernet (RoCE) is employed, extending reliable data movement across distances by managing credits exceeding one BDP to mitigate packet loss in inter-data-center scenarios.^[40] Recent developments as of 2025 in 6G research explore terahertz (THz) links promising terabit-per-second bandwidths with microsecond latencies for short-range, high-frequency communications.^[41] In satellite constellations like Starlink, dynamic BDPs arise from frequent handoffs in low-Earth orbit, with average values around 500 KB for 100 Mbps links and 40 ms RTT, compounded by jitter and latency variations that challenge traditional transport protocols. These systems employ handover optimizations to balance processing delays and maintain throughput during satellite transitions.^[42] A key challenge in modern networks involves Multi-Path TCP (MPTCP), which aggregates BDPs across multiple paths to boost throughput but faces issues like increased reordering delays and fairness conflicts in congestion control, particularly in heterogeneous environments such as wireless and data centers.^[43] MPTCP's subflow scheduling must account for varying path BDPs to avoid head-of-line blocking, though limited device support and bufferbloat in cellular links exacerbate performance degradation.^[44]

References

[1]
[PDF] CS 352 Bandwidth-Delay Product
The Bandwidth-Delay Product. • C * T = bandwidth-delay product: • The amount of data in flight for a sender transmitting at the ideal rate during the ideal ...
[2]
Bandwidth Delay Product - an overview | ScienceDirect Topics
The bandwidth-delay product is defined as the product of a network link's bandwidth and its round-trip time delay, representing the amount of data that can ...Introduction to Bandwidth... · Mathematical Definition... · Role of Bandwidth-Delay...
[3]
[PDF] The TCP Bandwidth-Delay Product revisited - GT Digital Repository
WHAT DOES BANDWIDTH-DELAY PRODUCT MEAN? Consider a unidirectional TCP transfer from a sender to a receiver . TCP is window-controlled, mean-.
[4]
[PDF] Congestion Control for High Bandwidth-Delay Product Networks
It operates the network with almost no drops, and sub- stantially increases the efficiency in high bandwidth-delay product environments. 11. ACKNOWLEDGMENTS.
[5]
[PDF] The performance of TCP/IP for networks with high bandwidth-delay ...
For LANs, the round-trip delay of the connection is small, so that the bandwidth-delay product could be much smaller than the buffering on the bottleneck link.
[6]
https://www.sciencedirect.com/book/9780128182000/computer-networks
[7]
[PDF] A History of the Improvement of Internet Protocols Over Satellites ...
Abstract. This paper outlines the main results of a number of ACTS experinlents on the efficacy of using standard. Internet protocols over long-delay ...
[8]
RFC 6349 - Framework for TCP Throughput Testing - IETF Datatracker
... Bandwidth-Delay Product (BDP) determines the Send and Received Socket buffer sizes required to achieve the maximum TCP Throughput. Then, with the help of ...
[9]
[PDF] Scheduling and Flow Control in CMT-SCTP - HKU Scholars Hub
For the other paths, if the transmission is allowed, the buffer size is intentionally delimited by the one-way bandwidth-delay-product (OWBDP). This ...<|control11|><|separator|>
[10]
[PDF] TCP Technology and Testing methodologies - EXFO
It refers to the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. Bandwidth-delay product is the product of the data link.
[11]
https://people.cs.uchicago.edu/~ravenben/classes/333/papers/xcp.pdf
[12]
RFC 1323: TCP Extensions for High Performance
### Summary of RFC 1323: TCP Window Size and Scaling
[13]
RFC 7323: TCP Extensions for High Performance
Summary of each segment:
[14]
RFC 1072 - TCP extensions for long-delay paths - IETF Datatracker
This memo proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product.
[15]
TCP FWA: Fast Window Advance for TCP - IETF
... Head of Line Blocking in TCP long alive connections and in TCP long fat networks. FWA flag shall be set by the sender to force the TCP receiver to change ...
[16]
[PDF] NINTH MEASURING BROADBAND AMERICA
Measuring Broadband America rtt_avg. Average RTT rtt_min. Minimum RTT rtt_max. Maximum RTT rtt_std. Standard deviation in measured RTT successes. Number of ...
[17]
[PDF] Latency Explained | BITAG
Jan 10, 2022 · The table gives the typical one-way distance over which the link technology is generally used, the nominal round-trip signal propagation delay ...
[18]
[PDF] Measuring Quality of Experience of Internet Access over HSDPA.
pensated with higher bit rates, making the overall bandwidth-delay product (BDP) or “pipe size” bigger. Using large window sizes makes it advisable to ...
[19]
[PDF] Improving 3G Performance for the Mobile Internet
The bandwidth delay product, BDP, is a way to characterize the topology in terms ... HSDPA is a new radio link that has not yet reached the market but it ...
[20]
[PDF] RIGHT-SIZING CABLE MODEM BUFFERS FOR MAXIMUM ...
If the optimal buffer size for TCP performance is presumed to be equal to the bandwidth delay product, then one might inquire how that compares to the buffer ...Missing: scaling | Show results with:scaling
[21]
[PDF] Efficient Wide Area Data Transfer Protocols for 100 Gbps Networks ...
Nov 17, 2013 · At 95ms, the bandwidth-delay product (BDP)8 of the path approaches 500MB. This neces- sitates that an application or middleware system with a ...
[22]
You Don't Know Jack about Network Performance - ACM Queue
Jun 7, 2005 · Because only 16 bits were allocated to the window advertisement field in the TCP header, the maximum possible window was limited to 65,535 ...
[23]
[PDF] The Interplay of Traffic Shaping and YouTube Streaming QoE over ...
satellites are typically 500-600 ms. To mitigate the effects of this latency, GEO ISPs often employ a variety of techniques. These usually include TCP ...
[24]
[PDF] TCP over GEO satellite hybrid networks - University of Maryland
The bandwidth delay product in this system is very large. In order to keep the pipe full, the window should be at least the bandwidth delay product [5].
[25]
CANARIE, ESnet, GÉANT, and Internet2 Unveil Highest Capacity ...
Mar 17, 2024 · This diagram shows three new 400 Gbps spectrum circuits operated by ESnet, CANARIE, and Internet2, as well as the combined capacity of the ANA ...Missing: delay product 200 ms RTT
[26]
[PDF] Demystifying the Performance of Data Transfers in High ... - arXiv
Significant investments have been made to build high-performance wide- area research networks (e.g., Internet-2 and ESnet) with up to 400Gbps bandwidth to ...
[27]
Network Successfully Carries 400 Gbps of Traffic Coast-to-Coast
May 3, 2021 · Internet2 Next Generation Infrastructure Update: Testing Underway; Network Successfully Carries 400 Gbps of Traffic Coast-to-Coast · Routes ...Missing: delay product 200 RTT
[28]
International Bandwidth Demand Surpasses 6.4 Pbps
May 12, 2025 · Our 2024 data represents a steady 32% compound annual growth rate (CAGR). Not to mention a tripling demand between 2020 and 2024, surpassing 6.4 Pbps.
[29]
[PDF] DOE Network 2025 - DOE Office of Science - OSTI.GOV
... bandwidth-delay product as a 1 Tbps link over a campus distance (1 ms RTT). Each of these paths can see a significant drop in throughput by losing just one ...
[30]
RFC 5681 - TCP Congestion Control - IETF Datatracker
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.
[31]
RFC 8312 - CUBIC for Fast Long-Distance Networks
CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side.
[32]
RFC 3649 - HighSpeed TCP for Large Congestion Windows
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows.Missing: divided | Show results with:divided
[33]
[PDF] A Compound TCP Approach for High-speed and Long Distance ...
In this paper, we propose a novel Compound TCP (CTCP) approach, which is a synergy of delay-based and loss-based approach. In. CTCP, we add a scalable delay ...
[34]
BBR: Congestion-Based Congestion Control - Google Research
When bottleneck buffers are large, loss-based congestion control keeps them full, causing bufferbloat. When bottleneck buffers are small, loss-based congestion ...
[35]
RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
QUIC depends on congestion control to avoid network congestion. An exemplary congestion control algorithm is described in Section 7 of [QUIC-RECOVERY].Missing: scaling | Show results with:scaling
[36]
Flow Control – quic-go docs
This page outlines the flow control algorithms used by QUIC. Flow control ensures that a sender doesn't overwhelm the receiver with too much data (and too many ...Missing: scaling | Show results with:scaling
[37]
RFC 9002: QUIC Loss Detection and Congestion Control
QUIC is a secure, general-purpose transport protocol, described in [QUIC-TRANSPORT]. This document describes loss detection and congestion control mechanisms ...
[38]
[PDF] 5G E2E Technology to Support Verticals URLLC Requirements
5G system from Release-15 has introduced a toolbox of low latency features including Edge Computing (EC), flexible numerology, mini-slots, short PUCCH, faster ...
[39]
[PDF] Enhanced Quality of Service mechanisms for 5G networks
Following, we propose the (enhanced). 5G Bandwidth Delay Product ((e)5G-BDP), the Dynamic RLC Queue Limit (DRQL) and the. UPF-SDAP Pacer (USP) solutions, ...
[40]
AWS Direct Connect Announces Native 100 Gbps Dedicated ...
Feb 15, 2021 · AWS Direct Connect now offers native 100 Gbps Dedicated Connections to support your private connectivity needs to the cloud.Missing: delay RoCE RDMA
[41]
[PDF] Bifrost: Extending RoCE for Long Distance Inter-DC Links
Dec 25, 2023 · For a 400 Gbps link and a time slot 10 µs, the maximum pause time in Bifrost would be 7813 quanta, which would not provoke PFC pause frame ...
[42]
[PDF] FCC TAC 6G Working Group Report 2025
Aug 5, 2025 · future WiFi generations in the 6G era are expected to: ○ Exploit Terahertz (THz) spectrum for ultra-high bandwidth and extremely low latency. ○ ...
[43]
Measuring Mobile Starlink Performance: A Comprehensive Look
Feb 24, 2025 · ... bandwidth-delay product causes TCP instabilities [15]. Overall, the download took. 35.09 minutes with an average throughput of 188.47 Mbit/s.Missing: handoffs | Show results with:handoffs
[44]
Handover challenges in disaggregated open RAN for LEO Satellites
Sep 1, 2025 · Using a realistic dynamic LEO constellation model, we analyze the interplay among conditional handover (CHO) delay, computational complexity, ...<|separator|>
[45]
Performance Analysis of Multipath TCP Congestion Control Algorithms
To address these, Multipath TCP (Transmission Control Protocol) offers a viable solution by aggregating multiple network paths, resulting in improved bandwidth ...Missing: products | Show results with:products
[46]
[PDF] On Bufferbloat and Delay Analysis of MultiPath TCP in Wireless ...
In this paper, we study two issues: the impact of the delay startup of additional flows in the current. MPTCP design, and the effect of cellular bufferbloat on ...