QoS (Quality of Service): Prioritising Network Traffic for VoIP and Video

Modern business networks carry a diverse mix of traffic: hosted VoIP calls, Microsoft Teams or Zoom video conferences, cloud-based ERP transactions, bulk file transfers, and recreational web browsing. Without any form of traffic management, routers and switches treat every packet equally, forwarding them on a best-effort basis. This works fine when utilisation is low, but the moment a large backup job or a Windows update saturates an uplink, every other application suffers — and voice and video degrade first because they are the most sensitive to delay and jitter.

QoS is the umbrella term for all the techniques that allow network devices to identify, classify, and preferentially handle certain traffic flows. Rather than simply adding more bandwidth (which is not always possible or cost-effective on WAN links), QoS ensures that the bandwidth you already have is allocated intelligently. For Australian businesses relying on NBN or fibre Ethernet services with fixed upstream capacity, proper QoS configuration can mean the difference between crystal-clear VoIP and an unusable phone system.

QoS is not a single feature you toggle on. It is a pipeline of distinct functions, each playing a role. Classification is the first step — the network device inspects each packet and decides which class it belongs to. Classification can be based on source or destination IP, port numbers, VLAN tags, or even deep packet inspection. Marking then stamps that classification decision onto the packet header so that every downstream device can make the same forwarding decisions without re-inspecting the payload. On Layer 3, this is done using the DSCP (Differentiated Services Code Point) field in the IP header; on Layer 2, it uses the 802.1p CoS (Class of Service) bits in the VLAN tag.

Once packets are classified and marked, queuing determines the order in which packets are sent out of an interface. A device might have multiple output queues — a strict priority queue for voice, a weighted queue for video and business applications, and a best-effort queue for everything else. Finally, shaping and policing control the rate at which traffic enters or leaves the network. Shaping buffers excess traffic and smooths it out over time, while policing drops or re-marks traffic that exceeds a defined rate. Together, these four functions form the complete QoS toolkit available on managed switches and routers.

DSCP replaced the older IP Precedence (ToS) model and uses six bits in the IP header, giving 64 possible values. In practice, the IETF defines a handful of Per-Hop Behaviours (PHBs) that map to specific DSCP values. Expedited Forwarding (EF), DSCP 46, is the gold standard for voice — it guarantees low latency, low jitter, and low loss by placing traffic into a strict priority queue. Assured Forwarding (AF) classes — AF11 through AF43 — provide tiered service for business applications, with each class having three drop precedence levels. Class Selector (CS) values maintain backward compatibility with IP Precedence, with CS6 and CS7 reserved for network control traffic like routing protocol hellos.

The queuing algorithm your switch or router uses determines how competing traffic classes share outbound capacity. Strict Priority Queuing (PQ) always empties the highest-priority queue before serving any lower queue. This is ideal for voice because it minimises latency, but it can starve other traffic if the priority queue is overloaded — which is why you should always police the amount of traffic entering the priority queue. Weighted Round Robin (WRR) and Deficit Weighted Round Robin (DWRR) serve multiple queues in rotation, giving more turns to higher-weighted queues. This prevents starvation while still providing differentiated service.

Most modern managed switches use a hybrid approach: one strict priority queue for EF-marked voice traffic, with the remaining queues served using DWRR or Weighted Fair Queuing (WFQ). Cisco's CBWFQ (Class-Based Weighted Fair Queuing) combined with LLQ (Low-Latency Queuing) is a textbook example — LLQ provides a strict priority path for voice while CBWFQ allocates guaranteed minimum bandwidth to other classes. Vendors like Aruba, Juniper, and Ubiquiti offer equivalent mechanisms, though the CLI syntax and queue naming differ. Understanding the underlying concept means you can configure QoS on any vendor's platform.

A critical but often overlooked QoS concept is the trust boundary — the point in the network where you trust incoming DSCP or CoS markings versus where you reclassify traffic. In a well-designed QoS architecture, the trust boundary sits as close to the traffic source as possible. For VoIP phones, this typically means trusting DSCP markings from the phone (which marks its own voice traffic as EF) but re-marking any traffic arriving from the PC port on the phone to a lower class. The access switch enforces this policy, and all upstream devices simply honour the markings.

If you trust markings from untrusted endpoints — such as user PCs — anyone could set their DSCP to EF and effectively jump the queue. Best practice is to set the access port to reclassify all PC traffic to CS0 (best effort) while trusting markings from known devices such as IP phones, access points, and surveillance cameras. At the WAN edge, your ISP may strip or re-mark your DSCP values unless you have a service agreement that honours them, so always check with your provider.

Deploying QoS effectively requires a methodical approach. Start by auditing your traffic — use NetFlow, sFlow, or SNMP interface counters to understand what traffic types exist and how much bandwidth each consumes during peak hours. Next, define your classes. Most organisations need no more than four to six classes: voice (EF), video (AF41), business-critical applications (AF21), default best-effort (CS0), and optionally a scavenger class (CS1) for low-priority bulk traffic. Keeping it simple ensures the policy is maintainable and debuggable.

Once classes are defined, configure classification and marking at the access layer. On a Cisco Catalyst switch, this might involve enabling mls qos, setting trust on the voice VLAN, and applying an ACL-based class-map on other ports. On an Aruba CX switch, you would create a QoS trust policy and apply it per-port. At the WAN edge, configure your router or SD-WAN appliance to schedule traffic according to the DSCP markings, allocating a guaranteed percentage of bandwidth to each class and shaping total traffic to match your contracted WAN speed. This prevents the provider from randomly dropping your voice packets when the link is congested.

Wireless networks introduce additional QoS challenges because the shared radio medium cannot provide the same deterministic queuing as a wired switch port. The Wi-Fi Multimedia (WMM) standard, based on IEEE 802.11e, defines four access categories: Voice (AC_VO), Video (AC_VI), Best Effort (AC_BE), and Background (AC_BK). WMM uses different contention window sizes and inter-frame spacings to give higher-priority traffic a statistical advantage in accessing the radio channel. While not as deterministic as wired QoS, WMM significantly improves voice and video performance over Wi-Fi when the channel is busy.

Enterprise access points from vendors like Aruba, Cisco Meraki, and Ruckus also support airtime fairness, which prevents slow clients from monopolising the channel. Without airtime fairness, a single device connected at a low MCS rate (e.g., an old 802.11n tablet at the edge of coverage) can consume a disproportionate amount of airtime, degrading performance for all other clients. Combining WMM with airtime fairness, band steering, and proper channel planning gives wireless VoIP and video the best chance of success.

The most frequent QoS mistake is marking everything as high priority. If every application is EF, then nothing is prioritised — you are back to best-effort with extra complexity. Voice should typically consume no more than 10-15% of link bandwidth in the priority queue. Another common error is configuring QoS on the LAN but not on the WAN edge, where congestion actually occurs. LAN links are often gigabit or faster and rarely congest, so QoS policies have the greatest impact on the slowest link in the path — usually the WAN uplink or internet connection.

Failing to match shaper rate to actual WAN speed is another pitfall. If your contracted speed is 100 Mbps but your router interface is 1 Gbps, the router sees no congestion at its interface and never invokes its QoS policy. The queuing actually happens inside the ISP's network, where your DSCP markings may be ignored. The fix is to apply an outbound shaper set slightly below your contracted speed (e.g., 95 Mbps) so that queuing happens on your device, under your control. This simple step is often the single most effective QoS improvement you can make.