[c-nsp] DTS traffic shaping & voice queuing

Rodney Dunn rodunn at cisco.com
Tue Dec 21 10:06:47 EST 2004 

On Tue, Dec 21, 2004 at 01:55:57PM +0100, Djerk Geurts wrote:
> http://www.cisco.com/warp/public/105/policevsshape.html
> 
> Last part of this page explains a little. Any additional facts are still
> welcome...
> 
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net 
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Djerk Geurts
> > Sent: Tuesday, December 21, 2004 10:47 AM
> > To: Cisco NSP
> > Subject: RE: [c-nsp] DTS traffic shaping & voice queuing
> > 
> > 
> > Is there any Cisco documentation which details the complete 
> > process as all that I can find is either the LLQ (in detail), 
> > the policing/shaping or the combination between the two. But 
> > nowhere is the adverse effect of policing and/or shaping on 
> > the PQ traffic discussed.

I don't think I get exactly what you need to convince them of
so I don't know how to give you the answer you need.
It's not as simple as X and Y.  It can be applied in a lot
of different ways.

It's like this:

shaping creates backpressure for queueing
You may or may not need shaping depending on the physical
media you are applying the queueing on.  You only need
to shape when there isn't a congestion notification mechanism
that will kick in automatically such as on Frame PVC's.

policing simply makes sure that traffic isn't sent that
exceeds a given rate

You can really turn it in to a debate because there
are two ways to look at it.

You have high priority traffic and low priority traffic
   that has to traverse a link with X bandwidth.

You can do two things:

a) police all low priority traffic to make sure there is
   enough BW always available for the high priority traffic
   Con: That low priority traffic is always limited to what
        you police to.  Therefore if there isn't high priority
        traffic the low priority never gets to use that bandwidth.
        That's one of the main reasons people don't like that approach.

b) You do QOS (LLQ and if needed shaping) to make sure that
   even during congestion you guarantee that the bandwidth
   is used as you define.  ie: LLQ (to provide little to no
   delay for voice traffic), BW class (to give some traffic
   a portion of the bandwidth at all times such as video),
   default class (to handle the extra traffic on a best effort
   basis).

Rodney

   

> > 
> > So all I can do is assume that it will work without too much 
> > delay. Thanks for the reply but I need to convince ppl based 
> > on facts and figured. We are conducting our tests but I'd 
> > like to make a well founded statement rather than an "I 
> > belive it is so" one...
> > 
> > Djerk
> > 
> > > -----Original Message-----
> > > From: Rodney Dunn [mailto:rodunn at cisco.com]
> > > Sent: Monday, December 20, 2004 4:24 PM
> > > To: Djerk Geurts
> > > Cc: Cisco NSP
> > > Subject: Re: [c-nsp] DTS traffic shaping & voice queuing
> > > 
> > > 
> > > On Mon, Dec 20, 2004 at 09:51:56AM +0100, Djerk Geurts wrote:
> > > > Who can tell me how voice is processed when doing DTS (QoS)
> > > 
> > > Depends to what level you are asking.
> > > The most basic is:
> > > 
> > > shaping creates backpressure to the queueing engine by
> > > saying the interface can transmit at X rate.
> > > Once the queueing kicks in when the shaper is allowed
> > > to send more data the queueing code determines which
> > > packets (in what order) are given to the shaper to send.
> > > 
> > > No congestion, it's FIFO for all traffic.
> > > 
> > > > 
> > > > The principle is to have a hyrarchical policy-map with the parent
> > > > shaping to CIR and the child doing the actual QoS queuing and 
> > > > bandwidth statements according to the set classes.
> > > 
> > > Yep.
> > > 
> > > The purpose is to apply QoS to a Fast-Ethernet
> > > > sub-interface where the sub-interface should be rate limited.
> > > 
> > > That's fine.  It should work on an IOS router.  There are
> > > some gotchas where the driver code didn't work just right for 
> > > the shaping (ie: ethernet interfaces).  I don't remember the 
> > > details of which but I know I've seen it before.  As for a L3 
> > > switch like the 65xx I'm not sure about this.  I don't think 
> > > it will do shaping.
> > > 
> > > > 
> > > > As far as I know now:
> > > > Shape average = Commits to CIR (best as I need to commit to CIR)
> > > > Shape peak    = Sends Bc & Be (not good when doing voice? 
> > > If Be=0 then the
> > > > same as average?)
> > > >
> > > 
> > > It all depends on how the downstream handles the traffic.
> > > Most people just do "shape average <CIR>" and leave it as that.
> > > 
> > >  
> > > > - Shaping delays traffic upon congestion as it's queued in
> > > the shaping
> > > > process. Which is not good for voice traffic.
> > > 
> > > Not true.  Shaping simply acts as the gateway to the wire on
> > > how fast it lets data go out.  You will introduce queueing 
> > > delay in the QOS queues but that's what you get when you have 
> > > congestion. You put your VOICE in a priority (LLQ) so the 
> > > queueing code makes sure those packets get out first so there 
> > > is little to no delay in that class.
> > > 
> > > The other classes will see some small amount of delay but in
> > > a BW class that just means that the queueing code will 
> > > guarantee that the class gets the configured amount of BW 
> > > over time.  It does NOT mean it will go out first.  That's 
> > > what LLQ is for.  Send the voice first.
> > > 
> > > > 
> > > > - Policing no queueing happens but packets are just
> > > dropped. This is
> > > > not good for voice either.
> > > 
> > > Not a good idea.
> > > 
> > > > 
> > > > Regards,
> > > > 
> > > > --
> > > > Djerk Geurts
> > > > 
> > > > 
> > > > _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > 
> > 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list