In this section,
we take a close look at UDP, how UDP works, and what it does. The reader
is encouraged to refer back to material in Section 2.1, which includes
an overview of the UDP service model, and to the material in Section 2.7,
which discusses socket programming over UDP.
To motivate
our discussion about UDP, suppose you were interested in designing a no-frills,
bare-bones transport protocol. How might you go about doing this? You might
first consider using a vacuous transport protocol. In particular, on the
sending side, you might consider taking the messages from the application
process and passing them directly to the network layer; and on the receiving
side, you might consider taking the messages arriving from the network
layer and passing them directly to the application process. But as we learned
in the previous section, we have to do a little more than nothing. At the
very least, the transport layer has to provide a multiplexing/demultiplexing
service in order to pass data between the network layer and the correct
process.
UDP, defined
in RFC 768, does just about as little as a transport protocol can do. Aside
from the multiplexing/demultiplexing function and some light error checking,
it adds nothing to IP. In fact, if the application developer chooses UDP
instead of TCP, then the application is almost directly talking with IP.
UDP takes messages from the application process, attaches source and destination
port number fields for the multiplexing/demultiplexing service, adds two
other small fields, and passes the resulting segment to the network layer.
The network layer encapsulates the segment into an IP datagram and then
makes a best-effort attempt to deliver the segment to the receiving host.
If the segment arrives at the receiving host, UDP uses the port numbers
and the IP destination address to deliver the segment's data to the correct
application process. Note that with UDP there is no handshaking between
sending and receiving transport-layer entities before sending a segment.
For this reason, UDP is said to be connectionless.
DNS is an example
of an application-layer protocol that uses UDP. When the DNS application
in a host wants to make a query, it constructs a DNS query message and
passes the message to a UDP socket (see Section 2.7). Without performing
any handshaking, UDP adds header fields to the message and passes the resulting
segment to the network layer. The network layer encapsulates the UDP segment
into a datagram and sends the datagram to a name server. The DNS application
at the querying host then waits for a reply to its query. If it doesn't
receive a reply (possibly because the underlying network lost the query
or the reply), it either tries sending the query to another nameserver,
or it informs the invoking application that it can't get a reply. We mention
that the DNS specification permits DNS to run over TCP instead of UDP;
in practice, however, DNS almost always runs over UDP.
Now you might
be wondering why an application developer would ever choose to build an
application over UDP rather than over TCP. Isn't TCP always preferable
to UDP since TCP provides a reliable data transfer service and UDP does
not? The answer is no, as many applications are better suited for UDP for
the following reasons:
-
No connection
establishment. As we'll discuss later, TCP uses a three-way handshake
before it starts to transfer data. UDP just blasts away without any formal
preliminaries. Thus UDP does not introduce any delay to establish a connection.
This is probably the principal reason why DNS runs over UDP rather than
TCP--DNS would be much slower if it ran over TCP. HTTP uses TCP rather
than UDP, since reliability is critical for Web pages with text. But, as
we briefly discussed in Section 2.2, the TCP connection-establishment delay
in HTTP is an important contributor to the "world wide wait."
-
No connection
state. TCP maintains connection state in the end systems. This connection
state includes receive and send buffers, congestion-control parameters,
and sequence and acknowledgment number parameters. We will see in Section
3.5 that this state information is needed to implement TCP's reliable data
transfer service and to provide congestion control. UDP, on the other hand,
does not maintain connection state and does not track any of these parameters.
For this reason, a server devoted to a particular application can typically
support many more active clients when the application runs over UDP rather
than TCP.
-
Small packet
header overhead. The TCP segment has 20 bytes of header overhead in
every segment, whereas UDP only has 8 bytes of overhead.
-
Unregulated
send rate. TCP has a congestion control mechanism that throttles the
sender when one or more links between sender and receiver become excessively
congested. This throttling can have a severe impact on real-time applications,
which can tolerate some packet loss but require a minimum send rate. On
the other hand, the speed at which UDP sends data is only constrained by
the rate at which the application generates data, the capabilities of the
source (CPU, clock rate, and so on) and the access bandwidth to the Internet.
We should keep in mind, however, that the receiving host does not necessarily
receive all the data. When the network is congested, some of the data could
be lost due to router buffer overflow. Thus, the receive rate can be limited
by network congestion even if the sending rate is not constrained.
Figure 3.6 lists
popular Internet applications and the transport protocols that they use.
As we expect, e-mail, remote terminal access, the Web, and file transfer
run over TCP--all these applications need the reliable data transfer service
of TCP. Nevertheless, many important applications run over UDP rather than
TCP. UDP is used for RIP routing table updates (see Chapter 4 on the network
layer), because the updates are sent periodically (typically every five
minutes), so that lost updates are replaced by more recent updates. UDP
is used to carry network management (SNMP; see Chapter 8) data. UDP is
preferred to TCP in this case, since network management applications must
often run when the network is in a stressed state--precisely when reliable,
congestion-controlled data transfer is difficult to achieve. Also, as we
mentioned earlier, DNS runs over UDP, thereby avoiding TCP's connection-establishment
delays.
Application |
Application-layer protocol |
Underlying transport protocol |
Electronic mail |
SMTP |
TCP |
Remote terminal access |
Telnet |
TCP |
Web |
HTTP |
TCP |
File transfer |
FTP |
TCP |
Remote file server |
NFS |
typically UDP |
Streaming multimedia |
proprietary |
typically UDP |
Internet telephony |
proprietary |
typically UDP |
Network management |
SNMP |
typically UDP |
Routing protocol |
RIP |
typically UDP |
Name translation |
DNS |
typically UDP |
Figure 3.6:
Popular Internet applications and their underlying transport protocols
As shown in
Figure 3.6, UDP is also commonly used today with multimedia applications,
such as Internet phone, real-time video conferencing, and streaming of
stored audio and video. We'll take a close look at these applications in
Chapter 6. We just mention now that all of these applications can tolerate
a small fraction of packet loss, so that reliable data transfer is not
absolutely critical for the success of the application. Furthermore, real-time
applications, like Internet phone and video conferencing, react very poorly
to TCP's congestion control. For these reasons, developers of multimedia
applications often choose to run their applications over UDP instead of
TCP. Finally, because TCP cannot be employed with multicast, multicast
applications run over UDP.
Although commonly
done today, running multimedia applications over UDP is controversial to
say the least. As we mentioned above, UDP has no congestion control. But
congestion control is needed to prevent the network from entering a state
in which very little useful work is done. If everyone were to start streaming
high-bit-rate video without using any congestion control, there would be
so much packet overflow at routers that no one would see anything. Thus,
the lack of congestion control in UDP is a potentially serious problem
[Floyd
1999]. Many researchers have proposed new mechanisms to force all sources,
including UDP sources, to perform adaptive congestion control [Mahdavi
1997; Floyd
2000].
Before discussing
the UDP segment structure, we mention that it is possible for an application
to have reliable data transfer when using UDP. This can be done if reliability
is built into the application itself (for example, by adding acknowledgment
and retransmission mechanisms, such as those we shall study in the next
section). But this is a nontrivial task that would keep an application
developer busy debugging for a long time. Nevertheless, building reliability
directly into the application allows the application to "have its cake
and eat it too." That is, application processes can communicate reliably
without having to succumb to the transmission-rate constraints imposed
by TCP's congestion-control mechanism. Many of today's proprietary streaming
applications do just this--they run over UDP, but they have built acknowledgments
and retransmissions into the application in order to reduce packet loss;
see, for example, [Rhee
1998].
3.3.1: UDP Segment
Structure
The UDP segment
structure, shown in Figure 3.7, is defined in RFC 768. The application
data occupies the data field of the UDP datagram. For example, for DNS,
the data field contains either a query message or a response message. For
a streaming audio application, audio samples fill the data field. The UDP
header has only four fields, each consisting of two bytes. As discussed
in the previous section, the port numbers allow the destination host to
pass the application data to the correct process running on the destination
(that is, the demultiplexing function). The checksum is used by the receiving
host to check if errors have been introduced into the segment. In truth,
the checksum is also calculated over a few of the fields in the IP header
in addition to the UDP segment. But we ignore this detail in order to see
the forest through the trees. We shall discuss the checksum calculation
below. Basic principles of error detection are described in Section 5.1.
The length field specifies the length of the UDP segment, including the
header, in bytes.
Figure 3.7:
UDP segment structure
3.3.2: UDP Checksum
The UDP checksum
provides for error detection. UDP at the sender side performs the one's
complement of the sum of all the 16-bit words in the segment. This result
is put in the checksum field of the UDP segment. Here we give a simple
example of the checksum calculation. You can find details about efficient
implementation of the calculation in the RFC 1071 and performance over
real data in [Stone
1998 and Stone
2000]. As an example, suppose that we have the following three 16-bit
words:
0110011001100110
0101010101010101
0000111100001111
The sum of first
of these 16-bit words is
0110011001100110
0101010101010101
1011101110111011
Adding the third
word to the above sum gives
1011101110111011
0000111100001111
1100101011001010
The 1's complement
is obtained by converting all the 0s to 1s and converting all the 1s to
0s. Thus the 1's complement of the sum 1100101011001010 is 0011010100110101,
which becomes the checksum. At the receiver, all four 16-bit words are
added, including the checksum. If no errors are introduced into the packet,
then clearly the sum at the receiver will be 1111111111111111. If one of
the bits is a zero, then we know that errors have been introduced into
the packet.
You may wonder
why UDP provides a checksum in the first place, as many link-layer protocols
(including the popular Ethernet protocol) also provide error checking.
The reason is that there is no guarantee that all the links between source
and destination provide error checking--one of the links may use a protocol
that does not provide error checking. Because IP is supposed to run over
just about any layer-2 protocol, it is useful for the transport layer to
provide error checking as a safety measure. Although UDP provides error
checking, it does not do anything to recover from an error. Some implementations
of UDP simply discard the damaged segment; others pass the damaged segment
to the application with a warning.
That wraps up
our discussion of UDP. We will soon see that TCP offers reliable data transfer
to its applications as well as other services that UDP doesn't offer. Naturally,
TCP is also more complex than UDP. Before discussing TCP, however, it will
be useful to step back and first discuss the underlying principles of reliable
data transfer, which we do in the subsequent section. We will then explore
TCP in Section 3.5, where we will see that TCP has its foundations in these
underlying principles. |