QoS Traffic Policing Explained

Lessons Discussion
102

Thanks very much Laz.

1 Like
103

Hello, everyone.

The dual-rate policing makes sense to me apart from 1 thing

When it comes to this

obrĂĄzok
obrázok758×532 60.7 KB

Say that the TC is 1 second (let’s ignore any extra details about it being 1/4 of a second and such to keep things simple). The CIR is 128 kbps and the PIR 256 kbps.

If the packet does not conform and the number of bytes of the packet is less than or equal to the number of tokens in the PIR bucket, the packet is exceeding. The policer will remove the required tokens from the PIR bucket

Why aren’t tokens removed from the CIR bucket too? Imagine this:

CIR: 128 kbps
PIR: 256 kbps

A 256-kbps packet arrives. The action is exceeding, the PIR bucket is emptied. However, the CIR bucket still stores tokens, so doesn’t this mean that if a 128-kbps packet arrived, it could still be sent? Which of course goes over 384 kbps per second. Or is the CIR bucket emptied in this case too?

Thank you.
David

105

Hello David

The logic of the Dual rate three color policer is the following:

  1. Conforming packets will remove the same number of tokens from both buckets.
  2. Exceeding packets will remove tokens only from the PIR bucket
  3. Violating packets will not remove any tokens from either bucket.

Now exceeding packets will only remove tokens from the PIR bucket and not the Bc bucket because exceeding packets are packets that go beyond the CIR but are still within the PIR. The logic behind removing tokens only from the PIR bucket and not the CIR bucket lies in how the two buckets are conceptually designed.

  • The CIR bucket represents the “guaranteed” rate of traffic that the network can handle without degradation. It enforces the primary rate at which the traffic is considered conforming. Once traffic exceeds this guaranteed rate, it is no longer tied to CIR, and thus the CIR bucket (Bc bucket) is no longer relevant for that traffic.
  • The PIR bucket allows for additional bursts beyond the CIR, up to a higher threshold. It provides a mechanism for handling temporary traffic spikes without dropping all traffic above the CIR. For packets that exceed the CIR but remain within the PIR, tokens are removed only from the PIR bucket because this traffic is classified as “excess” but still acceptable under the broader policy.

If you remove tokens from the CIR bucket as well as for exceeding packets it would incorrectly represent these packets as conforming to the committed rate, which they are not, resulting in an artificially degraded performance. Instead, these packets consume resources allocated for bursts only (PIR bucket), allowing the Bc bucket to remain dedicated to actual conforming traffic.

If exceeding packets also reduced tokens from the CIR bucket, it could deplete CIR tokens unfairly, causing future packets that should be conforming to be misclassified as exceeding or violating.

The scenario you describe is a possibility. However, in practice, if you come to the point where you are exceeding, and you remove tokens from the PIR bucket, it is highly likely that the tokens of the Bc bucket have also been depleted to a certain degree from previously conforming traffic. Remember, traffic is considered exceeded if there aren’t enough tokens in the Bc bucket. This is usually due to the fact that the bucket is depleted.

So you will find that even if a packet arrives that is causing an exceeding situation beyond 128kbps, it is likely that the previous packets that arrived were conforming, and had already depleted the Bc bucket to a certain degree. So when you get to the exceeding packet, only tokens from the PIR bucket are removed, and the very next packet that is conforming will be dealing with an already depleted bucket, so you will never see a BC+PIR situation as you describe. Does that make sense?

I hope this has been helpful!

Laz