Managing Latency (VoIP Deployment)

Latency is a delay in the transmission of a data packet. It’s also the most common concern during any VoIP deployment. Even after you clean, design, and work out all the signaling details between your LAN and your carrier on your network, you always have to worry about the specter of latency as it leads to poor call quality and even call failure.
You can’t entirely avoid latency because every piece of hardware that interacts with a VoIP packet adds a few milliseconds of latency to that packet. You probably don’t notice the overall impact as long as the total latency from end to end is below 200 milliseconds (ms). After you cross the 200-ms threshold, your calls experience a noticeable degradation of quality.
tmp2F-20_thumb
The exact point at which call quality begins to drop is subjective. The 200-ms mark is about the middle of the road for the upper limit of tolerable latency. Some manufacturers, such as Cisco, have a stated policy cautioning their customers against any transmissions with more than 150 ms of latency, but other providers are more forgiving and caution their customers only after 300 ms of latency.
PING your prospective carrier’s router to determine a benchmark for the latency you can expect on your VoIP calls. PING is a simple command that you can execute from a command prompt on your PC. Try to PING from the server that you plan to use to send the VoIP calls.
From a PC running Windows XP, follow these steps:
1. Click the Start button on the lower-left of the toolbar.
2. Choose All ProgramsOAccessoriesOCommand Prompt.
The Command Prompt window appears.
3. In the Command Prompt window, type the command PING and the destination IP address to which you want to connect.
This example PINGs the IP for www.google.com:
tmp2F-21_thumb
4. Click the Enter key on your keyboard to being the ping test.
You receive a quick check of the path used by your IP provider from you to the destination IP. The response I received wasn’t encouraging:
tmp2F-22_thumb
If this was a VoIP call, I’d still have 120 ms before I had to worry about call quality degradation — so overall, it’s okay, but not great.
Not every carrier has an IP address for its VoIP proxy server that you can test it. Many carriers deactivate a part of the Internet Protocol (IP) software called the Internet Control Message Protocol (ICMP) Protocol Stack, preventing you from either PING-ing their IP. If your carrier has a PING-able IP, PING it. If not, ask whether the carrier has an IP on its network that can act as a suitable alternative.
If your PING returns with lost packets, be very concerned. Lost packets quickly deteriorate your call quality. Under optimal conditions (with no packet loss), an uncompressed call using the G.711 codec has an expected MOS score of 4.4, and the compressed codec of G.729 has roughly a 3.6 MOS score. (I talk about MOS scores in the section “Coming to Grips with MOS,” later in this topic.) The quality of the calls deteriorates substantially when packets are lost. The compression used with G.729 amplifies the issue as the process of converting the audio into compressed packets takes more time than forming uncompressed packets. The additional latency adds to the existing transmission latency, increasing the risk of packet loss. A packet loss of only 7 percent degrades the call quality of a G.729 call to approximately 1.5. The same 7-percent packet loss over G.711 still remains over 2.0.
tmp2F-23_thumb


Dealing with jitter

Simple latency is a fact of life. Everything takes time on a VoIP call, from encoding the voice into packets, to sending it through the LAN and WAN, to decoding it on the other end. If you could somehow anticipate the latency on each call and adjust accordingly on both ends, latency would no longer affect either call quality or completion.
But latency isn’t constant. If the IP for your VoIP calls is also supplying the Internet connection for e-mail, IM, and Web surfing for your office, the strain on the bandwidth fluctuates while people conduct their daily lives. If someone downloads the complete IEEE Computer Society Digital Library, the usage spikes, and the latency that was consistently 30 ms because of other VoIP traffic now increases to 120 ms for the next 20 minutes, until the download completes, at which time, the latency returns to 30 ms. These swings in latency are called jitter.
Jitter is one of the most troubling aspects of latency because it results in packets arriving at the far end in an unexpected cadence, where the amount of time between arriving packets fluctuates to the point where they arrive out of sequence, making it that much more difficult to reassemble them in a consistent flow. Some devices can reduce the jitter, but those devices can be more of an overall hindrance than a help if improperly configured.
Devices such as jitter buffers and Packet Loss Concealment (PLC) devices may look like a solution. They collect the individual VoIP packets, arrange them in sequence, and then send them out in a uniform cadence.
You want your packets to transmit in a consist rhythm, but by holding on to the packets before sending them, the jitter buffers actually create more latency than they avoid. While the buffer adds latency, the packets for transmission may begin to collect in the buffer faster than the buffer can transmit them. This backup becomes a problem when outgoing VoIP packets fill the storage capacity on the jitter buffer. After the buffer is full, the next VoIP packet delivered overwrites an existing packet in the buffer. The arrival of subsequent packets in the buffer wipes out more of the existing packets, and your call quality quickly begins to drop. Jitter buffers can effectively be used as long as they are one element used to deal with the latency instead of the only management device on an overloaded or poorly built network.
tmp2F-24_thumb

Identifying flap

Networks are dynamic, living, and breathing entities. They both route traffic from one point to another and also redirect that traffic around congestion and areas of the network where packets are flowing slower than expected. The term flap refers to a sudden or temporary change in routing between end points. Figure 5-2 shows what a flap looks like.
Figure 5-2 demonstrates a transmission that has a single route flap. The primary route for the VoIP call from Seattle to Washington, D.C., goes first into Minneapolis, then on through Chicago, Pittsburgh, and finally to Washington, D.C. The transmission encounters congestion in Pittsburgh, so the very next packet sent from Seattle is now routed south through Salt Lake City, Dallas, and Atlanta before hitting Washington, D.C. As long as all the packets arrive at their destinations in a timely manner, you don’t experience any problems with the transmission. Route flaps do have a problem: They usually result in some packets arriving out of sequence. Because a VoIP call is a real-time application, the system can’t ask for packets to be resent or wait for missing packets to arrive before forwarding them. A receiving VoIP node can’t use the out-of-sequence packets and so discards them. The packet loss may not have occurred due to a failing piece of hardware, but the same call quality degradation occurs, regardless of whether the packets are lost in a network, overwritten in a jitter buffer, or discarded because they arrived out of sequence.
Route flap.
Figure 5-2:Route flap.
tmp2F-26_thumb
The example in Figure 5-2 illustrates a call with a single route flap employed on the transmission. The problem of out-of-sequence packets becomes much larger when the Internet provider employs multiple route flaps. Each additional route flap increases your chances of a packet arriving out of sequence. The more route flaps encountered on a VoIP call, the more packets are discarded when they arrive out of sequence at the destination, and the call quality begins to drop.
Out-of-sequence packets from a route flap don’t cause much trouble during the middle of a call, but if you’re transmitting anything that isn’t voice during a route flap, such as DTMF (Dual Tone Multi Frequency) xtones (meaning touch tones) or faxes, it can result in the receiving VoIP node failing a transmission or misinterpreting the data sent.. If final DTMF packets arrive out of sequence and aren’t discarded as they should be while the END notifications are sent, your hardware may perceive those packets as new DTMF digits. If you see a double representation of DTMF tones being sent or received, take a packet capture of your calls. topic 11 shows how you can take DTMF captures by using Wireshark to help you isolate the issue. If your hardware doesn’t discard out-of-sequence packets, contact the manufacturer to update the software, firmware, or hardware to correct the problem.

Analyzing Your Bandwidth

Traditional LANs that ran data were more brawn than brains. They were designed based on expected data transmission and use, and then over-engineered for the given application. The switches, routers, and hubs were designed to be stronger than the network needed at the time, and bandwidth was also piled on to take care of peak times. In reality, you can’t tell with any certainty the specific hardware, software, and bandwidth that an application requires.
Most LANs in the United States don’t have any management software or tools to identify network congestion. They simply make a reactionary, best-guess effort with diagnostic tools that generally rely on the perception of latency or congestion by employees. If pulling a file across the LAN seems to take a lot longer today when compared with yesterday, you don’t have many available options to identify why that file is taking so long to transfer.
At this time, you can’t find any tools used by LAN technicians to identify if you’re pushing the maximum Packets Per Second (PPS) on your switch, router, bridge, or firewall. You can’t easily tell whether one of these components has a software bug that’s injecting latency in transmissions or a component is shorting out and dying a slow, painful death. You can get a bit of insight by using one of two basic options — SNMP and Wireshark (formerly called Ethereal), which I talk about in the following sections.

Putting general information With SNMP

The tools available for LAN analysis are blunt instruments at best, but they have always worked fine for the analysis of data on a LAN. The need for performance information on a data LAN isn’t as crucial as the information required on a VoIP LAN as traditional data transmissions can be resent if they arrive at the destination corrupted. VoIP transmissions are real-time applications and don’t have the option to be resent if a packet is lost.
The most common LAN management tool available is the Simple Network Management Protocol (SNMP). SNMP is a team of software elements residing in nodes on a LAN that collect management data on the health of the LAN. The system functions based on a main management device called a Network Management System (NMS) that controls and monitors the other SNMP-enabled devices. These devices, called managed devices, are different than ordinary hubs, routers, printers, bridges, and switches because they have a software element installed in them (called an agent) that allows them to gather management data and relay it up to the NMS.
The statistical information available on SNMP-managed networks include counters for these values:
Alignment Errors Single Collision Frames Multiple Collision Frames Deferred Transmissions Late Collisions Excessive Collisions MAC Transmit Errors Carrier Sense Errors Internal Max Receive Errors Symbol Errors
The SNMP error counters collect information on the events and make them available to the NMS so that your network manager can read and interpret them. Unfortunately, the information represents only a total number of errors or collisions over a given period of time. The information doesn’t tell you when the errors occurred. If the SNMP notes 100 Single Collision Frames, you can’t tell whether they all occurred at the same time during a unique LAN event or they happened every 15 minutes on a single managed device.
If you were dealing with data, you’d need only this collected information to measure the health of a LAN. As long as the overall numbers looked good, you declared the LAN healthy, and everyone went about their business.

Gathering the details With Wireshark

Not everyone has a managed network that runs SNMP-enabled nodes (as discussed in the preceding section). Even if you do, the reports available don’t identify the exact source of a problem or how the errors or collisions occurred (whether they happened periodically or all at the same time). The other tool at your disposal is a packet-capture software called Wireshark (formerly Ethereal).
Plugging a laptop that has Wireshark installed into your main router, server or firewall allows you to capture all the packets flowing through that point of the network. Depending on how long you leave the capture open, you may need to sift through a huge accumulation of data to find an answer. As great as Wireshark is, it doesn’t provide any graphs or a matrix for congestion, allowing you to quickly identify and locate the source of congestion issues. So, you have to scroll down through hundreds and thousands of lines of code on each type of traffic and review the timestamps for each stream of data while it flows through the network.
The main limitation to this type of analysis is that a congestion issue or problem must be going on while you’re capturing packets if you want to actually identify the problem. If the problem you’re chasing down is intermittent and occurs only 5 or 10 percent of the time, it could persist for months before you can finally identify and resolve it.
Wireshark is a new version of Ethereal. It color codes the transmission types, allowing you to quickly identify the protocols used in the packets as TCP traffic, versus SIP with SDP. It’s the most helpful software available for analyzing problems on VoIP calls as it links together packets associated with individual VoIP calls, making it simple to scroll through every SIP method and response transmitted, and I give you all the details in topic 11.
Despite the fact that you can’t find many legacy LAN tools available to help you, a growing number of software programs can fill the gap between what you used to need for data transmissions and what you need now to monitor VoIP traffic. The leader in this field is the VoIP Lifecycle Management software and hardware available from Packet Island, which I talk about in topic 9.
tmp2F-27_thumb

Managing Your Bandwidth

Despite the lack of available tools to see how your bandwidth is doing (as I talk about in the preceding sections), you can use a handful of techniques that allow you to control the flow of traffic in your LAN. The following sections give you the details about these techniques.

Handling latency with prioritization

Hundreds, thousands, and hundreds of thousands of data packets may be coursing through a LAN at any given time. A router receives each packet and processes it accordingly, each in its turn, on a first come, first served basis.
This process can cause a problem because packets for real-time applications such as VoIP and video are waiting on packets used to send e-mails and surf the Web. All packets aren’t created equal. Some are in a rush, and some can take their time getting to a destination. Table 5-1 shows some common types of transmissions in a LAN, their bandwidth requirements, and their general levels of urgency.

Table 5-1 LAN Transmission Types
Application Bandwidth Urgency
E-mail 128 Kbps-1.5 Mbps Low
Surfing the Internet 128 Kbps-1.5 Mbps Low
Instant Messaging 28 Kbps Moderate
VoIP 64 Kbps High

Just like doctors can’t deal with patients in an emergency room on a first come, first served basis, you need to triage your data transmissions. All of the transmission types shown in Table 5-1 are transmitted with IP, which has the means to prioritize packets, giving some preferential treatment over others. Table 5-1 shows that e-mails and Internet surfing are low-urgency transmissions. If they lose connectivity, or if a packet arrives out of sequence or corrupted, it can always be resent without any harm done.
The real-time applications, such as Instant Messaging and VoIP, are much more sensitive and need to be processed with greater urgency. Each transmission type can be categorized in a different priority level to help refine data transmission on the LAN.
Internet Protocol (IP) identifies eight levels of priority, from 0 to 7, with 7 being the highest priority. Generally, network engineers use 7 only for mission-critical transmissions of network management or routing, and 5 and 6 typically identify real-time applications such as VoIP.
Don’t use prioritization as your only means of dealing with bandwidth management on a network running both data and VoIP because
It adds latency. The server utilizing the prioritization hierarchy must identify the priority level of the packets received in the router and usher all those packets into their appropriate queues for transmission. So, every packet — data and voice alike — experience more latency.
After a while, all the packets become 6s. While the volume of VoIP calls increases, your router spends more time sending VoIP transmissions into the priority 6 queue. The VoIP packets may represent 50 percent or 70 percent of the traffic on your LAN. Eventually, spending the time to identify packets as VoIP transmissions and dropping them in a queue wastes more time than if every router, switch, and server sent the packets along without being prioritized.

Resolving latency with packet shaping

Prioritization alone isn’t an effective tool for peacefully using bandwidth between VoIP and data packets. You can more effectively use prioritization as an auxiliary tool in conjunction with other constructs, such as packet shaping (also known as rate shaping), a standard feature on many routers. Packet-shaping devices don’t handle all your LAN traffic as individual packets, they actually manage the data flowing through them by criteria such as
Traffic protocol: They can categorize traffic by the protocol used,
whether TCP, IP, SIP, SDP, or RTP.
Transmission port: SIP traditionally uses port 5060, which the router with packet shaping can use to identify your VoIP traffic and differentiate it from someone surfing the Web.
Host connection: Your VoIP LAN sends your VoIP traffic to the same VoIP provider, and the outbound port or IP address on your LAN can also use this data to identify your VoIP traffic.
Rate shaping allocates a specific quantity of bandwidth to each type of traffic, based on the criteria you set. For example, if you have a 45-Megabit Internet connection, you can identify 35 Meg for VoIP traffic and the remaining 10 Meg for all other data transmission.
The traffic limits set on the packet shaper are either definite or burstable. Don’t make the limits set for the data portion of your network burstable. This setting allows the data traffic to invade the bandwidth allocated for VoIP calls. During peak business times, when both your voice and data networks have their greatest usage, you don’t want to sacrifice your VoIP call completion and quality for a data packet that can be resent.
tmp2F-28_thumb

Separating VoIP from data With a subnet

Packet shaping (discussed in the preceding section) is a great concept. You can go one further and, instead of simply splitting the existing bandwidth, move the VoIP traffic onto its own section of the LAN. Partitioning off a section of your LAN to prevent the VoIP traffic from interacting with the router traffic further isolates the system. If every router in your LAN doesn’t have to identify and manage every VoIP and data packet, that translates into less work for the routers, less latency, and a cleaner transmission.
Creating a subnet that contains only VoIP traffic is another great solution. You can partition off sections of your network into subnets, but those subnets can also add difficulty to a VoIP deployment if any VoIP node is installed outside of its subnet. Figure 5-3 shows a subnetted network in a VoIP application.
The design in Figure 5-3 looks acceptable at first glance. The network is separated into a VoIP subnet, containing VoIP phones managed by a router that has a direct Internet connection with a single connection into the main LAN. The one VoIP phone attached to the PC workstation faces a challenge. Its packets are directly immersed in every data transmission from the PC to the rest of the LAN, and those packets also have to flow through the server and the serving router before they even reach the final router connected to the Internet.
VoIP LAN with subnet.
Figure 5-3:
VoIP LAN with subnet.
In Figure 5-3, you might face some problems when you try to move the PC workstation’s VoIP phone or wire it into the VoIP subnet. For example, the location of the single VoIP phone not on the subnet may be on the other side of the office building from the VoIP subnet, or it might be in a remote office if you have a campus environment. Creating the physical connection may be a logistical nightmare, but you have a solution in a VLAN (discussed in the following section).

Employing a VLAN

A VLAN is a Virtual LAN that acts like a physically separate network, despite the fact that it uses the exact same switches as your primary LAN. Figure 5-4 shows what a VLAN looks like.
The Virtual LAN.
Figure 5-4:
The Virtual LAN.
The gray boxes in Figure 5-4 are VoIP nodes and devices connected on the LAN through switches. The circles attached to the switches are data devices such as PCs, servers, and other peripherals. In the world of the network, the switches on the LAN see two separate LANs functioning side by side. The VoIP portion of the LAN contains and sees only the VoIP nodes and the sections of the switches allocated for the VoIP LAN traffic. The data LAN runs through the data side of the switches and is blissfully unaware of the fact that VoIP traffic runs beside it on the network. It’s not only a peaceful coexistence, it also is the basis for a very efficiently deployed VoIP network.
Depending on the size and complexity of your LAN, you may not need to establish a VLAN. You may be able to manage your VoIP traffic effectively through a combination of prioritization and packet shaping as discussed previously in this topic. If you are sending more than 24 calls at the same time, deployment of a VLAN is something you should discuss with your network engineer.
Keep all your options in mind and reassess your LAN every four to six months. Your business changes while it grows (or shrinks), so you need to adjust to the new mix of traffic flowing through your LAN.
tmp2F-31_thumb

Next post:

Previous post: