QoS stands for Quality of Service and in a computer networks means a set of technologies to improve the perceived quality of network services, by modifying how network packets are managed, prioritizing the delivery of specific ones, as defined by a set of rules.
Usually network packets are processed using the simple FIFO (First In, First Out) rule. Devices may place them in buffers temporarily, but the order they are processed is always the same. This may not be always optimal, because some network services – for example audio/video streaming, and internet gaming – are more sensitive to delays in packets delivery (latency) than others. QoS may ensure this traffic is delivered more smoothly, and is not impacted (much) by other concurrent traffic.
QoS is a double edged sword. Correctly implemented and configured, it can improve latency for the needed services. Otherwise, it could make everything slower. It should be deployed when there is a real need, understanding what it really does, and the consequences.
- QoS is mostly useful when the network is heavily used, and packets starts to spend more time in the network devices buffers, or are dropped. It may be more useful in slow and strongly asymmetrical networks, than in fast ones lightly used, where there could be little or no benefits.
- QoS adds a processing overhead. Packets needs to be inspected to be classified and routed to the proper queue/buffer, then specific algorithms have to process these queues and decide which packets will be delivered next. Not all network devices may be able to accelerate QoS processing in dedicated hardware, and will switch to use their CPU, which in turn needs to be powerful enough to cope with the traffic.
- There is not a one size fits all solution. Configuration depends on how the network is used, and which traffic should have higher priority. Some device can use some kind of heuristic to identify which traffic should be prioritized (for example some “gaming” routers, it may be called “adaptive” or something alike), as always in this cases as long as they get it right, everything is fine. As soon as they don’t, it could lead to issues and there is no other solution but to disable the whole QoS. AI might change this one day.
- QoS is limited to the local network. While outside of it QoS can be used also, it’s outside our control. Some ISPs may prioritize their own VoIP traffic, for example, but any QoS tag we could set will be usually ignored when the packet leaves through the WAN interface. Thereby if the latency issues are caused by the upstream networks, no local QoS configuration can solve them.
- Inside a network, QoS needs to be performed end-to-end. If a device in the path ignores QoS settings, and just performs simple FIFO processing of packets, QoS benefits can be lost. You’ll have to configure QoS on each device in the path.
If you are experiencing latency issues, and you have assessed they are local to your network1 – VoIP calls where audio is lost when someone downloads/uploads something, streaming that often incurs in buffering, games that incur in issue while other local traffic use the network, QoS might help. It’s not only the Internet traffic that could cause latency issues, local traffic may be the cause as well. For example moving large files to/from a NAS may fill the available bandwidth over a local link.
Bandwidth limiters
The simplest type of QoS can simply use bandwidth limitations to hinder traffic from one or more devices to use the whole bandwidth available, leaving some for other traffic. This is a blunt approach, especially when it can be applied only to MAC or IP addresses, but may be enough in simple situations, for example limiting the bandwidth for the “guest” network.
It is easy to set bandwidth limits for specif IPs, subnets or VLANs. Some systems may avoid leaving unused bandwidth when no other devices needs it dynamically assigning it. This works well when the same device/network always does the same traffic. For example is quite simple to allocate a VoIP ATA some reserved bandwidth
It is more difficult when a PC could perform a VoIP call and HTTP download at the same time, or a gaming PC may still get an higher priority when it download a game than a TV streaming a live event, if the network device doesn’t allow per-protocol bandwidth limitations.
Moreover simple bandwidth limitations aren’t network wide – if you set one on the Internet router two devices communicating through a local switch won’t be impacted.
The correct bandwidth allocation may depend by the actual bandwidth available upstream. If for example a switch performing QoS is connected to an Internet router using a gigabit port, it will be not aware if the upstream bandwidth is not 1Gb/s symmetric – maybe the router is a VDSL one offering 100/20Mb/s only. The correct bandwidth may need to be set manually when the device is unable to detect it itself.
Priority based QoS
Priority based QoS allows to identify those packets, set a priority for their delivery, and then process them with more complex algorithms that can speed up their delivery while stil trying to avoid to delay too much lower priority traffic. Priority tags are part of the packets, and can thereby be recognized and honored by devices upstream and downstream.
Classifying packets for qos
The first operation needed to implement QoS is classifying packets. Unless told otherwise, network devices just look at the destination and source information to understand how to deliver packets. At the Ethernet layer, MAC addresses are processed. At the IP layer, IP addresses are processed. This is simple and ensure high-processing speed. Even if TCP and UDP ports are often assigned to specific protocols, there’s no enforcing of it. Thereby nothing is implied about the data a packet is actually carrying, and a deep inspection to identify what’s in them would slow down operations.
Implementing QoS requires packets to be classified somewhere, so their priority level can be set. Then just reading the priority level and acting accordingly avoids to re-classify the packet at each step, speeding up processing. Packets may be classified by the device creating them, or by an intermediate device where classifying rules are defined. An intermediate device can also modify priorities as needed.
Classifiers acts on packet properties, usually Ethernet and TCP/IP ones which are common to all packets. Rules can be configured to match addresses, ports, and specific packet fields, like the IP protocol type, TCP flags, VLAN IDs and so on. Some device can perform deep packet inspection to recognize some application-level protocols, like HTTP.
For example a VoIP device may set specific priority values for its packets, or a switch could set a specific value for packets coming or sent to specific IP addresses and UDP ports. Once a packet has been classified, it could be placed into a specific queue buffer for processing.
A packet can also be tagged with a priority tag so downstream devices can just use such tag and avoid re-classification. There are two standards for setting priority values inside Ethernet and TCP/IP frames. The first one uses the Ethernet 802.1Q format (the same used for VLAN tags also) to set a three bits priority field, thus allowing for eight different values. The other, Differentiated Services Code Point (DSCP) uses a six bits value (allowing 64 different values) in the IP header field. Many devices can act on both.
These values should not be assigned randomly. Higher values means higher priority, and they are recommended or defined by standards and should be used properly. The 802.1p standard recommends this values for the 802.1Q QoS field, but their actual use is left to the network implementation:
- 1 (priority 0 – lowest) – background traffic (BK)
- 0 (priority 1, default value) – best effort (BE)
- 2 – excellent effort (EE)
- 3 – critical application (CA)
- 4 – video, < 100 ms latency and jitter (VI)
- 5 – audio, < 10 ms latency and jitter (VO)
- 6 – internetwork control (IC)
- 7 (highest priority) – network control (NC)
Note that for historical reason the first two values are actually swapped, the lowest priority is 1, not 0.
DSCP uses more values, the standard ones can be found in RFC 4594 and successive updates. For example VoIP can use the value 46 (named EF), broadcast video 24 (named CS3) while video conferencing 36 (AF42). Again, higher values mean higher priority.
What standard to use depends on the devices used. The Ethernet standard is simpler and usually available on cheaper layer 2 switches, while the processing of DSCP data might require layer 3 switches. In a home network priorities based on 802.1p are usually enough.
Qos capable devices allows to write rules to be applied to incoming and outgoing packets to classify them. There isn’t a standard, and the syntax or interface to create such rules can be complex, and require different steps, especially on more advanced devices. You’ll need to read your device/application documentation. Some cheap devices may just respect the QoS settings made elsewhere. For example, many unmanaged switches can still understand and honor 802.1p priorities if present in the packet, even if no specific configuration can be made, and they are just using simple algorithms.
Packet processing
Network devices use the store and forward method for processing packets. That means a packet is received, processed, and when the final destination is know, forwarded. In the simple FIFO processing packets are queued into a buffer, incoming packets put at the end of the queue, those at the front processed, then forwarded or dropped as needed. QoS makes this processing more complex. Packets may be put in different queues depending on their classification. Then an algorithm needs to decide which packets should be forwarded first at any given time. The simplest algorithm would simply process the higher priority queues first, and when it is empty, switch to the lower priority ones. But this kind of algorithm could cause excessive latency for lower priority packets, up to the point they might be never delivered if higher priority ones keep coming. They also need to take into account how fast the packets in the queues can be actually delivered, as the receiving end needs to be ready to accept them. There are different queue management algorithms available. What is available depends on the devices used. Some examples are WRR, SQF, WFQ, FQ-Codel and others.
More complex algorithms may require more processing power, but also yield better result. What to use may be a compromise between the algorithm performance and processing power available.
Bandwidth limitations can be applied to queues also.
WiFi QoS
WiFi may have latency issues on its own, because the radio spectrum is a shared media, thereby not all devices can transmit/receive at the same time, and moreover slower devices can impact the performance of faster ones, since they will take more time to transmit or receive the same amount of data. That’s why hardcore gamers prefer cabled connections, and why using VoIP WiFi devices is harder. Streaming may take advantage of buffering, but live events may suffer anyway.
WiFi offers the older WMM (Wifi MultMedia) and the newer WiFi QoS. The WiFi Access Point need to support WMM or WiFi QoS.
WMM offers only four priority level, usually named Voice, Video, Best Effort and Background. WMM enabled devices can set them to work together with WMM capable access points to prioritize traffic.
DSCP values may work over WiFi, since they are carried in IP packets, while Ethernet 802.1p cannot. APs that support VLANs also may be able to associate a 802.1p priority to SSIDs, and map WMM priorities to 802.1p and DSCP ones, so packets keep their priorities along the network path.
WiFi QoS improves VMM with additional capabilities.
Conclusion
QoS may be a powerful tool to solve some network latency issues, but requires a good understanding of the network traffic and how to prioritize it. It won’t solve issues caused outside the network. Badly implemented, it could cripple your network speed. If you decide you need it, take your time to understand what your network device offer, and implement it step-by-step, and test, ready to remove any setting that reduce performance instead of improving them.
- If your “ping” is high because your destination is thousands of kilometers away (the speed of signals is not infinite, light in fiber optic cables and electric signals in copper cables travel at roughly 200km/ms, so do your math), or one or more router along the path is congested, no local QoS can improve anything ↩︎