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/

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_Sl... — here's the IETF Draft for increasing TCP's Initial Window 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 + 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.

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.