cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2109
Views
0
Helpful
6
Replies

Two Rates Policier-updating token bucket question

cristip
Level 1
Level 1

I am reading this document

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ft2RTplc.html

Search for the "Updating Tocken Bucket" paragraph if you need the original text

Here is the paragraph that is giving me a headache (question at the end in red)

Marking Traffic

The Two-Rate Policer marks packets as either conforming, exceeding, or violating a specified rate. The following points (using a packet of B bytes) illustrate how a packet is marked:

If (B > Tp(t)), the packet is marked as violating the specified rate.

If (B > Tc(t)), the packet is marked as exceeding the specified rate, and the Tp(t) token bucket is updated as Tp(t) = Tp(t) - B.

Otherwise, the packet is marked as conforming to the specified rate, and both token buckets—Tc(t) and Tp(t)—are updated as follows:

Tp(t) = Tp(t) - B

Tc(t) = Tc(t) - B

If the packet conforms then I substract its size from Tp and Tc

If the packet exceeds I substract its size just from Tp

Can anybody explain why?

In the case of single rate two buckets policier I either substract the size of the packet from the Bc bucket or from the Be bucket which seems

normal to me. Since you transmit one chunck of information I can not charge you twice

That doesn't seem to be the case for the two rates policier

Since the two buckets are independent I see it natural to charge both buckets when I send out packets.

1 Accepted Solution

Accepted Solutions

Hello Cristi,

I wonder how could you guess the short form of my first name :-) 

I do have some friends in Romania and I happen to be observant

My undestanding is that they are independent in the sense that the  credits (buckets) are filled up independently at constant rates (1/EIR  and 1/CIR)

However  it was also my understanding that when the router is sending out  traffic it will use credits from the first bucket and if those are not  enough it will use the second bucket complementary (borrow from there  just the difference needed to transmit the packet).

I believe I see the point of your confusion: the "Be" bucket is actually filled with the rate of 1/PIR, not 1/EIR as you suggested. The "Be" name is a misnomer here. We can continue using this name but be aware of the actual difference in this particular case.

So the Be bucket is filled with the rate of 1/PIR and the Bc bucket with the rate of 1/CIR. If you used only the Be bucket, ignoring the Bc bucket completely, you would be policing at the PIR rate. With both buckets, conformant traffic decrements both Be and Bc buckets, as it consumes both the budget from conformant and total traffic. The non-conformant exceeding traffic consumes only the Be bucket tokens.

See it this way: having enough tokens in the Be bucket for sending a packet mean that this packet would still conform to the PIR. It may or may not violate the CIR but that is not the Be bucket's business to check. The Be bucket only makes sure that the traffic does not exceed the PIR (that consists of CIR and EIR). In addition, the Bc bucket makes sure that the traffic is metered for the CIR rate, and if violates it, it can be remarked.

Once again, please feel welcome to ask further!

Best regards,

Peter

View solution in original post

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hi Cristi,

Recall that the two rate three color policer is giving you two independent sustained rates: the CIR and the PIR. The Bc bucket is refilled with the CIR intensity, the Be bucket is refilled with the PIR intensity. In fact, the Be bucket alone is capable of policing traffic to the rate of PIR=CIR+EIR, while the Bc bucket provides policing to the CIR.

In a very shorthand explanation: when a packet conforms, the tokens are subtracted from both Be and Bc buckets because

  • the conformant traffic decreased our budget for upcoming conformant traffic, hence the subtraction from Bc bucket
  • the conformant traffic decreased our budget for total upcoming traffic, hence the subtraction from Be bucket

When a packet exceeds, the tokens are subtracted only from Be bucket because they decrease our budget for the total upcoming traffic. However, because the packet exceeds, it is outside the subclass of traffic that can be termed as conforming. Because the two rate policer is supposed to give you two independent sustained rates - for conforming and for exceeding traffic, the exceeding traffic should not influence the upcoming conformant traffic - hence no tokens are subtracted from the Bc bucket for exceeding traffic. Otherwise, if you decreased the Bc bucket as well, your upcoming conformant traffic would be impacted, defying the idea of two independent sustained rates.

Does this make sense? Please feel welcome to ask further!

Best regards,

Peter

Hi Peter

Thanks for replying ...

I wonder how could you guess the short form of my first name :-)

Not sure I can wrap my mind around the two independent sustained rates.

My undestanding is that they are independent in the sense that the credits (buckets) are filled up independently at constant rates (1/EIR and 1/CIR)

However it was also my understanding that when the router is sending out traffic it will use credits from the first bucket and if those are not enough it will use the second bucket complementary (borrow from there just the difference needed to transmit the packet).

From what you are saying I understand that the router switches to the second bucket completely. If that is the case then I should substract the size of the packet being served either from one or the other bucket.

Thanks

Cristian

Message was edited by: Cristian Piatnitchi

Hello Cristi,

I wonder how could you guess the short form of my first name :-) 

I do have some friends in Romania and I happen to be observant

My undestanding is that they are independent in the sense that the  credits (buckets) are filled up independently at constant rates (1/EIR  and 1/CIR)

However  it was also my understanding that when the router is sending out  traffic it will use credits from the first bucket and if those are not  enough it will use the second bucket complementary (borrow from there  just the difference needed to transmit the packet).

I believe I see the point of your confusion: the "Be" bucket is actually filled with the rate of 1/PIR, not 1/EIR as you suggested. The "Be" name is a misnomer here. We can continue using this name but be aware of the actual difference in this particular case.

So the Be bucket is filled with the rate of 1/PIR and the Bc bucket with the rate of 1/CIR. If you used only the Be bucket, ignoring the Bc bucket completely, you would be policing at the PIR rate. With both buckets, conformant traffic decrements both Be and Bc buckets, as it consumes both the budget from conformant and total traffic. The non-conformant exceeding traffic consumes only the Be bucket tokens.

See it this way: having enough tokens in the Be bucket for sending a packet mean that this packet would still conform to the PIR. It may or may not violate the CIR but that is not the Be bucket's business to check. The Be bucket only makes sure that the traffic does not exceed the PIR (that consists of CIR and EIR). In addition, the Bc bucket makes sure that the traffic is metered for the CIR rate, and if violates it, it can be remarked.

Once again, please feel welcome to ask further!

Best regards,

Peter

Nice to hear about our common grounds ( romanian friends)

Though my last name is not a typlical Romanian one. It must be something else that made you beilieve I am Romanian

On topic:

-in other words when I receive a packet that conforms with Bc I know that it might count for both policiers Bc and Be for policing the traffic for that 1 second interval

-when I receive a packet that conforms with Be I know for sure that Bc doesn't count anymore for averaging the traffic for that 1 second interval...

thanks for helping me with this.

BTW could you recommend any good book for QoS topics? I am totally disapointed by the way these topics are explained on Cisco's site and in the books that I have seen

Each one of them seem to leave out some details and Cisco's site has fragmented explainations even for the router configurations

The two RFCs pointed here

  • RFC 2697 leavingcisco.com "A Single Rate Three Color Marker" - Cisco IOS Release 12.1(5)T
  • RFC 2698 leavingcisco.com "A Two Rate Three Color Marker" - Cisco IOS Release 12.2(4)T

are not very clear on the algorithms

Actually they are. What is not clear is what Cisco used/implemented in each case.

Hello Cristi,

Though my last name is not a typlical Romanian one. It must be something else that made you beilieve I am Romanian

To be perfectly honest, I was not absolutely sure, but your nickname "cristip" was an indication enough for me. Looking up your LinkedIn profile after you disclosed your surname only confirmed my original feeling.

when I receive a packet that conforms with Bc I know  that it might count for both policiers Bc and Be for policing the  traffic for that 1 second interval

Not just "might count for both policers" - it must count for both of them. Sending a conforming packet is going to consume a part of your total bandwidth (the PIR), and also it must be accounted towards consuming a certain portion of your CIR so that the budget is appropriately decreased for the next packet. Therefore, both token buckets must be deducted from.

when I receive a packet that conforms with Be I know for sure that Bc  doesn't count anymore for averaging the traffic for that 1 second  interval... 

I am not sure about this statement. If a packet conforms to Be bucket, it still can also conform to the Bc bucket as well. That is why the original decision diagram you posted contains comparisons with both Be and Bc buckets.

See it this way: it is the Be bucket that performs the actual rate limiting. The Bc bucket merely performs accounting whether - within the total PIR allowed by the Be bucket - we already consumed the CIR or not.

BTW could you recommend any good book for QoS topics?

Personally, I can recommend two:

http://www.ciscopress.com/bookstore/product.asp?isbn=1587201240

http://www.ciscopress.com/bookstore/product.asp?isbn=1587055384

Both are of older date and in need of updating but especially the first book is very good and the basic principles stand.

Best regards,

Peter

Above your observations are correct, my understanding was correct but the wording not the happiest.

Re: books -I was reading from the first one. Got confused by so many statements like these:

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800d7276.shtml#topic2

Here for CAR you clearly see 1 bucket for Bc and Be

In the first book you indicated, on page 343 they say

"CAR uses one or two token buckets to determine whether each packet conforms to or exceeds

a traffic contract."

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco