Why don’t you use “PCQ” instead of the default queue?
Could you create a rule that would reduce the priority for a large number of connections for applications like windows update?
Why is “SFQ” better for download than “PCQ”?
Thank you so much for this!
I have 940mbps/35mbps cable using a RB4011 router. When applying the optimized QOS, I see better results at dslreport’s bufferbloat test, but my overall throughput is much lower, around 500mbps. Is there a way to have QOS and still have close to line speeds with this model?
Thank you again!
I second this question. I have similar problems. Would it be similar with QOS?
Nice thread. 
I have not read all in detail yet, but there are on thing I do miss or not understand.
Do you need to mark the connection before mark the packet? Yes/No/Why?
Please add some words about this in your second post where you talk about marking.
phpBB that this forum is based on do support private message user/user user/admin etc, but for some reason MikroTik has turned this function off. It would be nice to have it one, since there are times you like to exchange private information that are not for all to read.
Before @pcunite addresses that, a quick answer:
Connection marking is a way to give all packets of the same “connection” (a TCP session, or a bi-directional UDP stream) the same treatment without need to analyse all the selection criteria for each individual packet. So usually the processing of the initial packet of a new connection results in choosing a treatment for the whole connection, and all connections whose packets should be treated that way are labeled with the same connection mark. Whenever a packet arrives to the firewall, the connection tracking module matches it to the list of existing connections, and if it finds a match, the connection mark is retrieved from the connection context (along with e.g. the eventual NAT treatment which is, however, applied directly by the connection tracking module) and attached as a metafield to the packet, so that further layers of the firewall (and queueing) can refer to it instead of re-evaluating all the other conditions again. Routing cannot refer to connection-mark directly but needs a routing-mark, so a rule must be used to translate the former into the latter for each packet; queues need a packet-mark so a translation rule is needed too. NAT rules can refer directly to connection-mark because they’re an organic part of the firewall; routing and queueing are not. A connection mark may be changed during the lifetime of the connection, but each connection may only bear a single connection mark at any given time, so policy routing along with queueing is a bit complex, yet doable. The change of connection mark in context of QoS is useful to de-prioritize large downloads to allow quick response for small-volume exchanges.
How to use RouterOS to accomplish a task vs. how RouterOS itself works are two different concepts. I only focus on the former. However, everyone is welcome to discuss. The examples show what you need to do in order to facilitate QoS.
I am trying to learning, so bear with me.
I could mark the HTTP packets directly by setting TCP and port 80 and select mark packet, without marking connection?
Yes, that would work too. The only drawback is that matching two items (protocol & port) takes more CPU than matching just one (connection mark), and if you start thinking about discrimination between several categories of http connections, so you start matching e.g. address lists, the amount of CPU power spent on handling every single packet in the firewall grows even higher.
Thanks for the explanation, some clearer now 
I’ve have tested your feedback and have made changes to the original post to include bucket-size recommendations, which indeed was helpful. However, I do find SFQ to be situational dependent. Yes, it drops very quickly and responds well to speed tests, but it does not handle global synchronization well, which is a real problem in the wild. Thus, I still show the recommendation for using RED, howbeit, as you did for all queues, which is a cleaner config example. There is still tweaking here to do. More testing is needed under real workloads.
@pcunite
No worries. I’ll see if I can rerun the test graphs with the updated baseline when office reopens.
@pcunite
Thanks for the hard work.
I’ve seen some weird packet issues when using RED for the defaults. So, I’ve gone back to SFQ for default but use RED for the bulky flows. The behavior of RED as default causes the VoIP queue to drop a single packet here and there when it does not appear to be under pressure. Perhaps there is something else going on, but I never want a packet to drop there, so SFQ (or probably any other type) prevents that behavior.
Guys, can anyone share QOS configuration which prioritizes gaming, browsing and some other important packets over downloads/uploads and video traffics, please?
Does it make sense to use RED for VPN queue running on UDP only? the congestion methods mentioned all seem to apply to TCP exclusively, but in the guide it’s mentioned that it can be applied to QUIC which uses UDP so I gues this means it’s fine to use it on UDP VPN?
TCP and QUIC are stream protocols - as in you have a large amount of data and you will send multiple packets to transfer it. What the connection methods do is to drop some packets as a signal that the stream should slow down. So we are using RED for example to say ‘speed up’ or ‘slow down’. TCP and QUIC have built in mechanisms to resend lost data so it doesn’t cause much issue to drop data.
UDP is just a packet format. Depending on the application it will behave differently. Some applications don’t have and contention management so dropping packets doesn’t cause it to slow down (it actually speeds up because it has to send everything twice). For example VoIP and gaming is usually a fixed rate, and if you drop a packet it causes stuttering or lag. BitTorrent is also UDP, but uses dropped packets to slow the stream down.
So the simple answer is - the router doesn’t care if it is TCP or UDP. All TCP connections can be slowed by dropping packets. Some UDP can be slowed, some UDP you don’t want to drop packets. It is based on the application though, and not anything to do with UDP.
@bharrisau, @pcunite and to all experts out there
Is it recommended to use 2 QOS servers, 1 is for the 2020 QOS-Optimized server (as main bandwidth management) and the other one is for the microCAKE and this will be running inside PPPoE/ Hotspot server?
@bharrisau I’m using your QOS2020 Optimized script and it’s working awesome but on my home network I have two bridges, one for the main network and the other for a guest wifi, how should I proceed?
I have an BIG doubt…My network is distributed, I have dozens of MK routers with OSPF on network and on each site I have an OLT and one Router that is PPPoE server.
I have too two places that arrive Internet(with two or more Carrier Link), on each place I have an MK to control this links.
So, where I should use the QOS? in all routers, In PPPoE servers or in Last router (link control).
Thanks a lot!
Very good work!