skip to content

In router QoS queuing, why pair a strict-priority queue for voice with class-based weighted fair queues, and why must the priority queue be policed?

level: middleimportance: should knowfreq 30%

answer

  1. who the scheduler picks next
  2. waiting your turn is jitter
  3. minimum shares, not caps
  4. unlimited preemption starves others
  5. RFC 3246 demands a limit

basics

~20 s

A strict-priority queue sends waiting voice first, giving the low delay and jitter Expedited Forwarding needs; weighted class queues guarantee every other class a minimum share. The priority queue must be rate-limited, or excess priority traffic starves every other class.

solid answer

~50 s

A **strict-priority queue** transmits any waiting voice packet next, so voice waits only behind the packet already on the wire. That is how a node meets RFC 3246's Expedited Forwarding behaviour, which requires EF to be served at or above a configured rate regardless of other traffic. **Class-based weighted fair queuing** gives each other class a guaranteed minimum share during congestion, with unused share available to busy classes; on its own it would make voice wait its turn, and that wait is jitter. One vendor's names for the pair, LLQ and CBWFQ, are used generically. The priority queue must be **policed** because strict priority can pre-empt everything: excess EF from a mis-marking host or too many calls would starve the other classes, routing traffic included. RFC 3246 says such an implementation MUST limit EF, for example with a token bucket, and MUST discard the excess.

code

pseudocode · 12 lines
pseudocode
function next_packet():
    # strict priority first, but only within its rate limit
    if priority_queue not empty:
        pkt = priority_queue.head
        if ef_bucket.tokens >= pkt.size:
            ef_bucket.tokens -= pkt.size
            return priority_queue.dequeue()
        priority_queue.drop_head()   # excess EF is discarded
        return next_packet()
    # otherwise weighted fair service across classes
    cls = class_with_smallest_virtual_finish_time(backlogged_classes)
    return cls.dequeue()

go deeper

for a junior

Recall that voice gets a strict-priority queue, other classes get guaranteed shares, and the priority queue always has a rate limit.

for a middle

Explain how strict priority and weighted fair scheduling choose the next packet, why waiting one's turn becomes jitter, and why unused shares are redistributed.

for a senior

Show how you size the priority limit from the call load, read policer drops on the priority queue, and keep video from crowding voice.

for a principal

Weigh how much of a link may be pre-emptible at all, and how queue policy, admission control and endpoint trust together keep the priority class honest.

## The scheduler decides who leaves next When an output interface is congested, packets wait in one or more queues and a **scheduler** picks the next packet to transmit. The main disciplines: | Scheduler | How it picks the next packet | Strength | Weakness | |---|---|---|---| | FIFO | arrival order | simple, never reorders | one burst delays everyone | | Strict priority | always the highest non-empty queue | lowest delay for the top queue | can starve lower queues | | Weighted fair queuing (WFQ) | approximates serving each flow or queue in proportion to a weight | fairness and isolation | a heavy-weight queue still waits its turn | | Class-based WFQ | WFQ across operator-defined classes, each with a minimum share | guaranteed bandwidth per class | no strict low-delay path | WFQ began as a per-flow algorithm: each conversation gets its own queue and a weighted share. **Class-based weighted fair queuing (CBWFQ)** and **low-latency queuing (LLQ)** are one vendor's names that the industry uses generically. CBWFQ gives each traffic class a guaranteed minimum share of the link during congestion; LLQ is CBWFQ plus one strict-priority queue on top. ## Why voice needs strict priority RFC 3246 defines the EF per-hop behaviour: EF packets must be served at or above a configured rate, independent of the load of other traffic, so that they usually meet short or empty queues. A weighted fair scheduler gives voice a share but makes it wait for its turn behind the other classes, and how long it waits depends on how busy they are. That varying wait is **jitter**. A strict-priority queue sends a waiting voice packet as soon as the current transmission ends. Transmission is not pre-empted, so a voice packet still waits for the packet already being sent, for any voice packets ahead of it, and for any small hardware transmit buffer below the scheduler. On a 10 Mb/s link a 1,500-byte packet takes 1.2 ms to send, so that residual wait is small. RFC 4594's summary table lists **Priority** queuing for the Telephony class and **Rate** queuing for the other classes. ## Why the priority queue must be policed Strict priority has a dangerous property: while the priority queue holds a packet, nothing else is sent. If more traffic is marked EF than planned, through a misconfigured application, a host that marks everything EF, or more calls than the link was engineered for, the priority queue can take the whole link and starve every other class, including routing protocol traffic. RFC 3246 makes the guard mandatory. If EF is implemented by a mechanism that allows unlimited preemption of other traffic, such as a priority queue, the implementation MUST include some means to limit the damage, such as a token-bucket rate limiter, and traffic exceeding the limit MUST be discarded. The maximum EF rate must be settable by the administrator. In practice: 1. Size the limit to the engineered voice load (calls multiplied by the per-call rate) plus headroom. 2. Excess EF is discarded, not queued behind other classes, so a voice overload damages voice rather than everything. 3. Police EF at the trust boundary too, so the core never receives more EF than planned (RFC 3246's security section asks domain edges to police EF to a negotiated rate). Implementations differ in whether the limit applies at all times or only while the interface is congested; the RFC's requirement is that a limit exists and that excess is discarded. ## The weighted classes Every other class receives a **minimum** share, not a maximum: - During congestion, each backlogged class gets at least its configured share. - Bandwidth a class is not using is available to classes that have traffic; RFC 2597 lets an AF class receive more than its minimum when resources are spare and leaves the sharing algorithm to the implementation. - Within a class, a drop policy decides what happens when its own queue fills: tail drop, or early random drop by drop precedence. ## A worked allocation For a 10 Mb/s link: | Class | Codepoint | Treatment | Rate | Share | |---|---|---|---|---| | Voice | EF | strict priority, policed | 1.5 Mb/s | 15 % | | Video calls | AF41 | guaranteed minimum | 3 Mb/s | 30 % | | Business data | AF21 | guaranteed minimum | 2 Mb/s | 20 % | | Signalling and routing | CS5, CS6 | guaranteed minimum | 0.5 Mb/s | 5 % | | Backups | AF11 | guaranteed minimum | 1 Mb/s | 10 % | | Everything else | DF | guaranteed minimum | 2 Mb/s | 20 % | The rows sum to 10 Mb/s and 100 %. When voice is quiet, its 1.5 Mb/s is used by the other classes; when voice offers more than 1.5 Mb/s, the excess voice is discarded rather than allowed to pre-empt everyone else.

  • Should interactive video share the voice priority queue?
    Usually not. Video packets are larger and burstier, so sharing one strict queue makes voice wait behind video frames and makes the priority limit hard to size. RFC 4594 maps conferencing video to AF41 with rate queuing, and notes that the Real-Time Interactive class MAY be configured as a second EF behaviour with relaxed parameters. Some designs therefore give video its own limited priority level or a generous guaranteed share.
  • What do you see on an interface whose priority queue limit is set too low?
    Drops counted against the priority queue's policer while other classes look healthy. Every call loses packets, because the limit cannot tell which call is the extra one, so users report choppy audio on all calls at busy hours. Fix the sizing from calls multiplied by per-call rate, and cap the number of calls with admission control.

saying these in an interview costs you the question

  • Putting voice in a large weighted queue gives the same result as a priority queue.
  • A priority queue needs no limit because voice traffic is small.
  • A class's guaranteed share is also the most bandwidth it can ever use.
  • Excess priority traffic should borrow bandwidth from the other classes.
  • Strict priority interrupts a large packet that is already being transmitted.