[c-nsp] QoS - questions

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Tue Aug 21 07:26:32 EDT 2007


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


More information about the cisco-nsp mailing list