This has very little to do with qos tags, which frankly don't work well for this use-case, even if everyone involved suddenly decided to support them. This is

This has very little to do with qos tags, which frankly don't work well for this use-case, even if everyone involved suddenly decided to support them. This is about how the router handles traffic flows when congested. The naive (and all too common) solution is to just lump all the traffic into a big buffer and push it through in fifo order. QoS algorithms like those used here tend to handle each stream individually, giving each an appropriate buffer and bandwidth. This means "thin" streams (voip) can have very low latency even when fat streams (80 people downloading the latest computer game) are eating all the bandwidth available and begging for more. The thin stream can easily get through the link and "should" be fast and low latency and drop no packets, it barely even needs a buffer, but the fat streams certainly do need a buffer, _must_ drop packets (that's the only way they know how fat they're allowed to be), and can accept higher latencies with no negative effects. fq-codel/cake try to handle the streams in a way that well behaving streams get a link that "feels" like everyone is behaving well, and greedy streams don't ruin that experience for everyone, only themselves. Even greedy streams benefit, since packets can be dropped earlier by smarter qos systems (rather than waiting until they're using the whole buffer), it can work out the optimal amount of buffer given the link speed, which is often not the same as an arbitrarily picked buffer size. Too little buffer and you lose throughput, too much and every packet sits waiting in a buffer for 200ms for no good reason.