Data networking folks tend to think of voice/data convergence as simply commingling one more application with others on the data network. So what's the big deal? Together with our colleague John Bartlett who specializes in troubleshooting VoIP and video quality issues, we think it is a big deal. VoIP is a different critter from data--and the sooner you understand and prepare for convergence, the better off you and your VoIP users will be.
One reason you should prepare well for convergence is to meet your users' expectations. In the plain old telephone service (POTS) world, users expect voice calls to be free from impairments like echo, noise and delay--and for dial tone always to be there. With rare exceptions like Inauguration Day on the Mall in Washington, you expect to get through--and if you can't you get irked.
Voice and data streams are different because voice streams need V.I.P. treatment to keep packet loss, delay, and jitter from degrading voice call quality for those finicky POTS users who will be quick to get on your case if they're not satisfied. The primary distinction between data and voice is that voice (as well as video of course) uses UDP not TCP, and the two protocols handle packet loss very differently. You may think that packet loss shouldn't be problem because your links are lightly utilized. Think again. Even lightly utilized links can and will experience packet loss, and here's why.
Data applications move blocks of information leading to bursty bandwidth usage and packet loss. TCP is designed to overcome packet loss, and it works well as long as the loss is moderate. It may surprise you to know that not only does TCP overcome packet loss, it often creates it to discover how much bandwidth is available.
TCP is an end-to-end protocol. Although the network speed at either end of a link may be high (100 Mbps or 1Gbps), the traffic may traverse a slow link along the path. TCP starts off slowly and speeds up until packet loss occurs. When it encounters packet loss, it backs down to half the speed and begins to creep up again, enabling it to determine available bandwidth and dynamically share that bandwidth with other TCP flows.
Unlike data traffic, voice flows as a continuous data stream that recreates human conversation, and bandwidth use is constant. Unlike TCP, UDP does not recover lost packets and degrades quickly when packets are undelivered. Like snail mail, UDP is a ‘send and pray' protocol. You put packets into the network and pray they get there. A UDP stream doesn't know anything about available bandwidth, and as a result it doesn't adjust insufficient bandwidth and loses packets. Because UDP doesn't recover packets, all the data doesn't get to the recipient and voice quality nosedives.
But, you ask, why should there be any packet loss if utilization is low--say in the 30 percent range? Because utilization measurements are averaged over some time period--often minutes--and peak utilization occurs in bursts that are often short, like during web page loading. During those bursts, TCP tries to use all the available bandwidth and causes packet loss. Because of such peaks, it's not uncommon to see packet loss on 10Gig backbone links that are a mere 3 percent utilized.
To overcome this problem, you need QoS to make sure your voice streams get through, even during peak bursts. QoS gives priority to voice traffic, which restrains the data packet peaks, and prevents packet loss and jitter in the voice streams. This capability is not just a nice to have, it's a must have if you want happy VoIP users.
Next week we'll give you some tips for how to plan and implement a successful VoIP QoS strategy.
Post new comment