Throughput on a Long Fat Path
A Singapore server streams a 20 MB file to a Frankfurt client over a 200 Mbps path with one-way propagation delay 35 ms and no configured queue bottlenecks. The TCP receiver advertises a 64 KiB window and the sender uses 1460-byte segments. The team measures about 7.5 Mbps and a transfer time near 21 s, and blames packet loss. Packet captures show retransmissions below 0.01%, and the bottleneck queue is shallow but not full. The operating system supports TCP window scaling, but it is disabled on both hosts. The application reads from the socket in 64 KiB chunks every 10 ms. The team asks whether loss is the cause, whether the application is the cause, and what to change. Assume a 70 ms round-trip time.
1. Compute the bandwidth-delay product and the window-limited throughput. Does the observed 7.5 Mbps support the loss explanation?
Read the worked answer
The bandwidth-delay product is 200 Mbps x 0.070 s = 14 Mbit = 1.75 MB. A 64 KiB window is 524,288 bits, so the window-limited throughput is 524,288 / 0.070 = 7,490,000 bits/s, about 7.49 Mbps. That matches the observed 7.5 Mbps almost exactly. Since retransmissions are below 0.01%, loss cannot explain a 26x shortfall from 200 Mbps; the sender is simply not allowed enough in-flight data. The path is a long fat network: the receiver window is far below the BDP, so TCP spends most of each RTT waiting for acknowledgements. The fix is not retransmission tuning but a larger window and larger socket buffers.
2. The application reads 64 KiB every 10 ms. Is the application the bottleneck? What if it instead read 1 KiB every 20 ms?
Read the worked answer
64 KiB every 10 ms is 6.4 MiB/s, or about 53.7 Mbps, which is well above the observed 7.5 Mbps, so this read pattern is not the bottleneck. The socket receive buffer may still fill if its size is small, but the dominant limit is the 64 KiB advertised window. If the application instead read 1 KiB every 20 ms, that is 50 KiB/s, about 0.41 Mbps, well below 7.5 Mbps. In that case the application would become the bottleneck because the receive buffer would stay full and the advertised window would shrink toward zero. The judgement depends on comparing the drain rate with the network rate, not on assuming that any slow-looking read loop is the cause.
3. Recommend changes and compute the expected transfer time for the 20 MB file after the fixes.
Read the worked answer
Enable window scaling and raise the receive and send socket buffers to at least the BDP, for example 2 MiB. A scaling factor of 5 multiplies 64 KiB by 32, giving 2 MiB, which exceeds the 1.75 MB BDP. With a 2 MiB window, the path can keep 200 Mbps in flight, so the transfer becomes bandwidth-limited. 20 MB is 160 Mbit; at 200 Mbps that is 0.8 s of transmission time. Add roughly one RTT for connection and protocol startup, about 0.07 s, giving an expected time near 0.9 s, plus modest TCP and application overhead. The application read rate of about 53.7 Mbps would then become a secondary limit; to sustain 200 Mbps, it should read larger blocks or use a dedicated drain loop. The main conclusion is that window scaling, not loss recovery, is the required change.