← Operator library MikroTik Operations

Engineer a Queue Tree from a Capacity Contract

Translate a real shared-link constraint into a measurable RouterOS hierarchy.

What this note covers

Translate a real shared-link constraint into a measurable RouterOS hierarchy.

A hierarchy needs a physical meaning

A queue tree works when its parent represents a real constrained egress and each child expresses a deliberate sharing rule. Decorative hierarchies add CPU cost while hiding where congestion actually occurs.

Boundary

Name the interface and achievable directional capacity.

Class

Define traffic that deserves a distinct operational treatment.

Evidence

Measure delay, drops, throughput and CPU under controlled load.

Set the parent below achievable capacity

Shape slightly below the sustained bottleneck when an upstream device otherwise owns the queue. Use measured capacity, including protocol overhead and time-dependent wireless behavior, rather than the product label.

Upload and download often need different parents because they leave through different interfaces.

Classify as little as possible

Use packet marks only where address, interface or connection identity cannot express the policy. Keep marking rules ordered, documented and observable. Exclude management traffic deliberately instead of assuming it bypasses the tree.

Give priority a ceiling

Priority changes the order of service during contention; it does not create bandwidth. Pair guarantees and maximums with a parent budget that can be satisfied. Test starvation behavior when every child is active.

Validate customer experience

Run simultaneous flows through all classes. Confirm latency during saturation, fairness between subscribers and recovery after the load ends. Queue counters alone cannot prove success.

Operational caution: Hardware offload, FastTrack and packet-path changes can bypass expected processing. Confirm the exact RouterOS path before rollout.

Put it into operation

  1. Measure. Capture clean-link and saturated-link performance in both directions
  2. Model. Draw one parent for each genuine bottleneck
  3. Configure. Introduce the smallest hierarchy that expresses policy
  4. Load test. Exercise every class concurrently
  5. Observe. Alert on sustained drops, backlog and unexpected zero counters

Research basis: MikroTik RouterOS Queues documentation; IETF RFC 7567. Implementation details must be verified against the deployed release and local policy.

Continue with ISPbills

Put this guide into practice