What is bursty traffic, and how does it affect quality of service (QoS) on a VoIP network?
Go out to your busiest road or highway and observe the vehicles, pedestrians, bicycles and other modes of transport along that roadway. Note that some may look alike, but in reality they are all different. Some vehicles have dirt, scratches, dents or even worse -- complete panels and parts missing -- yet they are still shooting down that path. Sometimes they collide and the results are ugly.
On the road, you have rush-hour traffic, and then you have seasonal and even local disruptions that create a really busy highway. You will see periods of idleness or no traffic at all, then periods of heavy traffic or traffic that gets heavy only for a short period of time. These clumps of uneven traffic could easily be deemed bursty traffic. The demand that this traffic can place on the highway will always create blocks or slow conditions where cars must stop and even reroute.
Now imagine the cars as packets -- voice, data, images, etc. -- where the real-time packets must not slow down, reroute or completely stop.
Network traffic engineers handle all types of traffic in the new and modern telecommunications model. We need to focus on how quality of service is going to be accomplished in the new models. Quality of service guarantees that a set amount of bandwidth is available for voice calls -- that real-time traffic must not be blocked, stopped or delayed too much.
Will you deploy Class of Service using the Differentiated Services, or DiffServ protocol, to set the prioritization for voice packets? In some cases, like firewalls, prioritization is a tool in a firewall group policy that is also handling routing, including treatment of voice and other real-time traffic. The policy will dictate that all outbound voice traffic will take precedence over all other traffic.
Learn more about bursty traffic and QoS in a VoIP network:
- Stop VoIP anomalies before they impact performance
- Policing and shaping within QoS
- VoIP: The face of the new network police
This was first published in February 2014