From: Dan Pontrelli (dp595@xxxxxxxxxxxxx)
Date: Sat Aug 11 2001 - 23:35:54 GMT-3
One thing that confuses me a bit is that I always understood Bc and Be to
apply to each interval/Tc and never heard anything about Be only applying to
the first interval/Tc.
I guess I'll have to read up more!!
Thanks for the excellent info.
I agree that in most production environments I'd agree with Pat's way. You
would not want to drop below your CIR/guaranteed transmission rate in
response to BECNs, therefore it makes sense to 'attempt' an average rate of
port speed and drop down to mincir/guaranteed rate during congestion.
I wanted to drop the rate down to 16k (below the guaranteed 48k) in this
'experiment.'
Thanks again,
Dan
> Hi Dan,
> I agree with your comment about why is timeslot 1 special. I'll quote
> directly from the QoS book P188
> "If not all Bc bytes are sent in a Tc interval, you can transmit the
unused
> bytes in the subsequent interval along with the new credit for Bc bytes.
> Hence, in a Tc interval during which there is less than Bc traffic, the
> credit can increase to an upper bound of Bc+Be for the next subsequent
> interval.
> If serious load sets in and the token bucket is full you can send Be+Bc
> bytes in the first interval and Bc bytes in each subsequent interval until
> congestion conditions ease. "
>
> This quote doesn't really say either way but it doesn't mention any
ability
> to build up Be credits which I think is what you are asking. I guess if Be
> credits can't be built up, the excess bits would be held over until the
next
> timeslot 1 comes around.I think on average this would work but it means
that
> a large packet would be delayed until timeslot 1 comes around again.
> There was a doc on the Cisco site which explained it better but now I
can't
> find it. The problem was that they assumed Tc=1 sec so it didn't really
> answer the question.
> I still think that if pushed for something like this in the lab I'd
probably
> do it your way.
> Regards,
> Lach.
>
> -----Original Message-----
> From: Dan Pontrelli [mailto:dp595@optonline.net]
> Sent: Sunday, 12 August 2001 11:20 AM
> To: lkidd@netstarnetworks.com; ccielab@groupstudy.com; 'Pat Bodin'
> Subject: Re: FRTShaping config
>
>
> 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