Is Double QoS only a Myth?

Suppose you have 5 clients dedicated 1MB. Our ISP can guarantee that bandwidth. You want to prioritize icmp traffic when a client is saturating his dedicated 1MB.

The setup is very simple and is the following:

/ip firewall address-list
add address=201.110.115.236 disabled=no list=prueba
add address=201.110.115.234 disabled=no list=prueba
add address=201.110.115.235 disabled=no list=prueba
add address=201.110.115.238 disabled=no list=prueba
add address=201.110.115.237 disabled=no list=prueba

/ip firewall mangle
add action=mark-connection chain=forward comment=Conexiones disabled=no \
    new-connection-mark=conexion passthrough=yes src-address-list=prueba
add action=mark-packet chain=forward connection-mark=conexion disabled=no \
    new-packet-mark=trafico passthrough=yes
add action=mark-packet chain=prerouting comment=QoS disabled=no \
    new-packet-mark=icmp passthrough=no protocol=icmp
add action=mark-packet chain=prerouting disabled=no new-packet-mark="no imcp" \
    passthrough=no protocol=!icmp

/queue type
add kind=pcq name=UP pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=\
    10s pcq-classifier=src-address pcq-dst-address-mask=32 \
    pcq-dst-address6-mask=128 pcq-limit=50 pcq-rate=1M pcq-src-address-mask=\
    32 pcq-src-address6-mask=128 pcq-total-limit=2000
add kind=pcq name=DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=\
    10s pcq-classifier=dst-address pcq-dst-address-mask=32 \
    pcq-dst-address6-mask=128 pcq-limit=50 pcq-rate=1M pcq-src-address-mask=\
    32 pcq-src-address6-mask=128 pcq-total-limit=2000

/queue tree

add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name="Total Download" parent=local priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name="Total Upload" parent=public priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=5M name=global packet-mark="" parent=global-in priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=Download packet-mark=trafico parent="Total Download" \
    priority=8 queue=DW
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=Upload packet-mark=trafico parent="Total Upload" \
    priority=8 queue=UP
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name=ping packet-mark=icmp parent=global priority=1 queue=\
    default-small
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
    max-limit=0 name="otro trafico" packet-mark="no imcp" parent=global \
    priority=8 queue=default-small

The problem with this configuration (based on MikroTik RouterOS Workshop
QoS Best Practice of Prague MUM 09) is that the prioritization of traffic only occurs if the total bandwidth reaches 5 MB available. However if I have a single client online saturating their connection to 1MB and would prioritize traffic icmp or otherwise, simply does not work.

I tried configuring with “limit-at” the icmp traffic to ensure a minimum, but still does not work.

Is Double QoS only a Myth?

There not documents or official examples to do it.

You are not specifying all the values that are required for priority to work. Priority in HTB isn’t strict priority (like LLQ, for example) - it just defines which queues get filled when there is contention.

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#Priority

Everyone gets limit-at, then the higher priority queue gets to max-limit before lower priority queues do.

you have to limit them, there is some guides, if you want better guides on this Google Traffic Shapping Mirotik, there is also a good youtube vid explaining it nicely, it seems your problem there is related to not having limit at set to a value, even if the value is higher than the 1mb/s.

Do u want to absolute limit, AKA each user can only get 1MB/s or Share the Bandwidth, letting a user burst into another users ques if the other user is not using it?

Its all trafic shaping.

In the example its configured max-limit, and prioritazition works only when all clients are having 1MB. Limit-at is only to guarantee, its not necesary.

I want priorize icmp traffic when a client reachs 1mb/s. Each client cannot have more than 1mb.

In what you posted there is no max-limit configured on any queue that is a leaf queue. There is one queue with a max-limit: “global”. That queue has children (“ping” and “otro trafico”), which makes “global” an inner queue. As the quoted section from the manual states priority doesn’t work on inner queues, it only works on leaf queues.



Make a note that priority only works:

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

The document says that priority dont work on inner queues. Not MIR (max-limit). All examples on that documents have a inner queue with max limit. Because priority works when a inner queue reachs max limit value.

But thats not the point. I set max limit for my inners queues for traffic icmp and not icmp at 5MB. Priorizing traffic dont works with less of 5MB of bandwidth.

Thanks for the data, Mikrotik cannot priorize traffic like a isp needs yet.

take a look to: http://wiki.mikrotik.com/index.php?title=MikroTik_RouterOS/Feature_Requests&redirect=no

where says:

Implement LLQ (Low Latency Queuing). Important for giving priority to one type of traffic over another, not just reserving bandwidth for each type. Especially important for growing number of VoIP implementations around the world.

It would be great that a mikrotik staff tell us when this will be implemented.

Sorry, but from what i have read about LLQ i can’t see any obvious benefits over HTB in this particular setup (and in general)
Maybe someone can give a practical example with highlighting benefits of the feature before asking for its implementation.

LLQ is very simple. Is a packet marked for LLQ ready transmit? Send it now. Regardless of bandwidth, regardless of any other consideration. On circuits that change the abilable bandwidth either due to physical reasons (wireless links) or dictated by providers (CIR and burst differ wildly) this makes prioritizing a few protocols such as VoIP very, very simple. It also reduces jitter introduced at least on that node since the processing time is theoretically the same always, and the packet does not hang around in buffers.