Re: UDP or TCP?

At 2:25 PM 8/10/95, Simon Spero wrote:
>Jeff is right on the money here- however there are a few interesting
>points that affect the decision as to which transport to use for general
>HTTP transactions.
>
>The key point to note is that the vast bulk of data currently transferred
>over HTTP has transport needs that don't correspond to the features
>offered by TCP, and using strategies can greatly improve performance and
>congestion characteristics.
[...]
>Real Time Transport protocols.
>
>A better approach for these particular media types is to use some sort of
>Real Time Protocol, such as RTP. These protocols provide feedback to the
>application as to the bandwidth available, latencies and jitters,
>together with an indication of the rate of data loss. Although RTP isn't
>a transport protocol in itself, transport protocols can be build on top
>of it by using the information provided to do limited re-transmission
>where applicable, and to do some sort of rate based congestion control
>(e.g., clock packets out at the same rate the receiver receives them,
>  treat increased jitter as a sign of router queue instability, etc)

I'm skeptical that rebuilding quasi-reliable protocols on top of UDP or
some such is a good idea for long-haul transport. It also making writing
clients a lot more work, as I recall this was a problem that limited the
development of "archie" clients.

Another consideration is that people administering firewalls seem to hate
UDP because its lack of state makes filtering less reliable.

Does IPNG or any of the protcol designs related to ATM networking address
any of these issues? (I'm thinking if we can let someone else re-enginer
the lower parts of TCP/IP it could save some work.)

---
    Albert Lunde                      Albert-Lunde@nwu.edu

Received on Thursday, 10 August 1995 14:44:06 UTC