From: Chris Home (clarson52@comcast.net)
Date: Fri Apr 18 2003 - 08:21:32 GMT-3
> So is it correct that if the credits BE uses are made from unused BC in
the
> previous TC interval, that if there is more data then BC in the current
> interval that those credits can be used as BE to transmit the excess in
the current tc interval? And that this happens
> every interval, not really BE in the first interval of the first second?
> This would make sense to me as I have never understood the be in first
> interval or when that first proverbial 1 second period started. (With the
> first packet? Some static clocking mechanism?) So it sounds as if it is a
> process that happens every TC interval and if there are teokns they can be
used as BE in any TC interval. Correct?
>
>
>
>
>
> ----- Original Message -----
> From: "Brian Dennis" <brian@labforge.com>
> To: "'OhioHondo'" <ohiohondo@columbus.rr.com>; <ANDF@nnpi.com>;
> <ccielab@groupstudy.com>
> Sent: Thursday, April 17, 2003 1:06 PM
> Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
>
>
> > It is from the previous time interval (Tc) not the previous second. That
> > is why that Tech Tip from CCO about Frame-relay traffic shaping creates
> > so much confusion.
> >
> > 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: OhioHondo [mailto:ohiohondo@columbus.rr.com]
> > Sent: Thursday, April 17, 2003 9:28 AM
> > To: Brian Dennis; ANDF@nnpi.com; ccielab@groupstudy.com
> > Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
> >
> > Brian
> >
> > Just for a clarification -- are the credits that Be uses in the 1st time
> > interval built up over the 1 second period (using all of the unused Bc
> > bits
> > in a 1 second period) OR over a single Tc period (Using the unused Bc
> > bits
> > of let's say a 125 millisecond period).
> >
> > If the first is true, then Be could be a much larger value than Bc.
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > Brian Dennis
> > Sent: Thursday, April 17, 2003 11: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 : Thu May 01 2003 - 13:35:57 GMT-3