20.5 QoS

Introduction

Quality of Service, or QoS, is about controlling how different kinds of traffic use the network so that important applications perform well even when links are busy. In enterprise networks you cannot assume that bandwidth is always enough. Voice calls, video conferences, backups, web browsing, and file transfers all compete for the same resources. QoS provides tools and policies that decide who gets priority when there is not enough capacity for everyone at once.

QoS is not a single protocol. It is a set of concepts and mechanisms that work together. At a high level, QoS classifies traffic into categories, marks it, then queues and schedules it according to rules that reflect business priorities. In advanced environments, QoS is closely linked with traffic engineering, MPLS, and SD‑WAN, but the fundamental ideas remain the same across technologies and vendors.

Why QoS Exists

Without QoS, the network treats all packets alike. When a link becomes congested, packets are queued until buffers fill. Once buffers overflow, packets are dropped randomly. This is acceptable for many applications, such as web browsing, but it is harmful for real‑time and interactive applications.

Different applications have different needs.

Real‑time voice and video are sensitive to delay and jitter. A small amount of packet loss is acceptable, but excessive delay or irregular arrival times quickly become noticeable to users.

Interactive applications, such as SSH or remote desktops, need low delay but typically use little bandwidth.

Bulk transfers, such as backups, software updates, or large file copies, care mainly about total throughput and can tolerate more delay.

QoS exists to enforce intentional unfairness. It lets the network favor important, time‑sensitive traffic over less important or delay‑tolerant traffic during congestion. When there is no congestion, QoS usually has little visible effect. QoS becomes relevant exactly when resources are scarce.

Main QoS Functions

Most QoS designs can be understood as a sequence of functions that packets pass through. Different vendors may use different names, but the logical steps are similar.

The core functions are:

Classification. Identify which traffic belongs to which class. This can use information such as source or destination IP address, protocol, port number, VLAN ID, or existing QoS markings.

Marking. Attach a label to the packet that indicates its class, so that future devices do not need to repeat deep inspection. In IP networks this usually means setting DSCP or IP precedence bits in the IP header. On Ethernet segments, class of service fields can also be used.

Policing and shaping. Control how much traffic of a given class is allowed to enter or traverse a link. Policing typically enforces a rate limit by dropping or remarking packets that exceed a defined rate. Shaping delays excess traffic by buffering it, smoothing the rate over time instead of dropping immediately.

Queuing and scheduling. When multiple packets compete for a link, they are placed into queues. The scheduler decides from which queue to send the next packet. Different algorithms implement strict priority, weighted fair sharing, or other behaviors.

Congestion avoidance. When queues start to fill, mechanisms such as random early detection selectively drop packets before buffers are completely full. This encourages some flows to slow down before severe congestion occurs.

These functions are chained in policy maps or service policies on routers and switches. On each device along the path, classification and marking tend to happen near the edge, while queuing and scheduling are most critical on low‑bandwidth or oversubscribed links.

QoS Models and Architectures

Enterprise QoS designs often reference two main architectural models.

The first model is Integrated Services, which aims to provide per‑flow reservations with protocols like RSVP. This model offers strong guarantees but does not scale well in large, dynamic networks because every flow must be signaled and maintained.

The second and much more commonly used model in enterprises is Differentiated Services. In this model, traffic is grouped into behavior aggregates, which simply means classes of traffic that will receive the same forwarding treatment. Packets are marked with DSCP values that correspond to these classes. Routers and switches then implement per‑hop behaviors based on these markings, such as low latency or best effort.

QoS in modern networks almost always follows the differentiated services approach. Instead of guaranteeing resources for each individual flow, it is easier to guarantee general treatment for a limited set of traffic classes, such as voice, video, critical data, and default best effort.

DSCP and QoS Markings

At the heart of differentiated services lies packet marking. In IPv4 and IPv6, the header includes a field commonly referred to as the DS field. The upper 6 bits of this field carry the Differentiated Services Code Point, or DSCP. DSCP describes how the packet should be treated in transit.

Older schemes used IP precedence, which is a 3‑bit field in the same location. DSCP generalizes and extends this idea with more possible values. In many enterprises you will see references to both DSCP and class names defined in documents such as RFC 2474 and related standards.

A simplified view of DSCP is shown in the following table.

Vendors implement their own mapping of DSCP to internal queues and priorities, but the principle remains consistent. Endpoints such as IP phones or collaboration clients often mark their traffic directly. At the network edge, switches and routers can trust, override, or normalize these markings according to policy.

Classification and Policy Design

In practice, one of the hardest parts of QoS is deciding how to classify traffic into meaningful classes. This is not a purely technical question. It involves understanding business priorities and application behavior.

A common approach is to define a small number of classes, for example:

Real‑time voice as the highest priority class for voice media.

Interactive video as a high priority but often with a bandwidth cap to avoid starving other services.

Critical business applications as a high but not real‑time class.

Best effort for ordinary user traffic.

Scavenger or background for bulk transfers that can be delayed or slowed.

Classification rules then implement this design. At the edge, access lists, protocol identifiers, or application recognition tools detect flows that match each class. The device then applies the appropriate DSCP marking. After that, core devices can rely mainly on DSCP instead of complex access lists.

Proper design requires limiting the number of classes. If there are too many classes, policies become complex, difficult to reason about, and harder to troubleshoot. Most real networks succeed with fewer than a dozen distinct traffic classes.

Queuing, Priority, and Scheduling

When a link is saturated, packets arriving faster than they can be sent must wait in queues. QoS determines how these queues are structured and how the scheduler selects packets.

The simplest scheduler is first in, first out, or FIFO. In this case, every packet uses a single shared queue, and the link sends packets in arrival order. This is functionally equivalent to having no QoS for scheduling.

More advanced schedulers can provide different behaviors for different queues. For real‑time applications, strict priority queues are common. Packets in a strict priority queue are always sent before packets in any lower priority queue, as long as the priority queue is not empty. This delivers minimal delay and jitter for that class. To avoid starvation of lower classes, priority queues are often policed so that they can use only a configured maximum share of link bandwidth.

Weighted fair queuing and similar algorithms divide link capacity among classes proportionally. Each class receives a minimum share of bandwidth based on its weight. If some classes are idle, others can temporarily borrow usable capacity. These schedulers help ensure that even lower‑priority but important traffic is not completely blocked during congestion.

An example is a policy where voice traffic is mapped to a low latency priority queue with a cap, video to an assured queue with a high weight, and default traffic to a best effort queue with a moderate weight. When the link is uncongested, all traffic flows freely. During congestion, voice packets jump ahead, video receives a larger share than best effort, and background traffic may be delayed or dropped first.

Policing, Shaping, and Congestion Management

When traffic from a certain class exceeds its allowed rate, QoS can respond in two main ways. Policing enforces a rate limit by dropping or remarking excess packets immediately. It is useful at network edges where you need to ensure that a device or tenant does not exceed its contracted bandwidth. Because policing drops packets, it introduces loss rather than delay.

Shaping addresses a different problem. On lower speed or burst sensitive links, such as WAN circuits, bursts of traffic can cause intermittent but severe congestion. Shaping buffers packets that exceed a target rate and then sends them later so that the output rate stays at or below a configured value. This smooths out bursts and reduces the chance of downstream congestion. Shaping introduces additional delay but can significantly improve stability.

Beyond these, congestion avoidance mechanisms try to prevent queues from becoming completely full. Random early detection and weighted variants of it start to drop or mark packets before buffers overflow. They aim to signal congestion to adaptive protocols, such as TCP, in a gradual way so that senders reduce their sending rate before a collapse occurs.

All these tools must be applied carefully. Aggressive policing of real‑time traffic can degrade quality quickly. Over‑shaping can add too much delay. Poorly tuned congestion avoidance can drop the wrong packets at the wrong time. This is why QoS in advanced enterprise environments is both powerful and subtle.

QoS Across Technologies and Domains

In large enterprises, QoS policies must cross many technological boundaries. A single business application may traverse access switches, campus cores, data center fabrics, WAN routers, provider MPLS networks, and finally remote sites or cloud environments.

Each segment may implement QoS differently. For example, Ethernet switches may use internal queues and class of service bits in the VLAN tag, while routers rely mainly on DSCP in the IP header. MPLS networks may map DSCP into the experimental bits of the label stack. Wireless networks have their own categories aligned with standards for Wi‑Fi multimedia, which must be mapped to wired QoS classes at the controller or access switch.

A critical part of advanced QoS design is defining consistent mappings between all of these representations. Voice traffic might be DSCP 46 in IP, a specific access category on Wi‑Fi, and a certain MPLS experimental value in the service provider core. If these mappings are inconsistent, the application may lose priority somewhere in the path.

In multi‑tenant and cloud environments, QoS also interacts with virtualization. Hypervisors and virtual switches must honor or rewrite markings. Overlay networks, such as those using VXLAN, can carry or reinterpret QoS fields from inner to outer headers. SD‑WAN solutions often provide their own QoS frameworks on top of transport underlays such as the public internet or MPLS.

Measuring and Verifying QoS

QoS policies are only effective if they deliver observable benefits. Verification involves both configuration auditing and performance measurement.

Configuration auditing checks that classes, markings, and scheduling behaviors match the intended design. This includes confirming DSCP values, queue allocations, and priority configurations on each relevant device and interface.

Performance measurement focuses on application experience and path behavior. For real‑time traffic, key metrics are latency, jitter, and packet loss. Active probes, synthetic tests, and monitoring from endpoints can provide visibility. For data traffic, throughput and response time under load are more relevant.

In many enterprises, troubleshooting QoS issues is challenging because symptoms can be intermittent and may appear only during specific load conditions. Problems can arise from misclassified traffic, inconsistent markings, incorrect queue maps, or oversubscription that exceeds what QoS can reasonably handle. Careful end‑to‑end testing, combined with packet capture and device statistics, is often necessary to validate that the network honors QoS intent along the entire path.

QoS Design Principles

Although detailed designs vary from one organization to another, several principles tend to lead to successful QoS deployments.

Keep the number of traffic classes small and well defined. Each class should have a clear purpose and example applications. Avoid creating unique classes for every minor application.

Mark traffic as close to the source as possible. This allows the rest of the network to use simple classification based on DSCP and reduces the risk of expensive or inconsistent reclassification deeper in the network.

Protect the priority queues. Reserve strict priority only for traffic that truly requires it, and cap its bandwidth usage so that other classes cannot be starved.

Align QoS with business priorities, not individual protocols. Focus on user experience and critical operations, then map technical mechanisms to these goals.

Treat QoS as part of overall network design, including capacity planning and traffic engineering. QoS cannot compensate for chronically undersized links, but it is an essential tool to manage temporary contention and ensure predictable performance when contention occurs.

By following these principles, advanced enterprise networks can use QoS to offer differentiated and predictable service to a wide variety of applications, while remaining manageable and maintainable as the network evolves.