From: ccie candidate (ccie1@xxxxxxxxx)
Date: Tue Aug 13 2002 - 15:27:43 GMT-3
well
Be is measured in bits (same like Bc) so that it cannot be AR-CIR
becasue both are measured in Bps .
however , i dont think there is a relation between AR and Be directly ,Be is c
onfigurable parameter but AR is the physical port speed .....
what i think can be mentioned in the docs is that Be MAX value
AR >= CIR + EIR where EIR = Be/tc
this is natural because under any condition your rates should not exceed the ph
ysical port speed .
--On Tue, 13 Aug 2002 13:54:36 beda jain wrote: >Hi, >I have question on Be. some doc says Be= AR - CIR, some docs say Be= (AR - >CIR)/8. >where Tc=125ms. which one is correct, > >Thanks, >Beda > > >At 09:36 AM 8/13/2002 -0700, ccie candidate wrote: >> Hi ; >>i would like to contribute in this topic . >> >>i have spent great time in the past trying to understand this FRTS , and >>as usual , Cisco never puts full info about one subject in one place or >>one document , you have to dig many places ..print lots of docs .....anyway . >> >>what you have said is nearly right , but let me add some more to it , i >>might be wrong too ...so you can correct me . >> >>Mincir is the amount you pay for , the only guranteed thing here proviced >>by the Service provided >>it is also the vlaue where the traffic throtled down when you face any >>congestion in your network . >> >>Cir is the normal or average rate at which you transmit you data when the >>network is not congested . >> >>now to Bc and Be and Tc . >> >>Tc is the time interval , it takes the value from 10Msec to 125 Msec so >>you can say the following >>Tc =Bc /Cir if <125 Msec >>Tc = 125 msec if Bc/Cir > 125 !!! >>Tc recommended to be 10 msec in case of voice . >> >>so Tc cannot go for more than 125 msec >> >>Bc is the amount of bits which you can send under normal conditions of the >>network ( it is like the Mtu ). >> >>Be is the amount you can send over the Bc when the network is not >>congested ,however this amount of Data will be DE and can be droped first >>in case of congestion . >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>-- >> >>On Mon, 12 Aug 2002 22:30:38 >> Frank B wrote: >> >Hey folks...sorry about the re-hash but after receiving my last post I >> >reread it and realized a couple of SNAFUs within. >> > >> >My statement: "Bc is commonly set to 1/8 of the CIR" is not exactly >> >correct. CIR is a rate of bits per second, Bc is in bits making Tc just >> >a time period in seconds (basic algebra-the bits canx each other out and >> >there's only seconds remaining...right?) well, you get it. >> > >> >My 2nd foul-up: I found that Be is set to zero bits by default (not >> >sure what I was thinking)...making Bc the max you can transmit in a >> >given time interval by default. I should think things through before I >> >transmit. >> > >> >Guess I don't get partial credit huh? Later, Frank >> > >> > >> > >> >-----Original Message----- >> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of >> >Frank B >> >Sent: Monday, August 12, 2002 9:38 PM >> >To: 'Mark Vann'; ccielab@groupstudy.com >> >Cc: 'Andri Bersvendsen' >> >Subject: RE: FRTS >> > >> > >> >Mark, >> > The way I attempt to keep it straight in my warped mind is that >> >what you're paying the carrier for is the "minimum" you ever want to >> >transmit at--else you're being ripped off ;-> So, the rate they give >> >you (whether they call CIR or whatever) should be configured on a Cisco >> >router as equal the minCIR. The CIR (in Cisco-eese) is the rate you >> >want to transmit at under uncongested conditions--usually set to the >> >access rate (aka port speed) and of course this can't possibly be faster >> >than the access rate of the interface. >> > >> >Tc=Bc/CIR --this is usually 125ms because Bc is commonly set to 1/8 of >> >the CIR...but doesn't have to be! >> > >> >BTW....that's also why there's usually 8 time periods per second. Which >> >brings us to Be (which you didn't ask about but we're so close) >> > >> >Be is the amount you can transmit over and above the Bc within that >> >first time period of each second...IF you have credit built up (not to >> >exceed the volume of the infamous and invisible token bucket right?) I >> >beleve that by default Be=Bc which in that case gives you the limit of >> >Bc in each time period within each second--not 100% sure about that one >> >though. >> > >> >Now I hope you don't mind a question on the topic from me...where in an >> >"official" Cisco document does it state that upon receipt of a BECN >> >within a given time interval that the transmit rate is decreased by 25 >> >percent? I've seen it around (and on page 385 of Solie's book for >> >example) but is this in fact correct? And in any event, is this >> >configurable?...and the obvious follow-on "How do you do it?" >> > >> >Thanks and aloha man! Frank >> > >> >-----Original Message----- >> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of >> >Andri Bersvendsen >> >Sent: Sunday, August 11, 2002 10:42 PM >> >To: Mark Vann; ccielab@groupstudy.com >> >Subject: Re: FRTS >> > >> > >> >Bc = 1/8 of CIR only if Tc=125mS (this is the normal/default value for >> >Tc). >> > >> >Bc = CIR*Tc >> > >> >Example: >> > >> >Bc=? >> >CIR=64000 >> >Tc=0.125 >> > >> >Bc=64000*0.125 >> >Bc=8000 >> >Bc=8Kbps >> > >> >CIR do not have anything with port speed (also called access rate (AR)) >> >to do. It must be lower than the access rate. >> > >> >And now LAB14: >> > >> >On page 382 the following information is given: >> > >> >port speed (JPL)=1.544 Mbps >> >CIR=32Kbps. >> >port speed (nasa_houston)=64Kbps >> > >> >In FRTS you must configure MinCIR=32Kbps. >> >And Bc is calculated from CIR in FRTS. >> > >> > >> > >> >>Can someone please clarify something for me? When >> >>cisco says that bc = 1/8 of cir, that basically means >> >>that 8/CIR=Bc . If this is so are they refering to CIR >> >>being the provider CIR or the CIR that is used in TS , >> >>such as Port speed? I am just trying to figure out how >> >>Karl Solie arrived at this values on lab 14 in the >> >>preparation volume 1. >> >>Thanks >> >> >> >>
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:24 GMT-3