Bufferbloat is typically a disease of your ISP (which throttles traffic), not of your router. A Mikrotik in its default configuration, like most other routers, will do nothing to address – nor exacerbate – bufferbloat caused by ISP throttling.
However, it is fairly simple to address ISP bufferbloat using RouterOS's "simple queues". In the most basic configuration, just add a simple queue targeting your WAN interface, with bandwidth limits in each direction slightly (~5-10%) lower than what your ISP throttles you to. If you have a slower connection (<10 Mbps), select "default-small" as the queue type. That's it, bufferbloat solved. (You can get fancier with multiple queues or different queue types, but the above alone gives you 90% of the benefit.)
Not so - Bufferbloat can occur everywhere there's a bottleneck link.
Your home router's link to the ISP is likely to be one, and most don't have any mitigation, and suffer from high latency. (And various ISP's equipment has bufferbloat for data coming toward your home.)
Some sites suggest that you knock your bandwidth down to 70% of the link speed to "leave some headroom" for other packets. That's fine if you want to give away 30% of your capacity.
SQM (implemented through fq_codel or cake qdisc's) takes off a few percentage points from the rated link speed, and achieves great results with minimal setup and configuration. Check out https://www.bufferbloat.net/projects/bloat/wiki/What_to_do_a... for more info.
That is… exactly what I said? Bufferbloat occurs where there's congestion. That's generally on the ISP's router, since they're the ones throttling your connection to 10 Mbps or whatever.
Yes, if you have a gigabit fiber connection and your home router can only handle 50 Mbps, you can get bufferbloat on your home router. But most people aren't in that scenario.
SQM is great, but not available on RouterOS, which is what the GP was asking about.
Yes, but it can occur on both ends of the bottleneck. Your ISP's equipment has a bottleneck link toward your home, and can have bloated buffers on that side. But if your router doesn't handle the uplink well, it'll be bloated as well.
Fortunately, SQM is available (from LEDE) for many MikroTik routers, so there may be a way out for the GP.
That's not how the Internet works. If your ISP is throttling, both upstream and downstream traffic is buffered on its router.
This is a consequence of how congestion is signaled in IP networks: by dropping packets. If the ISP is the bottleneck (it almost always is, due to throttling in both directions), it signals this to upstream equipment (i.e. the source of the packets) by dropping packets. They aren't sent back to some random router to be queued up.
Bufferbloat comes in because the ISP is trying to make use experience a little less crappy by hanging on to bursts of packets which would otherwise be dropped, with the intent of forwarding them on at the throttled rate. The consumer's router does not do this because it has no way of knowing this is happening. (But see below.) This is fine, except ISPs make their buffers HUGE.
There are two ways around this: one is, as you suggested, to use fq_codel, which monitors flows to infer packet buffering or loss at the ISP. So then, it is able to avoid sending packets which would be buffered or dropped by the ISP. The other is, as I suggested, to make your router the one dropping and buffering packets, which it normally does NOT do. It has no reason to: the links to the modem and the client are typically much faster than what the ISP throttles to, and those links are all it can see. (Though it's not unlikely that the user has subscribed to a higher speed than their wireless can handle, in which case inbound traffic is queued on the router, NOT outbound traffic.)
Yes, if your router is underpowered and you have a high-speed connection through the ISP, then your router could become a bottleneck and show bufferbloat. That is almost never the case, and when it is, it can happen in both directions.
The GP has "a way out", it is exactly to perform the steps I indicated. fq-codel is nice to have but NOT necessary.
I'm sorry, but I have to disagree. The laws of physics (of the internet) dictate that the piece of equipment at a bottleneck is responsible for handling bloat/congestion on its own end. Your ISP's head end/DSLAM/etc. has an opportunity to prevent download bloat (with data being sent to the home), but it has no way to know what's happening on the consumer end of the link.
Your router at home needs to have the same logic: it needs to control the buffering of data being sent toward the ISP. fq_codel/cake actually measures the time packets dwell in the queues (their "sojourn time") and drops/marks with ECN some of the packets of flows that build up a queue.
A cool feature of fq_codel/cake qdisc in LEDE is that it can control bloat in both directions. It imposes a bottleneck that's slightly (a few percent) below the actual ISP download link speed so that traffic queues up within your home router (instead of at the DSLAM/head end). Consequently, it can do the fq_codel/cake algorithm on the download (as well as the upload) direction, keeping your link unbloated at a very small loss of link speed.
However, it is fairly simple to address ISP bufferbloat using RouterOS's "simple queues". In the most basic configuration, just add a simple queue targeting your WAN interface, with bandwidth limits in each direction slightly (~5-10%) lower than what your ISP throttles you to. If you have a slower connection (<10 Mbps), select "default-small" as the queue type. That's it, bufferbloat solved. (You can get fancier with multiple queues or different queue types, but the above alone gives you 90% of the benefit.)