Bandwidth-delay product and TCP window scaling

Throughput is limited to one window of data per round trip.

Worked answer.

(a) Bandwidth-delay product (BDP)
BDP is the amount of data that must be "in flight" to keep the link fully busy.

• BDP = bandwidth × RTT = 100 × 10^6 bits/s × 0.080 s = 8 × 10^6 bits.
• In bytes: 8 × 10^6 ÷ 8 = 1 × 10^6 bytes ≈ 1 MB.

So the sender needs a window of about 1 MB to use the full 100 Mbps.

(b) Throughput with a 65,535-byte window
A sender can transmit at most one window of data per RTT, then must wait for acknowledgements.

• Window in bits = 65,535 × 8 = 524,280 bits.
• Max throughput = 524,280 bits ÷ 0.080 s = 6,553,500 bits/s ≈ 6.55 Mbps.

That is only about 6.55% of the link's capacity (6.5535 ÷ 100), no matter how fast the link is.

Cross-check: the window is 65,535 ÷ 1,000,000 ≈ 6.55% of the BDP, and utilisation equals window ÷ BDP when the window is smaller than the BDP — the two results agree.

(c) Removing the limit

• The original TCP header has a 16-bit window field, hence the 65,535-byte cap.
• The window scale option (originally RFC 1323, now RFC 7323) is negotiated in the SYN and SYN-ACK. It specifies a shift count (0–14), so the effective window = advertised value × 2^shift, allowing windows up to about 1 GiB.
• Here a shift of at least 4 is needed: 65,535 × 2^4 = 1,048,560 bytes ≥ 1,000,000 bytes. (A shift of 3 gives only 524,280 bytes.)
• The receiver must also have buffers large enough; operating systems auto-tune socket buffers, but limits can still cap throughput.
• The congestion window must also grow to the BDP, which takes several RTTs of slow start.

Common follow-up: "The link is 100 Mbps but a single download gets about 6 Mbps while multiple parallel downloads do better — why?" Each connection is window-limited per RTT, so parallel connections multiply the total in-flight data. This "long fat network" effect is why high-RTT paths (e.g. India to the US) need large windows.