----------
] From: Jeffrey Mogul <mogul@pa.dec.com>
] To: Paul Leach
] Date: Friday, August 11, 1995 11:48AM
]
]
] Will someone please try to explain why we need something besides
] TCP? In particular, what problem is RPC intended to solve?
]
] The "excess overhead packets" problem melts away with persistent
] connections; the extra 6 or 7 packets and one RTT are quickly
] amortized by the high locality of requests.
I agree that if there are persistent connection and enough locality
then connection overhead will be a non-problem.
Here are the reasons I still think about alternatives to TCP:
I suspect that locality might not be as high as (say) with distributed
file systems -- the hyperlinks can jump you all over the place. I'd
love to see data; I could be easily convinced otherwise.
Also, there's a situation I believe will arise that may reduce
locality. If proxy caches are in widespread use, then many/most hits
will be to the proxy caches, and lots of the traffic that gets onto the
net will be conditional gets for cached pages whose TTL has expired.
Much of the locality will be absorbed by the caches if the TTLs of
pages from the same server are uncorrelated. If I had a good set of
traces I could simulate this and see if the hypothesis was true.
Another question I have is, once we make the TCP connection persistent,
how well TCP implementations work if there are servers that now have
10s of thousands of open connections. Your HotOS paper points out the
problems with short lived connections; many (but not all) of them would
seem to be exacerbated by longer lived connections (buffer space and
PCB problems, e.g.).
I will agree in advance that there is nothing that would prevent any of
these problems with TCP implementations from being fixed -- even the
connection overhead (I've been told that there are experimental
implementations where the extra connection overhead is piggybacked on
initial data packets). However, since TCP is in most people's kernel,
it's harder to get such a fixed implementation deployed than a
semantically identical protocol layered on top of UDP embodied in an
HTTP server.
(Maybe if we could fix our servers so that clients that were using such
a more net-friendly TCP to the head of the service queue, then that
might be incentive enough to cause the problem to be fixed.)
Paul