- From: Paul Leach <paulle@microsoft.com>
- Date: Fri, 11 Aug 95 14:18:58 PDT
- To: mogul@pa.dec.com
- Cc: blampson@microsoft.com, janssen@parc.xerox.com, jg@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
---------- ] 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
Received on Friday, 11 August 1995 14:19:54 UTC