From: Scott Morris (swm@emanon.com)
Date: Mon Feb 16 2004 - 21:44:01 GMT-3
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