[e2e] Number of persistent connections per HTTP server?

[Jim.Gettys at hp.com]

Dave,

The prime motivation of the HTTP connection limit is a bit different
than is being discussed.

There are many small objects in the web (silly tiny gifs, etc), and
once cached, the HTTP protocol validation requests are small ("please
send me this URL if it has changed").

So HTTP 1.0 without persistent connections, running with 4 connections,
was essentially making a tiny request (~120 bytes), getting a small or
tiny reply (100-1000 bytes), and throwing the TCP connection away.
None of TCP's congestion mechanisms had a chance to come into play.
There was lots of data to show that HTTP/1.0's behavior was causing
congestion all over the internet (to the point that we succeeded
in getting Metcalf to literally "eat his words" on stage :-)).

In effect, most packets being sent by web software were therefore
*NOT* congestion controlled, and TCP was never being operated in the
regime it was intended for (relatively long lived, congestion controlled
connections).

So the attempt in the HTTP/1.1 spec is to get better behaviour out of
clients. Our paper showed that if you bother to implement HTTP/1.1 properly
(unfortunately non-tivial given how clients were/are structured, though
easy for servers) that this would also improve performance, while helping
the net  as a whole out.  At the time, congesion caused by HTTP/1.0 was
a serious problem (this is probably less true today with the advent
of other media and P2P protocols consuming alot of bandwidth).

If you left the # of connections at 4, many handshakes with web servers
would never get out of slow-start: by going to 2 or 1, you'll get up the
slowstart curve.  And ironically, pipelining, by collapsing multiple
packets into one, works against you in this process, so as soon
as you do pipelining, it becomes *more* important to reduce the number
of connections.

In general, our attitude was/is that if a client really needs additional
connections (and remember, it may be talking to many web sites at once),
this is fine; but not if TCP doesn't get a chance to work properly.

So discussing ways that congestion control can be improved is clearly
on topic for this list.  For example, current implementations/algorithms
are based on the TCP connection, rather than the client/server pair
that might make more sense (and make multiple connections between end-pairs
much "safer" for applications developers to use).
				- Jim

--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
Jim.Gettys at hp.com