Q: Your latency between London and Tokyo (transcontinental WAN link) is high on a single large file transfer (scp, 50GB file). Speedtest shows 10 Gbps available, but SCP maxes out at 150 Mbps. The link is 99% idle. Why is TCP not filling the available bandwidth, and what is the root cause?

This is a classic TCP Window Size limitation over high-latency links. TCP's congestion window grows slowly, and it's fundamentally designed for Local Area Networks (LAN latency ~1ms), not intercontinental links (~150ms RTT).

• SCP sends ~2MB per window, then waits 150ms for ACK before sending more.
• In 150ms of waiting, the pipe sits idle. The bandwidth is *available*, but TCP isn't using it due to the window limitation.
• Increase TCP Window Size (Quick fix):
• Use a faster transfer tool (Better):
• bbcp (Big Brother Copy): Custom protocol that opens multiple parallel TCP streams and handles congestion better over WAN.

Root Cause Math: TCP's maximum throughput is: Throughput = (TCP_Window_Size / RTT) London-Tokyo RTT ≈ 150ms (150,000 microseconds). Default TCP window on Linux: 64KB. Max throughput = 64KB / 0.15s = 3.4 Mbps Why SCP only achieves 150 Mbps instead of 10 Gbps? Solutions: This allows the window to scale up dynamically (RFC 7323 TCP Window Scaling). New calculation: Max = 64MB / 0.15s = 3.4 Gbps (closer to the available 10 Gbps). Lesson: WAN performance is fundamentally about RTT and window size, not raw bandwidth. A 10 Gbps link with 150ms latency can transfer ~3.4 Gbps max unless you increase the window.

sysctl -w net.ipv4.tcp_rmem='4096 87380 67108864'  # 64MB max
   sysctl -w net.ipv4.tcp_wmem='4096 65536 67108864'  # 64MB max

• perfsonar: Network tuning tool that automatically adjusts window sizes and buffer for your specific latency.
• rclone: Transfer tool designed for cloud workflows, handles retries and multi-part uploads.
• Enable TCP Fast Open + SACK (Modern):
• UDP-based alternatives: For non-reliable-delivery systems, use QUIC (HTTP/3) or custom UDP, which don't have the ACK-window bottleneck.