In previous newsletters, we've broken QoS tasks into two major components -- classifying flows of traffic and then queuing them. That is a good way to begin to understand the basics, but in this newsletter we will discuss two slightly more advanced and oft misunderstood components -- policing and shaping.
Traffic policing and traffic shaping are similar mechanisms in that they both inspect traffic and then take an action based on various characteristics of that traffic. These characteristics may be based on whether the traffic is over or under a given rate, or based on some bits in the headers, like the Differentiated Services Code Point (DSCP) or IP Precedence.
The simple difference between policing and shaping is that policing either discards the packet or modifies some aspect of it, such as its IP Precedence, when the policing agent determines that the packet meets a given criteria. By comparison, traffic shaping attempts to adjust the transmission rate of packets that match a certain criteria. This is accomplished by holding packets in a buffer and releasing them at a pre-configured rate.
In many environments, implementing a relatively simple Low-Latency Queuing (LLQ) or Priority Queuing (PQ) scheme is sufficient. However, these queuing methods still pass traffic as fast as they can; their goal is to service some types of traffic before others. Sometimes you actually need to slow traffic down, which you can do with traffic shaping. This is most common
Requires Free Membership to View
To understand why this is useful, try to stop thinking of rates in terms of bits per second. For QoS discussions, speaking in terms of bits per second may technically be accurate, but this average isn't necessarily the most relevant description of your traffic. The problem with bits per second is that a second is a very long time on the network. For instance, a traffic flow across an Ethernet link may be using 512K bits/sec, but all 512K may actually be transmitted in the first eighth of a second and the link might be quiet the other seven-eighths of the second. This bursty nature of data traffic can cause congestion downstream for any type of traffic, and it also causes jitter, which we all know is very bad for VoIP. Worse, if a burst of traffic is larger than the receive buffer in a router or switch, you will start to experience packet loss in what is commonly referred to as a "tail drop" scenario.
Traffic shaping solves this problem by allowing you to configure a router to transmit one-eighth of the packets from this flow above -- for example, at 125 ms intervals to distribute the traffic across the whole second. This allows all the devices downstream to keep up and prevents packet loss and reduces jitter. Of course, this necessarily adds some delay to a portion of the packets in that flow.
Traffic policing, on the other hand, is most often used in a crude way to simply maintain a rate. For instance, if a company subscribes to a metered Internet service and wants to keep their rate below a certain level, they could drop any HTTP traffic exceeding this rate using policing.
A good policing scheme can help your VoIP network in a number of ways. First, it can help you keep other traffic from trampling your VoIP by just dropping it. It can also augment your Call Admission Control (CAC) scheme by dropping the priority of additional voice calls to keep excess VoIP traffic from starving other queues. For example, if you're using a codec that sends 64K bits/sec per call and you want to support four calls at a time, you would assign a high priority to that traffic, then use policing to reduce the priority of any VoIP traffic that exceeds 256K bits/sec. (Note that this is just an example and is not appropriate for every network.)
Policing and shaping are not mutually exclusive technologies. They can often be used together. Again, for many networks, VoIP traffic is given a high priority and all other user traffic can be lumped together as low-priority. If your network has many complex requirements that often seem contradictory, policing and shaping may be tools you can use together to make the traffic behave in a precise fashion.
About the author:
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
Read all of Tom Lancaster's VoIP Tips.
Visit our extensive collection of Best Web Links on Voice/data Convergence.
This was first published in May 2002
Network Management Strategies for the CIO

Join the conversationComment
Share
Comments
Results
Contribute to the conversation