Note: Many topics at this site are reduced versions of the text in "The Encyclopedia of Networking and Telecommunications." Search results will not be as extensive as a search of the book's CD-ROM.

The TCP/IP protocol stack pictured in Figure U-1 consists of a best-effort network layer protocol (IP) and a reliable transport layer protocol (TCP). Reliable services can ensure that packets are delivered to a host in the correct order (e.g., if a packet is dropped, TCP can arrange to resend it, as opposed to relying on IP and the network layer to resend it). TCP also supports flow and congestion controls. Best-effort services simply deliver packets. UDP sits next to TCP in the transport layer of the protocol stack, but provides fewer services than TCP. Both TCP and UDP use IP for packet delivery.

When applications developers create programs for TCP/UDP/IP networks, they can choose TCP or UDP at the transport layer. The main difference is that TCP provides reliability and congestion control services, while UDP trades off those services to improve performance. A comparative list of TCP/UDP functions is provided later. Most applications use TCP because reliability is crucial. For example, FTP uses TCP to ensure that an exact copy of a file is delivered to the recipient. Multimedia applications use UDP because they can tolerate some loss, as discussed later. Actually, multimedia applications typically run RTP (Real-time Transport Protocol) on top of UDP. RTP is a service for controlling the transmission rate of real-time multimedia.

The most important thing that TCP and UDP share in common is the ability to establish a host-to-host communication channel for delivering packets between processes running in two different computers. In other words, these protocols provide a way for two applications to communicate. Therefore, they are end-to-end protocols.

When a user accesses a Web site, one or more temporary sessions are established between client and server applications in order to exchange packets. One session might be opening a Web page while another downloads a file. When more than one session is established, packets from those sessions are "multiplexed" across the same link. Some method is needed to differentiate the packets of one session from the packets of another.

Both TCP and UDP use ports and port numbers to identify application protocols. For example, Web services (HTTP) use port 80, FTP uses port 21, and Gopher uses port 70. A typical session involves sending packets from a source IP address and port to a destination IP address and port. TCP and UDP packet headers contain source and destination port address information. These packets flow between the applications at either end of the connection. Therefore, they are often called "flows." Many QoS techniques identify these flows (by looking at port addresses in packets) and give flows a particular quality of service.

The UDP header, pictured next, illustrates how port addressing is the primary function of UDP. The header is mostly port-addressing fields. Compare this to the TCP header in Figure T-3. A checksum is used to detect corrupted packets. If an application requires more reliable service than this, TCP or supplemental protocols must be used.

The endpoint of a connection is called a socket. It consists of a host's IP address and a port number. Therefore, a socket identifies a specific application running on a specific computer and is the endpoint of a connection. How does a client know which port to use when initially forming packets to send to a server? The usual method is to connect with well-known ports. These are published in RFC 1700 (Assigned Numbers, July 1992). While ports are predefined, sockets do not exist until a connection is established. Multiple connections may use the same port number, but each connection is differentiated by the local and remote addresses associated with that connection.

Here is a comparison of the most important services offered by TCP and UDP:

As mentioned, UDP minimizes delays for real-time traffic. The primary objective is to deliver packets on time. At the same time, some amount of packet drop is acceptable. For example, a single dropped packet in a video stream may not be detectable to a viewer, but attempting to recover the packet may cause delays that are detectable. About 5 percent of the packets in a voice stream can be dropped without detection. With multimedia traffic, speed is more important than reliability, and that is why application developers choose UDP.

Applications using UDP must provide some form of flow control on their own. For example, if a videoconferencing application notices that packets are being dropped, it may dynamically increase the compression ratio (and thus reduce quality) or drop packets on its own in a controlled way to match available bandwidth on the network, while still providing quality that it considers reasonable. It does not rely on UDP for this, and using TCP for flow and congestion control would be inefficient.

In fact, most real-time applications have their own special flow-control requirements that the generic control provided by TCP cannot provide. Basically, UDP-based real-time applications must be "self-regulating." RTP can rely on RTCP (Real-time Control Protocol) to control transmission rates when packets are dropped. RTCP is a feedback mechanism that helps real-time applications work within the available bandwidth of the network.

Keep in mind that real-time applications that use UDP will still attempt to grab network bandwidth, possibly causing congestion in the network. While real-time applications may be able to control the flow between end systems, they do nothing to prevent flows from congesting the network. That is a traffic management issue, as discussed under "Traffic Management, Shaping, and Engineering." Refer to RFC 768 (User Datagram Protocol, August 1980) and RFC 1180 (A TCP/IP Tutorial, January 1991) for more information about UDP.

David P. Read, one of the people involved in the design of the TCP/IP protocols, writes in "The End of the End-to-End Argument" that by splitting the Internet protocols into two protocols (TCP and IP), the network was "decentralized" and turned into a basic datagram-forwarding network. In this model, end systems handle functions that were previously handled by networks, such as flow control, acknowledgments, and retransmissions. By splitting the protocols, it was necessary to create UDP for applications that needed to bypass TCP's services.

Copyright (c) 2001 Tom Sheldon and Big Sur Multimedia.
All rights reserved under Pan American and International copyright conventions.