Hi!

I have some questions about Microtik's QoS and I would appreciate your help. My collegue an I are
trying to implement class-based queuing for VoIP. Our intention is to implement something as close
as possible as CBWFQ (Class-Based Weighted Fair Queuing) with one LLQ (Low-Latency Queue).

As much as we understand Microtik's QoS, class-based queuing is implemented through
Queue Tree. It is possible to mark certain types of traffic with DSCP values and then put them in
some queues. Also, it's possible to guarantee each queue a certain amount of traffic in bytes or
packets, which is close to CBWFQ (CBWFQ can do this in percentages, but this is close enough),
and then put priority on each queue to give it aditional amount of traffic. Although this priority will
guarantee certain (additional) amount of traffic, this is not good enough because it will not solve
the delay problem. The algorithm here is (we think) WRR (Weighted Round Robin), which is ok for
normal traffic, but we want one queue to be LLQ, so that VoIP traffic is allways sent immediatley,
without waiting for algorithm to go through all the queues. Is this possible to do in MikroTik?

We thought of using Simple queue as our LLQ, since the router will always send from this
queue first, but this is problematic because Simple queue is a flow-based queue, and not a class-
based queue. This means that if we make a mangle in which we include our VoIP traffic, Simple
queue can use it only as a condition for matching packets and then putting it in a flow. We want the
router to be able to mark certain traffic himself (if it isn't already marked) with appropriate DSCP
value, and then to put it in a certain (LLQ) queue. If the packet already has DSCP value, we want it
simply to be put in that queue and sent as soon as possible. Simple queue can't do that, but only use
mangle as a condition. Is this true?

Thanks.

Simple queues do not rely on mangle, they can fire on other reasons. Mangle and its packet marks are just usually the best way to go. Mark packets with packet marks based on DSCP or other criteria, have queues that fire on the packet marks. Simple queues do not always fire first, queue trees that have global-in and global-out as their parents fire before simple queues. There is no true LLQ in RouterOS, and no option to "always send this traffic first".

Mark all VoIP packets and all other packets with different packet marks in /ip firewall mangle. Then add parent queue to outgoing interface in qtree. Attach to this parent queue to queues: one for VoIP and one for all another traffic. Do not shape traffic for parent queue and queue for VoIP but shape it for queue for all another in such way that during the maximum usage of bandwith it was minimal amount of traffic for VoIP (for example, if you have total bandwith 10Mbps and you need at least 3Mbps for VoIP then set max-limit for queue for all another traffic to 7Mbps). Also you can try to use limit-at in queue for VoIP for this purpose. Finally set priority for the queue for VoIP to 1 and the queue for all another left at 8.

i concur, create separate leaf for voip with limit-at just below max-limit and high priority. Use short pcq with rate limit slighty higher than codec's bitrate and port+ip classifier.

Guys, thanks for your response. Me and Ajla are especially thankful for Fewi's correcting our false beliefs about simple queues and queue trees...
Unfortunately, we really need some sort of LLQ mechanism, especially for bigger implementations. So, if anybody else has some idea how to implement this with MikroTik, please let us know.

Hi, guys!
Thanks for the help, especially to Fewi for the insight in simple queues and queue trees.
Regarding the queue arrangement that AlexN talks about, this is a good plan but won't solve our delay problem.
It's not enough, in our case, just to have guaranteed bandwidth (or limited bandwidth in non-VoIP queues),
because we need VoIP traffic to be sent immediately upon arrival at MikroTik, thus stopping whatever is sent at that time.
Basically, we need LLQ.
Fewi says that there is no LLQ in MikroTik; Ajla and me have the same impression.
If anyone else has an idea, please share...