[cisco-voip] QoS Policing Bandwidth Question

Sat Nov 22 23:32:48 EST 2014

Josh,

Thanks for responding to my question on a Saturday!

The question was about traffic policing, which you do on ingress at the
access layer.  It's a mechanism to penalize traffic that doesn't conform to
your policies.  Usually by dropping or remarking to CS1.  Whereas traffic
shaping is the egress mechanism that wants all traffic to leave the
network, just, in a controlled manner.

I think about it like this: if a device plugged into a switch port started
flooding the port with traffic, it could impact network services.
Especially if that traffic was being marked with CoS 5 and I was honoring
CoS markings on that port.  It could be an attacker, or it could be a
broken piece of hardware which is malfunctioning.  Whatever the reason, my
network would be safe* from a flood if I policed on ingress.

*I don't claim to be a security expert, so "safe" is a relative term
On Sat Nov 22 2014 at 6:46:34 PM Josh Warcop <josh at warcop.com> wrote:

>  I'm finding per circuit bandwith becoming irrelevant. It is so easy tom
> get 100Mbps Ethernet circuits. 87.Kbps is still the answer.
>
>
> Sent from my Windows Phone
>  ------------------------------
> From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
> Sent: ‎11/‎22/‎2014 9:40 PM
> To: Cisco VoIP Group <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] QoS Policing Bandwidth Question
>
>  Oops!  Sorry folks, but I have an error in my explanation of my
> selection.  However, for the sake of keeping my reply hidden from view, I
> cannot easily correct it via the mailing list (a benefit of a web forum).
> When you spot it, you'll know, and you may even be able to guess why it's
> wrong.  Hint: I originally typed 64Kbps but then edited the value without
> editing the explanation.
>
> On Sat Nov 22 2014 at 3:14:33 PM Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141123/7c655cb2/attachment.html>