Simple Queues - prioritize not working

RouterOS Beginner Basics
1

Hello,
i have a DSL Line with Donwload Bandwidth of ~11M.

Now i try to prioritze the traffic of some networks over another. Goal is that prioritize networks get full speed of 11M and other gets 0M until some bandwidth are left.

I configure 3 queues, one as parent the other two as children to match the traffic and set the priority.
The traffic match and i see that the queues are hit. But the traffic is not prioritize over the other.. it seems they share the bandwith :frowning:

Here is the configuration of the queues :

/queue simple
add max-limit=4M/11M name=q1.parent priority=1/1 queue=default/default target=\
    vlan1111-dsl-bond2-int
add limit-at=4M/11M max-limit=4M/11M name=q1.prio2 parent=q1.parent priority=\
    2/2 queue=default/default target=\
    192.168.10.0/24,192.168.11.0/24,192.168.33.0/24
add limit-at=64k/64k max-limit=4M/11M name=q1.prio3 parent=q1.parent priority=\
    3/3 queue=default/default target=192.168.60.0/24

May be somebody could help me ?

Thank you in advance
Regards
Marcus

2

I don't think Simple Queue alone works well for QOS for VoIP.

QOS for VoIP basically involves two simple steps.

First, identify and mark the intended traffic for prioritisation; Secondly, set the priority specification.

Here is a basic example:

  1. Identify & Mark traffic

/ip firewall mangle add action=mark-packet chain=forward comment="mark voice packets"
protocol=udp dst-address="10.10.1.50" disabled=no new-packet-mark=voip-mark passthrough=no
/ip firewall mangle add action=mark-packet chain=forward comment="mark voice packets"
protocol=udp src-address="10.10.1.50" disabled=no new-packet-mark=voip-mark passthrough=no

/ip firewall mangle add action=mark-packet chain=forward comment="mark video streaming packets"
protocol=tcp dst-address-list="MedStreamDevices" disabled=no new-packet-mark=mediastreaming-mark passthrough=no
/ip firewall mangle add action=mark-packet chain=forward comment="mark video streaming packets"
protocol=tcp src-address-list="MedStreamDevices" disabled=no new-packet-mark=mediastreaming-mark passthrough=no

(The first two scripts above assume 10.10.1.50 as VoIP host address. They mark both VoIP packets coming to/from 10.10.1.50.
The last two scripts mark video streaming packets pulled from the NAS by various media-playing hosts included in MedStreamDevices as defined under the Address List. Included here to amplify the settings of prioritization).

  1. Prioritize

/queue tree
add limit-at=64k max-limit=64k name="1. Siemens_q" packet-mark=VoIP-mark
parent=ether6-Siemens priority=2
add limit-at=64k max-limit=64k name=2.Sipura_q packet-mark=VoIP-mark
parent=ether7-Sipura priority=3
add name="3.Minix box" packet-mark=Streaming-mark parent=bonding1 priority=4

(I have two VoIP phones connected at ether6 and ether7. Both have defined limits. No limit is applied to media streaming however). The above queue settings are not the most efficient as bandwidth is automatically set aside for VoIP. But at a basic level, it should work. Cheers.

3

By any chance, is this because Simple Queue doesn’t disable fast-path?

  1. Prioritize
    /queue tree
    add limit-at=64k max-limit=64k name=“1. Siemens_q” packet-mark=VoIP-mark
    parent=ether6-Siemens priority=2
    …

In order to apply this to a wireless link that is using dynamic-mesh WDS, what should we set for the parent interface?

4

My firewall has other priority specs (specifications) including VoIP-related and acceptance of established and related connections. This tends to produce conflicts such as hits and misses with specs configured under Simple Queue. Fast Track neutralises these priorities so I don’t use it. Not specifically sure about Fast-Path.

Borrowing an analogy. Fast-tracking a queue for a large crowd at the gate of a music festival does not quite work out logistically, if you have i) different classes of tickets, and ii) ticket holders are shown where to be on the ground (based on their ticket class). I’d say however that if firewall settings have nothing else in it but only VoIP-related priority configured in ‘Simple Queue’, it would probably work fine. This would be, I think, an underutilized deployment of MikoTik router capability.

As for wireless link, I am not using dynamic mesh WDS, I don’t know the answer to your question. For my network situation, however, I set the maximum for the parent queue at 95% of my SIP’s bandwidth allowance. I am not sure in a mesh scenario, you may want to set it even a bit lower than 95% to allow for higher overheads.

Cheers
(I am not a guru but a keen learner and I like MikroTik’s features).

5

I get that. We aren’t using fast-track, and we are trying to confirm that fast-path is disabled because fast-path bypasses queuing.

As for wireless link, I am not using dynamic mesh WDS, I don’t know the answer to your question. For my network situation, however, I set the maximum for the parent queue at 95% of my SIP’s bandwidth allowance. I am not sure in a mesh scenario, you may want to set it even a bit lower than 95% to allow for higher overheads.

We aren’t anywhere near capacity. Drop-outs get bad when the link is carrying as little as 2Mbps of traffic, on a link that negotiates solidly above 100+ Mbps. It’s as though traffic going out the wireless link isn’t getting prioritized at all.

6

I am not using Fast-Path (IP/Settings/Allow Fast pat) in case you still need an answer. I’d imagine you could have turned it off and see how the quality of VoIP calls is under that scenario.

Failing that, I suspect the unavoidable latency from inside a dynamic mesh may work again the desirable (i.e. uninterrupted streaming) quality of VoIP calls. If there is a way to compensate or even overcome the resulting latency (i.e. from mesh), I don’t know. I may be far off the track here, however.

Good luck.
(Sorry for the late reply).

7

I meant the mesh may work against the desirable …

(Sorry for being sloppy).