RE: QoS - Police - Congestion - NoCongestion

From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri Jun 04 2004 - 16:58:10 GMT-3


> Therefore, if the traffic from class-default wants/needs to use bw,
> there'll always be 25% guaranteed for it

        No this is not true. Class-default is best-effort unless you
manually reserve bandwidth for it. In the case of congestion, traffic
that falls into the default-class can still be dropped from the output
queue. Routing traffic is treated differently though. See the
following document for more information:

http://www.cisco.com/warp/public/105/rtgupdates.html

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
> Spolidoro, Guilherme
> Sent: Friday, June 04, 2004 1:37 PM
> To: Carlos G Mendioroz; Bob Sinclair
> Cc: ccielab@groupstudy.com
> Subject: RE: QoS - Police - Congestion - NoCongestion
>
> Carlos, not sure if I understand your question but the class-default
is
> always there (implicit) and you cannot reserve more than 75% in all
other
> classes combined (unless you use the max-reserved-bandwidth command).
> Therefore, if the traffic from class-default wants/needs to use bw,
> there'll always be 25% guaranteed for it (among other things like
routing
> traffic), otherwise class a can use as much as it is available.
>
>
> Bob, I guess we all learn something new everyday, rigth? :-)
>
> For some reason I always understood that the exceed/overflow traffic
from
> a given class would dispute the remaining of the bw with the overflow
of
> all other classes by using the WFQ algorithm, where packets with
higher IP
> Precedence get more bw.
>
> Doesn't sound like this is the case. Please visit the following link:
>
>
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configur
at
> ion_guide_chapter09186a00800b75a9.html#1009161
>
>
>
> Thanks.
>
>
>
>
> -----Original Message-----
> From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
> Sent: Friday, June 04, 2004 10:23 AM
> To: Bob Sinclair
> Cc: Spolidoro, Guilherme; ccielab@groupstudy.com
> Subject: Re: QoS - Police - Congestion - NoCongestion
>
>
> Me too. (inter class WFQ that is)
>
> I've been told that there is sort of priority to bandwidth assigned
> classes wrt non bandwidth assigned classes.
> So if you have class a bw 10% and class-default w/o bw, enough class a
> traffic can starve the rest of the link.
>
>
> Bob Sinclair wrote:
>
> > 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
> >
> >
> >



This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:33 GMT-3