From: Chris (clarson52@comcast.net)
Date: Fri Jun 04 2004 - 11:56:16 GMT-3
I think what is meant by that is that when you assign a bandwidth you are
actually assigning a weight to that traffic. Not an actual bandwidth value.
The router then uses that weight to determine its servicing in the q's. In
that sense it is "weighted" q'ing. Maybe that is what the post is getting
at.
----- Original Message -----
From: "Bob Sinclair" <bsin@cox.net>
To: "Spolidoro, Guilherme" <Guilherme.Spolidoro@unisys.com>;
<ccielab@groupstudy.com>
Sent: Friday, June 04, 2004 9:49 AM
Subject: Re: QoS - Police - Congestion - NoCongestion
> Guiherme,
>
> According to Wendell Odom in his book Cisco DQOS, the CBWFG algorithm is
not
> published. I have a hard time seeing how it could be precedence-based,
like
> WFQ. Do you have a reference you can share?
>
> Thanks!
>
> Bob Sinclair
> CCIE #10427, CISSP, MCSE
> www.netmasterclass.net
>
>
> ----- Original Message -----
> From: "Spolidoro, Guilherme" <Guilherme.Spolidoro@unisys.com>
> To: <ccielab@groupstudy.com>
> Sent: Friday, June 04, 2004 9:32 AM
> Subject: RE: QoS - Police - Congestion - NoCongestion
>
>
> > The word that should be used with CBWFQ is not reserve but guarantee.
> >
> > When you type the bandwidth percent 25 command on the class, what's
gonna
> happen is that CBWFQ will guarantee at least 25% of the bw for this class
> during congestion.
> >
> > If there's no congestion, the bw command will never kick off. It's used
> only during congestion, meaning it's basically a technology used to empty
> the queues (when used with the bw statement).
> >
> > If there's enough bw for everyone, there's no reason to guarantee
> anything, right?
> >
> > If this class doesn't need to use 25% or more (let's say it's using only
> 10%), the rest of the classes can use the remaining of the bw (the other
15%
> that this class doesn't need).
> >
> > CBWFQ uses the WFQ algorithm, meaning that packets from the different
> classes that have the highest IP Precedence will be the ones to benefit
more
> from that. Let me give you an example:
> >
> > class a = streaming video (ip prec 4)
> > class b = bulk data (ip prec 1)
> > class c = voip (ip prec 5)
> > class default-class = anything else (ip prec 0)
> >
> > Class c has 25% of the bw guarantee for it, but might need only 10% at a
> given time.
> > Class a has 5% of the bw guarantee for it, but might need more than that
> at a given time.
> > Class b has 5% of the bw guarantee for it, but might need more than that
> at a given time.
> > class default-class has 25% of the bw guarantee for it by default, but
> might need more than that at a given time.
> >
> > If there's congestion on the link, class c (voip) will get the 10% that
it
> needs. Classes a, b and the default-class' overflow will compete for the
> remaining bandwidth. They will use at least the bw that is on the command
> plus whatever they can get.
> >
> > Class a's overflow will be able to get more bw than class b and the
> default-class' overflows.
> >
> > By the end, you might see something like this:
> >
> > Class c only needed 10% and that's what it got.
> > Class a ended up getting 35% of the total bw.
> > Class b ended up getting 25% of the total bw.
> > Class default-class ended up getting 30% of the total bw.
> >
> > Not sure if this is a good example, but the idea is that all the
overflows
> will leave the queue faster or slower according to their IP Precedence...
> >
> > Without making it more confusing than it has to be, there are other
> options on CBWFQ (besides the bw command):
> >
> > - priority = new version of the low latency queue, typically used for
voip
> or interactive video. Instead of putting the packets in the queue, it
sends
> directly to the interface (except for the overflow) In our example, you
> could it on class c.
> > - policy = new version of the old CAR. Let you limit the traffic that
the
> class can use either for inbound or outbound. I personally don't like it
> because the way it works (basically drops the excess) causes too many
> retransmissions.
> > - shape = new version of the old traffic shape. Let you limit the
traffic
> that the class can use for outbound only. I use extensive here and it
works
> very well.
> >
> > I know this address a lot more than what you asked but I hope others on
> the list can benefit from it.
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > gladston@br.ibm.com
> > Sent: Friday, June 04, 2004 8:51 AM
> > To: ccielab@groupstudy.com
> > Subject: QoS - Police - Congestion - NoCongestion
> >
> >
> > Dear Group,
> >
> > Does Police within CBWFQ reserve a bandwidth when there is no congestion
> and when there is congestion?
> >
> > For example, to reserve 25% of the bandwidth to traffic from 10.100.5.0
to
> 10.200.6.0:
> >
> > Class-map p-100.5.0
> > Match access-group name p-100.5.0
> > !
> > policy QOS
> > class p-100.5.0
> > police 10000 1000 conform-action transmit exceed-action drop
> > !
> > interface ser 1
> > service-policy output QOS
> >
> >
> > If so, why should one use bandwidth and policy within the same class?
> >
> > _______________________________________________________________________
> > 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
>
> _______________________________________________________________________
> 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:32 GMT-3