Choose a MikroTik Queue Model from the Bottleneck
A decision guide for selecting simple queues, queue trees and shaping boundaries in an ISP network.
A decision guide for selecting simple queues, queue trees and shaping boundaries in an ISP network.
The bottleneck chooses the design
Queue configuration should begin with the constrained resource, not with a preferred RouterOS feature. A subscriber access limit, a shared transit link and latency protection at a wireless backhaul are different control problems.
| Need | Starting model | Reason |
|---|---|---|
| Per-subscriber rate contract | simple queue or RADIUS-created queue | direct identity-to-limit mapping |
| Shared parent capacity | queue tree | explicit hierarchy and class allocation |
| Fairness among many similar users | PCQ within a defined boundary | dynamic sub-stream distribution |
| Latency under saturation | appropriate queue discipline at actual bottleneck | controls standing queue |
Simple queues optimize the subscriber workflow
Simple queues are readable when the operational unit is a customer target and a rate. They work well with automated provisioning, but large lists and overlapping targets require careful ordering and measurement. Fast-path features can also change which traffic reaches queue processing.
Queue trees optimize shared policy
A queue tree makes parent capacity and traffic classes explicit. It is useful when business, voice, management and best-effort traffic must share a known egress. Classification must be stable; marking every packet through complex rules can cost more CPU than the shaping benefit.
Avoid shaping the same packet twice
Draw the packet path through access, aggregation and edge routers. Assign one authority for the subscriber contract and one deliberate authority for each shared bottleneck. Duplicate limits create unexplained throughput ceilings and make support testing misleading.
- Locate congestion. Measure utilization, drops and latency.
- Name the policy. Contract cap, fairness, priority or protection.
- Select classification. Prefer identities that survive the relevant path.
- Budget capacity. Parent limits must reflect achievable throughput.
- Test under load. Validate latency, fairness and router CPU together.
Observe outcomes, not just configuration
Track queue drops, backlog, achieved rate, latency and CPU during a controlled saturation test. A queue showing traffic is not proof that it enforces the intended customer experience.
Research basis: RouterOS queue behavior and active queue management principles. Exact processing depends on RouterOS version, hardware offload and packet path.