[c-nsp] QoS - questions

[Jeff Tantsura]

Hi Oli,

Thanks for your answers!!!

Another question :)

Migrating QoS config from 12K (12.0S) to 7200 (12.4T) I've found that
configuration of LLQ class with "priority" without bandwidth keyword is not
allowed anymore.
Is this a trend we will see in later IOS releases?

Thanks,
Jeff

P.S. Common, you are not that old, it's the feature sets growing more and
more :)


> -----Original Message-----
> From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
> Sent: dinsdag 21 augustus 2007 13:27
> To: Tim Franklin; jeff.tantsura at sscplus.nl
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] QoS - questions
> 
> Tim Franklin <mailto:tim at pelican.org> wrote on Tuesday, August 21, 2007
> 12:26 PM:
> 
> > On Tue, August 21, 2007 10:36 am, Jeff Tantsura wrote:
> >
> >> class LLQ
> >>  priority "bandwidth"
> >> policer would kick in only in case of congestion
> >> while in
> >> class LLQ
> >>  priority
> >>  police "bandwidth"
> >> policer would drop any traffic above the bandwidth specified.
> >
> > I'd go further than that - the behaviour I've seen to date, and would
> > expect, is that in the first case even with congestion there is no
> > policer.  Rather the LLQ gets a proportionate share of any 'free'
> > bandwidth above assigned minimum, just like any of the other CBWFQ
> > queues.
> >
> > I've definitely pushed more than 'priority bandwidth' worth of
> > priority
> > traffic through a congested link before now.
> >
> >> Thanks in advance for clarification.
> >
> > Seconded, I'd like to know how this is *supposed* to work.
> 
> Thanks for your input, made me look at the MQC specs again (and will
> have to revise my statement made earlier.. guess I'm getting old ;-)
> 
> the tocken bucket configured within the "priority" command is used to
> tell if the router needs to guarantee low-latency for the packets. If
> the traffic rate exceeds the configured rate, it will be sent right away
> if the link is uncongested at the time of excess traffic arrival, and
> will be dropped otherwise. I guess how this is exactly being implemented
> is somewhat platform/queuing-infrastructure-dependant..
> Either way: You don't want to send more LLQ traffic than configured
> there, otherwise you *might* drop packets.
> 
> priority without any cir/bw argument can result in all bandwidth being
> used by this class, so a policer confirmed in addition (the 2nd example
> above) would unconditionally drop packets above the configured policer's
> rate.
> 
> 	oli