# What is QoS and how does it relate to bandwidth management?

By: Gladius

9-10 minutes

Last updated: November 03, 2026

Quality of Service (QoS) is a set of techniques that tells network devices which traffic to forward first when a link is congested, so delay-sensitive applications like voice and video keep working while less urgent traffic waits.

By default, IP networks treat every packet the same. Routers forward packets in the order they arrive, and when an interface is busy, they queue the excess and drop it once the queue fills. That works well until a large file transfer and a VoIP call share the same link. The file transfer recovers from a delay without anyone noticing. The call doesn't, a few hundred milliseconds of extra delay or a burst of lost packets is enough to make speech choppy or freeze a video feed.

QoS replaces that first-come, first-served behavior with rules. Traffic is sorted into classes, each class receives its own treatment, and the applications that can't tolerate delay are protected during peak hours.

## How QoS fits into bandwidth management

Bandwidth management is the broader discipline, measuring how capacity is used, deciding what matters most, controlling traffic accordingly, and planning for growth. QoS is one of its main control mechanisms. Three points define the relationship:

- QoS divides capacity; it doesn't add any: If a 100 Mbps link carries 140 Mbps of demand, QoS decides which 40 Mbps waits or is dropped. It cannot make the link carry more.
- Prioritization only happens under congestion: Classification and marking run on every packet, and policing and shaping enforce their configured rates whether the link is busy or not. Queuing and scheduling are different, because they only engage once demand exceeds what the interface can send. That is the point where one class actually goes ahead of another.
- QoS depends on monitoring: A policy is only as good as the traffic data behind it. Without visibility into which applications actually use the link, it's easy to protect the wrong traffic or leave a critical application in the default class.

## How QoS works

Most QoS deployments follow the same sequence on each device along the path:

1. Classification: The device identifies what each packet is, using fields such as source and destination address, port, protocol, an existing DSCP value, or application recognition such as Cisco NBAR2.
2. Marking: Each packet's class is recorded in the IP header as a DSCP value, so devices further along the path can apply the same treatment without classifying the traffic again.
3. Queuing and scheduling: On a congested interface, each class waits in its own queue. A strict-priority queue serves voice first, while the remaining classes receive a guaranteed share of the bandwidth, often called a bandwidth reservation.
4. Policing and shaping: Policing drops or re-marks traffic that exceeds a configured rate. Shaping buffers the excess and sends it later, smoothing bursts instead of discarding them. For a detailed comparison, see traffic shaping vs bandwidth throttling.

The point where a network starts trusting markings is called the trust boundary. A switch port connected to an IP phone might trust its markings, while a port connected to a user's laptop would typically re-classify traffic so that no application can award itself top priority.

## DSCP marking explained

The Differentiated Services Code Point (DSCP) is a 6-bit field in the IP header, defined in RFC 2474. Six bits allow 64 possible values, but most networks use a small, standardized set. The recommendations below come from RFC 4594, which maps common application types to DSCP classes:

| DSCP name | Decimal value | Typical traffic |
|---|---|---|
| EF (Expedited Forwarding) | 46 | Voice (telephony) |
| AF41 | 34 | Interactive video and video conferencing |
| AF21 | 18 | Low-latency data, such as client-server transactions |
| DF (Default) | 0 | Standard best-effort traffic |
| CS1 | 8 | Low-priority data, such as bulk downloads |

A DSCP value is a label, not a guarantee. It has no effect until a device along the path has a policy that matches the value and applies a treatment to it. A packet marked EF that crosses a router without a QoS policy is forwarded exactly like everything else.

## QoS configuration examples: VoIP, Microsoft Teams, and ERP

The examples below show how the three most common QoS goals translate into markings and policy.

### Microsoft Teams

Microsoft publishes required DSCP values and suggested client source port ranges for each Teams media type:

| Media type | Client source ports | DSCP value | DSCP class |
|---|---|---|---|
| Audio | 50,000—50,019 (TCP/UDP) | 46 | EF |
| Video | 50,020—50,039 (TCP/UDP) | 34 | AF41 |
| Application and screen sharing | 50,040—50,059 (TCP/UDP) | 18 | AF21 |
| Signaling | 50,070—50,089 (TCP/UDP) | 40 | CS5 |

Microsoft notes that the port ranges can be adjusted, but the DSCP markings cannot. Mark traffic at the endpoint, for example through Group Policy on Windows, and use port-based rules on network devices to catch clients that don't apply markings themselves.

### VoIP and ERP on a WAN edge router

The following Cisco IOS example protects voice, gives Teams video and an ERP application a guaranteed share, and leaves everything else in the default class. ERP traffic is identified by the address of its application server, because ERP systems don't use a standard port, and it shares a class with Teams screen sharing, which Microsoft marks AF21.

```ios
ip access-list extended ERP-SERVERS
 permit ip any host 10.10.20.15!

class-map match-any VOICE
 match dscp ef

class-map match-any VIDEO
 match dscp af41

class-map match-any SCREEN-SHARING
 match dscp af21

class-map match-any ERP
 match access-group name ERP-SERVERS !

policy-map WAN-EDGE
 class VOICE
  priority percent 10

 class VIDEO
  bandwidth percent 25

 class SCREEN-SHARING
  bandwidth percent 10

 class ERP
  bandwidth percent 15
  set dscp af31

 class class-default
  fair-queue

!

interface GigabitEthernet0/1
 service-policy output WAN-EDGE
```

The priority class is policed to its configured share during congestion, so voice cannot starve the other classes. The bandwidth percentages are minimum guarantees, not caps, so a class can use spare capacity when the link is quiet. And the policy only affects traffic leaving this interface; traffic arriving from the provider needs a matching policy on the other end of the link.

Note: This is an illustrative example for Cisco IOS and IOS XE. Validate the class structure, bandwidth percentages, and interface against your own platform and measured traffic before deploying it.

## What is CBQoS?

Class-Based Quality of Service (CBQoS) is Cisco's class-based QoS framework, and the counters it maintains for every class in a policy can be read over SNMP. Those counters answer the question every QoS deployment eventually faces: is the policy doing what it was designed to do?

Three measurements carry most of the insight:

- Pre-policy traffic: what each class looked like before the policy was applied on the interface.
- Post-policy traffic: what each class looked like after the policy, showing how much it was held back or reshaped.
- Drops and queuing: how many packets each class lost or had to wait for because of the policy.

Reading them together turns symptoms into causes:

| What the counters show | Likely cause |
|---|---|
| Drops in the voice class | The priority queue is too small for current call volume.Check the configured percentage against measured peak concurrent calls, then check whether non-voice traffic is arriving marked EF |
| Voice class is nearly empty while calls are active | Calls are arriving unmarked or re-marked and landing in the default class. Check the trust boundary and the class-map match criteria before assuming the policy is wrong. |
| Steady drops in the default class during business hours | The link is consistently oversubscribed. Confirm the default class is not catching traffic that should be classified elsewhere before upgrading. |
| Video class rarely reaches its guarantee | The reservation may be larger than needed. Compare against measured peak demand across several weeks, since a reservation sized for an all-hands call will look idle most days |

## Why QoS policies fail

When video calls keep dropping even though QoS is configured, check these common causes first:

- Markings don't survive the path: A switch, firewall, or provider link along the way resets DSCP values to zero, so traffic arrives at the congested interface without its label. Public internet providers commonly do not honor customer markings, so QoS is most effective on links you control or contract with defined service levels, such as MPLS.
- The policy sits on the wrong interface: QoS acts where congestion happens. A policy on a 10 Gbps core link does nothing for a 100 Mbps branch circuit that is actually saturated.
- Only one direction is covered: Outbound policies don't control traffic arriving from the provider. Downloads competing with inbound voice need a matching policy on the provider's side of the link.
- Classes don't match real traffic: Applications change ports, move to the cloud, or switch to encrypted protocols, and traffic quietly falls into the default class.
- Nobody checks the results: Policies drift as the network changes. Without per-class reporting, a policy that stopped working looks identical to one that works.

## How NetFlow Analyzer validates your QoS policies

A QoS policy is a hypothesis about your traffic. ManageEngine NetFlow Analyzer provides the evidence to confirm it or correct it, without hardware probes.

- Verify markings with flow data: Where the exporter includes the DSCP field in its flow records, you can see the marking each flow carried as it passed that device. Comparing records from devices at different points along the path shows where markings are kept and where they are changed or reset, so you can confirm that voice, video, and business traffic arrive at the congested interface with the markings you assigned.
- Read CBQoS counters per class: CBQoS reports show pre-policy and post-policy traffic, drops, and queuing for each class, so you can see whether the priority queue is sized correctly and which classes are losing packets.
- Identify applications accurately: Cisco NBAR and AVC monitoring reveal which applications are actually on the link, which helps you build classes around real traffic instead of assumptions.
- Get alerted early: Threshold alerts on utilization, volume, or frequency flag congestion before it becomes a complaint.
- Adjust traffic from the same console: The Network Configuration Manager add-on applies traffic shaping policies to devices, configured directly from the NetFlow Analyzer interface.

Learn more about [QoS monitoring](https://www.manageengine.com/products/netflow/qos-monitoring.html), [CBQoS reporting](https://www.manageengine.com/products/netflow/cbqos.html), and NetFlow Analyzer's [bandwidth management features](https://www.manageengine.com/products/netflow/bandwidth-management.html).

## Frequently asked questions

### Does QoS reduce latency?

It reduces the part of latency caused by waiting in a queue, which is what makes calls choppy on a busy link. It can't reduce the delay caused by physical distance or by a slow application server. If an application is slow on a link that isn't congested, QoS is unlikely to be the fix.