From: Michael Snyder (msnyder@revolutioncomputer.com)
Date: Tue Feb 17 2004 - 01:03:06 GMT-3
If you do the math, `be` does very little. It only kicks in when the
full bandwidth isn't being used, during the first interval of the data
transfer.
"If I wanted to add some icing to the cake and try and increase the
throughput knowing some stuff from the provider (aka Available Rate),
then I could use Be to augment."
Let's see, I'm sending a 40 meg file over a T1. My cir is 768 kbs, and
my be of (96000 b/s) kicks in one time during the transfer.
40 meg = 41943040 bytes, 335544320 bits
Doing 768000 bits per second, 437 seconds.
96000 bits = 12000 bytes, roughly 11.7 kB of extra bandwidth (one time)
during that 7 and 1/2 minutes.
In summary, your icing isn't icing, more like a very thin layer of
powered sugar.
(I think) `Be` is mainly used to fill the outgoing fifo interface queue
before it gets to the frame-relay circuit. It primes the pump, because
if you don't fill the fifo queue at first, none of your other queuing is
activated. Just my take on it, `be` was a fix and not a feature.
-----Original Message-----
From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
Sent: Monday, February 16, 2004 7:20 PM
To: Scott Morris; ccielab@groupstudy.com
Subject: RE: FRTS question
Scott,
If, in my first example of R1/R2, I was only trying to throttle R1 to
not overrun the 64K of R2.
That being the case I should be like this:
R1: CIR=64000, Bc=8000, Be = 0, mincir = 32000, adaptive BECN
R2: CIR=64000, Bc=8000, Be=0, mincir=32000, adaptive BECN
yes?
And, my confusion arises on internetworkexperts page 8 Be descrition.
It says its the number of non-committed bits allowed to be sent above Bc
DURING THE FIRST INTERVAL (Tc). Then, Be builds more credits based upon
unused Bc from any interval or bit rate period.
I guess a better way to look at it is that we vary Bc to alter the time
interval (Tc) for time sensitive applications.
If I wanted to add some icing to the cake and try and increase the
throughput knowing some stuff from the provider (aka Available Rate),
then I could use Be to augment.
Would that be a fair analogy?
andy
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Monday, February 16, 2004 4:44 PM
To: Edwards, Andrew M; ccielab@groupstudy.com
Subject: RE: FRTS question
One of the entertaining things with QoS and traffic shaping stuff is
that
everything revolves around math. Sometimes that is a fairly evil
concept,
and we come up with the concept of token buckets to assist us with this
idea, but it still all goes towards basic math.
The tokens are a fleeting concept that has to do with how many bits can
possibly be sent out over 'x' period of time. At 128000 bits per
second,
consider that 128,000 tokens. Now if I tell you that your Tc is 125ms
(1/8
sec) that means your theorhetical maximum is 128,000/8 or 16000
bits/tokens
per second. How you divide that up is entirely up to you. The tokens
are
the same per interval, because it's representing the actual amount of
traffic that can be sent.
Where things get a bit freakier has to do with the timing. Consider my
128k
line (16k bits per second theorhetical max) and I decide that my CIR
will be
64k. So I'm dividing that in half. 8000 will be my Bc. Now, looking
at
pure serialization speed it is possible that I send them all out at the
beginning of a timing interval. If lots of traffic comes in and I'm
pumping
things out at wire speed, if my theorhetical maximum transmission if
16000
bits per 1/8 of a second that means that I can send 8000 of those bits
(my
Bc) out in 1/16 of a second! It also means that the tokens allocated to
my
committed burst (Bc) are depleted for that interval. When the target
line
of 125ms passes, I'll get 8000 more tokens to play with.
Be relates to the intervl in the same fashion. It is capable of being
any
delta between the Bc level and the maximum (AR) level. If we were
maxing
out Be here, it would be another 8000 tokens. Again, per 1/8 of a
second
interval.
They can be used in the same fashion. It's typically not the case when
we
are talking about bursting to port speed, because that maxes us out at
the
theorhetical max anyway. But if 64k is my CIR and I can burst to 96k,
then
that leaves some time that may be unfilled.
With Bc of 8000 and Be of 4000 and a theorhetical max of 16000, I could
send
both Bc and Be in 3/32 of a second. Leaving 25% of each interval unable
to
send any information at all, because the tokens aren't there.
So that's the relationship where things become confusing and diluted.
But
in the end, it's all just math! And we have to think about the
relationship
of each of the numbers towards whatever goal we are looking to achieve!
As for your calculations:
Thus, a simple frame relay R1 @ 128Kbps circuit guaranteed at 64kbps to
R2 @
64kbps circuit guaranteed to 32kbps would
be:
R1: CIR=128000, Bc=8000, Be = 8000, mincir = 64000, adaptive BECN
R2: CIR=64000, Bc=8000, Be=0, mincir=32000, adaptive BECN
With these things the argument is going to be on what you believe you
SHOULD
get versus what your guarantees are. In both of your examples, with a
Bc of
8000, you're coming up with strange numbers. On R1, a CIR of 128000 and
Bc
of 8000 gives a Tc of 1/16 sec. be is a value above the CIR target.
(somewhere between CIR and AR)
In your second example, you should be able to create settings based on
the
end destination, unless your commitments at R1's side are less than that
of
the other end. The goal is not to overflow the destinations.
I'm not sure what IPExpert slide show discussion you're talking about,
but I
assume you mean the Internetworkexpert one. :) it's a good
presentation,
but there's still a bit of magic behind that! It's all in good fun
though.
Hope that helps explain things a little bit better, or at least adjust
the
perspective a little bit. I think my token bucket needs filling. I'm
off
to dinner!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edwards, Andrew M
Sent: Monday, February 16, 2004 5:18 PM
To: ccielab@groupstudy.com
Subject: Re: FRTS question
Alright,
I have looked through the IPexpert slide show discussion, read solie PS
I,
Caslow 2nd Ed., and even looked on CCO but I'm seeing what appear to be
inconsistencies on the way FRTS is explained, particularly Be... and
also
implementing FRTS successfully by interpreting the given requirements.
So I have a 2 part question....
First, how does Be relate to the interval? Specifically, here is how I
have
seen it explained:
- I have seen Be operation discussed as Bc tokens depleted in the
interval
then the router can use up to Be tokens within the current interval.
After
that, no more Be can be sent during remainder of ALL intervals for the
bit
rate period. IOW, Be tokens are depleted over the ENTIRE BIT RATE
PERIOD,
not per interval.
- I have also seen Be operation discussed as Bc tokens depleted in the
interval then the router can use up to Be tokens within the interval.
After that, Be tokens are replenished for the next interval. This
behavior
occurs over ALL intervals for the bit rate period. IOW, Bc token
settings
are valid per interval.
Can someone please expound upon which one it is?
The second question relates to recommended methodologies to 'interpret
FRTS
requirements'. I will use the following 2 simplified examples of how to
interpret requirements, the first is my understanding (looking for
confirmation from peers) and the second is looking for how my peers
would
interpret these requirements.
First -
My understanding is that by definition of Bc and Be being per interval,
it
would seem that they are tokens being replaced per interval over the bit
rate period. Thus, a simple frame relay R1 @ 128Kbps circuit guaranteed
at
64kbps to R2 @ 64kbps circuit guaranteed to 32kbps would
be:
R1: CIR=128000, Bc=8000, Be = 8000, mincir = 64000, adaptive BECN
R2: CIR=64000, Bc=8000, Be=0, mincir=32000, adaptive BECN
Is this correct?
Second -
If I have a hub and spoke FR topology, R1 is hub, R2/R3 are spokes. R1
has
serial interface that operates at 1.544Mbps to provider. R2 is serial
interface with 64Kbps to provider and R3 is serial interface with
128Kbps to
provider. I know that I have a committed information rate from the
provider
on R2 at 32kbps and R3 at 64kbps.
How would I go about setting up FRTS at R1 to ensure I do not exceed
remote
or local settings? Or, suffice to say, would I need more information
about
R1s provider CIR?
Any thoughts or additional links are appreciated.
andy
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:50 GMT-3