TCP BDP & Linux sysctl Window Tuning Calculator

Calculate exact Bandwidth-Delay Product (BDP), RFC 7323 TCP Window Scale shift factors, Mathis packet-loss throughput ceilings, and production Linux /etc/sysctl.d/ BBR socket buffer parameters for high-latency WAN and cross-region cloud links.

Bandwidth-Delay Product & Throughput Bottleneck Analysis

Ready-to-Deploy Linux Kernel Tuning (/etc/sysctl.d/99-netdevkit-tcp.conf)

Why Long Fat Networks (LFNs) Throttle Single-Stream TCP Without BDP Tuning

In TCP congestion and flow control, the Bandwidth-Delay Product (BDP) measures the exact volume of unacknowledged data ("bytes in flight") that must exist simultaneously inside the network pipe to keep a link 100% saturated while waiting for an acknowledgment (ACK) to return across the round-trip time (RTT). Expressed mathematically, BDP (bytes) = (Bandwidth_bps × RTT_seconds) / 8.

Original RFC 793 TCP headers allocated only a 16-bit Receive Window field, capping unscaled in-flight bytes at 65,535 bytes (64 KiB). Over an 85 ms transatlantic path between us-east-1 and eu-central-1, a 64 KiB window limits a single SCP, rsync, PostgreSQL replication stream, or S3 upload to barely 6.17 Mbps—even on a 10 Gbps NIC! RFC 7323 TCP Window Scaling resolves this by negotiating a bit-shift multiplier (up to 2^14, or 1 GiB max window) during the initial SYN handshake, provided the Linux kernel's net.core.rmem_max, net.core.wmem_max, and net.ipv4.tcp_rmem auto-tuning ceilings are raised high enough to hold at least 2 × BDP.

Equally critical on transoceanic WANs is congestion control: traditional loss-based algorithms like CUBIC halve their congestion window on random shallow-buffer packet drops (governed by the Mathis equation), whereas Google's TCP BBR paired with Fair Queue pacing (fq) models actual bottleneck bandwidth and minimum RTT to sustain near-line-rate throughput even under minor packet loss.