From: Djerk Geurts (djerk@djerk.nl)
Date: Fri Jul 13 2007 - 17:31:10 ART
> 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.
> 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
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART