From: Brian McGahan (brian@cyscoexpert.com)
Date: Thu Apr 17 2003 - 18:19:47 GMT-3
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