From: Dan Pontrelli (dp595@xxxxxxxxxxxxx)
Date: Sat Aug 11 2001 - 22:20:11 GMT-3
You mentioned that from reading the Ciscopress QoS book that Be can be used
in the "1st interval" if the bucket is full.
Can it only be used in the first interval? If not I have a problem with
that.
This makes me think about the following situation:
CIR= 64k
Bc = 6000
Be=16000
In the 1st interval there is only 2,000 to send (out of a possible 22,000 or
Bc+Be). So the 2nd interval would get a credit for the 4,000Bc that was not
used during the 1st interval. I understand this, but would the 2nd interval
still be able to use the full Be since the 1st interval hasn't used it? It
think it should, otherwise even if we max every other interval we are not
able to achieve 64000 just because the 1st interval did not use enough
bandwidth (and why should the first interval or anyone else for that matter
get special treatment? :-). We would have:
2000,10000,6000,6000,6000,6000,6000,6000 = 48000
If the 2nd interval were allowed to use Bc+Be+credit or
6000+16000+4000=26000, then we can still achieve 64000 as follows:
2000,26000,6000,6000,6000,6000,6000,6000=64000
Thanks for your comments.
Dan Pontrelli
> 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
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:49 GMT-3