The Case for NOT Deploying End-to-End QoS
LiveNX started as an IP Quality of Service (QoS) Management and Monitoring tool for the U.S. Military. Originally, the product served as a tool that could provide QoS Monitoring, like a video game. This was the root creation purpose of LiveNX and over the years it has evolved into an enterprise-class NPM solution. I can say from first-hand experience that it does these tasks very well.
My primary responsibility at LiveAction is that of a SE, but I also provide consulting services focused on QoS policy architecture. I actually use LiveNX to help solve our customer’s needs. My background is that of a consultant, designing and building networks for multiple customers with a focus on VoIP solutions, and a specialization in QoS. So at LiveAction, I talk QoS almost every day to our customers. I am fortunate enough to see multiple networks, with every type of QoS requirement imaginable. I also have the pleasure to interact with many truly brilliant engineers that have built some amazing networks. With this unique view into all types of diverse environments, I see customers who I believe, do QoS the easy way and others who really make it hard on themselves.
To me, QoS is an art form, that’s what I enjoy about this topic. There is no one-size fits all solution for any network. It is a group of technologies that must be thoroughly understood and applied uniquely and appropriately in each network environment. But, I do believe I have witnessed a few principles that seem to work repeatedly for most circumstances. Of course there are no absolutes, there will always be an exception, but the number one rule to abide by that I have seen work repeatedly is: Implement QoS at the WAN edge first.
Implement QoS at the WAN Edge First
QoS is hard. There are a lot of variables that need to be understood in order to have traffic behave the way a business needs. Not only does one need to understand the tools in the QoS tool belt, but they also need to understand the differences, complexities and caveats of deploying QoS on the specific models of equipment in their network. One also needs to understand which applications require protection, how they behave and where they exist on the network. Finally, one needs to navigate the sometimes political waters and categorize which traffic types matter the most, and which traffic types are truly business critical. Is the CEO’s TV stream equivalent to the importance of an ERP solution or VoIP?
To make things harder, books have been written to encourage folks to deploy end-to-end QoS. What does this mean? One should enable every device in the network (LAN and WAN) with a QoS policy to adequately protect business-critical traffic. This could be for hundreds of thousands of ports in many environments. Each port would need an appropriate policy in order to function in the network. Successfully deploying such an initiative would be very costly and error-prone without the proper tools, and in many organizations it is infeasible with the manpower available. On-going management can also be difficult without the proper tools. If anyone changes anything about the network, and does not consider the QoS policy, then the QoS could easily be broken for huge portions of the network.
What I have seen work repeatedly is this concept: One must only focus QoS on the WAN edge. Why? This is where QoS matters the most in 95%+ of all networks. It is usually a very manageable group of devices that typically has a complete and consistent QoS tool belt at their disposal. By doing all QoS here, the chances of complete success are very high. If true end-to-end QoS is a requirement, I would recommend focusing all QoS at the WAN edge as your Phase One. Once WAN QoS is successfully validated, then turn the attention to the LAN as Phase Two. Although, as I have witnessed over and over again, folks seem to never get to Phase Two. They find out that it isn’t worth the effort and only the WAN policies are required for their business.
Make no mistake, end-to-end QoS is a great technical goal, but from my experience it is rarely, if ever, practically feasible to implement—nor is it a true requirement for any of the businesses I have served.
May 9, 2016
Author: Clark Zoeller