From: DWINKWORTH@wi.rr.com
Date: Wed May 23 2007 - 17:09:11 ART
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 :-/
> >
> >
>
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART