UDP or TCP?

    Also, you can more than halve the size of the spec you need to 
    implement by just doing the the UDP version -- which, given that one of 
    the problems with HTTP that everyone talks about is the overhead 
    incurred from opening TCP connections for one-off transactions, seems 
    like a good direction to go.  (If the normal interaction between client 
    and server is idempotent, it will only take one round trip...)

I think there's a misconception here.  Yes, there is some packet
overhead for creating and destroying TCP connections, and the current
one-request-per-connection model is expensive in that respect.

But simply going to UDP is not the answer, because UDP (without
some extra effort) does not offer any congestion-control mechanisms.
Sure, you can layer them on top of UDP, but I suspect that you would
quickly get back to something very similar to TCP.

Since we're discussing what is already the dominant source of packets
in the wide-area Internet, and will surely keep growing, we need to
be very sensitive about how HTTP's design affects WAN congestion.
Otherwise, nobody is going to be very happy.

One major benefit of a persistent-TCP-connection model is that it
allows the packet sources to learn, over sufficiently long periods,
what the congestion state of the network is, and therefore adapt
to it.

I should also point out that the average size of an HTTP retrieval
is well over one packet's worth of data (I don't have the stats handy,
but the number "8 K bytes" sticks in my head from someplace).  This
means that even for a single request per connection, the congestion
control mechanisms of TCP have some chance of being helpful.

Paul, what does DCE RPC do for congestion avoidance and control
in WANs, when it uses UDP?

-Jeff

Received on Thursday, 10 August 1995 10:02:47 UTC