A high-bandwidth path can remain mostly idle when a sender does not keep enough data in transit.

Consider a 1 Gbps connection with a round-trip time of 100 ms. During one round trip, the path could carry 100 megabits, or 12.5 megabytes. If a sender transmits only 64 KiB and then waits for an acknowledgment, most of that capacity goes unused. The link is fast, but the sender gives it too little work.

The bandwidth-delay product, commonly abbreviated BDP, quantifies this relationship. It estimates how much data must be in flight to use the available bandwidth across a path with a given delay.

For a flow that depends on acknowledgments returning to the sender, BDP is commonly calculated as:

The units show what the result means:

Bandwidth is a rate, and delay is a duration. Multiplying them produces an amount of data.

If a path can deliver 100 million bits per second and one round trip takes 40 milliseconds:

The sender can have about 500 KB of unacknowledged data outstanding during one round trip at 100 Mbps. It needs roughly that much data in flight to sustain the full rate under the simplified model.

BDP does not say how large a file is, how much traffic an application generates, or how much memory a machine has. It describes the amount of outstanding data associated with a path's rate and delay.

A sender can place bits onto a link without waiting for each individual bit to arrive. It sends a sequence of data while earlier data moves through the network. The receiver sends acknowledgments back, allowing the sender to continue.

If the sender exhausts its allowed outstanding data before an acknowledgment returns, it must stop and wait. The bottleneck link then has no new data to transmit. If the sender keeps at least one BDP of data outstanding, acknowledgments can return while new data continues to enter the path.

The relationship resembles filling a long pipe. Bandwidth determines the pipe's carrying rate, while delay determines how long data remains in transit. A higher rate, a longer delay, or both increase the amount needed to keep the path occupied.

This analogy has limits. Network paths contain queues, shared links, protocol rules, and changing traffic. BDP is a performance estimate, not the physical byte capacity of one literal pipe.

The term bandwidth-delay product appears with two related definitions.

For data traveling in one direction, multiplying bandwidth by one-way delay estimates how much data is propagating from sender to receiver at a given instant:

For an acknowledgment-driven protocol such as TCP, multiplying bandwidth by RTT estimates how much unacknowledged data the sender needs to sustain the rate while it waits for feedback:

This chapter uses the RTT definition because it directly explains end-to-end throughput limits for reliable transfers.

The distinction must be stated when quoting a BDP value. A path with symmetric 25 ms one-way delay has an RTT near 50 ms. The RTT-based BDP is approximately twice the one-way occupancy:

RTT is not always exactly twice one-way delay. The forward and reverse directions can take different routes or experience different queueing.

A fast local path can have a small BDP because acknowledgments return quickly. A lower-bandwidth long-distance path can have a larger BDP because data remains unacknowledged for longer.

The following values use decimal units and the RTT-based definition:

Doubling bandwidth doubles BDP when RTT stays constant. Doubling RTT also doubles BDP when bandwidth stays constant.

High-bandwidth, high-latency paths need substantial amounts of outstanding data. A 10 Gbps path with a 100 ms RTT needs about 125 MB in flight to sustain 10 Gbps. A few kilobytes of outstanding data cannot use more than a small fraction of that capacity.

In-flight data is data that the sender has transmitted but has not yet had acknowledged. It includes data traveling through the path, waiting in network queues, received but not yet acknowledged, and covered by acknowledgments that are returning to the sender.

If a sender may keep at most W bytes in flight and acknowledgments take one RTT to return, a useful upper-bound estimate is:

This estimate assumes that the in-flight limit, rather than another resource, constrains the flow.

Consider a sender limited to 64 KiB of unacknowledged data on a path with a 100 ms RTT:

Even if the physical path supports 1 Gbps, this flow cannot exceed about 5.24 Mbps while the 64 KiB limit remains. The path needs about 12.5 MB in flight to approach 1 Gbps at the same RTT:

The two equations express the same constraint from different directions:

Use the first equation to estimate how much outstanding data a target rate requires. Use the second to estimate the rate allowed by an existing in-flight limit.

Reliable transports limit how much data can remain outstanding. In TCP, the amount currently in flight is constrained by several values:

The usable in-flight amount cannot exceed the smallest applicable limit.

When the permitted amount is below BDP, the sender runs out of allowed data before feedback returns. When it is at least as large as BDP, the transport has enough room to fill the path, but full throughput is still not guaranteed. The application, CPU, storage, receiver, packet loss, and competing traffic may impose lower limits.

A window larger than BDP does not make the path transmit faster than its available bandwidth. It removes one possible restriction.

When the in-flight limit is smaller than BDP, the simplified maximum utilization is:

For a path with a 12.5 MB BDP and a 2.5 MB in-flight limit:

The equivalent throughput calculation gives the same result:

The path capacity is 1 Gbps, so 200 Mbps represents 20% utilization.

This estimate works best for a stable, long-running transfer with a consistent RTT and a clear in-flight limit. Short transfers and changing network conditions may never reach the estimated steady state.

Transport windows are not the only source of insufficient in-flight data. An application protocol can restrict outstanding work even when the transport allows much more.

Consider an application that sends a 1 KB request, waits one 100 ms round trip for a response, and then sends the next request. Ignoring response size and processing time, its sequential request rate is limited to:

A 1 Gbps path remains almost entirely unused because only 1 KB of application work is outstanding at a time.

Allowing several independent operations to be outstanding can raise aggregate throughput. The application can use concurrent requests, message pipelining, multiple streams, or multiple connections when the protocol and operation semantics permit them.

If 100 independent 1 KB requests are outstanding across the same 100 ms RTT, the outgoing request rate can reach about 1 MB/s under the same simplified assumptions:

This is still far below 1 Gbps, which is 125 MB/s. Filling the path with such small operations would require substantially more outstanding data.

Concurrency is not a universal performance fix. Operations can depend on earlier results, servers have finite capacity, and excessive parallel work can create queueing. BDP identifies the amount of outstanding data needed for a rate; it does not determine whether the application should generate that much work.

BDP describes steady-state occupancy. A transfer smaller than the path's BDP cannot place a full BDP of unique application data in flight.

On a path with a 12.5 MB BDP:

This does not make the 4 KB response inefficient in a harmful sense. Small responses do not need gigabit throughput to finish quickly. Their completion time depends more heavily on fixed delays than on sustained transfer rate.

Large transfers are more sensitive to whether the sender can maintain enough outstanding data. If the transfer ends before the flow reaches a steady rate, dividing path bandwidth into file size produces an optimistic completion time.

BDP is often used when reasoning about socket and protocol buffers, but it should not be copied directly into every buffer setting without context.

A sender needs enough buffered data to keep the permitted flight full. A receiver needs enough space to accept arriving data while the application consumes it. Protocol bookkeeping and scheduling can require additional room. Modern operating systems can also adjust TCP buffers dynamically within configured limits.

More buffering is not always beneficial. Large queues can hold packets for long periods during congestion. The link stays busy, but latency rises because packets wait in the queue. This condition is commonly called bufferbloat.

The goals differ:

BDP estimates useful in-flight data for a target rate. It does not justify unlimited buffering in endpoints or network devices.

Neither input to the BDP calculation is permanently fixed.

Available bandwidth changes. Other flows can consume capacity, wireless conditions can change, and routing can move traffic to a different bottleneck.

RTT changes. Queueing, route changes, and link conditions can alter round-trip time. RTT often rises while a path is heavily loaded.

A connection can therefore have different BDP estimates at different times:

In this example, available bandwidth falls while RTT rises. The resulting BDP increases from 3 MB to 5 MB.

The forward and reverse directions may also have different capacities. An asymmetric connection should be evaluated separately in each direction using the relevant data rate and feedback delay.

A BDP value should therefore include the measured or assumed bandwidth, RTT, direction, workload, and time period.

A practical estimate needs a representative RTT and a representative path rate.

ping can provide an ICMP RTT sample:

A bulk-transfer test between controlled endpoints can estimate achieved throughput:

Consider measurements showing:

The estimated BDP is:

About 1 MB of in-flight data is needed to sustain 180 Mbps at a 45 ms RTT under the simplified model.

The inputs must match the question being investigated. A 10 Gbps network-interface rating is not a useful path-bandwidth input when an intermediate link supports only 200 Mbps. Complete API response time is not an RTT input because it includes server processing and application work.

An achieved-throughput result can itself be restricted by the window being investigated. When diagnosing a possible window limit, use an independently known bottleneck rate, a target rate, or a test that can keep enough data in flight. Otherwise, a window-limited throughput measurement produces a BDP estimate for the already limited rate.

Separate ping and throughput tests also observe the path at different moments. A bulk test can increase queueing and RTT, while ICMP can receive different treatment from application traffic. Treat the result as an estimate and compare it with measurements taken under a workload similar to the target transfer.

BDP provides a structured way to investigate a bulk transfer that achieves far less throughput than expected.

Start with the path's achievable rate and representative RTT:

Next, estimate or observe the flow's in-flight data. If it never exceeds 3 MB:

The predicted ceiling is 400 Mbps, which is 20% of the 2 Gbps path rate. A measured transfer near 400 Mbps is consistent with an in-flight limit near 3 MB.

If the transfer reaches only 80 Mbps, the 3 MB limit does not fully explain the result. Storage, CPU, application generation rate, loss, sharing, or a lower path bottleneck may be responsible. BDP can identify one plausible ceiling, but it cannot prove the complete cause by itself.

This comparison is most useful when all values use the same direction and a similar observation interval:

Several connections share a path by contributing their individual in-flight data.

If one connection can keep only 1 MB outstanding on a path with an 8 MB BDP, eight similar connections could provide about 8 MB of aggregate in-flight data:

This can raise aggregate throughput when each connection is independently window-limited. Download tools sometimes use parallel connections for this reason.

Parallel connections also consume more endpoint state, compete with other traffic, and can increase queueing. They can hide a per-connection limitation instead of resolving it. The aggregate path still cannot exceed its available bandwidth, regardless of how many connections send.

The same reasoning applies to multiplexed streams within one connection. Many application operations can create enough queued data for the transport to fill the path, but the connection's transport-level in-flight limits still apply to their combined traffic.

"BDP is another name for bandwidth." Bandwidth is a rate measured in bits per second. BDP is an amount of data measured in bits or bytes.

"BDP is the amount of data in a file." File size describes application content. BDP describes how much data a path can keep in flight during the relevant delay.

"A 1 Gbps sender always transmits at 1 Gbps." The sender needs enough data and permission to keep approximately one BDP outstanding. A smaller window imposes a lower rate ceiling.

"A window equal to BDP guarantees full throughput." It removes one possible in-flight restriction. Application speed, receiver speed, loss, congestion, and competing traffic can still reduce throughput.

"A larger window always improves performance." Once another resource becomes limiting, more outstanding data does not increase useful throughput. Excessive queueing can increase latency.

"BDP always uses one-way delay." One-way delay estimates data occupying the forward path. RTT is used when estimating the unacknowledged data needed by a feedback-driven transfer. The chosen definition must be stated.

"BDP is constant for a connection." Available bandwidth and RTT can both change during a connection, so BDP is an estimate tied to observed conditions.

"Multiple connections create more bandwidth." They can increase aggregate in-flight data and use existing capacity more fully. They do not raise the path's physical capacity.

Bandwidth-delay product connects path capacity with feedback time: BDP = path bandwidth × RTT. It is an amount of in-flight data, usually expressed in bits or bytes, and grows with bandwidth or RTT.

When the in-flight limit is below BDP, throughput is bounded near in-flight limit ÷ RTT. Reaching BDP removes that restriction but does not guarantee full utilization: sequential applications, short transfers, congestion, and other limits may still leave capacity unused. Parallel connections increase aggregate in-flight data, not path capacity.

BDP guides window and buffer analysis rather than unlimited buffering. Because bandwidth and RTT change, every estimate needs explicit inputs and measurement conditions.

A wide path delivers high throughput only when the sender keeps enough data in flight across the round trip.