Real-time Traffic is DifferentReal-time Traffic is Different

Understanding how to calculate bandwidth requirements for a converged WAN link requires an understanding of the traffic we are trying to converge. If we were just calculating water flow through a pipe we could add the demands of each appliance that needs water and determine the size of the pipe. But the two types of network traffic we are converging have very different characteristics, and this needs to be taken into account if we want to deliver good performance for both types of traffic. IT teams understand data traffic well because they have supported it for a long time. But real-time traffic is different.

Understanding how to calculate bandwidth requirements for a converged WAN link requires an understanding of the traffic we are trying to converge. If we were just calculating water flow through a pipe we could add the demands of each appliance that needs water and determine the size of the pipe. But the two types of network traffic we are converging have very different characteristics, and this needs to be taken into account if we want to deliver good performance for both types of traffic. IT teams understand data traffic well because they have supported it for a long time. But real-time traffic is different.One of the key ways that real-time traffic is different is in how it consumes network bandwidth. Let's take a look at each type and see how they compare.

This figure shows the bandwidth utilization by a typical data application:

Data applications often have a low average utilization, but have high peak utilization, seen here in the spikes of traffic utilization in this chart. Having enough bandwidth available for these peaks of usage is important, because the user is waiting for the computer to respond during those moments of peak utilization. They usually represent data being moved from a server to create the next screen of information on the client. The user is waiting for that screen before she can make her next decision. If there is insufficient bandwidth for those peaks, the user experiences a slow application, which may affect her productivity.

Real-time traffic looks very different. The graph below shows the bandwidth usage of a 384K video conferencing call. The upper line is the video stream, and the lower line is the audio stream. A G.711 VoIP stream looks exactly the same as the lower line on this graph. A G.729 stream would have the same shape but be at a lower bandwidth.

It's clear from this graph that the bandwidth use of audio and video is constant, not showing the large variations seen in the data graph. This makes sense because with audio and video we are reproducing a real-time event that is constantly changing. The bandwidth use reflects the fact that the image or the audio signal must be constantly updated to properly represent the voice or visual image we are reproducing. So bandwidth use across the network is constant.

If we take an average of the bandwidth used for the data application, we will get an inaccurate picture of the required bandwidth, because the peaks of utilization will be averaged out. However if we average the voice and video we get a very accurate view of how much bandwidth is required to support the application. The voice and video streams are referred to as 'well behaved' because they do not have the peaks of utilization.

When we mix these two traffic types on the LAN or WAN they interfere with each other. We have to use both planning and QoS to get them to properly share the WAN resource. I'll tackle those interference issues and solutions in my next post.