From: Colin Barber (Colin.Barber@telewest.co.uk)
Date: Tue May 06 2003 - 18:12:56 GMT-3
I don't know if you can keep accumulating credit as you suggest, it's not
something I have tried, but it should be quite easy to test in a lab.
One thing you have to remember is that in the real world your frame
connection is being provided to you. If you start transmitting at higher
rates than you're allowed then the Telco will probably just start dropping
your traffic. You should find out how the Telco is defining your PVCs and
then configure your routers.
Colin
-----Original Message-----
From: Joe Martin [mailto:jmartin@capitalpremium.net]
Sent: 05 May 2003 16:51
To: OhioHondo; Colin Barber; Lewis, Ray; CCIE GroupStudy; brian@labforge.com
Subject: RE: An Epiphany!!! FRTS Revealed (was RE: MINCIR = CIR?)
Colin & Hondo,
Excellent posts!!! One last question on the subject. Is there a limit to
the max size of Be? In other words, is there a limit to the time period
over which Be can accumulate credits. If I am transmitting under CIR for 30
minutes, Be will continue to accumulate credits until it reaches the
configured Be number. If Be was configured large enough, it could
potentially accummulate credits during the entire 30 minutes. This would
then allow me to Burst passed CIR for 30 minutes, or at least until all the
Be credits were used.
Any responses are appreciated.
TIA,
Joe Martin
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
OhioHondo
Sent: May 04, 2003 11:25 AM
To: Colin Barber; 'OhioHondo'; Lewis, Ray; CCIE GroupStudy
Subject: RE: An Epiphany!!! FRTS Revealed (was RE: MINCIR = CIR?)
Colin
Good point. And I think it also makes a logical answer as to why Be CREDITS
are only used in the 1st Tc. If there were data to send the Bc credits made
available at the beginning of each Tc would be used. If there is not enough
data to cover the Bc CREDITS allowed, the unused Bc CREDITS are moved to the
Be counter. The next Tc interval (immediately following) receives another Bc
number of CREDITS to use.
There has to be some rationale for accumulating CREDITS for Be and then when
to use them. What I suspect (and what you are inferring) is that in the
first Tc - Be and Bc CREDITS can be used (if Be CREDITS were accumulated due
to a lack of data to transfer in the previous 1 second interval.) This is
consistant with the CCO url that I attached in the original message.
What you can also get out of this is that since Be CREDITS can only be
accumulated due to a lack of data to transfer --- and since Be is directly
related to unused Bc CREDITS --- the max thruput over time can never exceed
the Cisco CIR!!!!
In can exceed Cisco CIR in a single 1 second time period, only because it
transmitted less than Cisco CIR in the previous time period. So in any 2
second time period, the max amount of data that can be transmitted is Cisco
CIR x 2 ??
{=@)
-----Original Message-----
From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
Sent: Sunday, May 04, 2003 12:39 PM
To: 'OhioHondo'; Lewis, Ray; CCIE GroupStudy
Subject: RE: An Epiphany!!! FRTS Revealed (was RE: MINCIR = CIR?)
You will never get a 64K throughput in the example below. You have a CIR of
32K and therefore your throughput will be very close to 32K.
You can only burst if you have credit and you don't get credit unless you go
below the CIR. If you constantly transmit at or above 32K, which the traffic
generator will do, you will never have any credit and therefore your
throughput is limited to the CIR.
Burst is only sent in the first Tc however if the burst cannot be
transmitted in the first Tc because it is too large then it will queued in
the interface output buffers and then transmitted.
Colin
-----Original Message-----
From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
Sent: 04 May 2003 14:04
To: Lewis, Ray; CCIE GroupStudy
Subject: RE: An Epiphany!!! FRTS Revealed (was RE: MINCIR = CIR?)
I don't believe this has been answered because we do not trust the info on
CCO on this subject. I do not have the traffic generators to do this but if
someone does, this can be answered by the following setup.
On both sides of a frame pvc, on a circuit with a 64K signaling rate use the
following parms...
Cisco cir= 32000
mincir = 16000
bc= 4000
be= 32000
no adaptive shaping
Then send as much data as you can over the link.
If you can maintain a 64K thruput, then built up credits are being used in
any Tc time period. (you should not have congestion if you are in a lab
environment)
The CCO would state that the max Be used in the situation above would be 4K
and that credits are only used in the first Tc, in which case the max
thruput would be 32000 + 4000 = 36000.
See this link for the CCO example....watch the wrap
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_examp
le09186a00800942f8.shtml
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Lewis, Ray
Sent: Saturday, May 03, 2003 6:14 PM
To: CCIE GroupStudy
Subject: RE: An Epiphany!!! FRTS Revealed (was RE: MINCIR = CIR?)
Has this ever been resolved?
I believe the real question is this.
Is the Burst Rate (ie, can burst to 64kbps) calculated over the Tc1 or over
the entire 1 second?
Given:
If AR = 64k
CIR = 32k (from Carrier)
MinCir = 16k
We can burst to AR
Opinion #1 - Burst Rate calculated over 1 second
Bc = 32000/8 = 4000 bits per Tc
Be = AR-CIR = 32000
During Tc1: we are sending 36000 bits. This is equivalent to a rate of
36000*8 = 288000bps. (is this allowed?)
During Tc2-Tc8: we are sending 4000*7 = 28000 bits. This is equivalent to a
rate of 32000 bps
Over the entire 1 Second (all Tcs): we sent 28000 + 36000 = 64000 bits.
Opinion #2 - Burst Rate calculated per Tc interval.
Bc = 32000/8 = 4000 bits per Tc
Be:
Most we can send is 64000bps.
We calculate everything per Tc. So Burst Rate is really 64000/8 = 8000bps
(per Tc).
We are already sending 4000 bits in the 1st Tc (the Bc is doing that)
There are only 8000 - 4000 = 4000 bits remaining to be sent (during the 1st
Tc).
This would give the following:
During Tc1: we are sending 8000 bits. This is equivalent to a rate of 8000
* 8 = 64000bps.
During Tc2-Tc8: we are sending 4000 * 7 = 28000 bits. This is equivalent to
a rate of 32000bps
Over the entire 1 Second (all Tcs): we sent 28000 + 8000 = 32000 bits.
in Case #1, we theoretically exceeded the port speed of 64k (we sent at a
rate of 288000bps). But we only did this for 1/8 of a second. Is the
router physically able to accept the data at 288000bps for 1/8 of a second?
If yes, than this is the right answer.
in Case#2, we never exceeded the physical port speed of the interface. But
then maybe we have not utilized the link to full potential since we only
sent 32000 bits/s to a 64000 bit/s interface?
Anybody?
-----Original Message-----
From: Joe Martin [mailto:jmartin@capitalpremium.net]
Sent: Thursday, April 17, 2003 5:03 PM
To: OhioHondo; Brian Dennis; CCIE GroupStudy
Subject: RE:An Epiphany!!! FRTS Revealed (was RE: MINCIR = CIR?)
I have had an epiphany!!!!!
Thank you Brian, Brian, & Ohio? !!!!
So the formula is Be = (AR - CIR) * Tc/1000.
Or another way to state it.
Be = (AR * Tc/1000) - (CIR * Tc/1000)
I know it is the same thing, but after Ohio's last post it just made more
sense to me that way.
Again, thank you everyone. Brian D., I will never question your wealth of
knowledge again. :)
Joe Martin
-----Original Message-----
From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
Sent: April 17, 2003 1:53 PM
To: Joe Martin; Brian Dennis; CCIE GroupStudy
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
Joe
Brians point is that in 1/8 of a second (the time in the 1st time interval)
a circuit with a signaling rate of 64K can only manage to send out a TOTAL
of 8K. Since the Be is only sent in the 1st time interval and since the Bc
is already 4K, the max Be can only be 8K-4K = 4K
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Joe Martin
Sent: Thursday, April 17, 2003 2:09 PM
To: Brian Dennis; CCIE GroupStudy
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
Brian,
Yes, but you are only sending the Be for one interval. It is actually
Be + 8(Bc) per second
So 32000 + 8(4000) = 64000 <-----AR or Port Speed
So I am sending (32000(Be) + 4000(Bc)) + 4000 + 4000 + 4000....
( interval 1 ) (int2) (int3) (int4)...
Joe Martin
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: April 17, 2003 11:51 AM
To: 'Joe Martin'; 'CCIE GroupStudy'
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
Joe,
How is that port speed? If Be is 32000 and Bc is 4000 then you are
sending 36000 in 125ms which makes the port speed 288000bps.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
Director of CCIE Training and Development - IPexpert, Inc.
Mailto: brian@ipexpert.net
Toll Free: 866.225.8064
Outside U.S. & Canada: 312.321.6924
-----Original Message-----
From: Joe Martin [mailto:jmartin@capitalpremium.net]
Sent: Thursday, April 17, 2003 10:28 AM
To: Brian Dennis; CCIE GroupStudy
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
Brian,
I respectfuly disagree. Be is the excess burst for one interval, but is
made up of extra tokens for all intervals in the second. If the CIR is
less
than AR and we are using the default Tc (125ms), then I can burst up to
the
AR (port speed).
AR = 64000 <---- Port Speed
CIR = 32000
Bc = 4000
Tc = 125ms
Be = 32000
However, if the CIR is the same as AR then I have no room for bursting.
AR = 64000
CIR = 64000
Bc = 8000
Tc = 125ms
Be = 0
Of course, I would never want to burst passed the remote router's AR.
So that will be a determing fact for the Be.
Someone correct me if I am wrong.
Joe Martin
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brian Dennis
Sent: April 17, 2003 9:09 AM
To: ANDF@nnpi.com; ccielab@groupstudy.com
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
Since Be is made up of unused Bc bytes from the previous interval (Tc)
Be can not contain more bytes than Bc. So if Bc is 4000 how can you ever
have a Be value more than 4000?
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
Director of CCIE Training and Development - IPexpert, Inc.
Mailto: brian@ipexpert.net
Toll Free: 866.225.8064
Outside U.S. & Canada: 312.321.6924
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ANDF@nnpi.com
Sent: Thursday, April 17, 2003 6:46 AM
To: brian@cyscoexpert.com; ccielab@groupstudy.com
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
Brian,
I appreciate your input on this. On page 66 of the 2002 CCIE Power
Session
slides they show Be = 32000 when CIR = 32000, port speed = 64000, Bc =
4000
and Tc = 125ms. Are they incorrect? Shouldn't Be have been 4000?
Thanks,
Andy Fernandes
-----Original Message-----
From: Brian McGahan [mailto:brian@cyscoexpert.com]
Sent: Thursday, April 17, 2003 12:40 AM
To: 'OhioHondo'; 'Jonathan V Hays'; ccielab@groupstudy.com
Cc: 'Mike Williams'
Subject: FRTS Revealed (was RE: MINCIR = CIR?)
Due to incorrect documentation, FRTS is one of the most
misunderstood topics within the CCIE domain. Since this is my favorite
lecture which I usually end up giving 5 or 6 times per week, I'll just
go
for the complete explanation to start with :)
To calculate FRTS values, we will use the following formulas:
Bc = (CIR * Tc) / 1000
Be = ((AR - CIR) * Tc)/1000
In the CCO example you are referencing, the hub has an
access-rate
of 192000bps, while the remote only has an access-rate of 64000bps.
Therefore, the fastest speed that can be sustained over the second is
64000bps. This is what we want to average per second, which is Cisco's
term
CIR.
Hub:
AR = 192000
CIR = 64000
Remote:
AR = 64000
CIR = 64000
Since CIR <= 640Kbps, the default Tc is 125ms. (I'll explain
this
later) Now we have the following:
Hub:
AR = 192000
CIR = 64000
Tc = 125
Remote:
AR = 64000
CIR = 64000
Tc = 125
Now that we have both CIR and Tc, we can solve for Bc. Since
both
the CIR and Tc are the same for the Hub and the Remote, Bc will be the
same:
Bc = (CIR * Tc)/1000
Bc = (64000 * 125)/1000
Bc = (8000000)/1000
Bc = 8000 bits
Now we have:
Hub:
AR = 192000
CIR = 64000
Tc = 125
Bc = 8000
Remote:
AR = 64000
CIR = 64000
Tc = 125ms
Bc = 8000
Now we must solve for Be, starting with Hub:
Be = ((AR - CIR) * Tc)/1000
Be = ((192000 - 64000) * 125) / 1000
Be = ((128000) * 125) / 1000
Be = (16000000) / 1000
Be = 16000
Now the Remote:
Be = ((AR - CIR) * Tc)/1000
Be = ((64000 - 64000) * 125) / 1000
Be = ((0) * 125) / 1000
Be = (0) / 1000
Be = 0
So far, our calculations have nothing to do with how our line is
actually provisioned. Instead, we have simply calculated how our token
bucket will shape the traffic. The example then states "In case of
congestion, it can drop down to 32Kbps at the minimum." This statement
implies that the provider has provisioned 32000bps for us on this VC. In
order to dynamically react to congestion from the cloud, we must enable
BECN
adapt, which is where the following two statements come
from:
frame-relay mincir 32000
frame-relay adaptive-shaping becn
The following statement in the document is wrong:
"Ideally for data PVCs Bc = CIR/8 so that Tc = 125msec."
There is a maximum Tc value per CIR. The greater the CIR the
smaller the Tc value must be. Unfortunately, this behavior is not
documented. In the following example, the frame-relay map-class X is
applied to an interface with one VC. We can test this behavior based on
the
following:
Suppose we have a CIR of 640000. If Bc = CIR/8, then Bc =
640000/8
= 80000.
map-class frame-relay X
frame-relay cir 640000
frame-relay bc 80000
no frame-relay adaptive-shaping
end
Rack2R6#show traffic-shape
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment
Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
604 640000 10000 80000 0 125 10000 -
This indicates that we have 8 intervals per second (1000ms per
second, 125ms per interval), and are sending 80000 bits per interval,
which
works out to an average of 640000bps. So far so good.
Now let's change our CIR to 800000bps:
Current configuration:
!
map-class frame-relay X
frame-relay cir 800000
frame-relay bc 100000
no frame-relay adaptive-shaping
end
Rack2R6#sh traffic
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment
Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
604 800000 6300 100000 0 63 6300 -
Notice that our interval is not 125ms now, but our Bc still
conforms
to the formula Bc = CIR/8. In actuality, we have (bear with
me) 1000/63 = 15.873015873015873015873015873016 intervals per second. At
100000 bits per interval, we are averaging about 1587301bps, which is
clearly beyond 800Kbps. This is due to the fact that for a CIR of
800Kbps,
the maximum Tc value is 63ms.
Instead, let us compute Bc using 63 as the Tc:
Bc = (CIR * Tc) / 1000
Bc = (800000 * 63) / 1000
Bc = 50400
Rack2R6#sh run map-class
Building configuration...
Current configuration:
!
map-class frame-relay X
frame-relay cir 800000
frame-relay bc 50400
no frame-relay adaptive-shaping
end
Rack2R6#sh traffic-shape
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment
Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
604 800000 6300 50400 0 63 6300 -
We still have 1000/63 = 15.873015873015873015873015873016
intervals
per second. If we are sending 50400bits every
15.873015873015873015873015873016ms, we will be averaging 800000bps.
I'm not sure exactly where the cutoff values are for the max Tc,
but
the router will tell you the appropriate Tc value for a CIR if you enter
it
in the map-class, apply it, then show traffic-shape.
Hope I didn't confuse you all further :)
Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com
CyscoExpert Corporation
Internetwork Consulting & Training
Toll Free: 866-CyscoXP
Outside US: 847.674.3392
Fax: 847.674.2625
> -----Original Message-----
> From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
> Sent: Wednesday, April 16, 2003 10:08 PM
> To: Jonathan V Hays; 'Brian McGahan'; ccielab@groupstudy.com
> Cc: 'Mike Williams'
> Subject: RE: MINCIR = CIR?
>
> This new equation/explanation for calculating FRTS parameter -- I've
never
> seen it before. It doesn't make sense with anything I've read on the
> subject. How does it relate to the CCO iformation found at:
>
>
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_e
xa
> mp
> le09186a00800942f8.shtml
>
> where:
> Bc=CIR*Tc
> Be= (AR*Tc) - Bc
>
> Where is the source of your information?
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Jonathan V Hays
> Sent: Wednesday, April 16, 2003 9:00 PM
> To: 'Brian McGahan'; ccielab@groupstudy.com
> Cc: 'Mike Williams'
> Subject: RE: MINCIR = CIR?
>
>
> > -----Original Message-----
> > From: Brian McGahan [mailto:brian@cyscoexpert.com]
> > Sent: Wednesday, April 16, 2003 1:33 PM
> > To: 'Jonathan V Hays'; ccielab@groupstudy.com
> > Cc: 'Mike Williams'
> > Subject: RE: MINCIR = CIR?
> >
> [snip]
> > The following formulas hold true for Cisco's implementation of
> > Frame-Relay Traffic Shaping:
> >
> > Bc = (CIR * Tc)/1000
> > Be = ((AR - CIR) * Tc)/1000
> >
>
> Brian,
>
> What units are you using to require division by 1000? Most Cisco
> documents seem to give Bc= CIR * Tc.
>
>
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_e
> xample09186a00800942f8.shtml
>
> See the document I cited in my earlier post (included above) under
> "Nonconfigurable parameters - interval (Tc)" -
> ---
> "The time interval during which you send the Bc bits in order to
> maintain the average rate of the CIR in seconds.
>
> Tc = Bc/CIR in seconds.
>
> The range for Tc is between 10 ms and 125 ms."
> ---
> In the example given in the Cisco document, Bc is 8000 bits, CIR is
> 64000 bps, then Tc = 8000 bits / 64000 bps = 1/8 second.
>
> Or if you use Bc = CIR * Tc, then
> Bc = 64000 bps * 1/8 second = 8000 bits.
>
> What does dividing by 1000 get me?
>
> Thanks.
This archive was generated by hypermail 2.1.4 : Mon Jun 02 2003 - 15:13:38 GMT-3