Bandwidth-delay product is the amount needed in flight

Choose a bottleneck capacity and a relevant unloaded round-trip time, then multiply them. Capacity in bytes per second times RTT in seconds gives bytes. This round-trip bandwidth-delay product estimates the outstanding inventory needed for one backlogged flow to keep a simple bottleneck busy while acknowledgments return. A one-way propagation product answers a different inventory question. State which delay you used. For capacity quoted in bits per second, divide by eight before comparing against byte windows. Decimal megabytes and binary mebibytes are different units and should be labeled explicitly in a buffer estimate.

Using minimum or unloaded RTT helps separate propagation and fixed processing delay from congestion-induced waiting. If loaded RTT includes a large bottleneck queue, multiplying it by capacity includes that queued inventory too. Treating the inflated product as a new target for still larger windows can normalize avoidable delay. Minimum RTT is itself an estimate from measurements: route changes, host scheduling, asymmetric paths, and sampling affect it. A product derived from a nominal link rate is an engineering starting point, not proof that this flow has exclusive access to that rate across the entire path.

If a sender can keep only 100 kilobytes outstanding on a path needing one megabyte to cover the feedback interval, it may run out of permission before the next acknowledgments arrive. This can leave bottleneck service idle despite a large advertised physical rate. The receiver window, congestion window, application write pattern, and outstanding-request limit can each create this restriction. Enlarging only one limit may not help when another remains binding. Inspect actual unacknowledged bytes and sender limiting state rather than assuming a large socket-buffer setting means the application fills the path.

Short transfers can finish before slow start or another controller reaches a path-filling flight. Connection setup, security establishment, request dependencies, and server work can dominate their completion time. A larger bandwidth-delay product does not mean a 2-kilobyte response needs a megabyte of useful payload in flight. Reusing connections or avoiding unnecessary round trips may help such a response more than changing steady-state buffers. Keep bulk goodput and request latency as different experimental targets, and use object sizes and dependency patterns representative of the application instead of evaluating every design with one giant file.

Once service is continuously busy, more queued bytes do not make the link serialize bytes faster. Under a simple single-bottleneck picture, excess flight above the unloaded path inventory can contribute to a bottleneck queue, increasing RTT by roughly queue bytes divided by service bytes per second. Real multi-flow paths split flight across queues and receivers, so this is a diagnostic approximation rather than a universal decomposition. It still explains why high utilization and low latency require a controller and queue policy that avoid a permanently excessive standing backlog.

For the queue lab, Reset, explicitly set both λ=2 and μ=2, predict a constant four-unit backlog from t=0, then Play or Step. Compare separate runs: Reset and re-set BOTH rates to (1,2) before predicting zero at t=4 seconds; Reset and re-set (3,2) before predicting growth. A control edit retains t and recomputes from four, so it does not extend the previous run's history. There is no propagation pipe or bandwidth-delay controller. Relate backlog to extra waiting only with consistent units; the separate M/M/1 residence estimate is neither propagation RTT nor a BDP measurement.