QoS Solutions for Remote Workers

Protect connectivity with QoS solutions for remote workers

Kevin Tolly
Jul. 27 2020

When it comes to bandwidth, it seems that there are two truths: 1) You can always expect the future to bring higher bandwidth at lower cost, and 2) however much bandwidth you have, your applications will sometimes surge and use all of it- and want more than you have available. In times of high demand from multiple users of multiple applications, only Quality of Service (QoS) functionality will save you. And there is more.

Where legacy MPLS circuits were essentially dedicated to one company and had very predictable performance characteristics, the same can’t be said of internet links. Leveraging the internet saves a lot of money compared to dedicated circuits but leaves you open to situations where the bandwidth and latency available to you can vary due to conditions that you can’t control. Again, QoS can save the day.

QoS solutions for remote workers

Before Covid-19, remote workers were relevant to some companies but not to others. Now, remote workers are relevant to every company. QoS, and especially Infovista Ipanema’s implementation of QoS, is very relevant to remote workers.

With the surge in remote work, it is much more likely that WAN link usage will skyrocket and that congestion situations can occur – situations that require QoS.

Ipanema’s “tele|engine” software-defined site, let's you turn a home office into an SD-WAN “site” without needing any on-premises equipment. This remote site can now benefit from Ipanema’s QoS capabilities. Critical traffic can be given high priority, normal traffic can be handled accordingly and low priority or unnecessary traffic can either be given small amounts of bandwidth or even blocked if desired.

A detailed approach to QoS for the distributed enterprise

Now, let’s take a look at details relevant to all QoS implementations.

Unlike many aspects of networking, QoS is not standardized. While certain header bits in Ethernet frame headers and IP packet headers have been set aside to denote priority, those are only markers nothing more. Thus, it has been incumbent on each vendor in the market to implement QoS as they see fit. Thus, while they all have the same goal, implementations vary significantly.

In simplest terms, a QoS solution will allow you to designate traffic as being of varying priority – high, medium, low and best-effort are commonly found groupings.

QoS implementations will often vary in a few key ways. The first is in number of queues. Generally, there will be three to eight different priorities or queues available (our prior example would map to four).

Hugely important is the methods available to map traffic to priority (QoS) groups. Ideally, you want to be able to specify priority by type of traffic (e.g. VoIP) and let the system figure it out for you. You certainly don’t want to have to code IP address ranges or IP sockets to specify who-gets-what priority.

Within application, also look to see if there is any way to establish sub-groups. For example, does all VoIP have to be put into the same class or can I establish subgroups where, say, VoIP from a certain location or VLAN can be designated as having a higher priority within VoIP traffic. In a word, this is “granularity.” Ask your vendor what kind of granularity you have when assigning QoS priorities.

Once assigned, the QoS solution then processes traffic according to the priority sequence that you set. Much of the time – if your WAN link is not overloaded – you wont’ know (or care) if QoS is operational.

QoS Validation. You do, however, want to be sure that your QoS is going to kick in when you need it. Thus, you want to be sure to validate that your QoS policy (and implementation by your SD-WAN provider) will behave according to plan if and when (really, when not if) a congestion situation occurs. Remember, this can occur either because you have a flood of application use or if the ISP links that you use experience issues that impact the actual bandwidth and latency of your link.

There are several ways of validating QoS. None of which should be done with a production system, by the way.

If you or your SD-WAN vendor has a test lab environment set up, this is the best place to test. You don’t need a carbon copy of your production environment to test QoS. All you need is a WAN link (real or simulated), a high-priority application (such as VoIP) – again real or simulated, and an application (or a traffic generator) that can consume your WAN bandwidth.

Before and after is the best way to test QoS. Run your high-priority application alone and “benchmark” its performance. This benchmark could be as simple as you conversing with someone via VoIP over your test SD-WAN.

Then, WITHOUT turning on QoS, start your traffic generator app. This, again, could be as simple as a file transfer. By default, a file transfer will use large packet sizes and grab whatever bandwidth it can. As soon as your VoIP packets have to start waiting for file transfer packets to finish going across the WAN link, your voice quality will suffer.

Pro Tip: What you want is to create WAN congestion. Sometimes, it can be hard to fill up a WAN link with just a singe file transfer. So, where possible, reduce the WAN link speed to a lower rate so that you can be sure to congest it.

When the VoIP conversation quality degrades, you know that you have created a congestion situation – and that you need QoS to fix your user experience.

The “After” part is key, as this is where you turn on the QoS. With QoS enabled, re-establish your VoIP connection. With your conversation in progress, start your file transfer again. If QoS is doing its job, the call quality will remain good. The file transfer will be slowed down somewhat, as it should be, since your VoIP call is the priority application.

QoS is all about making “after” better than “before.”

Fortunately, your SD-WAN system will likely provide “before” and “after” analytics as well. Thus, you can typically look at your management screen and see how bandwidth is being allocated. This way you can visualize how QoS is divvying up bandwidth across your applications.

In closing, remember that QoS isn’t just about bandwidth. High-priority applications will also have reduced latency. This is essential for interactive applications such as VoIP.

Beyond QoS solutions

If you find that your QoS is being triggered constantly, it is probably time to look at increasing bandwidth on your links. QoS is a big help but it can’t create new bandwidth for you.


Learn how you can build a smarter WAN edge without re-engineering the network and see measurable ROI in as little as 2 months. The key is a transparent, hands-free migration.

Written By