Re: FRTS Revealed (was RE: MINCIR = CIR?)

From: Mark Miller (markmiller@alltel.net)
Date: Thu Apr 17 2003 - 21:00:29 GMT-3


My head is spinning!

----- Original Message -----
From: "Brian McGahan" <brian@cyscoexpert.com>
To: "'OhioHondo'" <ohiohondo@columbus.rr.com>; "'Jonathan V Hays'"
<jhays@jtan.com>; <ccielab@groupstudy.com>
Cc: "'Mike Williams'" <ccie2be@swbell.net>
Sent: Thursday, April 17, 2003 4:19 PM
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)

> Yes, believe it or not, that is the reason. There is a maximum
> Tc value per CIR. I have talked to TAC about this before, and they have
> confirmed the behavior. It is not documented this way because it is
> Cisco's internal implementation of the algorithm.
>
> Brian McGahan, CCIE #8593
> Director of Design and Implementation
> brian@cyscoexpert.com
>
> CyscoExpert Corporation
> Internetwork Consulting & Training
> Toll Free: 866.CyscoXP
> Fax: 847.674.2625
>
>
> > -----Original Message-----
> > From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
> > Sent: Thursday, April 17, 2003 4:01 PM
> > To: Brian McGahan; 'OhioHondo'; 'Jonathan V Hays';
> ccielab@groupstudy.com
> > Cc: 'Mike Williams'
> > Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
> >
> > Brian
> >
> > That is not it!!! Tc=Bc/cir but the interval Tc changes even if this
> > relationship stays the same.
> >
> > There is some other reason why the interval is "halved" when cir goes
> > above
> > 600,000+. I am curious to know what that reason is. If anyone out
> there
> > knows, please chip in.
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > Brian McGahan
> > Sent: Thursday, April 17, 2003 3:40 PM
> > To: 'OhioHondo'; 'Jonathan V Hays'; ccielab@groupstudy.com
> > Cc: 'Mike Williams'
> > Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
> >
> >
> > Yes,
> >
> > As I said, there is a maximum Tc per CIR. When you see that the
> > router has automatically reduced the Tc, you have reached the
> threshold
> > of the max Tc for that CIR.
> >
> > HTH
> >
> > Brian McGahan, CCIE #8593
> > Director of Design and Implementation
> > brian@cyscoexpert.com
> >
> > CyscoExpert Corporation
> > Internetwork Consulting & Training
> > Toll Free: 866.CyscoXP
> > Fax: 847.674.2625
> >
> >
> > > -----Original Message-----
> > > From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
> > > Sent: Thursday, April 17, 2003 11:20 AM
> > > To: Brian McGahan; 'OhioHondo'; 'Jonathan V Hays';
> > ccielab@groupstudy.com
> > > Cc: 'Mike Williams'
> > > Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
> > >
> > > Jonathan/Brian
> > >
> > > Based on your input I tried some things. Your classes may be
> > interested in
> > > this. The snippet of information below reveals some interesting
> > things...
> > >
> > > The interval is rounded up for the display from 62.5 to 63. The
> proof
> > is
> > > in
> > > the byte increment. Byte increment is the number of bytes sent in a
> Tc
> > > period. If you multiply the 6048 by 8 to get bits, and then divide
> by
> > the
> > > interval, you should get the cir. Soooo... 6048*8/.0625 = 768000.
> This
> > > will
> > > keep your class from messing with those strange numbers.
> > >
> > > Also it makes sense. The FRTS process running in the router cuts the
> > time
> > > interval by 1/2 at a certain point. In my testing, that point is
> > somewhere
> > > between a cir of 600000 and 700000.
> > >
> > > As the cir grows even further it will be "halved" (and rounded off
> by
> > the
> > > display) again.
> > >
> > > 3640-1_R1#sho frame pvc 401
> > > cir 768000 bc 96000 be 0 limit 6048 interval 63
> > > mincir 384000 byte increment 6048 Adaptive Shaping none
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
> Of
> > > Brian McGahan
> > > 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