Traffic Policing Mechanism

Traffic Policing Mechanism
Traffic policing is the mechanism that monitors the admitted sessions' traffic so that the
sessions do not violate their QoS contract. The traffic policing mechanism makes sure that all
traffic that passes through it will conform to agreed traffic parameters. When violation is found
(e.g., more traffic is sent than was initially agreed upon in the QoS contract), a traffic policing
mechanism is enforced by shaping the traffic. Because traffic policing shapes the traffic based
on some known quantitative traffic parameters, multimedia (real-time) applications are
naturally compatible to traffic policing. Most multimedia application traffic (voice, video) is
generated by a standard codec which generally provides certain knowledge of the quantitative
traffic parameters. Traffic policing can be applied to individual multimedia flows. Non-real-time
traffic does not provide quantitative traffic parameters and usually demands bandwidth as
much as possible. Therefore, traffic policing enforces non-real-time traffic (i.e., limits the
bandwidth) based on the network policy. Such policing is usually enforced on aggregated nonreal-
time flows. Traffic policing can be implemented on end hosts or intermediate hosts.
Examples of traffic policing mechanisms include the leaky bucket and the token bucket.
3.5.1 Leaky Bucket
The leaky bucket mechanism is usually used to smooth the burstiness of the traffic by limiting
the traffic peak rate and the maximum burst size. This mechanism, as its name describes, uses
the analogy of a leaky bucket to describe the traffic policing scheme. The bucket's parameters
such as its size and the hole's size are analogous to the traffic policing parameters such as the
maximum burst size and maximum rate, respectively. The leaky bucket shapes the traffic with
a maximum rate of up to the bucket rate. The bucket size determines the maximum burst size
before the leaky bucket starts to drop packets.
The mechanism works in the following way. The arriving packets are inserted at the top of the
bucket. At the bottom of the bucket, there is a hole through which traffic can leak out at a
maximum rate of r bytes per second. The bucket size is b bytes (i.e., the bucket can hold at
most b bytes). Let us follow the leaky bucket operation by observing the example shown in
Figure 3.10. We assume first that the bucket is empty.
l Figure 3.10 (A): Incoming traffic with rate R which is less than the bucket rate r. The
outgoing traffic rate is equal to R. In this case when we start with an empty bucket, the
burstiness of the incoming traffic is the same as the burstiness of the outgoing traffic as
long as R < r.
l Figure 3.10 (B): Incoming traffic with rate R which is greater than the bucket rate r. The
outgoing traffic rate is equal to r (bucket rate).
l Figure 3.10 (C): Same as (B) but the bucket is full. Non-conformant traffic is either
dropped or sent as best effort traffic.
Figure 3.10. Leaky Bucket Mechanism
3.5.2 Token Bucket
The token bucket mechanism is almost the same as the leaky bucket mechanism but it
preserves the burstiness of the traffic. The token bucket of size b bytes is filled with tokens at
rate r (bytes per second). When a packet arrives, it retrieves a token from the token bucket
(given such a token is available) and the packet is sent to the outgoing traffic stream. As long
as there are tokens in the token bucket, the outgoing traffic rate and pattern will be the same
as the incoming traffic rate and pattern. If the token bucket is empty, incoming packets have to
wait until there are tokens available in the bucket, and then they continue to send. Figure 3.11
shows an example of the token bucket mechanism.
l Figure 3.11 (A): The incoming traffic rate is less than the token arrival rate. In this case
the outgoing traffic rate is equal to the incoming traffic rate.
l Figure 3.11 (B): The incoming traffic rate is greater than the token arrival rate. In case
there are still tokens in the bucket, the outgoing traffic rate is equal to the incoming
traffic rate.
l Figure 3.11 (C): If the incoming traffic rate is still greater than the token arrival rate (e.
g., long traffic burst), eventually all the tokens will be exhausted. In this case the
incoming traffic has to wait for the new tokens to arrive in order to be able to send out.
Therefore, the outgoing traffic is limited at the token arrival rate.
Figure 3.11. Token Bucket Mechanism