Introduction

HTB (Hierarchical Token Bucket) is a classful queuing method that is useful for handling different kinds of traffic. We have to follow three basic steps to create HTB:

• Match and mark traffic – classify traffic for further use. Consists of one or more matching parameters to select packets for the specific class;
• Create rules (policy) to mark traffic – put specific traffic classes into specific queues and define the actions that are taken for each class;
• Attach a policy for specific interface(-s) – append policy for all interfaces (global-in, global-out, or global-total), for a specific interface, or for a specific parent queue;

HTB allows to create a hierarchical queue structure and determine relations between queues, like "parent-child" or "child-child".

As soon as the queue has at least one child it becomes an inner queue, all queues without children - are leaf queues. Leaf queues make actual traffic consumption, Inner queues are responsible only for traffic distribution. All leaf queues are treated on an equal basis.

In RouterOS, it is necessary to specify the parent option to assign a queue as a child to another queue.

Dual Limitation

Each queue in HTB has two rate limits:

• CIR (Committed Information Rate) – (limit-at in RouterOS) worst case scenario, the flow will get this amount of traffic no matter what (assuming we can actually send so much data);
• MIR (Maximal Information Rate) – (max-limit in RouterOS) best case scenario, a rate that flow can get up to if their queue's parent has spare bandwidth;

In other words, at first limit-at (CIR) of all queues will be satisfied, only then child queues will try to borrow the necessary data rate from their parents in order to reach their max-limit (MIR).

That is why, to ensure optimal (as designed) usage of the dual limitation feature, we suggest sticking to these rules:

• The Sum of committed rates of all children must be less or equal to the amount of traffic that is available to parents;

CIR(parent)* ≥ CIR(child1) +...+ CIR(childN)*in case if parent is main parent CIR(parent)=MIR(parent)

• The maximal rate of any child must be less or equal to the maximal rate of the parent

MIR (parent) ≥ MIR(child1) & MIR (parent) ≥ MIR(child2) & ... & MIR (parent) ≥ MIR(childN)

Queue colors in Winbox:

• 0% - 50% available traffic used - green
• 51% - 75% available traffic used - yellow
• 76% - 100% available traffic used - red

Priority

We already know that limit-at (CIR) to all queues will be given out no matter what.

Priority is responsible for the distribution of remaining parent queues traffic to child queues so that they are able to reach max-limit

The queue with higher priority will reach its max-limit before the queue with lower priority. 8 is the lowest priority, and 1 is the highest.

Make a note that priority only works:

• for leaf queues - priority in the inner queue has no meaning.
• if max-limit is specified (not 0)

Examples

In this section, we will analyze HTB in action. To do that we will take one HTB structure and will try to cover all the possible situations and features, by changing the amount of incoming traffic that HTB has to recycle. and changing some options.

Structure

Our HTB structure will consist of 5 queues:

• Queue01 inner queue with two children - Queue02 and Queue03
• Queue02 inner queue with two children - Queue04 and Queue05
• Queue03 leaf queue
• Queue04 leaf queue
• Queue05 leaf queue

Queue03, Queue04, and Queue05 are clients who require 10Mbps all the time Outgoing interface is able to handle 10Mbps of traffic.

Example 1: Usual case

• Queue01 limit-at=0Mbps max-limit=10Mbps
• Queue02 limit-at=4Mbps max-limit=10Mbps
• Queue03 limit-at=6Mbps max-limit=10Mbps priority=1
• Queue04 limit-at=2Mbps max-limit=10Mbps priority=3
• Queue05 limit-at=2Mbps max-limit=10Mbps priority=5

Result of Example 1

• Queue03 will receive 6Mbps
• Queue04 will receive 2Mbps
• Queue05 will receive 2Mbps
• Clarification: HTB was built in a way, that, by satisfying all limit-ats, the main queue no longer has throughput to distribute.

Example 2: Usual case with max-limit

• Queue01 limit-at=0Mbps max-limit=10Mbps
• Queue02 limit-at=4Mbps max-limit=10Mbps
• Queue03 limit-at=2Mbps max-limit=10Mbps priority=3
• Queue04 limit-at=2Mbps max-limit=10Mbps priority=1
• Queue05 limit-at=2Mbps max-limit=10Mbps priority=5

Result of Example 2

• Queue03 will receive 2Mbps
• Queue04 will receive 6Mbps
• Queue05 will receive 2Mbps
• Clarification: After satisfying all limit-ats HTB will give throughput to queue with the highest priority.

Example 3: Inner queue limit-at

• Queue01 limit-at=0Mbps max-limit=10Mbps
• Queue02 limit-at=8Mbps max-limit=10Mbps
• Queue03 limit-at=2Mbps max-limit=10Mbps priority=1
• Queue04 limit-at=2Mbps max-limit=10Mbps priority=3
• Queue05 limit-at=2Mbps max-limit=10Mbps priority=5

Result of Example 3

• Queue03 will receive 2Mbps
• Queue04 will receive 6Mbps
• Queue05 will receive 2Mbps
• Clarification: After satisfying all limit-ats HTB will give throughput to queue with the highest priority. But in this case, inner queue Queue02 had limit-at specified, by doing so, it reserved 8Mbps of throughput for queues Queue04 and Queue05. Of these two Queue04 have the highest priority, that is why it gets additional throughput.

Example 4: Leaf queue limit-at

• Queue01 limit-at=0Mbps max-limit=10Mbps
• Queue02 limit-at=4Mbps max-limit=10Mbps
• Queue03 limit-at=6Mbps max-limit=10Mbps priority=1
• Queue04 limit-at=2Mbps max-limit=10Mbps priority=3
• Queue05 limit-at=12Mbps max-limit=15Mbps priority=5

Result of Example 4

• Queue03 will receive ~3Mbps
• Queue04 will receive ~1Mbps
• Queue05 will receive ~6Mbps
• Clarification: Only by satisfying all limit-ats HTB was forced to allocate 20Mbps - 6Mbps to Queue03, 2Mbps to Queue04, and 12Mbps to Queue05, but our output interface is able to handle 10Mbps. As the output interface queue is usually FIFO throughput allocation will keep the ratio 6:2:12 or 3:1:6