From: Chris (clarson52@comcast.net)
Date: Fri Jun 04 2004 - 12:02:18 GMT-3
..... not really based on IP precedence though as the post suggested but
based on the prefernce of the weight. I dunno, I am trying to figure the
post out too but the weighting is what came to mind in trying to figure out
what the post is getting at.
----- Original Message -----
From: "Chris" <clarson52@comcast.net>
To: "Bob Sinclair" <bsin@cox.net>; "Spolidoro, Guilherme"
<Guilherme.Spolidoro@unisys.com>; <ccielab@groupstudy.com>
Sent: Friday, June 04, 2004 10:56 AM
Subject: Re: QoS - Police - Congestion - NoCongestion
> 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?
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:32 GMT-3