- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Dec 94 16:29:56 PST
- To: John Franks <john@math.nwu.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I don't see this as a very big problem. We have lost one roundtrip
time, but only a roundtrip between client and proxy. In normal use
client and proxy are very close with low latency. I don't think this
is a very big price to pay.
It is not always the case that client and proxy are close. In fact,
sometimes it's quite the opposite.
For example, Digital has two or three proxies that I know of. These
are all located in parts of the company that are "well-connected"
to the Internet. So the proxies are usually fairly close to the
servers.
However, the clients for these proxies are spread out all over Digital,
which is a world-wide company. And in many parts of the world outside
the US, our internal networks are not as well-connected as they should
be (after all, high-bandwidth transoceanic lines aren't cheap, and
satellite links are intrinsically high-delay). So we indeed have
many clients that are hundreds, even thousands, of milliseconds away
from their proxies.
There is an important principle to keep in mind here. Any proposal
that can't at least match the user's perceived performance which
Netscape obtains with multiple connections is not viable. It's a
competitive world out there and browser writers will have to go with
multiple connections if nothing else matches their performance. Any
proposed standard, MGET or stay-open, which can't measure up to
multiple connection performance just won't be implemented.
I would turn this around and say that any proposal that doesn't scale
as well as persistent-connection HTTP is not viable. It will sooner
or later collapse under its own weight. Sure, the Netscape approach
makes the browsers seem a little faster, but only as long as the
server and network have lots of excess capacity. When this is not
true, multiple connections could be a disaster.
Even the original single-connection HTTP model is likely to cause
trouble; it's not really Netscape's fault.
Anyone who tried to use the Internet before widespread adoption of
Van Jacobson's TCP congestion-avoidance mechanism will appreciate the
relative virtues of scalability and greediness.
-Jeff
Received on Tuesday, 20 December 1994 16:37:05 UTC