Quality of service (QoS) for voice, video and business applications

Why networks need QoS

Modern networks are converged: voice, video, business applications and backups all share the same links. When a link is congested, packets wait in queues or are dropped. A file download can recover by resending; a voice call can't, because late audio is useless. QoS gives each kind of traffic the treatment it needs.

The QoS toolkit

Classification, marking and trust

Classification identifies traffic by port, address, application or existing marks. Marking writes a value into the packet so later devices don't have to classify again:

• DSCP in the IP header (6 bits, 64 values). Common values: EF (46) for voice, AF41 (34) for video, CS3 (24) for call signalling, 0 (default) for best effort.
• CoS in the 802.1Q tag (3 bits) for Layer 2.

The trust boundary is where the network starts believing marks. Usually it is the access switch port connected to an IP phone; marks from ordinary PCs are reset, so users can't promote their own traffic.

Queuing, policing and shaping

• LLQ (low-latency queuing): a strict-priority queue for voice, with a limit so it can't starve everything else; other classes share the rest with guaranteed minimums (CBWFQ).
• Policing drops or re-marks traffic above a rate: used at provider edges and for unwanted traffic.
• Shaping buffers traffic above a rate and sends it later: used where your link is faster than the service you bought from the provider.
• WRED drops a few low-priority packets early as queues fill, so TCP slows down before queues overflow.

A sample policy (Cisco MQC)

class-map match-any VOICE
 match dscp ef
class-map match-any VIDEO
 match dscp af41
policy-map WAN-OUT
 class VOICE
  priority percent 20
 class VIDEO
  bandwidth percent 25
 class class-default
  fair-queue
  random-detect dscp-based
interface gigabitEthernet 0/0
 service-policy output WAN-OUT

Remember: QoS can't create bandwidth. It decides who waits when there isn't enough. If links are always full, add capacity too.

Real-world example: choppy calls in a call centre

A customer service centre with 60 agents moved to IP phones. Calls sounded fine in the mornings but became choppy every afternoon. Monitoring showed that a scheduled backup to the cloud filled the 200 Mbps internet link at the same time each day, and voice packets were waiting in the same queue as backup traffic.

The network team trusted the DSCP EF marking from the phones at the access switches, marked the backup traffic as low priority, and applied a policy on the router's internet interface. Voice received a strict priority queue with a limit, video calls a guaranteed share, and the backup was placed in a scavenger class. The backup now takes a little longer, but agents' calls stay clear even when the link is busy.