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.
