4 ms·
It's pretty much impossible to saturate even a LAN connection with a single TCP connection. The are a number of issues at play here — RTT (Round Trip Time, i.e.
by tav 16y ago
It's pretty much impossible to saturate even a LAN connection with a single TCP connection. The are a number of issues at play here — RTT (Round Trip Time, i.e. ping/latency), window sizes, packet loss and initcwnd (TCP's initial window).
The combination of the limitations imposed by the speed of light and TCP's windowing system means that you are buggered transferring large files over high-latency TCP connections. I haven't checked their figures, but here's a TCP rate calculator I just found which lets you tune the different parameters: http://osn.fx.net.nz/LFN/ http://osn.fx.net.nz/LFN/
The greater the delay, the bigger the impact. For example if we take a standard Windows XP machine and plug in the values for a standard Gigabit LAN (typically .2ms latency between hosts) we get a maximum speed of 700Mbit/sec, but if we try if between two hosts, one of them in the USA (typically around 120ms) the maximum transfer rate falls to 1.17 Mbit/sec.
There are a number of attempts trying to fix TCP's failings in this regard. For starters, see this presentation by the Google/SPDY guys making a case for changing TCP Slow Start: http://www.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf http://www.chromium.org/spdy/An_Argument_For_Changing_TCP_Sl... — here's the IETF Draft for increasing TCP's Initial Window http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd
And, more radically, see the uTP work by the Bittorrent folk who are trying to create a better alternative to TCP instead of simply fixing it — http://en.wikipedia.org/wiki/Micro_Transport_Protocol http://en.wikipedia.org/wiki/Micro_Transport_Protocol + https://github.com/bittorrent/libutp https://github.com/bittorrent/libutp (source code).
Anyways, sorry for not going into too much detail (it's 4am), but hope I was able to clear things up a little.
- neilc 16y agoThe are a number of issues at play here — RTT (Round Trip Time, i.e. ping/latency), window sizes, packet loss and initcwnd (TCP's initial window). Initial window size: not relevant AFAICS, I'm not talking about connection startup behavior. RTT, Window size: if the bandwidth-delay product is large, obviously you need a large window size (>>65K). Thankfully, recent TCP stacks support TCP window scaling. Packet loss: you need relatively large buffers (by the standards of traditional TCP) and a sane scheme for recovering from packet loss (e.g., SACK), but I don't see why this is a show stopper on modern TCP stacks. I'm not super familiar with the SPDY work, but from what I recall, it primarily addresses connection startup behavior, rather than steady-state behavior.
- nkurz 16y agoIn theory you should be right, and yet in practice it seems to be a problem. Here's a recent exchange that offers some real life numbers: http://serverfault.com/questions/111813/what-is-the-best-way-to-transfer-a-single-large-file-over-a-high-speed-high-late http://serverfault.com/questions/111813/what-is-the-best-way...