Re: UDP or TCP?

On Thu, 10 Aug 1995, Jeffrey Mogul wrote:

> For example, while it is true that inline images might be partially
> rendered faster if the transport protocol doesn't try to preserve
> ordering, except on very slow clients I can't imagine that latency
> for full rendering of an image would be significantly improved by
> out-of-order delivery.

It does make a visible difference (and not just in the sniffer window :-) 
I see this effect all the time, when the rendering stops halfway down, 
then suddenly shoots ahead when the lost packet and all it's followers 
are delivered at once

> That is, we should think of HTTP as a way to move non-realtime objects
> from place to place, and develop other mechanisms (such as the
> work being done in the context of the MBone) for providing real-time
> connectivity.  The Web is great, but that doesn't mean it should be
> coerced to do everything.

(If I were in emacs, I'd convert that entire region to upper case, bold 
italics with symphonic accompaniment. This is absolutely key.)

More and more, I'm starting to thing of HTTP* not so much as 
a transport protocol but as a hypermedia control protocol that also 
transfers data. For shipping around bulk data that needs reliable 
delivery, it's hard to do much better than TCP (T/TCP + Window scales 
excepted.), as long as the connection is re-used. What I'm arguing here 
is that most web traffic by volume has different, sometimes weaker 
requirements than those provided by TCP. This can be used to give 
improved performance *AND* improved congestion characteristics. 

For example, adapting transmission rates to the rate at which packets are 
being sucesfully delivered to the recipient, rather than the rate at 
which acks are received at the sender can give finer grain congestion 
control by preventing phenomena such as ack compression. Not 
retransmitting every lost packet saves bandwidth, and makes routers with 
random drop less painful. Smart use of latency changes can even be used 
to predict congestion before it occurs (jitter is pretty much a function 
of changes in queue length along the path- a steady increase in latency 
implies a queue that's filling up). 

A lot of the work that's been done for the mbone can be reused here; RTP 
and to a lesser extent RTCP can be borrowed wholesale. 

In summary:

	Using something other than TCP for basic HTTP operation on HTML 
files, or other similar object types is almost always a lose (unless you 
reimplement TCP from scratch). Using specialised transports for 
specialised media can be a tremendous win.

Simon

Received on Thursday, 10 August 1995 16:31:33 UTC