[vworld-tech] TCP for large bandwidth

[ceo]

Ben Garney wrote:
> Howdy,
> 
> My two bits:
> 
> TCP is great for streamed transfers of data where you don't care too 
> much about latency issues. Most file transfer falls under this. Telnet 
> sessions. Transactions - as TCP is reliable. TCP will scale to pretty 
> much any connection, large or small, though of course, it's not going to 
> be optimally efficient if you're in an odd case. (Too much overhead to 
> be really effective on 300 baud... and it can be a bit conservative if 
> you're running on a multigigabit link... maybe. These are minor nits.) 
> In the world of internet, TCP is the standard solution to getting data 
> from point A to B.

Although it's rarely relevant to games, there are some big dodgy areas 
for TCP on large bandwidth connections (and if games start streaming 
video across the net, it will become very relevant).

First of all, "standard"/vanilla TCP has an inherent bandwidth limit 
that is impossible to break. This is defined by your packet loss and RTT.

Secondly, there are a large number of companies spreading a HUGE amount 
of BS - and even outright lies - about this problem, making it up to be 
much worse than it is. According to their websites, you can't do TCP 
transfers continent-to-continent with more than a few hundred (or, 
according to some, far less) Megabits. This is not true (I've done it 
myself). These companies are selling "alternatives" to TCP, hence their 
marketing BS.

I'm still actively researching this, but talks with the Professor of 
communications at my old university confirm this problem is much less 
bad than is claimed (I can dig out his results if anyone needs them), 
although for a while I was doubting my own sanity - did I really send 
all those files that fast across the Atlantic?. Critically, for low 
packet loss / low RTT (and "low" can get quite high, actually), this 
problem never manifests.

Fundamentally, the problem is that "standard" TCP uses AIMD - i.e. 
linear increase in speed, exponential decrease. For large RTT, the 
linear increase is outpaced by the exponential decrease, and never 
reaches link saturation.

Better, more advanced, TCP implementations theoretically suffer less; 
I'm suspicious that Vegas could handle this without problems (since 
Vegas is designed to replace AIMD with a much smoother adaptive 
behaviour). This is what I'm researching, but I have little time to 
spare for it :( so don't wait for any results from me!

Adam