QoS Basics: Classification, Queuing and Voice Traffic

What are QoS basics in networking?

Quality of Service, or QoS, is a set of techniques used to identify traffic and control how packets are handled when a network link becomes congested. The main functions are classification, marking, queuing, congestion avoidance, policing and shaping.

QoS does not create additional bandwidth. It decides which packets should be transmitted first, which traffic receives a bandwidth guarantee and which packets may be delayed or dropped when demand exceeds capacity.

A simple diagram in words looks like this:

Packets enter interface
        |
        v
Classify traffic -> Mark traffic -> Apply policy
                                      |
                                      v
                              Place packets in queues
                                      |
                                      v
                         Scheduler selects next packet
                                      |
                                      v
                              Packets leave interface

QoS is particularly important for voice, interactive video and business-critical applications. File downloads can usually tolerate some delay, but a voice conversation becomes difficult when delay, jitter or packet loss increases.

Students should already understand IP addressing, VLANs, routing and basic Cisco IOS configuration. These foundations are covered in the CCNA course, while enterprise QoS design and implementation are developed further in the CCNP Enterprise course.

Why does voice traffic need QoS?

Voice traffic needs QoS because it is sensitive to delay, variation in delay and packet loss. A voice packet that arrives too late may be unusable even if it eventually reaches the destination.

Three conditions affect call quality:

IP phones normally send audio as a stream of small RTP packets over UDP. UDP does not retransmit a lost packet, and retransmission would usually be too late for a real-time conversation anyway.

Imagine a branch router with a 10 Mbps WAN connection. During normal operation, voice, web and backup traffic all pass without difficulty. When a backup starts using the full link, packets begin waiting in the router's outbound queue.

Without an appropriate QoS policy, a small voice packet may wait behind multiple large data packets. With Low Latency Queuing, the router services eligible voice packets from a strict-priority queue before servicing normal data queues.

Serialization also matters on slower links. A 1,500-byte packet takes approximately 6 milliseconds to serialize on a 2 Mbps link:

Serialization delay = packet size in bits / link speed
                    = 12,000 bits / 2,000,000 bits per second
                    = 0.006 seconds, or 6 ms

QoS cannot interrupt a packet that is already being transmitted on a normal Ethernet link. It can, however, select a waiting voice packet as the next packet to send.

How does QoS classification work?

Classification examines packet fields or traffic characteristics and assigns packets to logical classes. A policy can then give each class different queuing, marking, policing or shaping treatment.

Common classification methods include:

• Source or destination IP address
• TCP or UDP port number
• Differentiated Services Code Point, or DSCP
• Layer 2 Class of Service, or CoS
• Access control lists
• Network Based Application Recognition, where supported
• Ingress interface

For example, a router could classify RTP traffic from an IP phone subnet by using an extended ACL:

ip access-list extended VOICE-RTP
 permit udp 10.10.20.0 0.0.0.255 any range 16384 32767

class-map match-all RTP-FROM-PHONES
 match access-group name VOICE-RTP

This is suitable for a controlled lab, but production voice systems may negotiate different UDP port ranges. Check the call-control platform and phone configuration instead of assuming that every deployment uses the same ports.

Classification should be as close to the traffic source as practical. If untrusted endpoints are allowed to mark their own traffic, a user could mark bulk data as high-priority voice and consume the priority queue.

This leads to the idea of a trust boundary. A switch may trust markings from managed IP phones while rewriting or ignoring markings received from ordinary user devices. The exact trust commands vary across Catalyst platforms and software releases, so the configuration guide for the switch model must be checked.

What is marking, and which DSCP values are commonly used?

Marking writes a value into a packet header so downstream devices can recognize the traffic class without repeating complex classification. In IP networks, DSCP is the most common Layer 3 marking method.

The DSCP field uses six bits in the IP header. Common enterprise markings include:

EF means Expedited Forwarding and is commonly used for voice bearer traffic. A marking is only a label; it does not provide priority unless routers and switches have a policy that acts on it.

The following Cisco IOS MQC configuration marks matching lab traffic as EF on ingress:

policy-map MARK-VOICE
 class RTP-FROM-PHONES
  set dscp ef
 class class-default
  set dscp default

interface GigabitEthernet0/0
 description LAN-facing interface
 service-policy input MARK-VOICE

Be careful with the class-default action. Setting all unmatched packets to DSCP default is useful at an untrusted boundary, but it may erase valid markings if the interface also receives trusted application traffic.

Layer 2 Ethernet frames can also carry an IEEE 802.1p CoS value on an 802.1Q trunk. CoS 5 is commonly associated with voice, but CoS and DSCP are different fields. Any mapping between them depends on the switch policy and platform configuration.

How do queuing and scheduling work?

Queuing holds packets temporarily when packets arrive faster than an interface can transmit them. Scheduling decides which queue is serviced next and how much bandwidth each class can use during congestion.

The major queuing approaches are:

Class-Based Weighted Fair Queuing, or CBWFQ, allows an administrator to reserve bandwidth for defined classes. Low Latency Queuing, or LLQ, adds the priority command for traffic that must be serviced before ordinary queues during congestion.

A strict-priority queue must be controlled. If excessive traffic enters it, other applications could be starved. Cisco LLQ therefore applies priority treatment with an implicit policing function during congestion according to the configured priority allocation.

How can LLQ be configured for voice on Cisco IOS?

Cisco Modular QoS CLI uses class maps to identify traffic, policy maps to define treatment and service policies to attach the configuration to an interface. The voice policy is normally applied outbound on the interface where congestion is expected.

Consider this lab topology:

IP phones and PCs -- R1 -- constrained WAN link -- R2 -- call services
                         ^
                         |
              Apply outbound queuing here

Assume trusted voice packets already carry DSCP EF and signalling packets carry CS3:

class-map match-any VOICE
 match dscp ef

class-map match-any VOICE-SIGNALING
 match dscp cs3

policy-map WAN-QOS
 class VOICE
  priority percent 20
 class VOICE-SIGNALING
  bandwidth percent 5
 class class-default
  fair-queue

interface GigabitEthernet0/1
 description WAN-facing interface
 service-policy output WAN-QOS

The commands have the following effects:

• match dscp ef classifies marked voice bearer packets.
• priority percent 20 creates an LLQ allocation based on 20 percent of interface bandwidth.
• bandwidth percent 5 guarantees signalling traffic a share during congestion.
• fair-queue provides flow-based fairness within the default class where supported.
• service-policy output activates the queuing policy on transmitted traffic.

Percentages must be chosen from measured traffic requirements and available bandwidth. They should not be copied unchanged between networks.

The interface speed may also differ from the provider's committed rate. For example, a Gigabit Ethernet interface connected to a service limited to 10 Mbps may not experience local interface congestion. In that situation, a parent shaping policy can create the intended bottleneck:

policy-map WAN-PARENT
 class class-default
  shape average 10000000
  service-policy WAN-QOS

interface GigabitEthernet0/1
 no service-policy output WAN-QOS
 service-policy output WAN-PARENT

This hierarchical policy shapes aggregate traffic to 10 Mbps and runs the child queuing policy inside that shaped rate. Hierarchical QoS support and syntax should be confirmed for the specific IOS or IOS XE platform.

Provider networks may preserve, rewrite or ignore customer markings. QoS behaviour across carrier transport should be confirmed as part of the service design, especially when technologies such as MPLS are involved. See how MPLS labels and service-provider paths work for related forwarding concepts.

How much bandwidth should be reserved for voice?

Voice bandwidth should be calculated from the codec, packetization interval, protocol overhead, expected simultaneous calls and Layer 2 transport. Reserving bandwidth based only on the codec bit rate underestimates actual network usage.

For a simplified G.711 example with a 20 ms packetization interval:

Packets per second = 1,000 ms / 20 ms
                   = 50 packets per second

RTP + UDP + IP headers = 40 bytes per packet
Header bandwidth       = 40 x 8 x 50
                       = 16,000 bits per second

Codec payload          = 64,000 bits per second
Approximate Layer 3 total = 80,000 bits per second per call

Ethernet, VLAN, WAN encapsulation and other Layer 2 overhead increase the actual link requirement. Ten simultaneous calls in this simplified example require approximately 800 kbps at Layer 3, plus Layer 2 overhead and reasonable design headroom.

Call Admission Control is also important. QoS controls packets after calls exist, while admission control limits how many calls can use a constrained path. QoS alone cannot maintain quality if the network accepts more voice sessions than the link can support.

How can a QoS policy be verified?

A QoS policy should be verified through class counters, queue statistics, drop counters and tests performed during real congestion. A successful configuration does not prove that traffic is matching the intended class.

Use these commands on Cisco IOS or IOS XE:

show class-map
show policy-map
show policy-map interface GigabitEthernet0/1
show access-lists VOICE-RTP
show interfaces GigabitEthernet0/1

A shortened policy output may look like this:

GigabitEthernet0/1
 Service-policy output: WAN-QOS

  Class-map: VOICE (match-any)
    12540 packets, 2508000 bytes
    Match: dscp ef (46)
    Priority: 20% (2000 kbps), burst bytes 50000, b/w exceed drops: 0

  Class-map: VOICE-SIGNALING (match-any)
    430 packets, 60200 bytes
    Match: dscp cs3 (24)

  Class-map: class-default (match-any)
    85400 packets, 78200000 bytes
    Fair-queue
    Total output drops: 218

The increasing VOICE counters confirm that EF packets are matching the class. Zero priority exceed drops suggest voice has remained within its configured allocation, while default-class drops show that congestion has affected lower-priority traffic.

Counter formats vary by platform. Focus on whether the policy is attached in the correct direction, whether packet counters increase and where drops occur.

Why might a QoS policy appear not to work?

QoS commonly appears ineffective because the wrong traffic is classified, the policy is attached in the wrong direction or the router never sees congestion. Troubleshooting should begin with counters rather than assumptions.

Follow these steps:

1. Confirm the congestion point. Check interface utilisation, output drops and the provider rate. Queuing only changes behaviour when packets are waiting to leave.
2. Verify packet markings. Use a packet capture or platform monitoring feature to confirm that voice packets carry DSCP EF.
3. Check class counters. If the VOICE counter remains at zero, review ACLs, source subnets, port ranges and trust settings.
4. Check policy direction. Classification and marking may occur on ingress, while congestion management normally occurs on egress.
5. Review the trust boundary. An access switch or firewall may be clearing or rewriting DSCP values.
6. Check priority drops. Drops in the LLQ can indicate that voice exceeds its configured allocation or that non-voice traffic is incorrectly marked EF.
7. Test under controlled load. A ping test on an idle link does not validate queuing. Generate safe lab congestion and observe voice-class counters, delay and drops.
8. Confirm platform support. Commands and hardware queue behaviour vary between routers, Catalyst switches and IOS XE releases.

A useful test sends voice-like UDP traffic while a large TCP transfer fills the shaped WAN link. The expected result is not zero congestion; it is controlled congestion where voice remains in the priority class and lower-priority traffic absorbs most queueing delay or loss.

What should you remember about QoS?

Effective QoS follows a sequence: classify traffic, mark it consistently, queue it at the congestion point and verify the result with counters. Voice needs LLQ because delayed RTP packets quickly lose their value, but the priority allocation must be sized and controlled correctly.

Key points include:

• QoS manages congestion but does not add bandwidth.
• DSCP EF is commonly used for voice bearer traffic.
• Marking alone does not provide priority treatment.
• Queuing policies are usually applied outbound at the bottleneck.
• LLQ protects voice while CBWFQ provides bandwidth guarantees to other classes.
• Bandwidth calculations must include headers, packet rate and link overhead.
• Verification requires congestion, class counters and drop analysis.

To practise classification, marking, LLQ, shaping and enterprise troubleshooting in guided Cisco labs, enquire about syllabus and batch details for the CCNP Enterprise course.

Reviewed by Network Rhinos networking trainers.