Networking 101: Quality of Service (QoS)


Reprint from DSL reports dot com
Networking 101: Quality of Service (QoS)
by digitaldoc77
Monday Nov 28 2016 08:30 EST

Quality of Service (QoS) is a way of shaping the data traffic on a network so that the finite amount of bandwidth can be utilized most effectively. The idea is to prioritize certain packets of data that are more important, over the less critical data. What is more important is up to the individual user of course, but the typical use case scenarios are to reduce latency in gaming, or to keep HD video playing smoothly. What both of these usage scenarios have in common is that the data for the game or video needs to arrive in a certain order for an ideal experience.

Users often focus on the download and upload speeds of their connections, known as the bandwidth. While this is important, there is also the issue of latency, often synonymous with ping, a measure of how fast your computer through the network can communicate with a website.

For the home user, QoS is generally done at the level of the router. It requires a higher end router, but unfortunately most routers ship with it disabled by default. With QoS properly configured, it can make a significant difference. For example, this will allow stutter free playback of Netflix, while downloading a large Windows update file.

It is also useful for VoIP, which while low bandwidth, is important to prioritize the voice communication for a stable connection without artifacts. While QoS was once a luxury for a network, it has evolved to become a necessity with multiple users, and multiple devices connected to the router, all competing for internet bandwidth, and all desiring a seamless experience.

Without QoS, all the users and their devices get the same level of priority. Therefore the downloads that can wait get the same priority of those that can wait. Routers can implement QoS via two methods. The first method is to have QoS implemented via the device. The router will present a list of connected devices, which can then be prioritized. While this does provide some certain traffic shaping, it is less than ideal as gaming may not always happen on the same device, or the video viewing may shift from a higher priority notebook to a lower priority tablet, which then would force the user to have to redo their QoS settings on a frequent basis with each session to maintain the data priority.

The second method is to have QoS determined by the application. In this plan, the router prioritizes the traffic by the website. This is useful so that VoIP, video and gaming can all be given priority over general web traffic and downloads. The downside of this method is that the websites are preloaded, and while Netflix and Steam are choices, lesser known sites may not be there to be designated to an appropriate level of priority.

In some cases, a router may be able to prioritize the traffic by both the device and the application.  On the one hand, it is particularly robust as QoS can be controlled by both device and the application, with a specific subcategory for games.

However, it is still limited as the list is limited to a handful of applications and games, and if your app is not listed, it cannot be prioritized other than by the client, which may not need the consistent priority depending on the users on the network, and their devices use of these apps. (As an aside, this Linksys router is really sold for open firmware DD-WRT use, so many users will not use the Linksys factory firmware anyway).

Unfortunately, in the three examples above, it should be clear that QoS has not finished its evolution. Any list provided in the firmware of apps that can receive potential priority will be limited as there are literally millions of potential apps and games that users may wish to prioritize. No list included in the router, no matter how complete at the time the router ships, will ever be complete over the changing landscape of the internet. What would really be ideal would be to prioritize by both device and application, but that the applications could be added by the user. Perhaps a browser plugin, that could be turned on to give that site priority, and a more dynamic list with a hierarchy or more than just priority or no priority.

Router manufacturers, are you listening?

Buffer bloat testing your ISP connection ==> DSL Reports Speed testing
QoS on routers is a crock. Not implemented as the concept designed it.

On three different routers, I have had, QoS is a piece of bandwidth reserved for only that application, or protocol style.

This can be shown by doing a bandwodth test on some website providing that test service.

Now turn on QoS, say for your VOIP and reserve 0.5 Mbit.

Now perform your bandwidth test again and you will find your bandwidth has dropped 0.5 Mbit, exacty the amount you reserved in the QoS settings.

Turn QoS off again and retest.

All the QoS settings do is restrict the bandwidth from full usage so that when the preferred app needs it, it is always available.

This is all analogous to the extra bedrooms your wife keeps for your family guests, should they make the extremely long trip, that is so much longer, going your way, than the other direction. You can't use them for anything else and should they visit, once or twices per year, they have exclusive rights to those rooms, and you are not allowed in. :)

The preferencial treatment of QoS packets is a crock. They aren't givem preferential treatment over other packets, they are issued a virtual router channel, at the cost of your bandwidth for other tasks, whether you are using the QoS device/bandwidth or not.

Routers tested
QoS is pretty much a waste for the consumer, even at the enterprise level it is rarely useful.   First of all QoS will not be honored on the internet by your ISP.   So all it is good for is prioritizing outbound traffic through your router.  Second, QoS only has any effect if you are dealing with a bottleneck, if you are not saturating your circuit it will do nothing.    
It is all about how you prioritize packets in the queues/buffers on the switch/router and which you will drop first if they fill up.   So that means you are already in a situation where you are going to drop something you are just saying I would rather drop more of my XBOX traffic than my TV traffic, but you will still drop some of both, just more of one than the other.   It is a band-aid, if it is kicking in often you need to revisit things, like how much bandwidth you have or the traffic you are sending.   The only useful case is for real-time traffic like VOIP where it is required to reduce latency due to queuing and where both sides are controlled/trusted.  But again, that is not going to help you on a consumer based router because you won't have starvation based queuing technologies like LLQ available and the ISP isn't going to honor it anyway.
Beyond it's uses for real-time traffic in enterprises, QoS is mostly being replaced by more intelligent layer 7 based application aware technologies like rate/traffic shaping on proxies.
We are at the mercy of ISPs today.  
I have used it on a global commercial private network.
I have no issues here streaming (no jitters) movies.
Wondering if anyone tried the buffer bloat test and want your connection was graded at?
I've worked with Cisco equipment and on private networks, we always make use of QoS/CoS and Q manipulation (dropping packets, ex WFQ). While I mostly agree with "QoS is pretty much a waste for the consumer" (it's way too complicated) and that we are at the mercy of ISPs. Add buffer bloat and the network is excessively complex beyond belief.  It's been about 7 years since I did the work but we had lots of fun excel spreadsheets to figure this stuff out.
And when you reserve bandwidth, if you do it correctly, you only reserve the bandwidth when you are using it otherwise other traffic can make use of the bandwidth. I haven't played with that on Linux for a long time as get crazy and I haven't really needed it.
Yes today here two VOIP lines sound worse than my cellular connections.  First time I have seen this.
Commercially got involved here in the late 1990's moving from point to point circuits, then frame relay and finally MPLS.
Data was just that and not much else at the time so QOS was easy peasy. 
The transition stuff also involved using custom MATIP Cisco OS so we could keep the old and use the new stuff. 
Wrote a little instruction manual on configuring the MATIP (Mapping of Airline Traffic over Internet Protocol) ALC (airline line control) stuff on a Cisco router.
It was a learning process for our Cisco folks.
Tested some VPN / ISP connectivity relating to some call centers (IE: Tijuana, Alaska, et al).  It worked fine at the time.  Very simple data; lots of little bytes (same with air to ground data (ACARS)).  Bucket charges and expensive at the time.  Testing one day with one vendor; left the spigot on to test....vendor tried to bill me some 25k or more for testing...weeks worth of data.
pete_c said:
Wondering if anyone tried the buffer bloat test and want your connection was graded at?
I have to admit this is the first time I've heard of bufferbloat so I've just spent around 30 mins doing some research and tests of my own.
Now... as I've just said - I'm not experienced in this, but I'm thinking that test is more BS than what is really going on.
Whenever I ran a standard test, my download bufferbloat would hit 2000ms constantly! Now... if I maxed out the streams to 32, but reduced my download speed from 120 to 100mb/s, my bufferbloat would average around 25ms! I also ran a ping test while doing a speed test and the highest I'd hit while maxing my download of 120mb/s is 260ms. So... my 20 minute take is that as long as I'm not saturating my link I'm fine. Some quick searches on that lead me to posts of people using traffic shaping to "limit" their bandwidth which would reaffirm my initial findings.
What are your thoughts, guys?
Curious what grade was presented with your testing?
The ISP modem (router) of yesterday had it's own configuration from the ISP relating to anything.  You could only make changes to the modem rooting it  / JTagging it.  It was a big business (illicit as it was anyways).  The connection is already massaged before it gets to the modem, then massaged again at the modem (stuff you do not see). 
Today many folks are renting their combo modem, router AP from their ISP provider.  IE: Comcast / Xinfitiy just turns on guest AP access for whomever and uses your transport (that you pay for).
Back to Bufferbloat...
Bufferbloat is the undesirable latency that comes from a router or other network equipment buffering too much data. It is a huge drag on Internet performance created, ironically, by previous attempts to make it work better. The one-sentence summary is “Bloated buffers lead to network-crippling latency spikes.”
The bad news is that bufferbloat is everywhere, in more devices and programs than you can shake a stick at. The good news is, bufferbloat is now, after 4 years of research, development and deployment, relatively easy to fix. See: fq_codel: wiki. The even better news is that fixing it may solve a lot of the service problems now addressed by bandwidth caps and metering, making the Internet faster and less expensive for both users and providers.
The introduction below to the problem is extremely old, and we recommend learning about bufferbloat via van jacobson’s fountain model instead. Although the traffic analogy is close to what actually happens… in the real world, you can’t evaporate the excessive cars on the road, which is what we actually do with systems like fq_codel wiki.
Still, onward to the blow.
pete_c said:
Curious what grade was presented with your testing?
A big F
I just ran another set of tests now from work (a heavily utilized network) to home connected via OpenVPN and while maxing my upload bandwidth of 5 mb/s I averaged low 40's ms (up & down) while my idle was already at high 20's ms. And I was streaming music via youtube during the test.
so.... I do see where bufferbloat is real and an issue if you max your links.
I'm going to run another set of tests when I go home for lunch and see what the lines look like at that time of day.
I currently utilize PFSense here and just read that using the traffic shaping wizard can alleviate my bufferbloat.  I am not doing anything right now and did get an F here testing my Comcast ISP connection.
More on bufferbloat....
Packets on the Highway
To fix bufferbloat, you first have to understand it. Start by imagining vehicles traveling down an imaginary road. They’re trying to get from one end to the other as fast as possible, so they travel nearly bumper to bumper at the road’s highest safe speed.
Our “vehicles” are standing in for Internet packets, of course, and our road is a network link. The ‘bandwidth’ of the link is like the total mount of stuff the cars can carry from one end to the other per second; the ‘latency’ is like the amount of time it takes any given ar to get from one end to the other.
One of the problems road networks have to cope with is traffic congestion. If too many cars try to use the road at once, bad things happen. One of those bad things is cars running off the road and crashing. The Internet analog of this is called ‘packet loss’. We want to hold it to a minimum - however we do not want to eliminate it it entirely.
There’s an easy way to attack a road congestion problem that’s not actually used much because human drivers hate it. That’s to interrupt the road with a parking lot.
You drive in, a traffic cop at the exit tells you when you can leave, and then you drive out. If there’s nobody using the parking lot, you can just zip right through.
But, as the parking lot fills the cop at the exit becomes ever more necessary.
He has to control the timing and rate by which vehicles exit the parking lot, so he can hold the number of vehicles in the road downstream of the lot at sane levels. He looks at the upstream road he’s protecting occasionally, to make sure he’s not causing problems here.
We only have one cop managing the lot in this case, so the other thing that has to be true is that the lot doesn’t exceed its maximum capacity. That is, cars leave often enough relative to the speed at which they come in that there’s always space in the lot for incoming cars.
The Internet analog of our parking lot is a packet buffer. People who build network hardware and software have been raised up to hate losing packets the same way highway engineers hate auto crashes. So they put lots of huge buffers everywhere on the network.
In network jargon, this optimizes for bandwidth. That is, it maximizes the amount of stuff you can bulk-ship through the network in constant time. The problem is that it does horrible things to latency.
To see why, let’s go back to our cars in the parking lot.
It’s rush hour now, and vehicles of all types enter the parking lot, faster than they can exit. Emergency vehicles, cars, vans, food trucks, all pile up in the order they arrived. (This is called FIFO - first IN, First Out order).
Our bufferbloated parking lot is so big that our cop can’t see from one end to the other. He can’t see what vehicles are important, and which ones are not.
Our poor traffic cop overloads - he’s so busy sorting out the traffic jam in front of him, he can’t look upstream anymore, either. He gets distracted by the mess in front of him; people start driving over the berm, smooth traffic flows become clumpy, and the highway he’s trying to manage gets overloaded.
When this happens to the Internet, the parking lot - the buffer - adds latency to the connection. Packets get large time delays, just like you would when stuck in a real-world traffic jam. Smooth network traffic turns into a herky-jerky stuttering thing; cars try to find alternate routes, and often fail.
A constantly spaced string of vehicles coming in tends to turn into a series of clumps coming out, with size of each clump controlled by the width of the exit from the parking lot. This is a problem, because car clumps tend to cause car crashes.
Performance becomes worse than if the buffer weren’t there at all. And - this is an important point - the larger (more bloated) the buffer is, the worse the problems are.
The Bufferbloat Project has found some really, really, really oversized parking lots on the Internet. May Internet connections have buffers that, if the connections were highways, would be the proportional size of the state of Texas.
Today utilize whatever free tools are on the internet.  I have been a member of DSL reports dot com since the DSL days in the 1990's so utilize their on line tools.
Years ago though in the beginning of implementation of broadband; most if not all ISP providers left their back end routers at default login / passwords such that it was easy to look at the configurations.  A router is a router is a router.  That and you can sniff the internet and watch the at home modems do TFTP downloads with modem configurations.  I still think that this configurations are not encrypted.  That said you cannot change them on your ISP modem but you can change how and what presents itself to your internal network.

Like in medicine today you can seed your lymphatics / blood with radioactive tagging markings and watch. 
You can do that too today with internet packets and just watch what happens to it on the internet.
I switched over to using PFSense a few years ago; then updated my hardware to include now some 8 network interfaces.

There are many widgets / tools now for PFSense. Last one I installed here was Geo called pFBlockerNG. (with snort and squid still running). This software is very active blocking much from the pacific rim and the eastern parts of the EU. It's making the firewall do all sorts of work.

I went to googling PFSense / Bufferbloat and found a drop down widget in PFSense labeled traffic shaping.  It was suggested on the PFSense support forum to utilize the traffic shaping wizard.
Thanks Pete, I have enough information to poke around and see if I can work the Ubiquit EL router or should just jump to PFSense. I know you've posted about your setup in other messages so I may need to do a search (now on my todo list, dang that thing is long).
Always tinkered with firewalls at home here.  DDWRT'd / OpenWRT'd all sorts of AP's except for the Ubiquiti; which never needed tweaking.
Very first software firewall was in the days of Windows 95 and DSL while concurrently utilized firmware firewalls.  Have a little stack of old Sonic firewalls, Cisco (well only used Cisco for the airlines; never anything else).
Then in the 2000's went to Smoothwall then later to PFSense.  The base motherboard came with two Intel Gb NICs then added two server style 2-4 port Intel Gb NIC cards.  Outside two NICs are used for load balancing and failover; while inside NICs used for single automation hubs and their own networks. 
Went on here about work stuff which was totally different than the home stuff.....and deleted it....