Max Limit Necessary for QOS?

Does a max limit need to be set to effectively prioritize traffic?

I am currently using:

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w parent="ether2[m1w]" priority=1
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_1 parent=qos_m1w priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_2 packet-mark=dscp.48 parent=qos_m1w priority=\
    2 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_3 packet-mark=dscp.46 parent=qos_m1w priority=\
    3 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_4 packet-mark=testing parent=qos_m1w priority=\
    4 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_5 parent=qos_m1w priority=5 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_6 parent=qos_m1w priority=6 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_7 parent=qos_m1w priority=7 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=qos_m1w_8 packet-mark=dscp.0,no-mark parent=qos_m1w \
    priority=8 queue=default



/ip firewall mangle
add action=mark-packet chain=postrouting comment="" disabled=no \
    new-packet-mark=testing passthrough=no protocol=icmp
add action=mark-packet chain=postrouting comment=dscp.0 disabled=no dscp=0 \
    new-packet-mark=dscp.0 passthrough=no
add action=mark-packet chain=postrouting comment=dscp.46 disabled=no dscp=\
    46 new-packet-mark=dscp.46 passthrough=no
add action=mark-packet chain=postrouting comment=dscp.48 disabled=no dscp=\
    48 new-packet-mark=dscp.48 passthrough=n

The ICMP rule is just for testing, but it doesn’t seem to be having any effect. My theory is that the router has no idea when to actually “queue” the traffic since it has no idea what the intermediary wireless link is running at in a setup like:
-------))))))))))))))))))----------

I originally thought that the router would detect when the bridge latency increased, but this does not seem to be the case.

Any ideas or anyone else trying to do QoS in this case? (on the routers)

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

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

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

Make a note that priority only works:

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

http://wiki.mikrotik.com/wiki/Manual:HTB

Ah, so unless I set the max-limit there is no way this will work; that was my suspicion. This creates a real issue with using priority because I don’t know what the wireless interface is at. Sure most of the time the bridge runs at 30mbps, but if there is inclement weather or something it may drop to 22mbps or something. So how can I set max-limit? What have you all done in the past to properly prioritize traffic?

Thanks!
-Eric

I’ve presented to my training course a similar problem about qos on wireless links..
Maybe you can adjust this accordingly to your needs :slight_smile:
QoS on Wireless Links.pdf (1.03 MB)