Speeding M2M With UDP

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 some may not realise is that many other M2M communications utilise 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 many designs.



TCP/IP is a layered protocol, which means more complex protocols are built on top of simpler underlying protocols (see 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 categorised as network layers, even though they rely on IP for sending and receiving.





Table 1: Internet Protocol Layers



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 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 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.





Table 2: TCP Header



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 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 re-use 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; i.e., 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.





Table 3: UDP Header



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, which need to be considered within the context of the application (see 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 can also intentionally slow themselves down if losses exceed a certain threshold, to prevent congestion collapse.





Table 4: A comparison Of TCP And UDP



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 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 tradeoffs related to the use of UDP. It might turn out to be beneficial to sacrifice some reliability in exchange for greater throughput.



About The Author: John Carbone is vice president of marketing for Express Logic. He has 35 years experience in real-time computer systems and software, ranging from embedded system developer and FAE to vice president of sales and marketing. Mr. Carbone has a BS degree in mathematics from Boston College.