UDP Operation

No, it isn’t called Unreliable Data Protocol, although many will nickname it that way so they can remember it. UDP is an option at the transport layer that doesn’t provide a connection oriented or session based reliable communication; instead we say it is unreliable and connectionless. In this article I will explore in detail UDP and its operation.

The best analogy I like to differentiate UDP and TCP is to consider TCP an actual phone call where you have the initial “hello” and the middle “are you still there” to check if the other side is still on the line and the final “good bye” when the conversation is complete, all these kinds of control messages are used in a connection oriented phone call.

Well, if that is true UDP is like a post card, it is entirely “simple” and “connectionless”, once you drop your post card in the mail you hope it reaches its destination. As a matter of fact UDP is great for unidirectional type connection. UDP does not engage in any kind of re transmission which means that it has much lower bandwidth overhead and latency, as a result packets can be lost or received out of order.

Most people tend to think of Voice over Internet Protocol (VoIP) when it comes to UDP, but the concept that is hard to grasp for most beginner network engineers is that ”How in the world can UDP accomplish something as complex as making sure a VoIP phone call succeed properly in our network environment?” I will get in to that in a little bit but some other services like DNS, DHCP, and also SNMP benefits from the simplicity of UDP. To understand how UDP works first you need to be familiar with two concepts TCP starvation and UDP dominance.

TCP Starvation and UDP Dominance

If you are a network designer and you worry about Quality of Service (QOS) in your organization one of the first things you need to do is to organize traffic into different classes and give a particular treatment from the QOS perspective. However, in the process of organizing the traffic you need to watch out for taking a heavy amount of TCP traffic and putting them in the same class with a heavy amount of UDP traffic. Certainly there are times it is inevitable you are going to end up with TCP and UDP traffic in the same class. You can experiment to see if there is a negative effect on your network. At times it is unavoidable, but whenever possible we should try and give these different sorts of traffic their own classes. And here is why.

When TCP and UDP end up in the same class of traffic TCP (because it is a connection oriented & session based communication) will respond very actively to a lot of QOS mechanism such as Waited Random Early Detection (WRED), UDP on the other hand does not. UDP ignores these QOS type mechanisms because by its nature it thinks, “Hey I am just being sent “ So what happens is that as the congestion starts to build up in a queue UDP keeps getting blasted at the same exact rate but TCP starts diminishing, it starts peeling itself off because it is responding to the various QOS mechanism we configure in the queue for that particular class. Sure enough you see what happens UDP starts dominating the circuit and less and less room are made for TCP, it is literally starving itself out by giving a lot of room for the UDP traffic. Do you see how they come up with the name TCP starvation and UDP dominance?

RTP (Real Time Protocol)

Why most beginning network pros find it amusing to know that UDP is responsible for some network types as extremely complex and important as VoIP, and yet it doesn’t have mechanisms built-in to handle things like quality of services concerns. That is exactly why RTP was invented to address that very issue.

RTP is designed for end-to-end, real-time transfer of streaming media. RTP is actually what is allowing us to carry the data in a way which we can add QOS type functions. RTP is usually used in conjunction with the Real-time Transport Protocol (RTCP), While RTP carries the media streams (audio and video), RTCP monitor transmission statistics and quality of service information, that is RTCP provides feedback on transmission and reception quality of data carried by RTP. While we are on RTCP, you might want to know about Secure RTP (SRTP), which provides encryption or authentication methods because RTCP does not.

RTP was designed primarily to address head-on an issue called “jitter” and “out of sequence”. You might not be familiar with jitter, so let me quickly define what it is. Jitter is a real nightmare for voice applications, for example, if you have a VoIP phone in Phoenix AZ and that phone communicates through, let’s say, three routers to another VoIP phone in Washington DC, If we have a predictable delay along its path then we have a mechanisms built right in to the application that carries the VoIP to know the predicted delays, so it can work with that because the delays are predictable. Jitter happens when the latencies are unpredictable resulting in packets that take longer to travel from one system to the other. The variations in the latency on packet-flow between two systems is called jitter. RTP, when it is used between two VoIP devices is referred to as RTP Session. This is interesting because they are adding session to the session less Protocol.

RTP => Carries the actual data using even number ports.

RTCP => Carries control packet using odd number ports.

RTP and RTCP also leave room for optional signaling protocols that are used in VoIP environments; like H.323 which is something that’s utilized in addition to RTP and RTCP for coding and decoding the actual voice data.

I used a sample captured file from wireshark.org to demonstrate RTP. if you want one for your experiment feel free to go to their site and download.