--------- Forwarded message ---------- From: "simon hart" To: "Private Ryan" Date: Sun, 9 Oct 2005 15:38:36 +0100 Subject: RE: rate-limit vs. police Ryan, I think you may have the wrong concept of Bc. Bc is committed burst, in traffic shaping this is the amount of bits that can be sent in one time interval. With policing if a period of time has passed since sending packets equivalent to 1000000 / 31250*8 = the number of packets to be sent. We need to work out how Bc works (before looking at Be and PIR). 31250 * 8 = 250000 bits, if you now divide 250000 / 1000000 = 250ms. In traffic shaping this means that after each 250ms has passed 250000 bits can be sent to line. As you can see that in a 1 second period we can send 250000 bits 4 times, which equates to the rate 1000000 bits per second. There is no excess, no 1250000 in this. With policing the manner by which the Bc reacts is kind of the inverse of above, however it achieves similar ends ( the reason it works in a different way from shaping is that shaping can queue the packets, then 'burst' them all out at the beginning of a time interval, policing has no queueing so it will continously 'leak' bits onto line). For the purposes of this argument (I think Chris maybe able to explain this more elegantly), if no packets have been sent for a period of longer than 250ms, we can assume that the token bucket can be 'given' a credit of 250000 bits (31250*8). A stream of packets arrive that equate to 250000 bits, because the bucket is full we can send all the packets to line. Okay 100ms pass and a stream of packets equivalent to 250,000 bits arrive. We know look at 100ms and determine how much we can fill our bc bucket. We know that after 250ms there will be 250,000 tokens in the bucket, therefore after 1 ms there would be 1000 tokens, thus 100ms would be 100,000 tokens. From this we can determine that of the 250,000 bits that arrived only 100,000 bits are going to get sent the other 150,000 are dropped. Now 350ms has passed and we have sent 350,000 bits to line and dropped 150,000 bits. You should be able to see from this that if I extrapolate further and we have a continous data stream offered, then after 1000ms 1,000,000 bits would get sent to line, no more no less. This is how bc works in policing, and is very important that you understand it. Bc is the rate at which we fill the token bucket! Not as you have shown some additional bits you can send in excess of the configured police rate. This is where Be comes into play. When we have Be configured (this is SRTCM and not CAR!! again pretty important) we have another token bucket, the size of this token bucket is defined by by Be. So with Be set at 1000, we have a Be token bucket of 8000 bits. This bucket gets filled if and only if the Bc bucket is full to overflowing. Here is how it works Again we have had a quite time on our interface, no packets have arrived for the last 1 second. A stream of 300,000 bits arrive. As before we look at our Bc bucket and determine that we can fill it with 250,000 tokens, thus 250,000 bits can be sent. However since we have had a quite time, we can overflow some tokens into the Be bucket, in fact we can allocate 8000 tokens into the Be bucket, therefore we can send 8,000 bits to line. So if we have an exceed action of set-prec 0 and violate-action of drop, we will have done the following Sent 250,000 bits to line with no modification sent 8,000 bits to line with prec set to 0 Dropped 32,000 bits 100 ms later another 300,000 bits arrive. As before we can determine that we can fill our Bc bucket with 100,000 tokens, thus we can send 100,000 bits to line. However the Bc bucket was not full to overflowing, therefore Be is empty, we cannot send any excess. So for this time period we have Sent 100,000 bits with no modification Dropped 200,000 bits If this were to continue in a similar fashion we should see that after 1s we would have sent 1,008,000 bits to line, of which 8,000 bits are modified with a prec of 0. So in this instance Bc is the rate at which both the Bc bucket and Be bucket are filled. Peak Information Rate Now in the MQC command we can configure and Committed Information Rate and a Peak Information Rate. This modifies the behaviour of the Bc and Be Buckets. They are refreshed independently: So lets say we have CIR 1,000,000 and PIR 2,000,000 and Bc of 31250 and Be of 31250. The exceed action is set dscp 16 and the violate action is drop. At each interval the Bc is checked based upon its rate of replenishment 31250/1,000,000 and the Be is checked based upon its rate of replenishment 31250/1,000,000. As you can see the Be token bucket is not reliant on the fact that the Bc has 'overfilled', the Be gets replenished independently (and in this example at the same rate as the Bc) Safe to say that the overall policed rate will be at 2,000,000 bps of which over a period of 1 s, 1,000,000 bits will be sent unmarked and 1,000,000 bits will sent with the dscp set to 16. HTH Simon --- Here's an EASY way to memorize them: Rich People In France Frequently Cruise In Norway Once you get that mnemonic device programmed into your brain, you can easily decrypt the most significant letter: Routing Priority Immediate Flash Flash Override Critical Internetwork Network ---