Converged WAN links carry a combination of data, voice and video traffic intermingled. Because these applications use the bandwidth in very different ways, they can interfere with each other when bandwidth is limited, as is often the case in the WAN access link. In my last post we looked at how these traffic types are different. Now I want to talk about how they interfere with each other and how we can manage that interference, especially in the WAN.
Converged WAN links carry a combination of data, voice and video traffic intermingled. Because these applications use the bandwidth in very different ways, they can interfere with each other when bandwidth is limited, as is often the case in the WAN access link. In my last post we looked at how these traffic types are different. Now I want to talk about how they interfere with each other and how we can manage that interference, especially in the WAN.The bursty nature of data traffic means that while its average utilization can be quite low, its instantaneous demand is high, often the full bandwidth of the link. So while it may appear from average utilzation numbers that there is adquate bandwidth for both data and voice/video on the WAN link, the momentary bursts of data traffic ulitization cause queues to fill or overflow, causing packet loss or jitter. This loss and jitter have a negligable effect on data applications, but they quickly degrade the quality of voice and video.
We use QoS to solve this problem. During those instants when data traffic bursts, the QoS gives priority to the real-time traffic. This allows the voice and video packets to always get through quickly. The bursts of data are slightly slowed down as a result. This is the primary job of QoS and why it is so necessary in a converged network environment.
Note however, that there was an effect on the data traffic. I casually mentioned in the last paragraph that the data peaks are slightly slowed. As long as they are only slowed slightly, the data users will be happy. But if the amount of real-time traffic is high, which can easily be the case with video or with a heavily used trunk line of voice calls, then the data traffic peaks are crushed too much, and the data application users start to experience slow applications. Help desk phones begin to ring.
So the tricky part of a converged WAN link is to decide how much bandwidth is needed for the data applications to maintain acceptable performance for the users. We have to allow those peaks to occur, but how much headroom do they need? There are no easy formulas to derive this answer because there is so much variation in the behavior of data applications and in the expectations of users. In my consulting work we often need to either simulate this environment or test the application behavior in situ to determine how fast is fast enough. Testing can be done by constraining the WAN link or by simulating voice and video loads through synthetic traffic testing. Then listen carefully to the users to see if and when they begin to notice performance degradation.
Cisco has a rule-of-thumb recommendation that says real-time traffic should not exceed 33% of the link bandwidth. This rule is an attempt at solving the issue described above. This rule was easy enough to follow in the early days of VoIP deployment, but now I think more detailed engineering and testing is required.
The alternative is to use dedicated links for the support of real-time traffic. Real-time traffic is 'well behaved', meaning that it has a very consistent bandwidth profile and does not need to burst to high levels. Because of this characteristic it is possible to load WAN links that are dedicated to real-time traffic to much higher utilization levels, like 90%. Of course the disadvantage of this approach is that the bandwidth not being used by real-time can now not be shared with the data applications.
So the choice about using dedicated links is driven by the consistency of the real-time traffic usage, the burstiness of the data applications and the cost of bandwidth. If an enterprise has a constant demand for real-time traffic between locations, e.g. supporting a trunk for VoIP communications, it makes sense to dedicate bandwidth to this use. If real-time traffic is still a relatively small percentage of the overall WAN bandwidth demand, then a converged WAN may be the best solution. Be sure to test the impact on data applications, get the QoS right, and monitor the balance over time to make sure the WAN link continues to provide the services needed by a changing enterprise.
