[cisco-voip] QoS Policing Bandwidth Question

Sun Nov 23 06:43:06 EST 2014

The priority queue exceed was set to drop, which I didn’t recommend since it only had 7965 voice rtp packets, but failed to account for recording.

From: Anthony Holloway [mailto:avholloway+cisco-voip at gmail.com]
Sent: Sunday, November 23, 2014 12:36 AM
To: Jason Aarons (AM); Josh Warcop; Cisco VoIP Group
Subject: Re: [cisco-voip] QoS Policing Bandwidth Question

Thanks for sharing your experience Jason.  What was the exceed action set to?  Drop or remark and transmit?  Do you recall?  I'm thinking drop, because a remark to what would typically be CS1 shouldn't cause too much of a fuss as long as there's not congestion on the network.

Actually, that brings up a question in my mind: What percent of time does an average enterprise network spend in a congestive state?

This wikipedia article sheds some light on it with the following:

"Even on fast computer networks (e.g. Gigabit Ethernet), the backbone can easily be congested by a few servers and client PCs"

http://en.wikipedia.org/wiki/Network_congestion

But it doesn't elaborate if that's with light usage or streaming HD videos off of Netflix.  My curiosity is more around your average worker, checking email, surfing the web, chatting over IM, etc.

On Sat Nov 22 2014 at 7:40:55 PM Jason Aarons (AM) <jason.aarons at dimensiondata.com<mailto:jason.aarons at dimensiondata.com>> wrote:
Had a customer go with B and drop the priority queue above that.  Little did they remember they had Nice call recording, making the answer 261.6k.  It was rather interesting when they rolled out a 80k service policy on the L2 ports.

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Josh Warcop
Sent: Saturday, November 22, 2014 9:34 PM
To: Anthony Holloway; Cisco VoIP Group
Subject: Re: [cisco-voip] QoS Policing Bandwidth Question

B.
________________________________
From: Anthony Holloway<mailto:avholloway+cisco-voip at gmail.com>
Sent: ‎11/‎22/‎2014 9:17 PM
To: Cisco VoIP Group<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] QoS Policing Bandwidth Question
Here's a little Saturday afternoon thought provoking question for the group.

If you were asked to police your access ports to allow only a single g711 call, which of the following values is correct?  Assume you run an Ethernet based LAN on Cisco switches for this question.

A.  80Kbps
B.  87.2Kbps
C.  93Kbps
D.  95.2Kbps
E.  96.8Kbps
F.  None of the above

Yes, I am studying QoS at the moment.  ;)

So, here's my answer and why I think that it's right...Stop reading if you haven't picked your answer yet.

Only read on after selecting your own answer, so that my answer does not influence your choice.

The same would go for any replies to this discussion, pick your answer first, then read what others are saying.

Ok, here we go...

I choose F. None of the above

Here is why...also, if you click the links, it will take you to a reference for each value and why they were chosen as choices to this question.

A.  80Kbps<http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmsys/accm-712-cm/a02cac.html#wp1033346> is the bitrate of the codec, so that's plain wrong.  It's lacking all L2 - 4 headers.

B.  87.2Kbps<http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html#topic1> does consider the L2 - 4 headers, but it fails to account for Ethernet CRC and IPG.

C.  93Kbps<http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/QoSIntro.html#29651> also considers the L2 - 4 headers, while ignoring the CRC+IPG, but it does account for a 5% overhead buffer which is nice.

D.  95.2Kbps<http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/ipv6/ipv6srnd/netstruc.html#wp1057244> considers L2 - 4 headers, CRC+IPG, but an IPG value only valid for Gig ports.  Actually, you could argue a swap for CRC and IPG because they're both 4 Bytes.  It's not like you define which headers you're covering, rather it's the final value that matters.

E.  96.8Kbps<http://www.bandcalc.com/> considers L2 - 4 headers, CRC+IPG, and an IPG value for 100meg ports, which covers Gig ports as well.  I have two complaints with this value:

1) The value isn't a clean increment of 500 bps or 1Kbps, so when you type in: police 96.8k, the switch will change it to 96.5k, forcing you to go with 97k.  Then how would your value look if you needed to police for more than one call (think BIB media forking<http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/mediasense/105_SU1/Design_Guide/CUMS_BK_MC36D963_00_mediasense-srnd_105_SU1/CUMS_BK_MC36D963_00_mediasense-srnd_10-5_chapter_01110.html#CUMS_RF_PE0FD1E8_00>)?  97k * 2 = 194k.  97k * 2.5 = 242.5k  I don't know about you, but I would have to double check with a calculator to find out if those values were correct.

SW1(config-pmap-c)#police 96.8k 8000 exceed-a drop
SW1(config-pmap-c)#do sh run | in police 96
  police 96500 8000 exceed-action drop

2)  The value doesn't consider any overhead or "wiggle room."  I'd rather allow an extra 5% of traffic and carry the burden on the network versus impact a voice call.

Since all choices come with a caveat, I'd like to go with 100Kbps.

I have three main reasons for this value:

1)  It's enough to cover some wiggle room, "all preambles, headers, flags, cyclic redundancy checks, and padding"*, the highest IPG, but not so large that it weakens the integrity of the goal to police traffic to a single call.

2)  It's a nice round increment and multiplying the value for 2 or 2.5 calls (mediasense) is easy work.  100k * 2 = 200k.  100k * 2.5 = 250k.

*A modified wording from the following document<http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/QoSIntro.html#pgfId-46536>.

3)  Since picking anyone of the alternative answers leaves you defending your choice anyway ("I saw it in the SRND", "It's what Auto QoS configures", "My Magic 8 Ball Said I Could Rely On It<http://en.wikipedia.org/wiki/Magic_8-Ball#Possible_answers>," etc.), why not go with something original and creative and defend your answer with a well thought out explanation?  Who knows, you might provoke the next big revolution in QoS.  Oh wait, that's MediaNet, isn't it?

So, now that you have my answer, I'd be really interested in reading your's.

Have a great Saturday everyone.

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141123/0ef273ef/attachment.html>