I need something that both myself and a support tech can understand. A very common config we run into is a bridged DSL connection (no PPPoE) where the customer needs an actual router that we can maintain as a dmarc. We've been buying lots of RB750s for the slower connections and are mostly happy with them.

We're finding more and more people want VoIP, and on the bonded DSL connections, this is workable since we have 2Mb/s upload (for the US, this is a decent speed for a soho office or the like). It is slow enough that phones and things like Dropbox compete for that limited upload and the phones then tend to suffer.

We give the phones static DHCP assignments at one end of the LAN block and everything else gets IPs out of a pool at the beginning of the block. This, I hope, simplifies things - rather than trying to match SIP and RTP ports and always-changing RTP endpoint IPs, I can just match on a subnet.

All I want to do is give the phones priority. After reading up on "simple queues", I tried this:
It's after hours, so I don't know if it's working since no one is in that office. But am I on the right track?

192.168.1.0/25 is everything that's not a phone.
192.168.1.192/26 has only phones.

Available upload is about 1.9Mb/s. I don't necessarily want to limit as I want to prioritize. Should this work?

Also on the RB750, if I want to apply an interface-based rule, what interface encompasses the entire switch? Is it ether2-master or do I enable the firewall on the bridge interface and refer to that in any interface-based QoS rules (and where does one find that sort of model-specific info)?

You don't have a parent queue so priority will not do anything.

You don't have a parent queue so priority will not do anything.

OK, so if I add a parent queue, I'm not going to classify based on IP, so I need a target interface. On the RB750 would that be the bridge interface or one of the physical switch ports?

If my parent queue is say, 1800kb/s, what do my two child queues look like if I'm less worried about a hard bandwidth cap than I am about priority?

I have something in place now on bridge1, and it seems to be working (I'm at least seeing traffic counters increment).

The parent is set on the interface facing your client devices. On the parent queue you set your maximum available bandwith or below it, but close to max.
After that in the child queues you set that parent and in them you can set ip addresses. You can set after that every single queue to use the max bandwidth with the 'Max Limit' parameter, but with 'Priority' and 'Limit at' parameters you can choose which one can take more.
The 'Limit at' parameter is interesting, because it defines the minimum guaranteed speed given to a queue.
But maybe example is easier to see :
First rule here sets maximum available bandwidth for the interface at 20Mbit. After that we have two other rules. One for ip 192.168.1.2 and one for the entire network. Both of them can get the entire bandwidth if it is available, but if they both compete for it 192.168.1.2 will get at least 10Mbit. If both have the same 'limit-at' then priority will also play a part in who gets his packets server first.

Your original setup would work if you set both to use the max-limit = full internet bandwidth available, and limit-at to some reasonable minimum guarantee.

As long as a queue is below the limit-at amount, it is guaranteed to receive bandwidth (assuming your queues' guarantees don't total more than the actual interface bandwidth). So even though one queue does not have "priority" - it will get a guaranteed access to the wire, which is what you really want. I don't think Mikrotik does LLQ for its de-queueing mechanism anyway, so priority doesn't mean which packets get forwarded first - it means which queues get filled first.

Thank you both so much, that really clarifies things for me. If this works, it will be my go-to QoS setup, as it's really simple to explain, and I don't really see putting the phones in their own dhcp scope as a real big pain compared to a more complex QoS config.

I'm having a hard time validating this, because as luck would have the underlying bonded DSL circuits are currently a mess, so no matter what I do they're having problems. Once Verizon un-f*cks the copper, I'll get a chance to see if this is going to solve their issues or not.