Hello again, and welcome to the second installment of “Notes from Downstream.” As I sit writing this article, I can’t help but think of the current economic climate and how every day people are being asked to do more with less. Many are looking to Unified Communications (News - Alert) applications like voice, video, and conferencing to provide more effective communications with less travel and expense. In this column we will focus on what you should know about the real-time network traffic that comprises Unified Communications applications and how it can impact the performance of your network.
Real-time traffic (voice and video) has a unique set of performance requirements that make it a challenge for the infrastructure supporting any data network. Understanding what makes real-time different from the other traffic running on your network is a critical step in understanding what’s needed for optimal performance of both voice and data applications. In my last column I discussed the unique characteristics of data applications: They use the reliable and connection-oriented TCP protocol, have a client-server structure, are transaction-oriented, and are often written by programmers who aren’t networking experts. Here’s what makes real-time traffic different.
Real-time Traffic Characteristics
Unlike the data traffic generated by traditional TCP-based network applications, voice and video traffic has real-time characteristics:
Real-time applications use the RTP protocol: VoIP and video applications must send data immediately and don’t have time to wait for retransmissions. That’s why they use RTP. RTP rides on top of UDP (News - Alert), a connectionless protocol that doesn’t include a mechanism for retransmission or reordering of data. Instead of sending a packet and waiting to make sure it was received before sending another packet, RTP applications typically send packets at a fixed rate to avoid congestion. They do not resend data when loss occurs, and they don’t even slow down. If an RTP packet is lost, it’s lost, and there’s no chance to retransmit it. And if a group of consecutive packets is lost, entire portions of the conversation can be wiped out.
VoIP applications send small data packets: VoIP data packets are typically small in comparison to other types of data packets. VoIP codecs are tasked with producing data packets from a voice conversation. The payload size for these packets can be anywhere from 20 bytes (for G.729) at the low end up to 160 bytes (for G.711) at the high end. Using fixed data rates, the codec typically sends these packets out every 20 milliseconds. Without proper quality of service (QoS) mechanisms active on the network, these small VoIP packets may get blocked behind a larger data packet waiting to be sent on a slower-speed WAN link.
Video applications send large data packets: Video data packets are typically large, cramming as much information in a single packet as possible. Video codecs are high-bandwidth consumers and transmit data at variable rates. Not all video packets are created equal: Some packets carry information about the display image, and their loss can be more detrimental to video quality than simply losing other video packets. Video typically has all the requirements of voice, but uses a lot more bandwidth.
Real-time applications have strict delay requirements: Because voice and video calls are usually interactive in nature, they are not at all tolerant of long delays. If delay is significant enough (usually more than 150 milliseconds), the conversation will have lags and people will start talking at the same time. A VoIP or video packet may be delayed for several reasons:
· Packetization delay occurs when the speech is encoded by the codec and the packet is created.
· Network delay includes time to transmit the packets, buffer and queue them if needed, and move the packets from hop to hop through the network.
· Jitter buffer delay is added by the receiver when buffering packets to reduce the impact of variations in packet arrival times.
When these factors are combined, delay can easily become significant. As a result, minimizing the overall delay is an important consideration for maximizing the quality of interactive VoIP calls.
Real-time applications require QoS: The PSTN did a great job of guaranteeing the resources needed for a call and maintaining them throughout that call. After the initial signaling, a path through the PSTN and all associated resources is reserved for each call. By contrast, an IP network does not usually operate this way. In an IP network, the resources are shared by many different users. Congestion at a router caused by another user’s large file download can impair the quality of your VoIP or video call. There is a QoS mechanism known as RSVP that can provide guaranteed resource reservation, but the result is such high overhead that it is not widely implemented. Nevertheless, a QoS scheme that provides prioritization for voice and video traffic is required for every deployment.
Because of the unique characteristics of real-time traffic, a new set of demands is placed on data networks. Realize that good network performance for traditional data applications is not a guarantee that performance will be good for real-time applications. An inappropriately configured network could very easily cause VoIP or video calls to have poor quality: calls could be delayed, dropped, or they could just plain sound and look bad. These call quality issues would quickly affect the end-user experience. You could end up getting a lot of calls to the help desk to fix the problem — or at least, you would if the phones were working.
However, optimizing real-time traffic at the expense of other applications is not an option. Some balance is required. When deploying VoIP and video, you also need to consider the impact that it can have on other applications.
The Impact of Real-time Traffic on Other Applications
The differences in the UDP and TCP protocols can have an interesting impact on the performance of all applications when VoIP and video traffic is added to the network mix. Specifically, the adaptive nature of TCP can result in cases where TCP application performance degrades when faced with additional UDP traffic. Within conditions of congestion, TCP plays nice and backs off: the window sizes shrink, and less data is sent and received. But UDP, and VoIP and video in particular, continue to send data with no regard to congestion. Even though VoIP applications send data at a fixed, relatively slow rate, if enough calls are present, each with two unidirectional streams, the VoIP UDP traffic might create congestion and crowd out the TCP application traffic, creating longer transaction times and impairing the performance of TCP applications. Likewise, when video is added to the mix, the additional bandwidth requirements can quickly impact other data applications if proper QoS is not applied.
The goal in managing a converged network is to tune it so that many types of application data traffic can coexist and perform well. QoS mechanisms are necessary, as well as visibility into the underlying metrics that affect end-user quality of experience. And taking a step back from those metrics, knowledge of overall network performance is another significant factor in the success of a Unified Communications deployment.
In summary, you can’t treat real-time traffic the same as traditional networked applications. Why?
· Different protocols — RTP vs. TCP
· Different packet sizes — small VoIP versus large video versus large data
· Different QoS requirements — delay sensitive for VoIP and video
· Different data rates — relatively low, constant for VoIP, variable for video; elastic for TCP
· Different user expectations — PSTN-shaped, high quality for voice, versus data, where delays might not be noticeable
While optimizing the network for both data and voice is crucial, another imperative is monitoring the quality of experience that your users perceive from VoIP and video applications. This is largely shaped by their perception of the availability and call quality that the system provides. But that is a topic for another day.
Jeff Hicks (News - Alert) is Principal Technical Staff in the Office of the CTO of NetQoS, Inc. and author of the ebook “VoIP: Do You See What I’m Saying? Managing VoIP Quality of Experience on Your Network.”
Edited by Greg Galitzine