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 advantageous for many embedded M2M system requirements, and might be worth consideration for your next “Internet of Things” design. Following are highlights and some of my thoughts on the use of UDP in M2M communications.
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 for 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 responsible for sending and receiving simple packets, in a best effort manner, across the network. Management type protocols like ICMP and IGMP also are typically 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 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).
Most voice and video traffic is transmitted using UDP. To understand why, and to determine whether it is a good fit for your M2M system, we will 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 data 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 three-way 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 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 re-use elsewhere.
While 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 formof data transfer between network members. UDP data packets—datagrams—aresent from one network member to another in a best-effort fashion; i.e.,there is no built-in mechanism for acknowledgement by the packetrecipient. In addition, sending a UDP packet does not require anyconnection to be established in advance. Because of this, UDP packettransmission is very efficient, but the process is also prone to loss orerror.
UDP uses a simple packet header of 32 bits in length,compared to TCP headers, which can be 192 bits long. UDP uses IP forsending and receiving packets, which means there is an additional IPheader in front of the UDP header when the packet is on the network. Table 3 shows the format of the UDP header.
UDPuses a simple transmission model without dialogues for reliability,ordering, or data integrity. Thus, UDP provides an unreliable serviceand UDP datagrams may arrive out of order, appear duplicated, or gomissing without notice. UDP assumes that error checking and correctionis either not necessary or is performed in the application, avoiding theoverhead 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 ismost appropriate where data integrity is critical—lost packets must bere-tried and recovered 100% of the time, regardless of any resultantdelay. The TCP protocol includes provisions for channel creation, packetverification, packet ordering, and re-transmission in the event offailure. TCP communications also can intentionally slow themselves downif losses exceed a certain threshold, to prevent congestion collapse.
UDPis a simpler message-based, connectionless protocol, with no dedicatedend-to-end connection. Communication is achieved by transmittinginformation in one direction from source to destination withoutverifying the readiness or state of the receiver.
Because of thelack of reliability, applications using UDP must be tolerant of dataloss, errors, or duplication, or be able to assume correct transmission.Such applications generally do not include reliability mechanisms andmay even be hindered by them. In these cases, UDP—a much simplerprotocol than TCP—can transfer the same amount of data with far lessoverhead, and can achieve much greater throughput.
UDP is oftenpreferable for real-time systems, since data delay might be moredetrimental than occasional packet loss. Streaming media, real-timemultiplayer games, and voice over IP (VoIP) services are examples ofapplications that often use UDP. In these particular applications, lossof packets is not usually a fatal problem, since the human eye and earcannot detect most occasional imperfections in a continuous stream ofimages or sounds.
To achieve higher performance, the protocolallows individual packets to be dropped (with no retries) and packets tobe received in a different order than they were sent, as dictated bythe application. Real-time video and audio streaming protocols aredesigned to handle occasional lost packets, so only slight degradationin quality occurs, rather than large delays if lost packets areretransmitted.
Another environment in which UDP might bepreferred over TCP is within a closed network, where there is littlechance of data loss or delay. For example, on a board or within an SoC,data transfers from one component to another can be tightly controlledwithin the application, obviating the need for the reliability featuresof TCP. UDP might be a more efficient, equally reliable protocol in suchsituations. UDP's stateless nature is also useful for servers answeringsmall queries from huge numbers of clients, such as DNS, SNMP, and soon.
Both TCP and UDP are widely-used IPtransfer layer protocols. For applications requiring reliable transfers,TCP is generally preferred, while applications that value throughputmore than reliability are best served using UDP.
Most TCP/IPstacks provide both protocols, so the application can use whichevertransfer protocol is more appropriate, even changing from one to theother as desired. Rather than rely solely on TCP, the network systemdeveloper might want to investigate the tradeoffs related to use of UDP.It might turn out to be beneficial to sacrifice some reliability infavor of greater throughput.
John Carbone is vicepresident of marketing for Express Logic. He has 35 years’ experience inreal-time computer systems and software, ranging from embedded systemdeveloper and FAE to vice president of sales and marketing. Mr. Carbonehas a BS degree in mathematics from Boston College.