W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: UDP or TCP

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 11 Aug 95 14:18:58 PDT
Message-Id: <9508112202.AA08593@netmail2.microsoft.com>
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.)

Received on Friday, 11 August 1995 14:19:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC