Developinggap named

QoS & Traffic Control

Nikita Tarikin deploys MikroTik RouterOS traffic shaping in production with simple queues and Per-Connection Queue (PCQ) fairness; the deeper Hierarchical Token Bucket (HTB) queue-tree internals — bandwidth borrowing, priority classes, and the Stochastic Fairness Queuing (SFQ) and Random Early Detection (RED) disciplines — are studied to teaching depth and verified by the MikroTik Certified Traffic Control Engineer exam (MTCTCE), yet run thinner in production than in theory.

Simple queues and PCQ ship every day; the deep HTB queue-tree engine is mapped a step ahead of where it runs — the map below marks which is which.

3.6
Knowledge K̄: 2.7
Deployment Ē: 18
leaves mapped: 13
studied-ahead: 1
deployed-ahead

Verified by MTCNA 100%MTCTCE 86%

The map

Every QoS and traffic-control leaf the official MikroTik curriculum defines, plotted by what is known against what is deployed. Leaves on the diagonal are graded the same on both axes; leaves below it are the studied-ahead daylight, understood more deeply than they have yet been run. Here the shaping primitives — the simple-queue limits applied for every client — anchor the mastery corner, while the queue-discipline internals beneath them carry the gap.

Read left-to-right as knowledge, bottom-to-top as deployment. The cluster toward the upper-right is the deployed shaping base — simple-queue targets, the limit-at and max-limit pair, PCQ fairness, FIFO behaviour — run in production. The comb of drop-lines below it is the deep queue engine: HTB borrowing and priority, the SFQ and RED disciplines, and the Layer-2 switch-chip priority leaves — read closely, run thinly or not at all.

The topography

The full leaf-level ledger, grouped by topic — simple queues, the HTB engine, the queue-type disciplines, queue size and the queue tree, and the Layer-2 switch-chip QoS leaves. Each row carries its own two verdicts — what is known and what is deployed — and the field note that earned them, quoted verbatim from the assessment.

Leaf	Knowledge	Deployment	Field note
Modern AQM (CoDel / CAKE / fq_codel)		K̄ 3.0 · Ē 2.0 · 1 leaf · 1 split
Modern AQM (CoDel / CAKE / fq_codel)studied ahead	3Confident	2Aware	knows the bufferbloat/latency target; actively experimenting -- AHEAD of the MTCTCE syllabus (not in the classic curriculum)
Simple Queues		K̄ 4.0 · Ē 4.0 · 3 leaves
Target & Destination	5Teach	5Teach	target = shaped IP; upload=from it, download=to it.
Max-Limit & Limit-At	5Teach	5Teach	limit-at = guaranteed CIR; max-limit = ceiling when capacity free.
Burst	2Aware	2Aware	INVERTED: burst is allowed while the trailing AVERAGE stays below burst-threshold, not when the rate exceeds it
HTB (Hierarchical Token Bucket)		K̄ 5.0 · Ē 3.3 · 3 leaves · 3 splits
HTB Structurestudied ahead	5Teach	3Confident	HTB borrowing: a child exceeds limit-at only when the parent has spare (siblings below their limit-at), up to its max-limit ceiling. THEORY Teach; production leans simple-queues/PCQ over deep HTB trees (cf. v1).
Dual Limitationstudied ahead	5Teach	4Fluent	Dual limitation: limit-at (CIR) is always delivered even at full saturation; max-limit (MIR) only reachable when there's spare to borrow. This is everyday simple-queue mechanics he deploys.
Prioritystudied ahead	5Teach	3Confident	HTB priority governs the ORDER queues borrow spare bandwidth above limit-at — it does NOT touch the guaranteed limit-. Theory Teach; deploy-thinner on deep trees.
Queue Types		K̄ 3.3 · Ē 2.8 · 4 leaves · 3 splits
FIFO	5Teach	5Teach	pfifo = drop-tail (discards new arrivals when full); no fairness, one heavy flow can starve the others.
SFQ (Stochastic Fairness Queuing)studied ahead	3Confident	1Learning	never implemented; REASONED both correct by intuition (SFQ perturb=rehash interval, RED=avg-length early TCP signal) -- strong transfer, zero practice
RED (Random Early Detection)studied ahead	2Aware	1Learning	RED = 'no idea'. Niche queue-type, never studied/deployed — his stack is PCQ/FIFO/simple-queues.
PCQ (Per-Connection Queue)deployed ahead	3Confident	4Fluent	INVERTED: runs PCQ fairness in production; buffer-depth params fuzzy
Queue Size		K̄ 5.0 · Ē 4.0 · 1 leaf · 1 split
Queue Sizestudied ahead	5Teach	4Fluent	Oversized queue on a congested link = bufferbloat (packets sit in the deep buffer, latency/jitter rise even as throughput looks fine).
Queue Tree		K̄ 4.0 · Ē 2.0 · 1 leaf · 1 split
Queue Treestudied ahead	4Fluent	2Aware	pipeline architecture Fluent; queue-tree deployment thin
Layer-2 QoS		K̄ 2.6 · Ē 1.4 · 5 leaves · 5 splits
802.1p Prioritystudied ahead	2Aware	1Learning	Honest don't-know: 'no idea'. 802.1p = the 3-bit PCP in the 802.1Q VLAN tag; untagged frames carry no 802.1p. Part of the L2-QoS-priority edge ('never studied 802.1p').
RouterOS Bridge Filter Prioritystudied ahead	2Aware	1Learning	Honest don't-know: 'I never studied 802.1p'. (Local L2 classification = a bridge filter action=set-priority.) L2-QoS-priority edge.
CRS Priority Configstudied ahead	2Aware	1Learning	Correct BY ELIMINATION (PCP/DSCP→hardware egress queue, scheduled strict-priority/WRR) but admitted 'no idea, looks the only obvious option'. CRS QoS priority config not really known.
Traffic Shapingstudied ahead	2Aware	1Learning	Honest don't-know: 'no idea about L2 shaping' (shaping buffers+smooths vs policing drops). Part of the L2-QoS edge — his shaping knowledge is L3 (bufferbloat/HTB), not L2 switch-chip.
Bandwidth Limiting (Bridge Queues & Switch Chip)studied ahead	5Teach	3Confident	Correct: line-rate per-port limiting = switch-chip ASIC ingress/egress shaper (a simple queue would punt to CPU and lose offload). He knows L2 bandwidth-LIMITING (rate), distinct from the priority side.

The edges

The lead edge is the deep HTB queue tree. The borrowing rule, the dual-limitation guarantee, and the priority classes that order it are held to teaching depth — the theory graded at the ceiling — while production leans on simple queues and PCQ rather than hand-built queue-tree hierarchies, so deployment runs a notch behind the study. Beside it sit the queue disciplines reasoned correctly from first principles but never implemented — Stochastic Fairness Queuing, and Random Early Detection, which the assessment records as a flat blank — and the Layer-2 switch-chip priority leaves, where the recorded verdict is the owner's own note of never having studied them. On a single leaf the gap runs the other way: PCQ fairness is deployed a step ahead of its buffer-depth internals. Each gap is quoted below exactly as the assessment recorded it.

Knowledge ahead of deployment

Known deeper than it currently runs — named, not rounded over.

HTB Structureknow 5 Teach→run 3 Confident
HTB borrowing: a child exceeds limit-at only when the parent has spare (siblings below their limit-at), up to its max-limit ceiling. THEORY Teach; production leans simple-queues/PCQ over deep HTB trees (cf. v1).
Priorityknow 5 Teach→run 3 Confident
HTB priority governs the ORDER queues borrow spare bandwidth above limit-at — it does NOT touch the guaranteed limit-. Theory Teach; deploy-thinner on deep trees.
SFQ (Stochastic Fairness Queuing)know 3 Confident→run 1 Learning
never implemented; REASONED both correct by intuition (SFQ perturb=rehash interval, RED=avg-length early TCP signal) -- strong transfer, zero practice
Known
reasoned SFQ/RED both correct from theory
Run
never implemented
Queue Treeknow 4 Fluent→run 2 Aware
pipeline architecture Fluent; queue-tree deployment thin
Bandwidth Limiting (Bridge Queues & Switch Chip)know 5 Teach→run 3 Confident
Correct: line-rate per-port limiting = switch-chip ASIC ingress/egress shaper (a simple queue would punt to CPU and lose offload). He knows L2 bandwidth-LIMITING (rate), distinct from the priority side.
Modern AQM (CoDel / CAKE / fq_codel)know 3 Confident→run 2 Aware
knows the bufferbloat/latency target; actively experimenting -- AHEAD of the MTCTCE syllabus (not in the classic curriculum)
Known
knows bufferbloat/latency target — ahead of MTCTCE syllabus
Run
experimenting, not production
Dual Limitationknow 5 Teach→run 4 Fluent
Dual limitation: limit-at (CIR) is always delivered even at full saturation; max-limit (MIR) only reachable when there's spare to borrow. This is everyday simple-queue mechanics he deploys.
RED (Random Early Detection)know 2 Aware→run 1 Learning
RED = 'no idea'. Niche queue-type, never studied/deployed — his stack is PCQ/FIFO/simple-queues.
Queue Sizeknow 5 Teach→run 4 Fluent
Oversized queue on a congested link = bufferbloat (packets sit in the deep buffer, latency/jitter rise even as throughput looks fine).
802.1p Priorityknow 2 Aware→run 1 Learning
Honest don't-know: 'no idea'. 802.1p = the 3-bit PCP in the 802.1Q VLAN tag; untagged frames carry no 802.1p. Part of the L2-QoS-priority edge ('never studied 802.1p').
RouterOS Bridge Filter Priorityknow 2 Aware→run 1 Learning
Honest don't-know: 'I never studied 802.1p'. (Local L2 classification = a bridge filter action=set-priority.) L2-QoS-priority edge.
CRS Priority Configknow 2 Aware→run 1 Learning
Correct BY ELIMINATION (PCP/DSCP→hardware egress queue, scheduled strict-priority/WRR) but admitted 'no idea, looks the only obvious option'. CRS QoS priority config not really known.
Traffic Shapingknow 2 Aware→run 1 Learning
Honest don't-know: 'no idea about L2 shaping' (shaping buffers+smooths vs policing drops). Part of the L2-QoS edge — his shaping knowledge is L3 (bufferbloat/HTB), not L2 switch-chip.

Deployed ahead of the textbook

Run in production a notch beyond the studied internals — the rarer direction.

PCQ (Per-Connection Queue)know 3 Confident→run 4 Fluent
INVERTED: runs PCQ fairness in production; buffer-depth params fuzzy

The warrant

Third-party verification, in support of the depth above — not a substitute for it.

MTCNAVerified — 100%, Network Associate
MTCSWESwitching Engineer — in progress / not yet taken
MTCTCEVerified — 86%, Traffic Control Engineer

Traffic control shapes the packet-flow it shares. The honest neighbour:

The questions

Do you build deep HTB queue trees, or shape with simple queues?

The honest verdict: production shaping here is simple queues and PCQ; the deep HTB queue-tree hierarchies — multi-level parents and children, classified by mangle marks — I have studied and exam-passed (MTCTCE), but they run thinner in production than in theory. The distinction, publicly: both /queue simple and /queue tree are built on the same Hierarchical Token Bucket engine, but they behave differently. Simple queues have a strict order — a packet is tested against every rule top-to-bottom until one matches, first match wins — and one rule can cap upload and download together. A queue tree is not ordered: all traffic passes it at once, it classifies only on packet-marks from /ip firewall mangle, and it is the only way to attach a queue to a single interface. I reach for the queue tree when the policy genuinely needs per-class hierarchy; for per-client limits, a simple queue is the right tool, and that is what I run.

What traffic shaping is genuinely production-proven on RouterOS?

The everyday shaping layer: per-client simple queues and PCQ fairness, run daily. On a simple queue the target is the shaped address — upload is traffic from it, download is traffic to it — and the two limits do the work: limit-at is the committed rate the client always gets, max-limit is the ceiling it can reach when there is spare capacity. For shared links I lean on PCQ, which is the one leaf I deploy a step ahead of its own internals. The mechanism, publicly: a PCQ queue type uses a classifier — src-address per uploader, dst-address per downloader — to split traffic into per-IP sub-streams, and with pcq-rate=0 it simply divides the available bandwidth equally among them. That equal-share behaviour is the workhorse on a contended uplink; the FIFO and queue-size tuning underneath it I know in theory but rarely hand-tune.

How well do you actually know HTB priority and the queue disciplines?

Candour first: I can place HTB borrowing and priority cold, and I reasoned SFQ and RED correctly from theory — but I have never deployed either; my running stack is PCQ, FIFO and simple queues, and on RED my own assessment reads a flat blank. What I hold accurately: in HTB, priority (1..8, where 1 is highest and 8 lowest) governs only the order in which sibling queues are allowed to borrow spare bandwidth toward their max-limit. It never touches the guaranteed limit-at — the committed rate is delivered no matter what — and it only has meaning on leaf queues that actually carry a max-limit. The common myth is that priority reorders or guarantees traffic; it does neither. I can teach that distinction; building and tuning a deep multi-level tree against a live link is where my deployment thins out.

Can you tune a link against bufferbloat with the modern AQMs?

This is my active experimenting edge, ahead of the classic MTCTCE syllabus rather than behind it — I know the bufferbloat and latency-target problem and I am testing the modern algorithms, but I would not yet call them production-hardened in my hands. Publicly: an oversized queue on a congested link is bufferbloat — packets sit in a deep buffer and latency climbs even while throughput looks healthy — and RouterOS has shipped the modern answers since version 7.1: CoDel, FQ-CoDel and CAKE. FQ-CoDel pairs flow fairness with a delay target (default fq-codel-target=5ms) so a bulk transfer cannot bloat the buffer under a latency-sensitive flow; CAKE (Common Applications Kept Enhanced) folds fair queuing, CoDel-style delay control and integrated shaping into a single queue type. That is the part of this domain I am still moving from lab into production — and I will say so before I bill it.

Bring the traffic-shaping problem.

If it is per-client bandwidth limits, PCQ fairness, or a dual-WAN shaping policy on RouterOS, that is ground I run in production. If it needs a deep HTB queue-tree hierarchy or a switch-chip Layer-2 QoS build, I will tell you where it sits against my deployed edge — and lab it before I bill it — before the work starts.

Start the conversation