Re: UDP or TCP?

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.

Inline images:
	
Inline images have two properties that make a non-tcp transport 
desirable.
	
	1) Out-of-Order reassembly: Images are in general 2-dimensional 
	(pace, Pesce :). If messages are labelled, they can be rendered 
	immediately upon arrival, regardless of whether preceding messages 
	have been successfully delivered. Because TCP provides ordered 
	delivery, if a single packet is lost, no data can be delivered to 
	the application until that packet is successfully retransmitted 
	and received.

	2) Some data loss is acceptable: Because the human eye and brain 
	are designed to work with partial data, images can be 
	reconstructed sucesfully even if some data is missing. Thus, 
	not every lost packet needs to be re-transmitted. This effect is 
	most noticeable if the data is ordered so as to minimise the 
	number of adjacent pixels contained in a single message. 
        TCP is a reliable transport service - if a message is lost, the 
	sender will re-transmit it after a timeout. 

Audio data:

	1) Audio data is linear, and real time: If a message containing 
	audio data fails to arrive within a given window, it has missed its
	chance and is no longer wanted. Retransmission is not helpful- 
	the only way to deal with data loss is via regeneration from 
	other packets (I think Christian has done some work on this?)

	2) Audio data rates are adaptable: If the bandwidth available to 
	the sender decreases, the data rate can be reduced by increasing 
	compression ratios (MPEG), or by switching to a different 
	encoding scheme (ADPCM, etc). TCP does not make bandwidth information
	available to the application, and does not allow data that has been
	sent but not delivered to be recalled. 


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)

Simon

Received on Thursday, 10 August 1995 14:28:18 UTC