Quality of Service

As I have mentioned before, packets are transmitted from one end and recompiled at the destination. Not all packets will necessarily take the same path to their destination, which means that they may not all arrive in the same order they were sent in. We can also experience packet loss. In a data network, if a packet is lost or discarded, it is simply re-sent. In a VoIP environment this is not an option. All packets are time-critical and must be received in a timely fashion. We can’t wait for a packet to be re-sent! Quality of Services tries to ensure that time-sensitive packets are given priority over data packets. Other considerations include the amount of packet overhead and the size of the packets. A smaller packet size is more tolerant to packet loss, but every packet has a fixed amount of overhead. For Ethernet, this is 40 bytes. Packet size must be considered when we calculate the bandwidth requirements for our network.

There are several methods that can be used to ensure quality of service in a VoIP network. First I would like to look at Call Admission Control (CAC). CAC can help prevent network congestion by limiting the number of calls that can be active through various nodes in the network. Without CAC, voice quality in the network will decline as the number of calls increases above the recommended utilization. CAC can be defined by a number of rules, including (but not limited to) time of day restrictions, user-level restrictions, VLAN restrictions, IP restrictions, and many more. Policies regarding CAC should be developed at the time of implementation to ensure that problems do not arise down the road. If an organization outgrows it’s CAC policy more bandwidth may be required to grow the voice network.

A firewall may be another factor that affects Quality of Service. Firewalls restrict traffic coming onto and leaving the network based on security rules. An improperly configured firewall may block voice traffic in one direction or another, or both. This can result in one-way speech or no-way speech. It is necessary to open the required ports on the firewall to allow voice traffic to pass through. An even more effective method of managing your firewall would be to have a firewall that specifically recognizes VoIP packets and allows them through.
Network Address Translation (NAT) is another common problem with VoIP implementations. NAT allows multiple devices on a private network to have access to a public network through a single public IP address. VoIP does not work well with NAT, as the originating IP address does not correspond with the external IP address, and the originator is deeply embedded into the packet when it is sent through the NAT server. When the packet is returned to the NAT server, the server is unable to identify where the packet should be sent, resulting in one-way speech. Some new NAT servers are able to understand and process VoIP communications, however.

Packet Delay is also another important consideration with regards to Quality of Service. As delay increases users will start to experience loss, delay, and jitter. With any VoIP implementation there is a fixed delay as the packets cross the network. Fixed delay is also referred to as latency, and is defined as the minimum time it takes from speaking at one end to being heard at the other end. There are many factors that affect packet delay, including the CODEC, network topology, serialization delay, propagation distance, and link delay. As delay increases, the usability of the voice signal decreases. A general rule of thumb with regards to delay is:

Toll Quality < 100 ms < Good Quality < 150 ms < Potentially Useful < 400 ms < Poor Quality

Additionally, Serialization Delay is an issue caused when data is going from a high-speed pipe to a low-speed pipe. The high speed pipe can quickly overwhelm the low speed pipe with information, particularly if QoS policies are not maintained. This can result in jitter and packet loss as the low speed pipe tries to handle all of the data that the high speed pipe is feeding through to it. Serialization delay issues can be solved fairly easily. First you must implement fragmentation. This divides the large frames into smaller frames, which allows for interleaving. Interleaving is the process of allowing smaller frames to be transmitted in between the fragments of the larger frames. If you fragment without interleaving you will actually increase serialization delay, however, as each packet will still have a fixed amount of overhead. Additional overhead will cause more data to be transmitted across the network, resulting in further serialization delay. Nortel recommends only implementing fragmentation on links that require it, primarily links with less than 1Mbps of bandwidth. Fragmentation is set by using the Maximum Transmission Unit (MTU) setting. There are a few formulas for calculating MTU and serialization delay:

Serialization Delay: MTU (B) x 8 / link speed (bps) = Delay (s)
Serialization Delay: MTU (b) / link speed (bps) = Delay (s)
Ideal MTU: link speed (bps) * 0.01s / 8 = Ideal MTU (b)

Packet Loss Concealment is another solution for QoS. Packet Loss Concealment is a method by which the CODEC will guess as to what the missing packet contains. It is not supported by all CODECs, but is an effective way to ignore lost packets without sacrificing much call quality. G.711 does not support PLC, as it transmits PCM data, but G.729 does.

Finally, there is a single solution to a large number of QoS issues: Increase bandwidth. When more bandwidth becomes available, almost all QoS issues disappear.