Your network isn’t performing as well as it should, and you’re frustrated. You’ve added bandwidth, you’re monitoring for QoS, yet still there are lags.
Worse, like many organizations you’ve migrated to a VoIP system and the quality isn’t quite as good as advertised. Sometimes the conversations sound a little watery, and the priority given to real-time traffic means day-to-day access for e-mail and file loading can be slow.
On top of this you want your network to be secure, and you know the anti-spam, anti-virus, and firewall software is another burden on your CPUs.
Alejandro (Alex) Pares, research analyst for network equipment at IDC, knows the story. “Often people put in VoIP when they move to a new location, and the cabling organization might not have the correct expertise for installing the networking gear,” he says.
This is especially true when migrating from Category 5e cable to Category 6. There are a lot of advantages to Cat 6, including improved transmission performance, available bandwidth extensions to 200 MHz from 100 MHz, higher signal-to-noise ratios, as well as increased reliability and data rates. However, much of the true potential of Cat 6 can be lost due to poor practices.
Nathan Jang, a service manager with Netdigix, a Vancouver-based data/network cabling and voice wiring company, concurs.
“Cat 6 infrastructure supports a gig, but some people go cheap and use an electrician,” he says. “They don’t certify the job, and a year later the network can’t handle the traffic.” This means that installers should be doing more than a continuity test; they must conduct cross-talk tests that cover off interference from other electrical devices such as air conditioners.
That said, even using the best gear and the best people might still get you in trouble. “You have to start with a design,” says IDC’s Pares. “And that’s not just getting the cabling right. It also means integrating QoS [quality of service] policies. If you don’t do that you’ll be in trouble again.”
Tracy Fleming, national IP telephony leader for Avaya Canada, sees the solution as less a matter of bandwidth than proper monitoring for QoS, especially in larger enterprises.
“A VoIP call requires the network to be looked at with a magnifying glass,” Fleming says. It’s not enough, then, to have the hardware up to standard. There is also a software component.
And the problem sometimes isn’t visible, even to engineers. Often networks are working great, at five nines, and seem well positioned for VoIP. Then voice is added, things get sluggish, and confusion reigns, because five-minute traffic tests are showing no problems.
“That’s not good enough,” says Fleming. “A voice call averages 3.6 minutes, and you’re tracking latency, packets and jitter every five minutes? A call can be blown and you don’t even know it occurred.”
The problem, as is so often the case, is that application-based solutions themselves can put a strain on a network. Today, a typical software-based router can’t handle monitoring a packet on a 50- to 100-millisecond basis.
Not surprisingly, Fleming suggests that the hardware manufacturers are not the best people to get your software from.
“Those processors can get so busy monitoring they aren’t doing much else. A granular approach, with built-in real-time control protocol (RTCP) on a mesh system, millisecond by millisecond, showing buffered overflows and under-runs, and coming from the application itself and not a 3 a.m. test run, that’s the only way to know what’s going on.”
The discussion, then, must be more than a red light-green light approach to managing data networks. The nature of the bottleneck has changed, with networks now expected to handle multiple end-points and devices.
Network managers are then challenged to give employees the same look and feel across systems that are both secure and distributed. “Firewalls can really slow things down,” says Pares, “and sometimes the best approach is an appliance. A VPN can load processing time onto the CPU, but a hardware-based firewall takes pressure off the CPU, and can provide optimized unified threat management.”
One common fallacy is that the problems are primarily on the LAN, whereas industry experts are seeing more and more issues on WANs.
The carriers have to take some responsibility for this, as many say they can handle multi protocol label switching (MPLS), whereas in fact packets are going through the same switches.
That said, you don’t automatically have to pull your whole WAN to do VoIP, which is a good thing, because a rip-and-replace approach can ruin a business case.
“Of the networks that we put on VoIP, 80 per cent have the functionality and require fine tuning,” Fleming says.
“The problem is a lot of people throw bandwidth at the problem.” In fact many networks are built to handle the traffic they receive but aren’t tuned to handle bursts. As a result, companies experience packet loss but don’t know it, in large part because they are relying on the port on the router for visibility.
“Tools to look at software-based latency help,” says Fleming. It’s also a good idea to know the specifics of your business and how this affects traffic loads.
Insurance companies need their call centres to scale dramatically, and quickly, when dealing with natural disasters such as hurricanes. Then there are the more predictable demands of retail at Christmas, and financial services during RRSP and tax season.
In these cases VoIP networks have to be distributed, without putting the load on one point in the infrastructure.
