Token bucket algorithm operation during a dual-rate policer

[Mitrixsen]

Hello, everyone.

When it comes to policing, there are policers that are known as dual-rate. This means that their operation is based off and can be adjusted by two values - CIR and PIR.

I understand that packets that fall under or are equal to the CIR are considered conforming. If the number of bytes in the packet exceeds the CIR but are within the PIR range, they are exceeding. If they go above the PIR, they are violating.

My confusion lies in the token bucket operation for this specific kind of policer. My study resource says the following:

If a packet is categorized as conforming (so its size in bytes is less than or equal to the CIR), why are tokens removed from the Be (PIR) bucket as well?

That's all, thank you.

David

[Joseph W. Doherty]

That statement might be an error unless it's taken as anything that has not exceeded Bc and Be is conforming (because you haven't totally run out of tokens - I touched on this in our recent discussions in your other threads, but believe you found my remark confusing - basically Be can be used to treat traffic like it met Bc, but you can use it otherwise too).

[Mitrixsen]

I might have missed that, my bad.

So if the action is conforming, tokens aren't removed from both buckets but only from the BC Bucket, even in dual-rate policers?

[Joseph W. Doherty]

"So if the action is conforming, tokens aren't removed from both buckets but only from the BC Bucket, even in dual-rate policers?"

Depends whether conforming is being used as within Bc allowance or whether traffic is not being dropped.

If you have an enabled Be, you should pull all tokens from the Bc bucket and only when it runs out, then draw from the Be bucket.

So, no to your question.

Again, to me, it appears that partial statement was made in error, or what conforming means switched from the Bc action to meaning not being discarded.

(I would to need to see more of the text, and context, to better guess whether an error or a jump in meaning.  BTW, learning texts are not always error free.)

[Mitrixsen]

I've been thinking about this for a while now, and I need some clarification if you have the time.

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 both buckets are full, so the CIR bucket has 16,000 tokens (128 kbps in bytes) and the PIR bucket has 32,000 tokens (256 kbps in bytes). If a packet with a size of 48,000 bytes (384 kbps) arrived. Wouldn't it still be considered as exceeding (due to the fact that there are enough tokens in both buckets) despite the fact that it's way bigger than both the CIR and the PIR?

Thank you.

[Joseph W. Doherty]

Yes, it would be considered exceedingly as it was accepted using Be.

If it was just 1 byte longer, it would be violating, and if being dropped rather than marked, would never get past the policer (a situation, for packet always too large, you can run into which some policer documentation warns of if Bc/Be is too small).

BTW, in the case of a real 48k packet, on Ethernet, the packet would be fragmented, and each fragment independently using Bc then Be and finally running the tokens dry.  In my example of a 48,001 packet, about first 1/3 of packet fragments are confirming, about the remaining 2/3s are exceeding, but that last byte is violating, and if dropped, precludes the receiver from reconstructing the whole packet, which in IP, will cause sender to resend all 48,001 bytes even though 48,000 successfully received.  Assuming retransmission subject to same policing, same result.  (NB: I'm ignoring all real considerations of fragmentation overhead and L2 overhead, which actually can be additional considerations using a policer or shaper - again, my deep rabbit hole warning.).  Oh, as a side, note IP on ATM, can run into similar issues, as individual cells, for the same packet, even a small IP packet needing two cells, loss of any packet's cell causes loss of whole packet.

[Joseph W. Doherty · Accepted solution]

I suspect the my prior reply doesn't make sense, partly that because it's an important difference whether you use a policer for marking or dropping.  (Also there are two very different ways to "recharge" Be, which makes a huge difference whether policing for marking vs. dropping.

If Be is recharged just like Bc, for dropping usage you'll obtain the same results for:

Police average rate Bc

And for

Police peak rate Bc Be

If average Bc equals peak Bc + Be

But if you use the two above policers for marking, you'll obtain different results, but they would be as you expect.

If the policer recharges its Be using unused Bc, dropping and marking behavior may differ from the full recharge Be policer, above, and the results will likely not be as expected (without deep analysis).  Also, dropping and marking results for the latter recharge method may also not agree wth each other (and likely would need deep analysis to explain why).

Unsure above, will help you beyond these features are more complex than they appear, but remember "Alice", in a prior thread I warned about going down the rabbit hole.  ; )