The same problems happen on networks where it may sometimes be slow, and other times packets end up never reaching their destination due to a network impairment.
For data packets, it’s easy to re-transmit the data if it was lost along the way, as TCP/IP is designed specifically to accomplish the goal of retransmitting lost data in an efficient manner. As a result, if a file transfer normally takes 10 seconds, but there is 10% loss, it will now take 11 seconds. In this case, nobody cares or even notices the problem.
With real-time protocols like VoIP, UC, and video, 10% loss would equate to a poor experience. Imagine missing one out of every ten words from a conversation. So much understanding would get lost that most people would give up on the conversation and hang up the call.
When considering latency, jitter, and loss metrics required for real-time protocols, loss is the number one problem that affects VoIP/UC quality, as it affects quality the most dramatically.
Packet loss is when a transmitted packet does not make it successfully to the destination.
Note: | For real-time protocols like VoIP, UC, and Video, if packets arrive at their destination out-of-order, the codec must discard the packet because it is out of time sequence and cannot be spliced back together. Many monitoring and troubleshooting solutions may not view this as a dropped packet, but the codec will consider this a lost packet regardless, as it did not get received successfully in proper order. For more information about this problem, read Do Out-of-Order Packets Affect VoIP. . |
Packet loss can happen virtually anywhere in the network: any interface, any device. This is the part that makes it hard to troubleshoot the root-cause source of the problem, as even small networks can still be quite complex with many different interfaces, switches, and routers that are traversed to reach the destination.
Note: | Packet loss can even occur inside the destination device. If a PC runs out of receive buffers, it may drop the packet before it is able to send the packet to the softphone.
Additionally, if a PC is running VPN software and has a slower CPU and is running a complex high-security VPN encryption, it may drop packets as it is unable to keep up with the encryption/decryption. |
Something that should not be overlooked is if the problem happened outside of your domain. For example: If a user complains about a call quality problem, it may be that the other user was on a cell phone, or the problem occurred on the other company’s VoIP/UC phone system.
Loss can also occur between a phone or softphone and a wireless Bluetooth headset. This is not part of the IP network, but is a network regardless and can have packet loss problems. These problems usually relate to one of the following issues:
Packet loss affects real-time protocols like VoIP and video by creating drop-outs, clipped words, and video artifacts. Entire phrases might also be missing from the conversation.
If the packet loss gets really bad, one side of the audio stream can completely disconnect causing one-way audio, or if packet loss is bi-directional, the entire call can drop.
When a user complains about VoIP/UC or video problems, you want to determine who heard the problem. If the reporting user heard the drop-outs, that means they had problems receiving the audio information from the sender. If the reporting user said the other person could not hear them, then it is a problem where their transmission did not make it to the receiver.
In some cases, both parties may have problems, but only one person heard or complained about the problem.
Something else to consider is when you dial into a meeting but say nothing the entire meeting, you might have call quality problems where nobody could hear you speaking if you did say something, but since you didn’t say anything, nobody detected the problem.
Most video and audio codecs can deal with a certain amount of loss, and some are better at handling loss than others.
In general, packet loss should be below 1% when received by the endpoint.
Certain codecs can work better on lossy connections, as they will work to duplicate audio information in successive packets. This means that you may be able to have more than 1% loss and still have acceptable call quality, but only if the lost packets are not sequential.
The problem is that most packet tends to be sequential:
Communications might be perfect for 10 minutes with no loss, but then 10 packets in a row get dropped because of congestion on a link for a few seconds during a large file transfer. No codec can repair this problem because too much information was lost.
The above example also shows that packet loss tends to be sporadic.
Packet loss can happen for several different reasons:
Many additional reasons are possible depending on your network’s configuration and capabilities.
Loss can be detected in a variety of methods:
Proprietary mechanisms like Cisco’s IPSLA may also be employed to detect packet loss across specifically defined segments.
Finding the specific location where packets are getting lost and fixing the problem can be hard due to the number of interfaces and devices that exist between a pair of IP phones.
Documentation may not be helpful here if STP (Spanning Tree Protocol) is enabled and there are different possible layer-2 paths that may be crossed as well as different routing paths for layer 3.
Once all of the interfaces and devices are mapped out, each of these elements need to be interrogated for errors to see if they dropped or buffered any packets for any reasons. Most switches and routers have a large number of error counters that are tracked, so each one should be evaluated to make sure that they are not incrementing.
In addition, if any of these interfaces are configured for QoS, the queueing should be evaluated to see if it is configured properly and the queues are showing proper utilization.
This process may take hours to accomplish on even the smallest networks due to the number of interfaces, devices, error counters, and QoS configurations that need to be evaluated TotalView's path mapper will identify every link, switch, and router used to connect two IP endpoints and present the historic health, performance, and QoS configuration of every element along that path.
Troubleshooting where loss is coming from can be challenging due to the number of network interfaces and devices that need to be checked.
Troubleshooting loss can be a two-step process:
Note: | If packet loss is 100% and a firewall is involved, it should be suspected as a firewall rule misconfiguration. |
Since loss is a transient problem that may occur sometimes and not other times, you may not be able to find the source of the problem if you don’t have a historical perspective of the above information. See also
See also this related blog: Diagnosing and Fixing Packet Loss in Your Network
A little bit of loss detected on a single router or switch may not be of much concern, but consider its affect throughout the entire network. If a little bit of loss happens at each step across the network, you may end up with some very large packet loss totals at the remote end of the network.
Additionally, if you reduce loss in the parts of the network that you control, it will help reduce the effect of loss added in parts of the network that you do not control: SIP Trunks, and VPN tunnels.
Overall, loss can be prevented if the right information is brought to bear about your network’s performance.
Preventative steps can be taken to avoid creating packet loss in networks:
Review our VoIP Troubleshooting white paper, watch our Webinar on Packet Loss, or contact us with questions about how PathSolutions can solve call quality and many other VoIP issues.