From: Lachlan Kidd (lkidd@xxxxxxxxxxxxxxxxxxx)
Date: Tue Aug 14 2001 - 06:15:38 GMT-3
Hi Weibing,
I'm not saying that Be is used just in the first interval. What I'm say
ing
is that in the first interval a total number of bits equal to Bc+Be can be
sent without any credit build up in the token bucket. After that first
interval however, Be is equal to whatever is left in the token bucket from
the previous time interval. Without wishing to confuse matters futher, this
is how I think it goes together.
First I'll define some symbols
Bc=Configured comitted burst
Be=Configured comitted burst
Bcn=Burst committed in the nth interval (Bc1=Burst committed in the 1st
interval, Bc2 second interval etc). This is the actual number of bits sent
in a given interval.
Ben=Burst excess in the nth interval (similar to above)
Therefore if we look at each time interval, the number of bits possibly
transmitted is
1st interval
Be+Bc
2nd interval
Bc2+Be2
where Be2=Bc-Bc1 (i.e. what is left in the token bucket from the previous
interval)
3rd interval
Bc3+Be3
where Be3=Bc-Bc2
and so on.....
This is pretty much how the Ciscopress QoS book describes it on Page 188
HTH,
Lachlan
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
weibing gu
Sent: Tuesday, 14 August 2001 6:00 PM
To: Lachlan Kidd
Cc: CCIE LAB
Subject: Re: RE: FRTShaping config
Hi,
You can read at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2009.htm#xtocid13460
23
It said that the MAXr=(Be+Bc)/Bc*CIR.
So the be is used every interval, not the first interval.
>Hi Dan,
> Looks pretty good to me. The only comment I would make is as follows.
>Cisco's doco of the FRTS parameters is pretty dodgy. The doco around on
this
>is really inconsistent. The web site has a number of examples where the
>calculations have been done exactly how you've done them. If I was in a lab
>environment I would do them that way. However, Pat Bodin (who works for
>Cisco) on this list posted a mail in which he showed a different way of
>calculating the parameters. From more reading his way makes more sense. Pat
>are you still out there ? Any comments ?
>From reading the Ciscopress QoS book, Be is the amount of excess bust data
>that can be sent during the first time interval (Tc) if the token bucket is
>full. After that first time interval if there is less than Bc bits
>transmitted in any given time interval, credit is built up such that in the
>next time interval up to Bc+Be bits can be transmitted. O.K, taking this
and
>applying it to an example like yours...
>Lets assume that in the first Tc interval (125ms), there is 14000 bits to
>send. Because this is the first Tc we can send Be+Bc bits, so that's fine,
>everything can go. Next Tc (250ms) we've got 8000 bits to send. We've got
no
>credit built up so we can only send Bc (6000) bits. So we've got 2000bits
>left over. Next Tc(375ms) we've got 2000 bits to send plus 2000 bits from
>the last Tc so 4000 bits go out. We've not used our total credit for this
Tc
>so next time round we can send 8000 bits out.
>O.K.....If what I've said is correct and taking your figures we get
>14000, 6000,6000,6000,6000,6000,6000,6000=56Kbits/sec (max)
>or if we had really bursty traffic we could get
>14000,0,12000,0,12000,0,12000,0=50Kbits/sec
>Now, if we set Be=16000 we get
>22000, 6000,6000,6000,6000,6000,6000,6000=64Kbits/sec
>Just to prove that the web site indicates your way is correct
>http://www.cisco.com/warp/customer/788/voip/fr_traffic.html
>Look at the data PVC example. But I'm still not convinced. Anyone else got
>any comments ?
>
>HTH,
> Lachlan
>
>
>----Pat's original mail----
>This should help!
>
>Terminology:
>
>Tc = Bc/Cir ! time interval (the internalized version of Tc where the
> time interval can't exceed 125ms)
>
>CIR = Average rate you want to send out (This is generally not the
> same as the CIR you get from your provider unless you aren't
> allowed to send above CIR) This is measured in bits/second.
>Bc = Amount of data to send per each Tc interval. This is
> measured in bits.
> (this also gets internalized and real amount of data sent per
> interval is expressed in bytes by the "increment" variable).
>Be = Amount of excess data allowed to be sent during first
> interval once credit is built up. Also measured in bits.
>
>Mincir = Minimum amount of data to be sent during periods of congestion.
> This defaults to half of CIR.
>
>Interval = Bc/CIR with the maximum size being 125ms.
>
>byte increment = Bc/8 . Must be > 125. Upper side has no bound
> or limitation except if interval is locked at 125ms.
>
>limit = byte increment + Be/8 (measured in bytes)
>
>--------------------------------------------------------------------
>
>OK let me throw some numbers in which may help explain this better.
>
>Let's say you have a frame relay link with following parameters:
>
>Physical port speed 64KB
>CIR = 16KB (In this case I mean CIR your provider has guarenteed
> you in their network)
>
>Now let's say your provider has told you that you can send data on your PVC
>up to port speed as long as there is no congestion in their network but
that
>when there is congestion they will only guarantee you CIR on your PVC.
>
>Here is what you should configure on the router:
>
>encap frame-relay
>ip address 10.10.10.1 255.255.255.0
>frame-relay traffic-shaping
>frame-relay map ip 10.10.10.2 200 broadcast
>frame-relay interface-dlci 200
> class 64KB
>
>
>map-class frame-relay 64KB
> frame-relay cir 64000 ! This is rate you want to normally send at
>when
> there is no congestion
> frame-relay bc 8000 ! This is amount you will send per interval.
> rule of thumb is to make it 1/8 CIR
> frame-relay be 0 ! This is extra amount to send in first
> interval. In this case you are already
> sending at port speed so this should be 0.
> frame-relay mincir 16000 ! This is what you will slow down to during
> congestion. This should be set to your
true
> CIR that your provider has guarenteed you
>when
> there is congestion in their network
>
>*Note that BECN Response(ie dropping down when receiving BECNs) is
> enabled by default in 11.2
>
>Now here are a couple of other numbers that are used in traffic shaping:
>
>Tc= Bc/CIR where Tc is the measurement interval. This value should
> be no larger than 1/8 second for good shaping to take
affect.
>
>So in above example Tc = 8K/64K = 1/8 second
>
>So basically here is what you would see transmitted in 1/8 second
intervals:
>
>8000(Bc+Be), 8000(Bc), 8000, 8000, 8000, 8000, 8000, 8000
>
>which equals 64000bits/second.
>
>Now if you actually had a 128KB port speed but you left all numbers the
same
>except you changed Be = 64000 then here is what you would see.
>
>72000, 8000, 8000, 8000 ....
>
>You would keep sending at Bc(8000) until you had an idle interval or only a
>partially used interval and you built up credit again. The maximum credit
>you
>can build up is Be.
>
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>Dan
>Sent: Sunday, 12 August 2001 8:44 AM
>To: ccielab@groupstudy.com
>Subject: FRTShaping config
>
>
>Can someone take a look at my config and let me know if it is correct?
>
>I'm trying to accomplish the following:
>
>CIR is 48k burstable to 64k. BECN will be sent by provider.
>I want to lower the speed to 16k when receiving BECN and I'm using Tc of
>125ms.
>
>
>interface Serial0
> ip address 101.1.6.71 255.255.255.224
> encapsulation frame-relay
> frame-relay traffic-shaping
> frame-relay class shape
> frame-relay map ip 101.1.6.74 102 broadcast
> no frame-relay inverse-arp
>
>
>map-class frame-relay shape
> frame-relay cir 48000
> frame-relay bc 6000
> frame-relay be 8000
> frame-relay mincir 16000
> frame-relay adaptive-shaping becn
>**Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
Guwb
guwb@gd.bank-of-china.com
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:50 GMT-3