Save Time for Yourself and Your Subscribers
“Lost time is never found again,” wrote Benjamin Franklin, a proverb that grows truer the older we get.
Time is at the center of most things, and operating and maintaining a network is no different. Network engineers fret about Round Trip Time (RTT) and latency, while subscribers complain when they experience slow Internet speeds or long delays during gaming or updates.
Quite simply, time is our greatest resource, and the greatest gift you can give to yourself and your customers is to find more of it by removing as many time-consuming obstacles as you can.
Waxing philosophical about time is all well and good, but as you know, “time is money” (Ben Franklin again!), so we’ll get straight to the point. Active Queue Management (AQM) can provide you and your customers with the time savings you crave while eliminating the need for outdated traffic management techniques like TCP proxies (‘acceleration’) or time-consuming methods like Deep Packet Inspection.
Here’s why we think know so.
The Internet is Changing QUICkly
Before we get into the pros and cons of various traffic management options, it’s important to note that the way traffic moves on the Internet is changing.
Since the beginning of (Internet) time, the Transmission Control Protocol (TCP) has been the dominant transport layer protocol for moving data reliably between two devices.
It’s been used for most applications on the Internet, everything from streaming video to simple web browsing. If you’re of a certain age, you’ll remember back in the ‘90s when the then-new Internet was referred to as the “information superhighway.” Using that retro metaphor, TCP was every car, truck, and bus on the road, safely delivering its passengers to their destination.
What do you think, ‘90s kid? Is that a good way to describe it?
Thanks, buddy. There’s a new and improved vehicle on the superhighway these days, however. Designed by Google, QUIC (Quick UDP Internet Connections) is a low-latency UDP-based transport protocol developed in 2012 and standardized by the IETF (Internet Engineering Task Force) in 2021.
Much of Google’s current traffic, including YouTube, is already using QUIC and usage will only continue to grow with the introduction of HTTP3, which is also QUIC-based. As well, more than 75% of Meta (Facebook) traffic already uses QUIC. Meta engineers say it has driven improvements in areas like “request errors, tail latency, response header size, and numerous others that meaningfully affect the experience of people using our apps.”
In other words, it improves the subscriber experience—good news for users and ISPs alike. Consider it the information superhighway’s flying car 🙂
If you’d like to know more on this subject, check out this 10-minute history of transport layer protocols and the emergence of QUIC from one of our recent webinars, starting around the 19:45 mark.
TCP Proxies (Acceleration) are Nearing the End of the Line
As another famous saying goes, “Father Time is undefeated.” This one is not attributed to Benjamin Franklin but to another noted renaissance man—*checks notes*—former Dallas Cowboys wide receiver Michael Irvin.
We mention this because, with the rise of QUIC and the subsequent decline of TCP, the need for TCP proxies (‘acceleration’) is … quickly 😎 … becoming obsolete, especially for fixed wireless networks.
TCP proxies have historically attempted to improve some aspects of network performance, like throughput, by modifying TCP congestion control and retransmission behaviors.
This is done by actively interacting with the TCP flow between two endpoints, creating two TCP connections—one between the server and the TCP accelerator, and another between the accelerator and the user device. This allows the accelerator to implement different congestion control and retransmission policies on each of the connections.
Here’s the issue.
All types of traffic, TCP and UDP, need to co-exist on the same link. By ‘optimizing’ TCP, the accelerators make TCP more aggressive. This necessarily has to come at the cost of other traffic. That means if you’re relying on TCP proxies for a good experience, UDP traffic will suffer.
As noted earlier, with more high-value traffic already using QUIC, this will inevitably lead to complaints from customers having a poor experience. As well, if someone wants to use TCP proxies because there are problems with the last mile, they might make the test look good but will actively harm total system efficiency.
Deep Packet Inspection: Complex and Unnecessary
Another traffic management method rapidly approaching its best-before date is deep packet inspection (DPI). This technique uses complex rules and traffic identification methods to attempt to classify packets by application. Traffic from high-use applications can then theoretically be prioritized so that subscribers don’t get a poor experience when using them.
One of the many challenges with this is that applications are constantly changing. Keeping up to date is a constant game of cat and mouse. This is becoming more challenging over time as applications add encryption and move to common infrastructure at a small number of cloud providers. It also puts a ton of labor-intensive, time-consuming work in the hands of ISPs who have to continuously apply updates and keep up to date with application changes.
Prioritizing specific applications (like Netflix, to use a common example) has numerous drawbacks. Here are a few that we’ve noticed:
- ISPs can’t really be expected to decide which applications or activities are high or low priority. Gaming updates, for example, might be seen as a low priority activity to some, but not to the ever-growing number of gamers! Why alienate a section of your subscribers based on faulty assumptions?
- Subscriber behavior and traffic patterns change all the time. Why put yourself in the complicated position of having to anticipate user changes or update traffic identification rules? Wouldn’t you rather have a network that provides a good experience automatically for all applications and protocols?
- When it comes to slow-Internet complaints, DPI can help identify which applications may have been causing the problem, but wouldn’t it be better just to solve the problem before the customer complains?
To be fair, DPI was necessary back in the early part of this century prior to the arrival of AQM. Thanks to the development of AQM, however, network operators no longer have to spend their time trying to master geek knobs and complex rules while battling latency issues. It’s also worth noting that using DPI to prioritize certain types of traffic is actually illegal in some jurisdictions, and strongly discouraged in others.
AQM is Queue Management That “Just Works”
FQ-CoDel (Fair/Flow Queuing Controlled Delay) is an AQM technique used to dynamically size queues and optimize for superior latency and throughput, even under heavy usage.
Unlike DPI, FQ-CoDel’s traffic classification is based on the behavior of each individual network flow. So, for example, if a flow has lots of packets in a short interval, it’s automatically treated as bulk (e.g. a system update). If a flow has a few packets in a short interval, it’s treated as interactive (e.g. Zoom calls and games).
Separating traffic into bulk and interactive flows automatically allows those supposedly low-priority gaming updates to happen smoothly, even when someone else in the home is on an important Zoom call or binging their favorite Netflix show. Just as importantly, this means fewer support calls, freeing up valuable time for you and your staff.
AQM can help you move to proactive management of your network, in this case by removing the cause of the most common subscriber complaint: slow Internet. That’s because AQM helps the Internet ‘feel fast’ for your customers, even at peak times.
Think of the time you’ll save for your support team and network engineers when they’re no longer bogged down by tickets and calls about sluggish Internet, some of which might require costly truck rolls.
Using AQM is really a no-brainer—just set it and forget it, give your subscribers the great experience they deserve, and enjoy all that time you just put back in your day! Benjamin Franklin would be proud 🙂
