[c-nsp] DTS traffic shaping & voice queuing
Rodney Dunn
rodunn at cisco.com
Tue Dec 21 11:07:29 EST 2004
Djerk,
I'll try again.
On Tue, Dec 21, 2004 at 04:27:28PM +0100, Djerk Geurts wrote:
> The debate is for when shaping to less than the physical speed and requiring
> LLQ for VoIP.
Ok. I guess it's when you are trying to deliver a subrate FE connection.
>
> In this case (Fast Ethernet for example) shaping delays traffic during
> congestion.
That's not really true. I think of it this way. If you have a T1
you can only clock bits out on the wire at a T1 rate. So the shaping
is /*if you will*/ built in to the circuit. Therefore to do QOS you
just apply the queueing policy on the interface.
Now when you go to an interface type where you need to impose some
form of sending rate control *and* do queueing you have to do shaping.
Shaping simply acts as a clock rate to govern the rate at which
bits are sent down the pipe. I can see how it can be said that
shaping delays packets but a T1 that gets a burst of packets
delays packets too. How much delay depends on the rate you
are allowed to send and the queue depth that packets are allowed
to build up in. To calculate the maximum delay you devide the
queue depth by the sending rate and that's the maximum delay
that could be imposed by the QOS. Anything above the queue depth would
be a drop.
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.
I think I see where things are confused here. The token bucket
implementation is just for the shaper/policer to know at
what rate it can send traffic. That token bucket doesn't
have anything to do with the order in which packets are sent.
Once the shaper kicks in any packets that are waiting to
be sent out the interface sit in queues. It's how those
packets are serviced from those queues that matters. For
LLQ if a packet is in the LLQ it always goes first and that
is what minimizes latency.
> Nowhere is the process detailed which makes
> sure that shaping does not adversely affect VoIP performance...
If shaping configured correctly was bad for VoIP performance
it would be impossible for customers to run voice over low
speed frame-relay links. It's the basis for QOS for customers
doing voice in their networks and it does work.
>
> 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...
I tried the best I could above without writing a thesis on it.
I guess the way I say it is think of a shaper as acting just like
if you turn the clock rate down on a serial. It simply tells the
box at what rate it can send out bits on the wire (how it does
it under the covers is via a token bucket implementation but that's
irrelevant here). If the rate you need to send out exceeds that
rate then packets are backed up in queues and how those packets
are serviced from the queues are what determines the affect on
packet delay/jitter/drops.
It just so happens that policing also uses a token bucket implementation
to control the rate at which packets are sent. The difference with
policing is there is no concept of backpressure to allow for intelligent
queueing to kick in (ie: LLQ). Policing just drops or transmits.
I find (and myself included) that people say it's complex, which it is,
because they don't understand right down at the code level exactly how
the bit bucket implementation works so they can't explain it at that
level.
I typed this to try and provide it to a wider audience if someone
learns from it.
If you want to discuss it some more send me an email offline
and maybe a call would be quicker.
Rodney
>
> 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/
> >
>
>
> _______________________________________________
> 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