this was sent to me personally but seems generally relevant.
There is at least one case where multiple connections will be faster, and I suspect there are actually several.
tcp without congestion avoidance is always faster than tcp with congestion avoidance. whether you take away congestion avoidance by running lots of short lived connections in parallel, or whether you actually dyke out the code that avoids congestion, the result is the same: other tcp's will back off and give you more of the channel. this is another example of a cooperative protocol suite trying to survive in a competitive world. that tcp only behaves well if all other tcp's behave well, where "behaves well" means "shares paths fairly" creates an automatic incentive on the part of some designers to not "behave well" so they can get more than their fair share. this feeds directly into arguments about flat rate, peering, open smtp relays, checking of source addresses on egress gateways, and the rest of the usual nanog chatter.
[there is a] paper on TCP performance over satellite links (really any long-fat-pipe), and [there is] a lot about TCP performace I would have never expected. One of the simpler ideas is the "TCP speed limit". You must have buffer space that is greater than the bandwidth * delay product to keep the pipe full.
yes. this is why we have a window scale tcp option now. and this buffer requirement is per end-host, whether there are multiple tcp sessions or just one.
On very high delay links (satellite) or very high bandwidth (OC-3/OC-12 to the desktop) current workstations don't allocate enough buffers, either system wide or per-connection.
at least one satellite ip provider is evaluating transparent caching as a way to obviate these effects by aggregating dumb-client connections into something smarter for the sky link.
So, if you have a system with per-connection bufffering, and that hits a "speed limit" of 512 kbits/sec over your satellite T1, you can raise the speed up to the full T1 by opening 3 streams. Thus more connections == faster downloads.
it's still the same amount of buffering per end host though.
... The same group ... did some satellite testing, trying a parallel FTP client they had. They benchmarked 1, 2, 4, 8, and 16 streams between two SunOS 4 boxes over a T1 satellite (500ms RTT). Maximum performance (shortest transfer time) was achieved with 4 TCP streams.
that's got more to say about the sunos tcp implementation than about tcp as a protocol.
I'll throw in one more subjective measure. When Netscape first came out some of the CS people at Virginia Tech wondered about the perception, and did some tests with willing college student subjects using Mosaic (which at the time supported HTTP keepalives, and used them to connect to the server once for all transfers) and Netscape (multiple connections, no keepalives). ... On the more complex pages Mosaic downloaded and displayed the page faster, in wall clock time, but the users always preferred Netscape. The observation is that many people don't wait for a full download, they click on picture links, for instance, when they are half down....so having them all half down allows someone to proceed with browsing, rather than having half fully there, and half not visable.
which means the server gets a lot of RSTs and a lot of data which is committed into the path ends up being thrown away. seems like if we wanted things to go faster, we would waste less bandwidth by sending only data which was useful and not creating a huge number of retrans- missions by effectively turning off tcp congestion avoidance.
... - I would suspect that two connections with keepalives would be optimum....you get multiple stream advantages, minimize load on the server, and can drive those two connections fast (past slow-start) as they are long lived.
i agree. too bad the browser manufacturers are driven by competition rather than cooperation. of course, human nature has in this case created a product opportunity in transparent caching.