From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Fri Jul 13 2007 - 18:46:18 ART
Djerk Geurts @ 13/07/2007 17:31 -0300 dixit:
>> Djerk was talking about different ways of PQ.
>> This is different ways of policing, which is what I was pointing out
>> in #4.
>> I thought this is actually the case on low level platforms too.
>> -Carlos
>
> Carlos, Mike is right, I was referring to what I thought was cisco's
> preferred way. But I think Mike is spot on in his explanation.
>
> Shaping is not policing, using the priority statement instead of the
> bandwidth statement does make it a PQ but the rate will indicate the weight
> of the queue which implies shaping (peak/average?) and _not_ policing.
This is kind of complicating things....
AFAIK, policing is not a queue servicing function. Shaping is.
And up to now, we all were talking about policing (i.e. enforcing
a maximum throughput on a class).
Sticking to LLQ (the priority queue in CBWFQ/MQC) it does have an
implicit policer. If you use the priority keyword, this class goes
to the only LLQ, FIFO, but only this much, i.e., it gets an implicit
policer. (Which only works if you are congested, as everything else in
CBWFQ).
Allmost, because explicit policers work all the time.
I have just verified that in a 2600... you can police a priority class
like:
policy-map test
class test
priority 1000
police rate 8000 bps
conform-action transmit
exceed-action drop
What is news to me is that you can put just "priority" w/o a value. I
have no access to a hardware assisted router like a 7600 now to test that.
-Carlos
>
>> Mike Kraus (mikraus) @ 13/07/2007 16:19 -0300 dixit:
>>> On higher end platforms (> 7200), there can be two modes of
>> operation
>>> for LLQ. (Depends on platform, IOS, modules...).
>
> Maybe the wording could have been "there are two ways of configuring queue
> management for PQ's" The LLQ operates as a PQ in fifo mode regardless of the
> queue management algorythm applied (shaping or policing)
>
>>> 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
>
> Also preferred to safeguard the CPU cycles as the software based routers are
> PPS based, VoIP is a quick killer. Often it's better to have a customer
> complaining about his voice rather than all his applications due to
> overloaded routers. I must say the SLA is a strong argument for us ISP's :)
>
> http://www.cisco.com/en/US/netsol/ns341/ns396/ns172/ns103/networking_solutio
> ns_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
>>>
>>>
>> ______________________________________________________________
>> _________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>> --
>> Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- 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