Re: Question about Bc

From: Richard Kleimon (richk@knowledgenet.com)
Date: Sun May 04 2003 - 22:44:11 GMT-3


This is something a friend I worked with posted on group study once. QOS has
been escaping me and I only have weeks to go before my test. I found this
today and it helped me, so maybe it will do the same for you.

Larry Roberts wrote:

>

Shaping mechanisms, such as Frame Relay Traffic Shaping (FRTS) and

Committed Access Rate (CAR) use a token bucket mechanism. The token bucket
basically regulates the amount of data that can be sent during a time
period. Data can only be sent if there are enough free tokens in the token
bucket equivalent to that amount of data. If there are enough tokens, the
data is sent and the appropriate amount of tokens are removed from the Token
Bucket. If there is not enough tokens, the router will buffer the data until
the Token Bucket has enough tokens to send the data and then remove the
appropriate amount of tokens.

There are many terms and formulas you must understand to grasp

this concept:

CIR (Committed Information Rate) - This is the average amount of data

that either you (or your service provider) wants you to be able to send.

Bc - (Committed Burst) - This is the amount of data that can be sent

during a time interval. There is really no bursting at this point. This is
just the amount of data that you are allowed to send each time interval to
meet your CIR.

Be - (Excess Burst) - Here is where bursting happens. This is

Normally the difference between your CIR and actual line access rate (or
another pre-defined parameter by your service provider).

Be + CIR = the depth of the token bucket

Bc = the rate at which tokens are added to the bucket

Now, in order to put all of this together we need one more important

Piece of data. That piece of data is the time interval or Tc.

Tc = Bc/CIR

This usually comes out to 0.125 or 125ms. This is the default setting on
Cisco routers.

Example - I have a 128k Frame Relay circuit. I have configured the CIR

as 64k. By default, the Tc is 125ms. So, 0.125 times 64,000 = 8,000.

Therefore, my default Bc is 8,000. Therefore, my token bucket fills at this
rate and allows me to send 8k every 125ms. 125ms is one eighth of a second.
So, 8,000 times 8 equals 64,000 or 64k per second. Now, my actual line speed
is 128k. I can configure a Be of 64k. This will allow my Token Bucket to
fill to a capacity of 128k. This means that if I don't send any data for a
period of 128,000 divided by 8,000 = 16 time intervals, which equals 2
seconds, my token bucket will fill to capacity and during the next time
interval I can send 128k worth of data or burst to 128k. However, I would
then go into a period of quite time where I couldn't send any data at all
until the token bucket filled back up to CIR, which would be CIR (64,000)
divided by Bc(8,000) = 8 time intervals or one second.

Now, this is probably the perfect example of how to do this right.

-Rich

----- Original Message -----
From: "Joe Chang" <changjoe@earthlink.net>
To: "j" <wkfrktpdy@hotmail.com>; <ccielab@groupstudy.com>
Sent: Monday, May 05, 2003 6:17 AM
Subject: Re: Question about Bc

> Interesting question. Why is the recommended Tc interval in CIR 1.5
seconds
> while the maximum interval in FRTS is 0.125 sec ?
>
> Keep in mind that during congestion FRTS buffers unsent traffic in a
limited
> size queue. It would be desirable for the token bucket algorithm to be
> re-evaluated more frequently than less, so that the queue can be relieved
> more often , avoiding packet drops.
>
> In CAR, traffic that cannot be sent is discarded, so there is not the same
> sort of penalty in FRTS for longer intervals.
>
> ----- Original Message -----
> From: "j" <wkfrktpdy@hotmail.com>
> To: <ccielab@groupstudy.com>
> Sent: Sunday, May 04, 2003 6:37 AM
> Subject: Question about Bc
>
>
> > In calculating CAR parameters, in
> > Bc= CIR * (1byte)/(8bit) * 1.5
> > Why is it necessary to multiply 1.5 at the end??
> > Most of the configs I saw had Bc=CIR/8



This archive was generated by hypermail 2.1.4 : Mon Jun 02 2003 - 15:13:37 GMT-3