Download Speed Communications for Selected Applications with UDP For

Speed Communications for Selected Applications with UDP
For applications like streaming video that offer real-time validation, user datagram protocol
(UDP) can provide a fast, low-overhead option to TCP.
by John Carbone, Express Logic
In today's world of connected devices, smartphones upload photos to servers in the cloud, car
rental agencies check in your rental upon your return, you can purchase in-flight meals using
your credit card, and doctors access vital signs of patients across town—or around the world.
While such machine-to-machine (M2M) communication is performed over the Internet, and
generally uses the popular transmission control protocol (TCP), what you may not realize is that
many other M2M communications utilize user datagram protocol (UDP) and communicate at
rates that would be unachievable using TCP. In fact, UDP can be very advantageous for many
embedded M2M system requirements and might be worth consideration in your next design.
TCP/IP is a layered protocol, which means more complex protocols are built on top of simpler
underlying protocols (Table 1). In TCP/IP, the lowest layer protocol is at the link level and is
handled by the network driver. This level is typically targeted toward Ethernet, but it could also
be fiber, serial, or virtually any physical media. On top of the link layer is the network layer. In
TCP/IP, this is the IP, which is basically responsible for sending and receiving simple packets—
in a best effort manner—across the network. Management type protocols like ICMP and IGMP
are typically also categorized as network layers, even though they rely on IP for sending and
receiving.
The transport layer rests on top of the network layer. This layer is responsible for managing the
flow of data between hosts on the network. UDP operates within the transport layer, along with
TCP, DCCP, SCTP, RSVP and others, since, as the name implies, these protocols are used to
move data from sender to receiver. In particular, two general transport services are commonly
used by M2M applications: UDP and TCP:


UDP services provide best-effort sending and receiving of data between two hosts in a
connectionless manner;
TCP provides connection management between two host entities with a reliable data path
between them.
The UDP protocol is the "poor sister" of the Internet, not getting much media love, while TCP
soaks up all the attention. But UDP operates with far less overhead, and can run rings around
TCP. While each is a general purpose protocol, and TCP is more widely known and used, many
Internet applications use UDP, including the Domain Name System (DNS), simple network
management protocol (SNMP), routing information protocol (RIP) and dynamic host
configuration protocol (DHCP). And, did you know that most voice and video traffic is generally
transmitted using UDP? To understand why, and to determine whether it is a good fit for your
M2M system, we need to introduce some fundamental characteristics of each protocol and show
how those characteristics make one protocol better than the other for a given application.
Transmission Control Protocol (TCP)
TCP is a widely used protocol for Internet traffic. It enables applications to send data from one
system to another, across arbitrary distances, through an arbitrary number of intervening
machines. Indeed, the sender does not need to know where the receiver is, or how to get to it.
Those critical functions are taken care of by other aspects of the Internet protocol.
TCP provides reliable data transfer between two network members. All data transfers sent from
one network member are verified and acknowledged by the receiving member. In addition, the
sender and receiver must have established a connection prior to any data transfer. All this results
in reliable data transfer, but it does introduce substantial overhead. Additional overhead is
introduced in the TCP header.
TCP places a somewhat complex packet header in front of the application’s content when
sending data and removes the header from the packet before delivering a received TCP packet to
the application. Table 2 shows the format of the TCP header. TCP uses the IP protocol to send
and receive packets, which means there is an additional IP header in front of the TCP header
when the packet is on the network.
The data section follows the header. The length of the data section is not specified in the TCP
segment header. It can be calculated, though, by subtracting the combined length of the TCP
header and the encapsulating IP header from the total IP datagram length (specified in the IP
header).
TCP protocol operations may be divided into three phases: connection establishment, reliable
data transfer and connection termination. To establish a connection, TCP uses a threeway handshake. For data transfer, the protocol uses a sequence number to identify each byte of
data. If the sender infers that data has been lost in the network, it retransmits the data. Sequence
numbers and acknowledgments cover discarding duplicate packets, retransmission of lost
packets and ordered-data transfer. To assure correctness, a checksum field is included.
TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for
the TCP receiver to receive and process it reliably. The protocol also includes a number of
mechanisms to improve performance and prevent congestion collapse, an event that can cause
network performance to fall by several orders of magnitude. These mechanisms control the rate
of data entering the network, keeping the data flow below a rate that would trigger collapse.
They also yield an approximately max-min fair allocation between flows. Once transfers are
complete, the connection is terminated to free system resources for reuse elsewhere.
While it's clear that the TCP protocol is a rich one, with many features related to data integrity,
the TCP header is quite large. One can imagine the overhead that those characteristics introduce.
For certain applications, UDP may be a more efficient solution.
User Datagram Protocol (UDP)
UDP provides the simplest form of data transfer between network members. UDP data packets—
datagrams—are sent from one network member to another in a best-effort fashion, which means
there is no built-in mechanism for acknowledgement by the packet recipient. In addition, sending
a UDP packet does not require any connection to be established in advance. Because of this,
UDP packet transmission is very efficient, but the process is also prone to loss or error.
UDP uses a simple packet header of 32 bits in length, compared to TCP headers, which can be
192 bits long. UDP uses IP for sending and receiving packets, which means there is an additional
IP header in front of the UDP header when the packet is on the network. Table 3 shows the
format of the UDP header.
UDP uses a simple transmission model without dialogues for reliability, ordering, or data
integrity. Thus, UDP provides an unreliable service and UDP datagrams may arrive out of order,
appear duplicated, or go missing without notice. UDP assumes that error checking and correction
is either not necessary or is performed in the application, avoiding the overhead of such
processing at the network interface level.
Comparison of UDP and TCP
The two protocols have different strengths and weaknesses that need to be considered within the
context of the application (Table 4). TCP is a protocol focused around reliable data transmission.
TCP is most appropriate where data integrity is critical—lost packets must be re-tried and
recovered 100% of the time, regardless of any resultant delay. The TCP protocol includes
provisions for channel creation, packet verification, packet ordering and re-transmission in the
event of failure. TCP communications also can intentionally slow themselves down if losses
exceed a certain threshold, to prevent congestion collapse.
UDP is a simpler message-based connectionless protocol, with no dedicated end-to-end
connection. Communication is achieved by transmitting information in one direction from source
to destination without verifying the readiness or state of the receiver. Because of the lack of
reliability, applications using UDP must be tolerant of data loss, errors, or duplication, or be able
to assume correct transmission. Such applications generally do not include reliability
mechanisms and may even be hindered by them. In these cases, UDP—a much simpler protocol
than TCP—can transfer the same amount of data with far less overhead, and can achieve much
greater throughput.
UDP is often preferable for real-time systems, since data delay might be more detrimental than
occasional packet loss. Streaming media, real-time multiplayer games and voice-over-IP (VoIP)
services are examples of applications that often use UDP. In these particular applications, loss of
packets is not usually a fatal problem, since the human eye and ear cannot detect most occasional
imperfections in a continuous stream of images or sounds. To achieve higher performance, the
protocol allows individual packets to be dropped with no retries and UDP packets to be received
in a different order than they were sent as dictated by the application. Real-time video and audio
streaming protocols are designed to handle occasional lost packets, so only slight degradation in
quality occurs, rather than large delays, which would occur if lost packets were retransmitted.
Another environment in which UDP might be preferred over TCP is within a closed network,
where there is little chance of data loss or delay. For example, on a board or within an SoC, data
transfers from one component to another can be tightly controlled within the application,
obviating the need for the reliability features of TCP. UDP might be a more efficient and equally
reliable protocol in such situations. UDP's stateless nature is also useful for servers answering
small queries from huge numbers of clients, such as DNS, SNMP and so on.
Both TCP and UDP are widely used IP transfer layer protocols. For applications requiring
reliable transfers, TCP is generally preferred, while applications that value throughput more than
reliability are best served using UDP. Most TCP/IP stacks provide both protocols, so the
application can use whichever transfer protocol is more appropriate, even changing from one to
the other as desired. Rather than rely solely on TCP, the network system developer might want to
investigate the trade-offs related to use of UDP. It might turn out to be beneficial to sacrifice
some reliability in favor of greater throughput.
Express Logic, San Diego, CA. (858) 613-6640. [www.rtos.com].