Calculating VoIP Throughput Requirements
By stretch | Monday, February 14, 2011 at 1:04 a.m. UTC
Member rakem recently mentioned in the forums an issue he experienced with a QoS policy for VoIP traffic over a low-bandwidth (512 Kbps) link. The original QoS policy had allocated 15% of the available throughput for VoIP traffic. Generally speaking, this is not an unacceptable approach; however, such slow links require diligent consideration of absolute (versus relative) traffic requirements.
A QoS policy map statement which allocates 15% of the available throughput on a 512 Kbps interface is only reserving roughly 76 Kbps for the given traffic class. Such a policy might be configured like this:
class-map match-all VoIP match dscp ef ! policy-map Uplink class VoIP priority percent 15 ! interface FastEthernet0/0 bandwidth 512 service-policy output Uplink
We can use the command
show service-policy interface to verify that the policy is applied as expected:
Router# show policy-map interface f0/0 FastEthernet0/0 Service-policy output: Uplink Class-map: VoIP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: dscp ef (46) Queueing Strict Priority Output Queue: Conversation 136 Bandwidth 15 (%) Bandwidth 76 (kbps) Burst 1900 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
In rakem's case, the VOIP codec being used was G.711, which requires 64 Kbps of throughput per call. However, this number accounts only for voice payload. To calculate the overall throughput required per call, we have to factor in payload sample size (packetization rate) and lower-layer packet headers (RTP, UDP, IP, and layer two). A sample calculation can be found on the VoIP Basics cheat sheet. We can calculate this overhead manually or use a VoIP bandwidth calculator like the one at bandcalc.com:
Without factoring in the L2 overhead (which will vary depending on the medium used), we can calculate that a single VoIP call using the G.711 codec and a 20 msec sample size requires at least 80 Kbps of throughput (each way), more than the 76 Kbps allocated by the 15% QoS policy. Packets from the voice stream will be dropped when there is contention for the available throughput.
Using the VoIP bandwidth calculator and specifying Ethernet (non-802.1Q) as the layer two medium, we see that a single call requires at least 95.2 Kbps of throughput, which we'll round up to 96 Kbps. Now we can redefine the earlier QoS policy with a more appropriate measure:
class-map match-all VoIP match dscp ef ! policy-map Uplink class VoIP priority 96 ! interface FastEthernet0/0 bandwidth 512 service-policy output Uplink
Of course, we're still limited to a single call of guaranteed quality. A more desirable solution, as rakem saw, would be to employ a more efficient voice codec. G.729a, for example, requires only 8 Kbps of throughput for its voice payload. This results in a total unidirectional utilization of ~40 Kbps per call (assuming Ethernet is used at L2); less than half of that required for a single G.711 call.
February 14, 2011 at 12:08 p.m. UTC
Throw in some RTP header compression on the G.729a and you could get that 40kbps down significantly I'm sure too.
Definitely something to make sure to take into account, the data is only a portion of the packet, I guess when people are used to high bandwidth links and higher data generating/requesting applications, the header usually makes up such an insignificant portion of the bandwidth used that it isn't something you come across as often as you would with voice.
February 14, 2011 at 4:22 p.m. UTC
One thing I just discovered about how matching/queuing in regards to VoIP and GRE/IPSEC tunnels...in my experience you must create two service policies. The first to match on the inbound interface because the traffic is unencrypted and the second for the physical interface to apply queuing policy.
When I tried to apply a match and queue policy in a single service policy, my rtp traffic was never matched and there for my priority queue never used. I'm assuming because the packet was encrypted and the router couldn't tell what the payload was.
February 14, 2011 at 8:12 p.m. UTC
Mikeh: look into the qos pre-classify command, that applies QoS before encryption
February 14, 2011 at 8:58 p.m. UTC
Mikeh: Actually you don't need to. If packets enter your router already marked (dscp ef, af31 - coming from IP telephone or VoIP enabled switch they usually do), Cisco router automatically copies existing ToS bytes to new tunnel header. So if you do matching on ToS, it works. However, if you need to do matching based on other criteria that get scrapped with new IP header such as source/destination IP address, deep packet inspection using nbar etc., use qos pre-classify command under tunnel interface or crypto-map. Try it and see if it works for you.
February 15, 2011 at 1:42 a.m. UTC
Question - If you assign a value to a LLQ (15% link this example) even when there is nothing else using the bandwidth the LLQ will police anything over 15% right?
February 15, 2011 at 4:00 a.m. UTC
You're right for probably 99.9% of deployments. In our case though, the rtp traffic is originating from workstations - so we chose not to trust the dscp values. I suppose it's a trade off between security and end-to-end qos. We're managing the risk between someone maliciously marking their ftp download traffic as "ef" and the odds of the access switch being overwhelmed. Pick your poison.
That being said the incoming rtp traffic is dscp 0, there for I found that even if I used the qos pre-classify the router couldn't classify or mark the rtp as ef when the policy was applied to the outbound physical interface because encryption had already taken place. All the rtp traffic was going in the best effort queue. Once I applied a classify and mark policy on the inbound interface, the new dscp value based upon the inbound policy got bumped up to the gre/ipsec headers thus making the outbound queuing policy effective.
February 15, 2011 at 4:21 a.m. UTC
rakem: From this cisco article
"IP RTP Priority does not become active until there is congestion in the interface."
"When the interface is congested, the PQ is serviced until the load reaches the configured Kbps value in the priority statement."
I interpret this as being "no" in answer to your question.
February 15, 2011 at 1:17 p.m. UTC
Mikeh: not sure if qos pre-classify has to be applied under outgoing physical interface ... according to documentation (and QoS books) it has to be applied under tunnel interface, virtual template or crypto-map. See http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfvpn.html
Rakem: Mikeh is right, it will be policed only when in congestion. http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/pqcbwfq.html#wp7085
February 15, 2011 at 8:53 p.m. UTC
You can use the following link from Cisco to calculate the bandwidth needed :
You will need a CCO account.