[cisco-voip] QoS Policing Bandwidth Question

Sun Nov 23 00:35:58 EST 2014

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> 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] *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 <avholloway+cisco-voip at gmail.com>
> *Sent: *‎11/‎22/‎2014 9:17 PM
> *To: *Cisco VoIP Group <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/f3fac7c3/attachment.html>