From: Andy (and123and@googlemail.com)
Date: Thu May 24 2007 - 07:21:27 ART
Ok, this is good info, if I can understand the Be token bucket I think I got
this :-)
Using same parameters
Router has AR of 384000
CIR of 192000
MinCIR 128000
Use default Tc and allow to burst up to AR.
frame-relay CIR 192000
frame-relay bc 24000
frame-relay mincir 128000
frame-relay be 24000
Once traffic shaping is enabled Bc and Be bucket are both full.
Bc bucket gets filled every Tc without fail, therefore 24000 credits every
Tc, if traffic to be sent is less than 24000 bits in a Tc, the extra is sent
to the Be bucket.
Say in 1st second we send 384000
The 2nd second we send at 192000, each second consists of (8 Tcs x 24000 =
192000).
Does this mean that the Be bucket does not get filled as there were no
"excess" Be credits!
How does the Be bucket get filled if the line is sending at Bc rate
continuously, does the Be bucket get filled at the start of each second?
each Tc? If there are no excess Bc credits how do the Be credits accumulate?
-A
On 23/05/07, DWINKWORTH@wi.rr.com <DWINKWORTH@wi.rr.com> wrote:
>
> Oops on the interval math in previous e-mail.
>
> You'll still get the 384000bps, but the intervals break out as follows:
>
> (1) Initial burst 216000 credit- 4.5 intervals to transmit - 120000
> credits earned
> (2) Second "burst" 120000 credit - 2.5 intervals to transmit - 48000
> credits earned
> (3) Third "burst" 48000 credit - 1 interval to transmit - 24000 credits
> earned.
>
> All this happens contiguously, so in the first second you get
> 384000bps. Subsequently, you only get your guaranteed CIR. You will
> not get another 384k in one second until you have had 1 whole second of
> quiescence.
>
> In real-life, you probably will not want to do this. Your carrier
> would probably allow you to transmit at 384k continuously, and expect
> you to rate down when you receive FECNs or BECNs. Some carriers will
> mark anything about CIR as DE ingress at their frame-relay switch,
> other carriers let YOU do your marking, so you can mark the traffic you
> want to be discard eligible.
>
> I believe using 'be' on a credit-basis amounts to what is known
> as "credit-based flow control" as opposed to "rate-based flow control."
>
> It has been my experience that most carriers use the "rate-based" flow
> control. So 'be' would always be 0. CIR would be your sustained rate
> (usually up to port on your spokes), and your minCIR would be your
> guaranteed rate. You would then configure adaptive-shaping for BECNs.
>
> In addition to this, I configure "frame-relay fecn-adapt." This
> causes the router to flip the BECN bit on in the next frame to leave
> the output queue. If no frame is present, the router generates a test
> frame. The reason I do this is sometimes the spoke will receive FECNs,
> but I will not see a corresponding BECN from the carrier at the other
> end of the PVC. This way the other end knows to slow down. Here's a
> map-class example.
>
>
> map-class frame-relay 64-256
> frame-relay cir 248000
> frame-relay bc 31000
> frame-relay be 0
> frame-relay mincir 62000
> frame-relay adaptive-shaping becn
> frame-relay fecn-adapt
>
> Also, Cisco recommends that you actually shape to 95% your port speed.
> In practice, I have substituted the words "port speed" in that sentence
> with "target rate." I know from direct experience that the traffic-
> shaper for frame-relay is not perfect. The actual send rate will drift
> above and below the configured rate. I have seen a PVC, on a daily
> basis, exceed the configured CIR by 13k. That was over a five-minute
> average. The configured CIR was 752000, so the five-minute average was
> 765000. The actual port speed was 768000. That is a pretty dramatic
> example, but its common for the actual rate to exceed the configured
> amount by a small percentage. Thus: Cisco's recommendation of 95%.
>
> I've been pretty successful with going somewhere around 97%.
>
>
> All this is way more then you originally asked. Nevertheless, there it
> is.
>
>
> ----- Original Message -----
> From: <DWINKWORTH@wi.rr.com>
> Date: Wednesday, May 23, 2007 1:55 pm
> Subject: Re: FRTS and Be - first interval?
> To: ccielab@groupstudy.com
>
> > If you interpret Cisco's documentation strictly (at least from
> > that
> > horrible document they have never corrected), then you have
> > reached
> > your maximum burst size by setting be at 24000.
> >
> > However, in reality, you can (as you propose) set your 'be' to
> > 192000.
> > After one second of quiescence you will have 216000 for credit.
> > During
> > the time frame that you transmit this, over seven intervals, you
> > will
> > have accrued an additional 168000 credit (one 'bc' per each of the
> > seven intervals). This will carry you through the rest of the
> > second
> > after the initial burst is exhausted, to give you 384000 bits in
> > one
> > second.
> >
> > There is documentation on Cisco's website that says that the
> > initial
> > burst is not limited by the first Tc, and that would seem to
> > validate
> > my own experience as well as others experience who previously
> > posted on
> > this list. see http://www.cisco.com/warp/public/125/21.shtml
> >
> > "If the Be is very big and, if at T0 the bucket is filled with Bc
> > + Be
> > tokens, you can send Bc + Be bits at the access rate. This is not
> > limited by Tc but by the time it takes to send the Be. This is a
> > function of the access rate."
> >
> >
> > ----- Original Message -----
> > From: Andy <and123and@googlemail.com>
> > Date: Wednesday, May 23, 2007 9:45 am
> > Subject: Re: FRTS and Be - first interval?
> > To: Edison Ortiz <edisonmortiz@gmail.com>
> > Cc: "Group Study (E-mail)" <ccielab@groupstudy.com>
> >
> > > Edison, its not a task or a question, its an understanding of
> > the
> > > way FRTS
> > > works. I'll try and explain as best I can.
> > >
> > > Documentation (cisco.com et al) says that Be is sent only during
> > > Tc1. If we
> > > have default Tc of 8 intervals, then I take this to read that Be
> > > is sent
> > > only during Tc1, then using the above example, if we configure
> > Be
> > > as 24000,
> > > then only 24000 is sent for each second (ie intervals Tc1 - Tc8).
> > > Therefore, if we have AR of 384000 and Be of 24000 and Bc of
> > 24000
> > > we have
> > > only 216000,
> > > (Be 8 x 24000) + (Tc1 1 x 24000) = 216000.
> > >
> > > Why not configure Be as 192000 as this would reach Ar of 384000.
> > > (Be 8 x 24000) + (Tc1 1 x 192000) = 384000.
> > >
> > > I get all the maths stuff, I also looked at the Token Bucket, I
> > > understandthe Token bucket gets filled (using our example) with
> > Bc
> > > = 8000 EVERY Tc.
> > > Could not find any info on the Be / Token bucket realtionship tho.
> > >
> > > Still Confused :-/
> > >
> > >
> >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART