QoS is not about faster internet. It is about who waits when the line is full. As long as there is room to spare, a queue does nothing. The moment someone starts a large upload, the queue decides whether your video call notices or not.
Where it lives
In advanced mode it is the QoS / bandwidth section, off by default. In the wizard you can switch it on as an extra ("Bandwidth (QoS)"); you then see only the method and the two speeds, and the rest stays in advanced.
The speeds first, and slightly low
You enter Download and Upload in Mbit/s. Do not enter what your contract says, but roughly 90 to 95 percent of what you actually measure. That sounds like throwing bandwidth away, and it is the heart of the whole thing: a queue only works while it is the thing doing the braking. Set the limit at or above the real line speed and the jam forms in your provider's modem instead, where your router has no say. That is exactly why a connection with "plenty of bandwidth" can still stutter during a call.
The four methods
- Off
- No queues. Nothing is generated.
- Total limit
- One simple queue for the whole LAN with a maximum up and down. Useful when you want to cap a line, for instance because you share it. Nothing is shared out and nothing is favoured.
- Fair share per host
- The default choice, and the right one for most networks. Every host gets roughly an equal share and latency stays low even with the line full. You pick the algorithm: CAKE (recommended, RouterOS 7.1 and up), fq_codel, or PCQ (classic, with an optional maximum per host).
- Priorities
- A queue tree with three classes, so voice and interactive traffic go before downloads. This is the heaviest option and the only one that needs mangle rules.
Fair sharing
For CAKE the tool creates two queue types, one per direction, with diffserv4, per-host fairness (dual-dsthost downward, dual-srchost upward) and cake-nat=yes, because behind NAT the router would otherwise only see its own address. The upload side also gets an ACK filter, since that direction is usually the narrow one. Then comes one simple queue on the LAN with your limit.
fq_codel does broadly the same with fewer knobs. PCQ shares per host by source or destination address, with an optional per-host maximum.
What this fixes is bufferbloat: that second of delay that appears the moment someone starts downloading. The difference is directly measurable.
Priorities with a queue tree
Here traffic is first identified and then treated. Three switches decide what gets priority:
- VoIP and video: DSCP EF and AF41, SIP on UDP 5060 and 5061, and small UDP packets in the RTP port range.
- Small UDP packets, for gaming.
- DNS, ICMP and ACK.
Classification happens once per connection, not per packet: the first packet gets a connection mark and every later packet is handled with a single comparison. After that there are two trees, download on the LAN and upload on the first WAN interface, each with three branches: voice at priority 1, interactive at 2 and the rest at 8. Every branch has a guaranteed minimum and may borrow up to the full line rate.
Two things to know. The upload tree hangs off the first WAN interface; with two uplinks the second one is not shaped, and the tool says so. And on the older MIPS routers (hAP ac, hEX and relatives) this shapes in software with a ceiling somewhere around 200 to 300 Mbit/s. Enter a higher speed there and the tool warns you and suggests fair sharing instead.
Limits per host
At the bottom is a table where you set a maximum up and down per host or network, with a priority from 1 to 8. This works alongside whichever method you chose. Use it for the backup server that should not fill the line in the afternoon, or for a guest network with a ceiling. Each row becomes a simple queue named after the address.
Fasttrack goes off
This is the important side effect. Fasttrack sends existing connections past the firewall and past the queues. That is exactly what you want for throughput, and exactly what makes QoS impossible: a fasttracked packet never reaches a queue. So the firewall switches fasttrack off automatically as soon as QoS is active, leaving a line in the script that explains why it was omitted. The tool warns about it, because on small routers this costs throughput. The same trade-off applies to PCC load balancing. See Firewall and NAT.
What QoS cannot do
- Empty a congested uplink. You share out scarcity differently, you do not make it smaller. If four people are on video calls over 10 Mbit of upload, no queue will save you.
- Really steer the download. Download traffic has already crossed your line before your router sees it. You can slow it down so the sender holds back, which works surprisingly well, but it stays indirect. Upload you control fully, download only halfway.
- Fix congestion at your provider. If the knot is inside your ISP's network or somewhere out on the internet, your router changes nothing about it. A line that only stutters in the evening while your own graphs are empty is a conversation with your provider, not a QoS problem.
- Enforce DSCP outside your network. Markings you send along are often ignored or wiped on the way.
Measure before and after
Run a bufferbloat test with the line idle, and the same test with a large upload running. The difference in latency between those two is what you are repairing. On the device, /queue simple print stats shows whether traffic is actually going through your queue, and /system resource print whether the CPU is keeping up.
Read on
Recipe: keep calls clear for a worked example, Firewall and NAT for fasttrack, and Several uplinks if you have two lines.