weighted fair queuing
/ WFQ /
Imagine several lines of people merging into one cashier. First-in-first-out serves them in pure arrival order — but then one huge group could hog the cashier for ages while a single shopper waits behind them. Strict priority always serves the VIP line first — but then the ordinary lines could starve completely. Weighted fair queuing is the sensible middle: it gives each line a guaranteed share of the cashier's time, in proportion to a weight you assign, so no line is starved and an aggressive line cannot steal more than its share.
Concretely, a WFQ scheduler keeps a separate queue per traffic class and serves them so that, over time, each class i receives a fraction of the link bandwidth equal to its weight w_i divided by the sum of all weights. If three classes have weights 3, 1, 1 on a 100 Mbps link, they are guaranteed roughly 60, 20, and 20 Mbps respectively. A key fairness property: if some class is not using its full share, WFQ is work-conserving — it lends the idle bandwidth to the active classes rather than leaving the link idle, then takes it back when the quiet class becomes busy again. So a class always gets at least its guaranteed minimum, and more when others are quiet.
Why it matters: WFQ (and its practical variants) is the scheduling discipline that makes class-based QoS actually deliver. It lets an operator promise, say, that real-time voice always gets enough of the link to stay smooth, without ever completely starving best-effort web traffic — combining the protection of priority with the fairness of round robin. A subtlety worth stating: WFQ controls how a link's capacity is shared among classes; it does not create capacity. On a link that is genuinely too small for the offered load, WFQ decides who suffers and by how much, but something still has to wait.
A 100 Mbps link serves voice, video, and bulk data with weights 2, 2, 1. Guaranteed shares are 40, 40, 20 Mbps. If video is momentarily idle, WFQ lends its 40 Mbps to voice and bulk data; the instant video resumes, it reclaims its guaranteed 40 — no class is ever starved.
Each class gets at least its weighted share, and idle bandwidth is lent out, not wasted.
Unlike strict priority, WFQ cannot starve a class — every class gets a guaranteed minimum. But it allocates existing capacity; it does not manufacture more, so on an undersized link some traffic still queues.