LogoENEnglish

Quality of Service Fundamentals: Classifying and Prioritizing Network Traffic

Not all network traffic is equally sensitive to delay, and treating a voice call the same as a large file download during periods of congestion produces a poor experience for both. This article explains why QoS matters, covers the classification and marking of traffic using CoS and DSCP, walks through queuing strategies that determine which traffic is serviced first, and covers the essential configuration for applying QoS policies on a Cisco device.

QoS ConfigurationDSCP MarkingTraffic Queuing

~6 دقیقه مطالعه · آخرین به‌روزرسانی ۱۹ شهریور ۱۴۰۵

Why Not All Traffic Can Be Treated Equally

A network link has finite bandwidth, and during periods of congestion, some traffic must wait while other traffic is transmitted first. Different applications have very different tolerances for this delay: a large file download can tolerate significant delay without any noticeable impact, while a live voice or video call becomes choppy and unusable with even small amounts of delay or jitter. Quality of Service (QoS) is the set of techniques that identify, prioritize, and manage traffic so that delay-sensitive applications are protected during congestion.

Key QoS Characteristics That Matter

Bandwidth: how much data can be transmitted per second
  - large file transfers need high bandwidth, but
    tolerate delay

Delay (Latency): time for a packet to travel from
  source to destination
  - voice and video need low, consistent latency

Jitter: variation in delay between consecutive packets
  - voice and video are extremely sensitive to jitter,
    since it causes audio/video stuttering

Packet Loss: percentage of packets that never arrive
  - voice can tolerate a small amount (using codec
    error concealment), but TCP-based applications
    handle loss very differently through retransmission

Understanding which of these characteristics matters most for a given type of traffic is the foundation for designing an effective QoS policy — voice traffic specifically needs low latency and low jitter, even at the cost of occasional small packet loss, while a file transfer needs neither low latency nor low jitter but benefits enormously from available bandwidth.

Classification and Marking: Identifying Traffic Type

Before a device can prioritize traffic, it must first identify what kind of traffic each packet represents — a process called Classification — and then typically mark the packet with that classification so that other devices along the path can make consistent decisions without needing to re-classify it themselves.

Layer 2 marking: CoS (Class of Service)
  A 3-bit field within the 802.1Q tag, discussed
  earlier in this series regarding VLANs
  Range: 0-7, only meaningful on trunk links,
  since it exists within the VLAN tag itself

Layer 3 marking: DSCP (Differentiated Services Code Point)
  A 6-bit field within the IP header itself
  Range: 0-63, survives across the entire path
  end to end, since it's part of the IP header
  rather than a Layer 2 tag that gets stripped
  at Layer 3 boundaries

DSCP is generally preferred over CoS for end-to-end QoS policy specifically because it survives Layer 3 routing hops, while a CoS marking in an 802.1Q tag is lost the moment a packet is routed rather than switched, since routing strips the Layer 2 header entirely.

Common DSCP Values

EF (Expedited Forwarding, DSCP 46):
  Reserved specifically for voice traffic,
  guaranteeing the lowest possible latency and jitter

AF (Assured Forwarding, various values):
  A family of values providing different levels
  of guaranteed delivery, commonly used for
  video and business-critical data applications

Default (DSCP 0):
  Best-effort traffic with no special handling,
  the default for traffic with no explicit marking

Configuring Classification and Marking

Router(config)# class-map match-all VOICE-TRAFFIC
Router(config-cmap)# match protocol rtp
Router(config-cmap)# exit

Router(config)# policy-map MARK-TRAFFIC
Router(config-pmap)# class VOICE-TRAFFIC
Router(config-pmap-c)# set dscp ef
Router(config-pmap-c)# exit
Router(config-pmap)# exit

Router(config)# interface gigabitethernet 0/1
Router(config-if)# service-policy input MARK-TRAFFIC

This configuration follows the standard Cisco Modular QoS CLI (MQC) pattern: a class-map defines what traffic to match, a policy-map defines what action to take on that matched traffic, and service-policy applies the policy to a specific interface in a specific direction.

Queuing: Deciding Which Traffic Goes First During Congestion

Once traffic is classified and marked, Queuing mechanisms determine the actual order in which packets are transmitted when a link is congested and multiple packets are competing for the same output interface.

FIFO (First In, First Out):
  Simplest queue, no prioritization at all —
  traffic is transmitted in the exact order received

Priority Queuing (PQ):
  High-priority traffic is always serviced first,
  completely emptying the high-priority queue
  before any lower-priority traffic is sent —
  risk: low-priority traffic can be starved entirely
  if high-priority traffic is constant

Weighted Fair Queuing (WFQ):
  Automatically allocates bandwidth fairly among
  flows, giving smaller/interactive flows
  proportionally more attention

Low Latency Queuing (LLQ):
  Combines strict priority queuing (for voice,
  which truly needs to always go first) with
  weighted fair queuing for all other traffic classes
  — the most commonly deployed queuing strategy
  in modern enterprise networks

Configuring LLQ with a Priority Queue for Voice

Router(config)# policy-map QUEUE-POLICY
Router(config-pmap)# class VOICE-TRAFFIC
Router(config-pmap-c)# priority 128
-- guarantees up to 128 kbps of strict priority
-- bandwidth reserved specifically for voice

Router(config-pmap)# class class-default
Router(config-pmap-c)# fair-queue
-- remaining traffic is handled with weighted
-- fair queuing among all other flows

Router(config)# interface gigabitethernet 0/0
Router(config-if)# service-policy output QUEUE-POLICY

The priority 128 command both guarantees bandwidth availability for voice and, critically, imposes a policing limit — voice traffic exceeding 128 kbps is dropped rather than allowed to consume the entire link, preventing a misbehaving or attacking flow from monopolizing the strict-priority queue and starving all other traffic entirely.

Verifying QoS Configuration and Statistics

Router# show policy-map interface gigabitethernet 0/0

  Service-policy output: QUEUE-POLICY
    Class-map: VOICE-TRAFFIC (match-all)
      1204 packets, 96320 bytes
      Queueing
      Strict Priority
      Bandwidth 128 (kbps) Burst 3200 (Bytes)
      (pkts matched/bytes matched) 1204/96320
      (total drops) 0

The (total drops) counter is the single most important field to monitor — any drops within the voice class specifically indicate either the reserved bandwidth is insufficient for actual voice traffic volume, or an unexpected surge of traffic is being incorrectly classified into that priority class.

Why QoS Matters Even on High-Bandwidth Links

A common misconception is that QoS becomes unnecessary once link bandwidth is sufficiently high — but momentary congestion, even on a link with generous average capacity, still causes brief queuing delays that are catastrophic for jitter-sensitive traffic like voice, even when the link's long-term average utilization looks entirely comfortable. Understanding classification, marking, and queuing together provides the complete picture needed to guarantee that critical, delay-sensitive traffic receives consistent treatment regardless of momentary congestion elsewhere on the network.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

ادامه

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

ادامه

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

ادامه

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

ادامه

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

ادامه

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

ادامه
مقاله‌ی قبلیمقاله‌ی بعدی