From: Mike Kraus \(mikraus\) (mikraus@cisco.com)
Date: Fri Jul 13 2007 - 16:19:52 ART
On higher end platforms (> 7200), there can be two modes of operation
for LLQ. (Depends on platform, IOS, modules...).
Voice Traffic
There are two configurations that are generally used for the low-latency
("realtime" or "priority") class, which are distinguished by the
policing mode used. MQC supports two priority queue policing
configurations:
Congestion-aware policer
class SP-VOIP
priority [percent <%>|<kbps>] <burst>
set ip dscp|prec <dscp|prec> or set mpls experimental <0 through 7>
imposition
In this mode, the priority queue traffic is only policed when the
interface is congested. This mode is initiated by using the "rate"
option on the priority command.
Always On policer
class SP-VOIP
priority
police <bps> bc <bytes> conform transmit exceed drop
set ip dscp|prec <dscp|prec> or set mpls experimental <0 through 7>
In this mode the priority queue traffic is permanently policed. This
mode is initiated by using a discrete police statement within the
priority queue class. This method is more favorable for service
providers who wish to strictly enforce the VoIP contract
http://www.cisco.com/en/US/netsol/ns341/ns396/ns172/ns103/networking_sol
utions_white_paper09186a00801b1c5a.shtml
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Carlos G Mendioroz
Sent: Friday, July 13, 2007 1:42 PM
To: Djerk Geurts
Cc: ccielab@groupstudy.com
Subject: Re: Class-default contradiction
Djerk,
Djerk Geurts @ 13/07/2007 08:23 -0300 dixit:
> Carlos,
>
>> Djerk,
>> this is exactly what I was saying, so we agree.
>> (Nobody remembers custom queueing ???)
>
> Correct. Nobody _wants_ to remember custom queueing... ;)
>
>> I don't understand the PQ(LLQ) thing you are bringing up though.
>> PQs have priority, which is a police statement. They get ALL the
>> bandwidth, even first thing (PQ, right?) but up to this much.
>> AFAIK, a queue becomes a PQ when you use the priority keyword, and
>> this implies the policing of it, so there is no way you can have a PQ
>> w/o policing.
>
> Apparently this is not true, CCO doesn't help here as there are too
> many conflicting docs on QoS there.
>
> One has to distingush here between software (up to 7200) and hardware
> (7300 GSR CRS-1) based platforms. The priority key-word, like you say,
> enables the priority queue. However the word strict has come to mean
> (to me at least) a policed PQ. The confusion is that a priority
> statement with bandwidth % isn't a policed PQ, resulting in
> 'unpredictable' behaviour when shaping VoIP traffic. So does this mean
> it is a strict PQ? I recall something from Networkers this year that
> best practice is to use the priority keyword with a police statement
> and not use the bandwidth option on the priority statement.
>
> So please correct me if I'm wrong Cannes was back in January after all
> and I've not had the time since to look it up in my notes or
> hand-outs. Btw, I don't trust CCO anymore on the subject of QoS...
>
> I understand that things may be different from what they said at
> Networkers to what we study for the lab. Networkers referred to the
> CRS-1 mostly (due to marketing?) while the lab uses only SW based
routers.
Well, this is possibly above my level of knowledge, and I usually agree
with things being far more messier than it shows.
But:
1) MQC is a syntax. If the implementation in a platform of a given
config is different from another, I would call this a bug (or a
feature:)
2) PQ is PQ is PQ. I don't really know what "strict" PQ is.
If there is a strict, there should be a loose version of it ? :)
3) As far as I know, there is no way to make a queue a PQ without using
the priority keyword. Percent only changes the meaning of the numbers,
by scaling them.
4) priority implies policing. Allmost. The implied policer only works
when queue management is engaged (i.e. interface congested).
Configuring an explicit policer engages it (the policer) all the time.
>
>> The whole thing I was trying to say is that the default queue works
>> like a "low priority" queue, but without the grace of the policing of
>> the rest, and thus the starving possibility.
>> (when no bandwidth is assigned)
>
> I agree totally
>
>> BTW, queues don't need to know their bit rates, just their "share"
>> of available BW. In your examples, 3/4/3 or 1/5/4.
>
> And again 100% correct
>
>> -Carlos
>
> Djerk
>
BTW, do you have any pointer to NW presos ?
Take care,
-Carlos
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART