From: John Gibson (johngibson1541@yahoo.com)
Date: Wed Jun 13 2007 - 17:08:55 ART
Sorry, never mind, I think they mean adaptive shaping
not in effect if you use "bandwidth" kind of
CBWFQ commands in the hierarchical policy.
I think they mean adaptive shaping still works
if you use "priority" kind of command in
the hierarchical policy.
I will have to read how LLQ is supported in
adaptive shaping with hierarchical policy.
John
--- John Gibson <johngibson1541@yahoo.com> wrote:
> Brian,
>
> When you said this is "relatively new", did
> you mean this is not a complete implementation ?
>
> I am reading MQC FRTS, and just realized what they
> mean by saying this,
>
-------------------------------------------------------------------------
> In configurations created by using traditional FRTS
> commands, the minimum acceptable outgoing committed
> information rate (minCIR) will be used as the total
> available bandwidth for a policy map that has
> class-based weighted fair queueing (CBWFQ) attached
> to
> the map class for the PVC.
>
> If the MQC-Based Frame Relay Traffic Shaping feature
> is used to configure FRTS, the shaping rate that was
> configured in the parent policy map using MQC will
> be
> used as the total available bandwidth for the child
> policy map, if CBWFQ is configured. If both the
> shape
> average and shape adaptive commands are used for
> traffic-shaping, the available bandwidth will be
> based
> on the parameters specified by the shape adaptive
> command
>
-------------------------------------------------------------------------
>
> This means adaptive shaping mechanism does not work
> in
> hierarchical policy.
> Not only MQC style but also old FRTS style.
>
> When the minCIR or "shape adaptive" value is used as
> "available bandwidth",
> they can't throughput faster than the static
> configured value to me.
>
> If they only shape to the fixed configured speed,
> FECN
> BECN signals aren't
> taking effects to me. Also "shape average" and
> "frame-relay cir" are
> not in effect to me.
>
> John
>
> --- Brian McGahan <bmcgahan@internetworkexpert.com>
> wrote:
>
> > minCIR is traditionally used for adaptive shaping
> > with BECN,
> > FECN, and Foresight. For example when BECN adapt
> is
> > enabled and you
> > receive a BECN from the Frame Relay network the
> > shaping algorithm will
> > incrementally slow down your sending rate either
> > until BECNs stop being
> > received or you reach the minCIR. Adaptive
> shaping
> > to interface
> > congestion is a relatively new feature, but uses
> the
> > same concept. When
> > the output queue length exceeds the configured
> value
> > the shaper will
> > back off either until the queue length drops below
> > the configured value
> > or you reach the minCIR, whichever comes first.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593 (R&S/SP)
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com] On Behalf Of
> > johngibson1541@yahoo.com
> > Sent: Wednesday, June 13, 2007 11:23 AM
> > To: ccielab@groupstudy.com
> > Subject: frame-relay minCIR purpose ?
> >
> > I know this will slow down the shaping rate when
> > adaptive-shaping interface-congestion [queue
> depth]
> > is reached.
> >
> > But in one sentence, minCIR's purpose is to
> maintain
> > discrimination on packets by letting them dropped
> > in the shaping 4 queues rather than dropping
> > at the single software queue. Right?
> >
> >
>
This archive was generated by hypermail 2.1.4 : Sun Jul 01 2007 - 17:24:49 ART