Stop #BroadbandBlindness: See Last Mile Packet Loss
AHHHHHH!! NOT NOW!! Sound familiar? Perhaps those are the words you silently screamed when your Internet connection either went down or degraded so badly due to packet loss that your web-browsing became erratic or your voice or video call started breaking up. But how do you prevent the next occurrence? How much faith do you have that your ISP will actually do something when you call to complain?
The problem is pervasive – last-mile Internet circuits are getting more overloaded by the day, and network providers frequently don’t keep pace by provisioning more bandwidth. When problems occur, it’s not in their interest to notify their customers that circuits are down or congested, and without hard proof of the network issue, it’s a perpetual finger-pointing exercise as the ISP declares “it’s not us.” It’s therefore no surprise that in a recent Dell sponsored Unified Communications survey “55 percent of respondents spend time troubleshooting quality of experience issues weekly, and 20 percent troubleshoot daily or hourly.”
Companies can no longer afford to be afflicted by #BroadbandBlindness and Firebind can help.
What defines a good broadband connection? Many people first think of ‘bandwidth’ since that is the most common metric by which network circuits are sold, such as a Verizon FiOS 75/75 (75 Mbps up/75 Mbps down) circuit. But bandwidth is only a small part of the equation. Latency is another factor. It’s basically the round-trip-time it takes for a packet of data to go from your machine to the remote destination and back. And jitter is simply the variation in the latency.
But the metric that is the true scourge of the Internet is really packet loss. Packet loss is the villain that causes your VoIP call to break up or your video to ‘pixelate’ or stop working altogether. It can also be the cause of slow web browsing as the TCP transport layer that the HTTP protocol runs over tries to re-transmit dropped packets.
There are 2 big problems when measuring packet loss. First, you want a solution that is always sending test packets because without continuous testing, you can’t see when there is a problem. If there is no train going down the track, you can’t tell the track is safe, not even by looking at it. This is the primary drawback of a passive only monitoring approach because you can’t monitor for something going missing when it was never there to begin with, just like you can’t monitor for dropped packets on a VoIP call at 3am if no one is making calls at 3am.
The second issue is sending the test traffic. Ping can be helpful, but at a rate of 1 per second, it simply doesn’t stress the network like a VoIP type call at 50 packets per second would. And to make matters more challenging, network switches and routers frequently de-prioritize ping. Iperf is another open-source tool and while it can emulate the bit rate and payload size of voice and video calls, it’s highly manual and not designed to run continuously or in a multi-session fashion.
Enter Firebind. Firebind was designed from the ground up to be a rapidly deployable solution that can continuously stress network connections and alert when certain thresholds are either not met or are exceeded. Firebind agents can be installed at a remote site on virtually any device, including PCs, Macs, Linux servers, virtual machines, or even Raspberry Pis, then configured to continuously execute tests to Firebind provided test points in the cloud as well as user-configured destinations.