From: Brian Hescock (bhescock@xxxxxxxxx)
Date: Wed Nov 14 2001 - 17:57:45 GMT-3
Here's a good white paper about the token bucket, etc:
http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/carat_wp.htm
Brian
Wade Edwards wrote:
> I don't think there is a time relationship with CAR like there is with
> GTS and FRTS. I have not read the book you quoted but I have just went
> off what CCO say. That might be a mistake but it is the only place I
> have seen CAR discussed.
>
> I think the reason why the URL does not talk about the time relationship
> is because CAR has a constant time interval. If you look at the output
> of show interfaces hssi 0/0/0 rate-limit they show:
>
> Hssi0/0/0 45Mbps to R1
> Input
> matches: all traffic
> params: 20000000 bps, 24000 limit, 24000 extended limit
> conformed 8 packets, 428 bytes; action: transmit
> exceeded 0 packets, 0 bytes; action: drop
> last packet: 8680ms ago, current burst: 0 bytes
> last cleared 00:03:59 ago, conformed 0 bps, exceeded 0 bps
> Output
> matches: all traffic
> params: 20000000 bps, 24000 limit, 24000 extended limit
> conformed 0 packets, 0 bytes; action: transmit
> exceeded 0 packets, 0 bytes; action: drop
> last packet: 8680ms ago, current burst: 0 bytes
> last cleared 00:03:59 ago, conformed 0 bps, exceeded 0 bps
>
> It is labeled as bps which means bits per second. So the interval from
> this seems to be one second. I wish I had the book you are talking
> about but I will try and find one and check it out.
>
> Like I said I have only looked at CCO so that is what I am basing my
> comments on.
>
> The book talks about token buckets and the URL says nothing about token
> buckets so I still don't know who is correct. I guess the best thing is
> to get a smartbits device and start blasting packets at a router with
> CAR defined and play with the numbers and see what it does. I don't
> have access to such equipment so I am left to speculation.
>
> L8r.
>
> -----Original Message-----
> From: R.J.Neill Craven [mailto:ncraven@cravenworks.com]
> Sent: Wednesday, November 14, 2001 12:50 PM
> To: Wade Edwards
> Cc: ccielab@groupstudy.com
> Subject: RE: How to calculate CAR?
>
> Unfortunately the referenced URL does not explain the time
> relationship between Bc and CIR. Have a look at "IP Quality of
> Service", Srinivas Vegesna, Cisco Press, 2001. Although I don't agree
> with the definition of conformed burst on page 43 (I think it should
> read "This is the amount of traffic that is allowed to ENTER the
> token bucket ...") I find the discussion to be quite good.
>
> As for rate limiting versus traffic shaping, I believe they both make
> use of the same tools but have different contexts. Using my earlier
> analogy to salary, rate limiting controls the amount of money that is
> made available (how much is put in the bank), whereas traffic shaping
> controls the way the money is spent (how it is removed from the
> bank). For example, when I was at school I received an allowance of
> $4 per week. (Yes, that was many years ago!) How I chose to spend my
> allowance was independent of the rate at which I received my
> allowance. The only absolute rule was that I couldn't spend my
> allowance faster than I received it.
>
> In the realm of switching, I think of a bucket with two spigots, one
> allowing the bucket to fill (or accept traffic to be processed) by up
> to Bc bytes every Tc seconds (rate limiting), and a second, defining
> the rate at which the bucket is emptied (traffic shaping), again
> defined by a CIR, Bc, and Tc. The former can be quite coarse (lumpy?)
> in that the arrival of data in the bucket can be quite bursty,
> whereas the delivery of the data to the network might need to be
> quite smooth. In either case, though, we define the desired rate
> (CIR) and establish the bursty nature of the traffic by manipulating
> the Bc to obtain the desired Tc. The smaller the Tc, the lower the
> tolerance to burstiness and visa versa.
>
> Cheers,
> Neill
>
> At 11:24 AM -0600 14/11/01, Wade Edwards wrote:
> >I think you are thinking of CAR like GTS or FRTS which are traffic
> >shaping technologies. This is the document that I have always used
> with
> >CAR.
> >
> >http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/c
> a
> >r.htm
> >
> >It gives some examples and states that CAR propagates bursts. It does
> >no smoothing or shaping of traffic as you state in your email. BTW I
> >really liked your explaination.
> >
> >Give it a look and let me know.
> >
> >L8r.
> >
> >-----Original Message-----
> >From: R.J.Neill Craven [mailto:ncraven@cravenworks.com]
> >Sent: Wednesday, November 14, 2001 11:01 AM
> >To: Wade Edwards
> >Cc: tom cheung; kevin@btamail.net.cn; ccielab@groupstudy.com
> >Subject: RE: How to calculate CAR?
> >
> >
> >Wade,
> >
> >I have very different view as to how CAR works! The first number
> >(1544000) is indeed the bit rate, but the remaining two values are
> >NOT in addition to the first. The second, the burst (in bytes) and
> >sometimes referred to as Bc, helps to indicate the size of the token
> >bucket and is used to determine the time over which the traffic is
> >rate limited (Tc). In particular, Tc=Bc*8/CIR. The "*8" is used to
> >convert the bytes of Bc to bits.
> >
> >Tc is a very important parameter in rate limiting or traffic shaping.
> >Suppose as a new CCIE you are offered a salary of $120,000 per year
> >but you are offered several payment strategies. You could take one
> >payment of $120,000, or 12 payments of $10,000, or 24 payments of
> >$5,000, or .... I have never been very good at budgeting money so I
> >would choose to spread the salary over more periods. In other words,
> >I want the salary to arrive at a fairly even rate. Someone else might
> >prefer the lump sum approach. Any way you look at it though, we are
> >only getting $120,000 per year, each! In the context of CAR (and
> >disregarding the bits and bytes business) I would define the rate
> >limit for my salary as "rate-limit input $120000 $5000 $5000". Tc
> >would be 5000/120000 or 1/24th of a year giving me 24 payments of
> >$5000 each.
> >
> >I think you will agree that having some way to define the time over
> >which the rate is limited is particularly useful. We just need to be
> >clever about how we choose the Bc to achieve the right Tc.
> >
> >The third parameter (typically called Be), is the excess burst and in
> >the context of of my pay, indicates the maximum I can be paid during
> >each pay cycle. Perhaps I have an overtime provision in my contract
> >which allows me to accumulate additional pay credits. But the company
> >can limit their exposure by indicating that they will not pay more
> >than a certain total amount during each period. And they will not let
> >me work overtime continuously, either. So if I try to inflate my pay
> >package by working a lot of overtime, they are going to stop me
> >working overtime, period! Suppose I am allowed to accumulate $1,000
> >in overtime pay in addition to my regular salary, I would define this
> >as "rate-limit input $120000 $5000 $6000".
> >
> >So, Kevin, to get your desired effect, I would have used "rate-limit
> >input 154000 6000 8000" or something similar to allow for bursts of
> >1/3rd of the average rate. (Adding 1/3rd to 6000 bytes makes 8000
> >bytes; 8000 bytes during the same period increases the rate by 1/3rd
> >or approximately the difference between 1.544 Mbps and 2.048 Mbps.)
> >You could use bigger values than 6000 and 8000, so long as you keep
> >the ratio of 3 to 4.
> >
> >Cheers,
> >Neill
> >
> >At 9:33 AM -0600 14/11/01, Wade Edwards wrote:
> >>The rate-limit command you specified is going to allow 1.544Mb normal
> >>traffic then allow another 2.048Mb of burst traffic then it will drop
> >>all traffic after 3.592Mb. The numbers should be 1544000 63000 63000.
> >>This will give you 1.544Mb normal traffic then allow another .504Mb
> >>(63000 bytes x 8 gives you 504000 bits or .504Mb) for a total of
> >2.048Mb
> >>of traffic then all traffic will be dropped.
> >>
> >>The burst numbers are in addition to the normal traffic and the second
> >>and third numbers are in bytes and the first number is in bits. Hope
> >>this helps.
> >>
> >>L8r.
> >>
> >>-----Original Message-----
> >>From: tom cheung [mailto:tkc9789@hotmail.com]
> >>Sent: Tuesday, November 13, 2001 8:03 PM
> >>To: kevin@btamail.net.cn; ccielab@groupstudy.com
> >>Subject: Re: How to calculate CAR?
> >>
> >>
> >>rate-limit in 1544000 256000 256000 conform transmit exceed drop
> >>
> >>
> >>>From: Kevin <kevin@btamail.net.cn>
> >>>Reply-To: Kevin <kevin@btamail.net.cn>
> >>>To: "ccielab@groupstudy.com" <ccielab@groupstudy.com>
> >>>Subject: How to calculate CAR?
> >>>Date: Wed, 14 Nov 2001 9:18:52 +0800
> >>>
> >>>Hello all, I do learn Commit Access Rate(CAR).
> >>>I found there are three parameter about car.
> >>>If I want to give one my custom a contract bandwidth on FastEthernet
> >>which
> >>>commit access rate 1.544M and burst size is 2.048M. How to setup the
> >>second
> >>>and third parameter on "rate-limit" command. Of course the first
> >>parameter
> >>>is 1544000, but which value is precision for normal burst size and
> max
> >>>burst size.
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:15 GMT-3