From: John Underhill (stepnwlf@magma.ca)
Date: Wed Jun 16 2004 - 15:06:14 GMT-3
Brian,
I don't necessarily disagree with you but..
Well for one, this would seem to run contrary to the rather murky way Cisco
defines CIR in their docs:
CIR-committed information rate. The rate at which a Frame Relay network
agrees to transfer information under normal conditions, averaged over a
minimum increment of time.
This line: 'The rate at which a Frame Relay network agrees to transfer
information under normal conditions' implies an agreed upon, or provisioned
rate.
Also, if you are oversubscribing the line for an extended period of time,
your provider will usually either bill you for the traffic as part of your
SLA, or simply drop the excess traffic.. so really it comes down to best
practices versus vendor symantics. If I were to set my CIR to AR rate, I
would create a backflow, and cause a great deal more congestion with
retransmissions then if I were to simply set MINCIR and CIR to the agreed
upon provisioned rate.
Am I wrong?
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "studygroup" <ccielab@groupstudy.com>
Cc: "John Underhill" <stepnwlf@magma.ca>; "Geert Nijs"
<geert.nijs@simac.be>; "Tom Rogers" <cccie71@yahoo.com>
Sent: Wednesday, June 16, 2004 1:31 PM
Subject: RE: MINCIR vs CIR
> John,
>
> It's not listed in the standards because it's a Cisco specific
> implementation. minCIR is a value used in conjunction with adaptive
> frame-relay traffic-shaping to define the lowest possible value you will
> shape down to in the case of a congestion notification. Congestion
> notification can occur due to receipt of a BECN notification, a
> foresight notification, or due to the exceeding of a defined output
> queue length.
>
> The logic of averaging a rate higher than what you are
> provisioned is that you are betting that the provider cloud is not
> congested 100% of the time. By configuring an average shaping rate
> (Cisco CIR) to higher than what is provisioned (provider CIR, Cisco
> minCIR), you are betting on the fact that the cloud will notify you of
> congestion with a BECN or foresight notification, at which time you will
> slow down.
>
> The biggest confusion with Cisco's FRTS is their usage of the
> term CIR. Cisco's CIR value in the frame-relay map-class configuration
> simply defines the rate at which traffic is moved from the
> traffic-shaping queue to the transmit ring of the interface. This value
> does not relate to the provisioned rate for the circuit. For this
> reason they added the additional value of minCIR to have a field that
> may relate to the provisioned rate of the circuit.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > John Underhill
> > Sent: Wednesday, June 16, 2004 11:19 AM
> > To: Geert Nijs; Tom Rogers; Brian McGahan; studygroup
> > Subject: Re: MINCIR vs CIR
> >
> > For one thing, it is unlikely that you will see mincir as part of your
> > SLA,
> > the switch does not know what you have set mincir to, or how your
> router
> > will react to becns, but only drops traffic when it exceeds a certain
> > rate,
> > (and not many providers are using cisco lmi, because they have to
> maintain
> > vendor neutral standards..). Mincir is not part of the lmi exchange
> > standard, because it is a local, discretionary value. If you have
> > purchased
> > 128k, and they start dropping traffic at 64k, it's time to put your
> > yelling
> > hat on and call the provider.
> > CIR = the bandwidth you have purchased.
> > FRF NNI agreement standard:
> > http://www.mplsforum.org/frame/Approved/FRF.2/FRF_2_2-final.pdf
> >
> > <Cisco Quote:>
> > When the congestion level exceeds a configured value called queue
> depth,
> > the
> > sending rate of all PVCs is reduced to the minimum committed
> information
> > rate (minCIR). As soon as interface congestion drops below the queue
> > depth,
> > the traffic-shaping mechanism changes the sending rate of the PVCs
> back to
> > the committed information rate (CIR). This process guarantees the
> minCIR
> > for
> > PVCs when there is interface congestion.</Quote>
> > Seems pretty plain to me.. Mincir is a congestion control mechanism.
> >
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_
> gu
> > ide09186a0080087b91.html
> >
> > Here is a good explaination of how frame is working, including all the
> > standards, note in an illustration of an lmi frame, there is no
> 'mincir'
> > field.
> > http://www.protocols.com/pbook/frame.htm
> >
> >
> >
> > ----- Original Message -----
> > From: "Geert Nijs" <geert.nijs@simac.be>
> > To: "Tom Rogers" <cccie71@yahoo.com>; "Brian McGahan"
> > <bmcgahan@internetworkexpert.com>; "studygroup"
> <ccielab@groupstudy.com>
> > Sent: Wednesday, June 16, 2004 4:15 AM
> > Subject: RE: MINCIR vs CIR
> >
> >
> > > Higher average bandwidth maybe ??
> > >
> > > I know many people think that CIR is "the guaranteed rate". And, in
> real
> > > life, many times, MINCIR is equal to CIR.
> > > But, as you can read in the white paper on the internetworkingexpert
> > > site, MINCIR is the rate at which your service provider will start
> > > marking packets as DE.
> > >
> > > So, the question now is: why not try to sent at a higher rate and
> > > falling back to MINCIR when we receive BECNs ??
> > > Suppose there is no congestion in the Frame Relay cloud of the ISP,
> the
> > > ISP marks packets with DE but they don't get dropped
> > > since there is no congestion. So we could sent at a higher
> rate.......
> > >
> > > So, when the lab says "Your ISP will mark every packet above 48kbps
> with
> > > the DE-bit",
> > > then, i must correct myself, and say that 48kbps is the MINCIR.
> > > I can try to send at a higher rate, and fall back to the MINCIR when
> > > congestion occurs.
> > > In this case, my CIR and the frame-relay providers CIR are
> > > different.....
> > > Right ?
> > >
> > > Geert
> > >
> > > -----Oorspronkelijk bericht-----
> > > Van: Tom Rogers [mailto:cccie71@yahoo.com]
> > > Verzonden: woensdag 16 juni 2004 5:08
> > > Aan: Geert Nijs; Brian McGahan; studygroup
> > > Onderwerp: Re: MINCIR vs CIR
> > >
> > >
> > > Geert,
> > > If DE is going to set above minCIR, then what the point of
> > > having cir?
> > >
> > > Tom
> > >
> > > Geert Nijs <geert.nijs@simac.be> wrote:
> > >
> > > I am also confused about the deliniation between CIR and
> > > MINCIR. Can
> > > someone give some examples on how the lab
> > > would formulate these parameters ?
> > >
> > > If the lab specifies:
> > > "Your ISP provider will mark every packet above 48kbps
> > > with the DE-bit"
> > >
> > > Then CIR = 48 kbps ? Right ?
> > >
> > >
> > > If the lab specifies:
> > > "Your ISP provider will mark every packet above 48kpbs
> > > with the BECN-bit"
> > > (in the opposite direction is implicitely
> > > assumed here ??)
> > >
> > > Then MINCIR = 48 kbps ? Right ?
> > >
> > > Regards,
> > > Geert
> > >
> > > -----Oorspronkelijk bericht-----
> > > Van: nobody@groupstudy.com
> > > [mailto:nobody@groupstudy.com] Namens Brian
> > > McGahan
> > > Verzonden: dinsdag 15 juni 2004 19:27
> > > Aan: studygroup
> > > Onderwerp: RE: Bandwidth Vs MinCIR for CBWFQ
> > >
> > >
> > > The MINCIR value in the frame-relay map-class is simply
> > > used to
> > > define a worst case rate you will shape down to when the
> > > BECN bit is set
> > > in frames you receive from the frame-relay network.
> > >
> > > HTH,
> > >
> > > Brian McGahan, CCIE #8593
> > > bmcgahan@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com
> > > Toll Free: 877-224-8987 x 705
> > > Outside US: 775-826-4344 x 705
> > >
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com
> > > [mailto:nobody@groupstudy.com] On Behalf
> > > Of
> > > > samccie2004@yahoo.co.uk
> > > > Sent: Monday, June 14, 2004 12:29 PM
> > > > To: studygroup
> > > > Subject: Bandwidth Vs MinCIR for CBWFQ
> > > >
> > > > Hi Group
> > > >
> > > > When asked to guarantee BW foe QOS using CBWFQ on
> > > interfaces
> > > encapsulated
> > > > with frame-relay. What is the correct way to do so.
> > > >
> > > > Do I apply Bandwidth statement as I would for a HDLC
> > > interafce or even
> > >
> > > > ethernet, or do I rely on shapping DLCI with a MIncir
> > > equal the BW
> > > > required.
> > > >
> > > > TIA
> > > >
> > > > Sam
> > >
> > >
> > >
> _______________________________________________________________________
> > > Please help support GroupStudy by purchasing your study
> > > materials from:
> > > http://shop.groupstudy.com
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> ########################################################################
> > > #############
> > > This e-mail and any attached files are confidential and
> > > may be legally privileged.
> > > If you are not the addressee, any disclosure,
> > > reproduction, copying, distribution,
> > > or other dissemination or use of this communication is
> > > strictly prohibited.
> > > If you have received this transmission in error please
> > > notify Simac immediately
> > > and then delete this e-mail.
> > >
> > > Simac has taken all reasonable precautions to avoid
> > > virusses in this email.
> > > Simac does not accept liability for damage by virusses,
> > > for the correct and complete
> > > transmission of the information, nor for any delay or
> > > interruption of the transmission,
> > > nor for damages arising from the use of or reliance on
> > > the information.
> > >
> > > All e-mail messages addressed to, received or sent by
> > > Simac or Simac employees
> > > are deemed to be professional in nature. Accordingly,
> > > the sender or recipient of
> > > these messages agrees that they may be read by other
> > > Simac employees than the official
> > > recipient or sender in order to ensure the continuity of
> > > work-related activities
> > > and allow supervision thereof.
> > >
> > >
> ########################################################################
> > > #############
> > >
> > >
> > >
> _______________________________________________________________________
> > > Please help support GroupStudy by purchasing your study
> > > materials from:
> > > http://shop.groupstudy.com
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > >
> > > ________________________________
> > >
> > > Do you Yahoo!?
> > > Yahoo! Mail
> > >
> <http://us.rd.yahoo.com/mail/taglines/*http://promotions.yahoo.com/new_m
> > > ail/static/protection.html> - You care about security. So do we.
> > >
> > >
> _______________________________________________________________________
> > > Please help support GroupStudy by purchasing your study materials
> from:
> > > http://shop.groupstudy.com
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:41 GMT-3