The complaint, as ever, was "the internet's gone weird again", which translated to: someone's on a video call, two people are streaming, something's downloading in the background, and the call has turned into a slideshow. Plenty of downstream bandwidth, so on paper nothing was wrong. The problem was never bandwidth. It was a fat download filling the upstream buffer and adding a couple of hundred milliseconds of latency to every packet, the call included. Classic bufferbloat.
I spent an evening years ago trying to fix this with hand-written QoS rules, classifying traffic by port and marking the video call as high priority. It was miserable. Half the things you want to prioritise don't sit on predictable ports any more, everything's just HTTPS over 443, and the rules rotted the moment an app changed.
The thing that actually fixed it was a smart queue: CAKE on the router, told the honest truth about my line speed. The trick is to set the shaper a touch below your real upstream rate so the queue lives in the router, where it can be managed, rather than in the modem, where it can't. Mine looks roughly like this:
tc qdisc add dev wan root cake bandwidth 18mbit nat dual-srchost
That's it. No per-application rules, no port lists to maintain. CAKE keeps each flow's latency low by refusing to let any one of them hog the queue, so the download still gets the bandwidth nobody else is using, but the instant the call needs a packet through, it gets one. The bufferbloat test went from a couple of hundred milliseconds of added latency under load down to single digits, and the "internet's gone weird" complaints stopped. The lesson I keep relearning: don't classify traffic by hand, just stop the buffer from filling and let the queue sort itself out.