[cisco-voip] QoS Policing Bandwidth Question

[Josh Warcop]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141122/e0bad09d/attachment.html>
-------------- next part --------------
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip