[cisco-voip] PER CALL BANDWIDTH CONSUMPTION OVER ETHERNET+802.1Q

Thu Apr 16 14:32:22 EDT 2015

Thanks Dennis, that’s interesting figures. 

Surprised that Cisco in their SRNDs and even the end to end Qos book, have used a 128k everywhere, without any explanation that this depends on the codecs/no. of calls. 

From: Heim, Dennis [mailto:Dennis.Heim at wwt.com] 
Sent: 16 April 2015 12:42
To: Abbas Wali; 'Anthony Holloway'
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] PER CALL BANDWIDTH CONSUMPTION OVER ETHERNET+802.1Q

With BiB it is 3x your codec.

G.711 example:

1.       80k down far-end audio (remote party->current user)

2.       80k up current user audio (current user->remote party)

3.       80k up bib far-end audio (current user->recording server)

4.       80k up bib current user audio. (current user->recording server).

On a G.711 call you would have need 80k down and 240k up.

Dennis Heim | Emerging Technology Architect (Collaboration)

World Wide Technology, Inc. | +1 314-212-1814

 <https://twitter.com/CollabSensei> 

 <xmpp:dennis.heim at wwt.com>  <tel:+13142121814>  <sip:dennis.heim at wwt.com> 

"Innovation happens on project squared" --  <http://www.projectsquared.com/> http://www.projectsquared.com

 <https://wwt.webex.com/meet/dennis.heim> Click here to join me in my Collaboration Meeting Room

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Abbas Wali
Sent: Thursday, April 16, 2015 5:16 AM
To: 'Anthony Holloway'
Cc: cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net> 
Subject: Re: [cisco-voip] PER CALL BANDWIDTH CONSUMPTION OVER ETHERNET+802.1Q

Thanks mate. 

From: Anthony Holloway [mailto:avholloway+cisco-voip at gmail.com] 
Sent: 15 April 2015 21:46
To: abbas Wali
Cc: cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net> 
Subject: Re: [cisco-voip] PER CALL BANDWIDTH CONSUMPTION OVER ETHERNET+802.1Q

I read somewhere that a phone could generate up to 2.5x call traffic with its BIB.  Multiplying by 3x would still be acceptable, I would think.

The 8000 is a burst threshold over the policed rate.  It's always been 8000 in my experience, but probably only because no one knows enough to adjust it  You cannot have an average and a max rate with voice.  It's constant (excluding VAD).  Video on the other hand is variable.

If you are studying for your CCIE, I can share with you that Cisco has publicly stated they have some percentage of forgiveness.  I.e., If they say 3 g711ulaw calls worth of bandwidth, and I enter 90*3=270, but you enter 93*3=279 (or even round up to 280), we would both get the points.  What the percentage is, I don't recall.  I want to say it was like 10%.  So for every 100kbps, you can be plus or minus 10kbps.

On Wed, Apr 15, 2015 at 1:00 PM abbas Wali <abbaseo at gmail.com <mailto:abbaseo at gmail.com> > wrote:

Anthony, 

yes makes sense. but for the sake of argu. a single phone with even with BIB how many max g711 streams it can get to. 3? if so, for a safe figure can multiply by 3. 

moreover, I dont really understand this statement police 90500 8000 exc drop - as per docs, the actual transmission is 8k but on the avg. the max is 90k ( plz correct if wrong)

On 15 April 2015 at 18:10, Anthony Holloway <avholloway+cisco-voip at gmail.com <mailto:avholloway+cisco-voip at gmail.com> > wrote:

After reading the Medianet document, I'm certain they are just giving you an example, not a definitive answer nor the best practice.  While 128kbps does police the port to a single g711ulaw call, it also allows for a little wiggle room, which I like.  If you are looking for the absolute minimum bandwidth needed for a g711ulaw call, you could go lower than 128kbps, but you wouldn't gain anything.  Don't forget that the BIB of the phone could cause more than a single call's worth of RTP to ingress the switch port, in which case your 128kbps would not be enough and you would have issues with things such as network recording or silent monitoring.

On Wed, Apr 15, 2015 at 9:19 AM abbas Wali <abbaseo at gmail.com <mailto:abbaseo at gmail.com> > wrote:

medianet is 

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

Vik's post 

http://www.collabcert.com/blog/qos/how-much-bandwidth-does-1-call-consume/

On 15 April 2015 at 13:44, Anthony Holloway <avholloway+cisco-voip at gmail.com <mailto:avholloway+cisco-voip at gmail.com> > wrote:

Can you link us to the sources in question? I personally need a little more context to go with your question. 

In general, policing a single g711ulaw call is around 93kbps, and rounding it to 100kbps still achieves the goal of policing a single call. And yes, a class based policer would police media and signaling separately. 

Also, I saw something on medianet at last year Cisco Live, but other than that, I'm clueless about medianet. I can't say if and how things changed once medianet came in to the picture. I'm sure Vik wasn't considering that either, based on the fact that he teaches CCIE Collab boot camps, and medianet is not a part of the blueprint. 

On Wed, Apr 15, 2015 at 4:22 AM abbas Wali <abbaseo at gmail.com <mailto:abbaseo at gmail.com> > wrote:

hi all,

Vik Malhi posted that for a successful g711 call 

HQSW(config-pmap-c)#police 90500 8000 exc drop ! 0 packet loss
now, as per Ciso medianet 4
The VoIP and signaling traffic from the VVLAN can be policed to drop at 128 kbps and 32 kbps, respectively (as any excessive traffic matching this criteria would be indicative of network abuse)
Question is 128 kbps supports 1 single voice stream of g711 OR if you go with Vik, you need to multiply 90500 with the number of calls you need on that port. I will assume that the sig is classified differently and handled by diff policer on that port.

many thanks

-- 

Abbas Wali

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net> 
https://puck.nether.net/mailman/listinfo/cisco-voip

-- 

Abbas Wali

-- 

Abbas Wali

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150416/2b4a9b00/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3876 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150416/2b4a9b00/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1389 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150416/2b4a9b00/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1292 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150416/2b4a9b00/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1391 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150416/2b4a9b00/attachment-0003.png>