[c-nsp] DTS traffic shaping & voice queuing
Djerk Geurts
djerk.cisco at easynet.nl
Tue Dec 21 10:27:28 EST 2004
The debate is for when shaping to less than the physical speed and requiring
LLQ for VoIP.
In this case (Fast Ethernet for example) shaping delays traffic during
congestion. If VoIp traffic destined for the PQ is delayed as well (all
tokens have been assigned - full bucket) then this delay affects VoIP
performance which is not good. Nowhere is the process detailed which makes
sure that shaping does not adversely affect VoIP performance...
PW does policing so I'm not talking about VoIp BW guarantees just the effect
of shaping on VoIP latency. I've been told by Cisco that PQ traffic is not
affected by the shaping and that the process is complex. All nice and well
but in a debate hear-say does not stand a chance...
Djerk
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com]
> Sent: Tuesday, December 21, 2004 4:07 PM
> To: Djerk Geurts
> Cc: Cisco NSP
> Subject: Re: [c-nsp] DTS traffic shaping & voice queuing
>
>
> 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