Solving Bandwidth Starvation: When to Use WFQ over Strict Priority Queueing

The Latency vs. Starvation Dilemma

In high-throughput environments, the goal is often simple: ensure critical traffic (like VoIP or control signals) gets through first. The instinctive reaction is to implement Strict Priority Queueing (SPQ), where the scheduler empties the high-priority queue completely before even looking at the low-priority ones. However, this creates a critical failure point: if your high-priority stream saturates the link, every other service on that interface—DNS, SSH, background backups—simply stops. This is known as bandwidth starvation.

The solution is to move from a binary \"first or last\" approach to Weighted Fair Queueing (WFQ), which guarantees a minimum slice of the bandwidth to every traffic class regardless of the load on others.

Comparing the Scheduling Logic

To choose the right mechanism, you have to understand how the scheduler treats the packet buffer. In a Strict Priority model, the scheduler follows a rigid hierarchy. If Queue 0 has a packet, it is sent. Queue 1 is only serviced when Queue 0 is empty. This is ideal for jitter-sensitive traffic but dangerous for general network health.

Weighted Fair Queueing (WFQ) assigns a weight (a percentage of the total link capacity) to each queue. If you assign 20% to background traffic and 80% to priority traffic, the background traffic is guaranteed its 20% even if the priority queue is overflowing. If the priority queue is empty, the background traffic can burst to use 100% of the link.

Implementing a Weighted Policy

When configuring these policies, you typically define a class map to identify traffic and a policy map to assign the weights. Below is a conceptual configuration for a Cisco-style Modular QoS CLI (MQC) to prevent starvation on a 1Gbps link.

# Run these commands in global configuration mode with administrative privileges
# Step 1: Identify the traffic
class-map match-any VOIP-TRAFFIC
 match dscp ef
class-map match-any BULK-DATA
 match dscp af11

# Step 2: Define the bandwidth weights
policy-map QOS-POLICY
 class VOIP-TRAFFIC
  bandwidth percent 30
 class BULK-DATA
  bandwidth percent 10
 class class-default
  bandwidth percent 60

# Step 3: Apply to the egress interface
interface GigabitEthernet0/1
 service-policy output QOS-POLICY

Expected Result: During a congestion event, the VOIP class will never receive more than 30% of the link unless other queues are empty, and the BULK-DATA class is guaranteed 10% to prevent TCP session timeouts.

The Trade-off: Bufferbloat and Latency

While WFQ prevents starvation, it introduces a different risk: bufferbloat. Because WFQ buffers packets to ensure fairness rather than dropping them immediately (as a policer would), queues can grow very long during sustained congestion. This increases the end-to-end latency for all packets in that queue.

To mitigate this, combine WFQ with a Token Bucket filter. A Token Bucket allows for short bursts of traffic (by accumulating tokens) but enforces a strict average rate over time, preventing a single queue from filling the hardware buffer to capacity.

Verifying the Scheduling Behavior

To verify that your weights are working and that starvation has been eliminated, you cannot rely on simple \"up/down\" interface status. You must monitor the drop counters and queue depths.

• Check for Drops: Run show policy-map interface (or equivalent) to see if packets are being dropped in the class-default queue. If drops occur here while the priority queue is full, the weights are functioning.
• Analyze Inter-packet Arrival: Use a tool like Wireshark on the receiving end. If you see a steady stream of background packets interleaved with priority packets during a load test, WFQ is active. If background packets stop entirely during a priority burst, you are still using Strict Priority.