# Bandwidth-Delay Product Calculator

> Computes the bandwidth-delay product (bits in flight) of a network path from its bandwidth and round-trip time, the TCP receive window needed to fill it, and the throughput a given window size can achieve.

- Calculator id: `bandwidth-delay-product` · Category: Developer & IT (`developer`) · Tool name: `calculate_bandwidth_delay_product`
- Canonical page: https://tttkmbb.com/developer/bandwidth-delay-product · This document: https://tttkmbb.com/developer/bandwidth-delay-product.md · JSON definition: https://tttkmbb.com/developer/bandwidth-delay-product.json

## Purpose

Computes the bandwidth-delay product (bits in flight) of a network path from its bandwidth and round-trip time, the TCP receive window needed to fill it, and the throughput a given window size can achieve.

**Use when:** You are tuning TCP buffers (net.core.rmem_max, SO_RCVBUF) for a long-fat network, or want to know why a single TCP stream is slow over a high-latency link.

**Do not use when:** You need transfer time for a file (use download-time) or unit conversion of data sizes (use data-storage); the model ignores packet loss and congestion control.

## Input

| Parameter | Type | Unit | Required | Description |
| --- | --- | --- | --- | --- |
| `bandwidth_mbps` | number | Mbit/s | required | Bottleneck link rate in megabits per second (10⁶ bit/s). (> 0, max 10000000) |
| `rtt_ms` | number | ms | required | Round-trip latency (ping) in milliseconds. (> 0, max 100000) |
| `window_kib` | number | KiB | optional | Optional receive window size in KiB (1024 bytes) to compute the throughput it allows; 64 is the classic un-scaled maximum. (> 0, max 1000000000) |

## Output

| Field | Type | Unit | Description |
| --- | --- | --- | --- |
| `bdp_bits` | number | bit | bandwidth × RTT: bits that must be in flight to keep the link busy. |
| `bdp_bytes` | number | bytes | bdp_bits / 8. |
| `bdp_kib` | number | KiB | bdp_bytes / 1024. |
| `bdp_mib` | number | MiB | bdp_bytes / 1048576. |
| `recommended_window_bytes` | number | bytes | Minimum receive/congestion window (= bdp_bytes) for one stream to reach full bandwidth. |
| `window_scaling_required` | boolean |  | true when the window exceeds 65,535 bytes, the limit without the RFC 7323 window-scale option. |
| `max_throughput_mbps` | number | Mbit/s | window_kib × 1024 × 8 / RTT, capped by the bandwidth (only when window_kib is given). |
| `link_utilization_percent` | number | % | max_throughput / bandwidth × 100 (only when window_kib is given). |

## Formula

`bdp_bits = bandwidth_mbps × 10⁶ × rtt_ms / 1000; bdp_bytes = bdp_bits / 8; max_throughput_mbps = min(bandwidth_mbps, window_kib × 1024 × 8 / (rtt_ms / 1000) / 10⁶)`

A TCP sender can have at most one window of unacknowledged data per RTT, so throughput ≤ window / RTT; the window must equal the BDP to saturate the link (RFC 7323 window scaling allows windows up to 1 GiB).

## Data Sources

- Bandwidth-delay product (Wikipedia) — https://en.wikipedia.org/wiki/Bandwidth-delay_product (reference, retrieved 2026-09-24)
- RFC 7323 – TCP Extensions for High Performance (window scaling) — https://www.rfc-editor.org/rfc/rfc7323 (standard, retrieved 2026-09-24)

Data freshness: `static`. Deterministic formula with fixed constants; results never go stale. Inputs supplied by the caller determine the output.

## API

- `GET https://tttkmbb.com/api/v1/calculate/bandwidth-delay-product?bandwidth_mbps=…&rtt_ms=…`
- `POST https://tttkmbb.com/api/v1/calculate/bandwidth-delay-product` with JSON body `{"inputs": {…}}`
- Response: unified envelope (`success`, `request`, `result.values`, `result.units`, `sources`, `freshness`, `timestamp`, `next_actions`, `links`); see https://tttkmbb.com/docs/response-format.md
- Schema: https://tttkmbb.com/api/v1/calculators/bandwidth-delay-product · OpenAPI operationId `calculate_bandwidth_delay_product` in https://tttkmbb.com/openapi.json
- Authentication: none. Rate limit: fair use, see https://tttkmbb.com/docs/rate-limits.md.

## MCP

- Server: `https://tttkmbb.com/mcp` (Streamable HTTP, JSON-RPC 2.0, no auth)
- Tool:  `run_calculator` with `{"calculator_id": "bandwidth-delay-product", "inputs": {…}}`

## Example

- 100 Mbit/s, 50 ms: inputs `{"bandwidth_mbps":100,"rtt_ms":50}` → `{"bdp_bits":5000000,"bdp_bytes":625000,"bdp_kib":610.35,"recommended_window_bytes":625000,"window_scaling_required":true}`
- 100 Mbit/s, 50 ms with a 64 KiB window: inputs `{"bandwidth_mbps":100,"rtt_ms":50,"window_kib":64}` → `{"bdp_bytes":625000,"max_throughput_mbps":10.49,"link_utilization_percent":10.49}`

```
GET https://tttkmbb.com/api/v1/calculate/bandwidth-delay-product?bandwidth_mbps=100&rtt_ms=50
```

## Limitations

You need transfer time for a file (use download-time) or unit conversion of data sizes (use data-storage); the model ignores packet loss and congestion control. A TCP sender can have at most one window of unacknowledged data per RTT, so throughput ≤ window / RTT; the window must equal the BDP to saturate the link (RFC 7323 window scaling allows windows up to 1 GiB). All values are computed from the formula above; no measurement or live data is involved.

## FAQ

**Why is my 1 Gbit/s transfer to another continent so slow?**

With 150 ms RTT the BDP is 18.75 MB; a default 64 KiB–4 MiB window allows only 3.5–224 Mbit/s per stream. Raise the socket buffer limits or use parallel streams.

**Is the RTT the ping time?**

Yes, use the round-trip time reported by ping (or the TCP RTT from ss -i), not the one-way latency.

**What does window scaling do?**

The 16-bit TCP window field caps the window at 65,535 bytes; RFC 7323 multiplies it by up to 2¹⁴, allowing the megabyte windows that fast, long paths need.

## Related

- [Download Time Calculator](https://tttkmbb.com/everyday/download-time.md) — Time to move a file at a given throughput.
- [Data Storage Converter](https://tttkmbb.com/conversion/data-storage.md) — Convert bytes, KiB and MiB.
- [IP Subnet Calculator](https://tttkmbb.com/developer/subnet-calculator.md) — Other network-engineering arithmetic.