Daniel Roesen added: > On Mon, Nov 08, 2004 at 01:12:23PM -0500, Uday Kumar Reddy wrote: > > > So the aim of seperating trackers is not avoiding small bandwidth links, > > > but high RTT (delay) links, which directly affects TCP performance. > > > > I understand what you are saying. But, isn't it that the link delay > > doesn't matter for large transfers? For large transfers, the link > > delay is just reflected as the startup time. So, an 'n' mbps link > > whether it is transatlantic or close-by would almost take the same > > time to transfer data for _large_ files/streams. > > No, this is wrong, exactly the other way 'round. > > TCP has a concept of "windowing" where it limits the amount of data > which can be in-flight without having received an ACKnowledgement of > receipt from the receiver. The window is initially very small and grows > larger over time. This is the so-called "slow start". The window > doesn't grow infinite though, so you you'll arrive at some maximum > size. Let it be 16K, 32K, 64K... depending on OS, version etc. Now > you can calculate how much unACKed data can be "on wire" on a given > latency link at once and thus calculate the maximum theoretically > possible throughput of that link which is characterized by the latency. Thats the problem with fast links! I don't remember how fast the link has to be before its an issue, but at some point the max window size does not allow the pipe to maintain its fullness before the sender has to stop and wait for an ack. TCP was designed for low speed links. Some of these LANs and WANs are _no longer_ 'low speed'. :-(