Why is my end user seeing packet loss?

mindchatter Member
edited August 2022 in Q&A 🤔

I have an end user that left the following feedback on my platform:

“I did an internet speed test - my internet is great, so why am I still seeing packet loss?”

I’m still learning webrtc so I'm not sure how to answer this, can someone give me any advice?


Best Answers

  • Jen3
    Answer ✓

    Tell them that packet loss is different from your speed test or download speed.

    Packet loss reflects UDP data, which is the data transmitted when you stream live media. But like when you are watching hulu you are not streaming media yourself only receiving. Best course if to tell them to reboot/refresh/restart all the usual things.

  • RaviAtDaily
    RaviAtDaily Dailynista
    edited July 2022 Answer ✓

    Great question! Completely understand the frustration here. Your expectation is fair, and in most cases does hold true. Some things to note here:

    Most internet speed tests measure data transmission rates on the TCP layer. This is because most of the traffic on the internet is on TCP. However, WebRTC transmits media bytes on the UDP layer instead of the TCP. It is possible that the poor network condition being experienced might be specific to the UDP traffic. In other words, only the UDP packets are being dropped while the TCP traffic is flowing without issues. Sometimes, VPNs or other network configuration might selectively block UDP traffic.

    Another point to note here is that - most internet speed tests will report back a bandwidth throughput estimate, i.e how many Mbps Up and how many Mbps down a network can support. Which is great to know! Packet loss can be caused by a variety of factors. Bandwidth limitations can definitely cause packet loss, but there are many other potential ways of encountering packet loss. For instance, high network jitter or latency could also lead to packet loss. For real-time media, like in WebRTC, the media bytes need to be received within a short window of time for them to be playable. If some of the bytes arrive too late, it can count towards the packet loss value measured on the media track.. because they were not received in time.


  • chad
    chad Dailynista

    Like Jen3 mentioned, WebRTC uses a different mechanism for sending information than most of your other internet connections. (Google: "transport layer.") Typical HTTP requests use TCP as the transport layer. WebRTC uses UDP for sending media. TCP is "guaranteed delivery", but UDP isn't. Here's the difference:

    TCP: I pick up the phone and dial your number. You answer the phone. I say "Hi, is this mindchatter?" You say, "Yes, it is, what can I help you with?" I say, "0xAB134FDC." You say, "Got it, 0xAB134FDC!" and we both hang up the phone.

    UDP: I drive by your house, standing up in the back of a pickup truck. I grab a bullhorn and say "0xAB134FDC!" really loudly as I go past.

    TCP's good for most things, because I can be certain you heard what I said. But each time I want to send you a new packet, there's that overhead of dialing the phone, waiting for you to answer, dealing with pleasantries, etc. That creates latency, which makes an interaction feel less "real-time"—especially if the phone call drops out in the middle of one of the packets, and I have to redial, and tell you everything all over again.

    The nice thing about the bullhorn approach (UDP) is I can drive by, yell a whole lot of packets at once, and presume you heard enough of them to make sense of what I said. In fact, it often still ends up being faster for me to just yell every packet twice as I drive by, and hope you heard one of them, than deal with calling you directly! (That's not _exactly how WebRTC tries to handle loss; rather, the audio and video codecs have some built-in redundancy and error correction to handle some packet loss. But that's less fun from the back of a pickup truck.)

    Back to your original question. If you're on a fast internet connection but a terrible wifi router, for example, you can often still get a good speed test. If your router is dropping TCP packets that the speed test server is trying to send you, the server can just retransmit them; it'll drop your overall speed result a bit, but you may still see a good number. But if your router is dropping 20% of the UDP packets it's supposed to send you, there's no way for the sender to know that. It won't try to retransmit the packets that got dropped, and you'll end up with dropouts in your audio or video.

    Unfortunately, the way you fix it is "standard network troubleshooting"; things like rebooting your router, trying a different wifi router if you can, and so on. Because of the nature of UDP, it can be fiendishly difficult to track down what's dropping packets.

  • vr000m
    vr000m Dailynista

    Bandwidth is a shared resource, when there is contention for that bandwidth, it results in packets getting lost or in packet jitter. Packet loss means that packet was not delivered, while jitter means that the packets were arriving out of order or are delayed.

    Your experience depends a lot on what was happening in your local network at that moment in time when you were having a bad experience. If there are other people or devices streaming content at the same moment as you are on a call, this can result in a bad experience, as those devices maybe taking more share of the bandwidth and less is available for your session. Another likely issue can be the wireless connection, you may be either too far away from the wireless access point or not have direct line of sight to the wireless access point (for example, walls can reduce the bandwidth capacity).

    If you are using a VPN, it is also possible that the VPN servers are loaded and again there is insufficient bandwidth for your call. Lastly, it could be your CPU or battery, i.e., if you are running low on battery, the operating system will start to going to power conservation mode and your call may under perform as a consequence. Or if you are editing pictures or playing video games on your device, those other applications can be taking a larger share of your device's CPU that may also result in degraded performance.

    Here a rudimentary checklist to diagnose when you are experiencing a poor call quality and you think it is due to packet loss, jitter, or CPU.

    • Check if you've any bandwidth or CPU intensive apps like streaming apps, games, or similar running in the background. Consider closing them and connecting to direct power instead of using battery.
    • Check if you are sitting close to your wireless router, at least are in the same room. Consider connecting directly over ethernet or wire, so that you can disregard wireless issues.
    • Check if someone else is streaming or online gaming which may be impacting the performance of your call.
    • Check if you are on a VPN and consider turning it off and using the internet directly, if turning of your VPN is not possible, talk to your VPN provider
    • Avoid using Mobile hotspot (3G/4G) by tethering via wireless (bluetooth or wifi), there are two wireless components, which can cause issues. If it is unavoidable, make sure you are close to windows or exterior walls. Further inside the building the mobile signal can attenuate and degrade the network.