Equipment Support > Hardware By Brand > Cisco > Priority Queue - Threshold other traffic denied service.

Priority Queue - Threshold other traffic denied service.

Depends on the number of calls, bandwidth used per call and latency that’s required... While no specifics have been provided, this request might not be out of line if a couple hundred call are active at one time…

reply to carp
20Mbps is being allocated to the queue. 90.1kbps per call. Peaks at 168 calls, ~221 max allowed in the 20Mbps.

Latency, well you know how upper management can be. Essentially not allowed for interactive traffic. They can't wait seconds for screen pops with a customer on the phone.

QOS profiles are dependant on the traffic utilizing the circuit. I have tables full of real profiles and how they chop things up.

I have also seen several providers pull a stunt: "priority percent 90" for EF traffic. This works well because the priority LLQ mechanism is IOS is congestion aware. It only flips on if the interface is "experiencing congestion".

Why? Voice (RTP) is important, and everything else will retransmit. If a circuit is congested a good percent of the time, it needs to be upgraded. For the instances where traffic bursts and problems crop up, the VOIP will be protected.

reply to carp
How big is the pipe in question?

Would you be able to supply your current QOS configs, if not the entire config, for us to review?

Second all that has been said so far. Do you have any sort of monitoring in place that shows
you how much bandwidth is being used by what apps? If you don't have any sort of measurements
in place, how are you going to tell what's going on?

Regards

reply to carp
Not looking for help working out a policy. Asking if anyone has seen documentation or has an opinion/experience of when PQs in CBWFQing become troublesome or DOS other classes when the PQ has too high of a bandwidth reservation. I get the impression it's merely create policy, monitor, tweak. Repeat until time to add capacity.

Yes, we know all the applications on the link, what they use, current PQ/CBWFQqueue , etc. There's a "policy/politics" part of the problem since it's rare to get buy in to a traffic policy that makes sense. Can't even be restrictive on email traffic or remote file transfers in most cases.

The answer usually given is "then you need to increase bandwidth if you want everything on a level playing field". It's actually the smart answer in this situation anyways. It's a bigger location with a call center and no redundancy to begin with. It would be a rather busy DS3 when near peak calls. Peak calls + Peak Data will put the link over 1o0% utilization and for some good chunks of time.

Thanks for the thoughts.

"Only a guru or a fool would break the 33% rule!"

That is the general consensus when provisioning voice bandwidth against Cisco's design recommendations as stated in the SRND.

It all depends on how one perceives oneself.

I am assuming you are talking about low latency queueing here and not another priority mechanism such as "ip rtp priority" but the consensus is the same either way.

You can, of course, deploy any amount of bandwidth you want for LLQ as have many others in the past and so will in the future however you should only breach the Cisco design guidelines if the circuit is relatively low bw (yours isn't) and if you have performed traffic analysis and checked out the jitter, delay and loss for any non-VoIP critical traffic (IP SLA is good for that) with both the 33% profile and the 43% profile. This will also include checking the router's stats.

Don't forget that any call signalling protocols which may also traverse the link will also suffer giving rise to call setup, call tear down, and any mid-call features delay and registration issues if the phones need to register to their CUCM across the WAN.

Here is some bed time reading which is the CUCM 8.x SRND however the rule is true across all previous versions of CUCM:

»www.cisco.com/en/US/docs/voice_i···p1165070
--
A word to the wise ain't necessary, it's the stupid ones who need the advice!

Would you provision 33% EF priority queue for a call center with hundreds of agents and an expectation of 120+mbps of VOIP on a 155mbps OC3?

The correct policy is entirely dependant on the traffic and calculated required bandwidth protection for realtime traffic coming from a given location.

So what if EF starves out other queues? If that is legitimate voip, would you rather be dropping phone calls or slowing down youtube videos?

I guess that is directed at me... That is a very general question with no real detail to be honest and thus I will make some assumptions. I would use a lower bandwidth codec (iLBC is a very good example) AND not put all my eggs in one basket in the context of having just a single cct from a single carrier to carry all my voice calls but have geographically diverse ccts from different carriers.

In your example, it looks like this is a pure voice cct with data as a "distraction" and in my opinion there is no point in having data across on that. You might as well as provision a 20 Mbps circuit with no QoS just for data and leave the OC3 for the voice. It could also in times of outages, be a backup for critical calls outbound.

You mentioned YouTube... I guess you are being cheeky as I am sure the environment you are thinking of does not just have people talking on the phone endlessly with no aim or way to log their calls, and if they are not, they are on YouTube. Depending on the topology, there are CRM applications, CTI control of the agents' desktops, intranet, third party partner websites, etc, which if starved, can also lead to issues.

So in your example, if you can't reach the 33% and are closer to 80% voice traffic, then you can either use a low bw codec + compression to get it below that (assuming you are using G.711u/a) or just move the data to another circuit.

We found that separation at levels above 40% on circuits bigger than your OC3 was the optimum level HOWEVER any request for over 33% needs a traffic profile built up first with 6 monthly checks as to the jitter, delay and packet loss for the 6 class QoS model we have.

Hope that helps.
--
A word to the wise ain't necessary, it's the stupid ones who need the advice!

$SPEED >=1 <= 120
policy-map DSCP_1M_TO_120M_$PERCENTVOIPEF_$PROFILE_6Q
  class DSCP_EF_CS5
    priority percent $PERCENTVOIP 
  class DSCP_AF4X
   bandwidth remaining percent $Q1PERCENT
    queue-limit 1024 packets
    random-detect dscp-based
    random-detect dscp cs4  171 500 1
    random-detect dscp af41 171 500 1
    random-detect dscp af42 52  171 1
    random-detect dscp af43 52  171 1
  class DSCP_AF3X_CS6_CS7
   bandwidth remaining percent $Q2PERCENT 
    queue-limit 2048 packets
    random-detect dscp-based
    random-detect dscp cs3  250 500 1
    random-detect dscp af31 250 500 1
    random-detect dscp af32 52  250 1
    random-detect dscp af33 52  250 1
    random-detect dscp cs6  511 512 10
    random-detect dscp cs7  511 512 10
  class DSCP_AF2X
   bandwidth remaining percent $Q3PERCENT
    queue-limit 1024 packets
    random-detect dscp-based
    random-detect dscp cs2  171 500 1
    random-detect dscp af21 171 500 1
    random-detect dscp af22 52  171 1
    random-detect dscp af23 52  171 1
  class DSCP_AF1X
   bandwidth remaining percent $Q4PERCENT
    queue-limit 1024 packets
    random-detect dscp-based
    random-detect dscp cs1  171 500 1
    random-detect dscp af11 171 500 1
    random-detect dscp af12 52  171 1
    random-detect dscp af13 52  171 1
  class IP_BEST_EFFORT_BE
   bandwidth remaining percent $Q5PERCENT
    queue-limit 512 packets
    random-detect dscp-based
    random-detect dscp 0    171 500 1
 

reply to carp

reply to nosx

I was not speaking as a customer of a provider, i was speaking as an engineer from the provider that implemented the services. I have the engineering documentation behind alot of that research and deployment as well. Cisco (AS & CE) have been engaged periodically and on the last call they refered to the architecture as "very strong".

The 33% number doesnt hold true unless you are stuck in 2005 on a T1. The right answer is to construct a service policy based on the actual traffic that will use the circuit and must be protected.

If you want an SRND example, see www.cisco.com/warp/public/cc/so/neso/vpn/vpnsp/spqsd_wp.pdf where Cisco explicitly exceeds 33% priority queueing for realtime traffic.

Well thank you for that insider knowledge. I was under the impression that VZB like numerous other SPs actually have an in house algorithm which is based on Cisco (after a NDA) providing the inner workings of its QoS algorithm as the WRED thresholds can be complicated based on a 6 or more QoS model but it's nice to know they still do things the old fashioned way.

That SRND is dated 2002 AND is not relevant to the OP. Why... because we are talking about the 33% rule in context of CE to PE, not PE to CE. You are still acting like a Data engineer and not a VoIP engineer. The methodologies and way of doing things are different. Try spending time in a VoIP specific forum and you will see there is more to VoIP than QoS or just trying things out.

Actually, I realised I am talking to a Data engineer and not a VoIP engineer so you look at it from a SP point of view, I will look at it from a VoIP point of view, and let it be.

The SRND posted for VoIP is the one and only reference for Cisco VoIP in an enterprise environment.

So let's not complicate matters for the OP by throwing in SRNDs which are dated and are not relevant to them as the OP is asking from an enterprise background and not SP. Let me re-iterate that again, there is a difference in QoS between SP and Enterprise and if that can't be appreciated, well, I know for sure that I will never be out of a job and I look forward to many years of consultancy work when I get out of this game.

In addition, if this old hat, why is it in the Voice CCIE? I rest my case now.

Think the OP has long gone cos we scared him off... LOL!

--
Edit: Too blunt for my own good!

reply to Covenant

Re: Priority Queue - Threshold other traffic denied service.

reply to carp
I'm still here.

I reset the counters of the current policy last Thursday and have dropped ~110000 packets in the policy since then with only 13% of the bandwidth for LLQ, which isn't ustilized much since the voice is currently on separate T1's from the data Most of the drops come from the class with the biggest chunk of BW and a little assured forwarding (only AF41).