[c-nsp] DTS traffic shaping & voice queuing

[Djerk Geurts]

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.

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/
>