Based on that type of usage, yes I agree. However, for one client QoS locally would likely be just as effective. OP's router may not even support SQM.
I mean, you are always at the mercy of the ISP's bandwidth policer. There is no escaping that policer - all you can do is not hit it.
Yeah, not hitting it is exactly what SQM is for!
What do you mean by 'QoS locally'? Running a plain queue discipline (e.g. fq_codel) and/or congestion control algorithm (e.g. cubic, reno, bbr) on the interface of a device without a shaper is ineffective on its own. It will sense congestion via packets dropped upstream, and crash/seesaw your transfer speeds in response, but it will never control the link or provide real benefit. Unshaped fq_codel is still slightly smarter than FIFO, but without a shaper active (AQM/SQM) it will never activate in the meaningful way we're discussing here.
If you meant to run fq_codel or similar
with a shaper then we're still back to what is effectively AQM/SQM, just not CAKE. You don't really want to make a single device the bottleneck on your link (I'm assuming on-device is what you meany by 'locally'), that job should always be the place of the edge router. If your router isn't capable of SQM or at least AQM, it's time to upgrade!
As for the single-user argument: Even with a single person in a home, it's highly unlikely these days that they have only one device connected to the Internet. There's the PC, smart TV, home and/or mobile phone, IPTV streaming, games consoles, maybe a NAS - all kinds of things. Even a single device can cause bloat for itself, much more so with multiple devices running at once (cloud backups, Steam download/game update, file downloads, video streams). I don't know anyone these days who pays for Internet (much less 'good' Internet) and just plugs a single PC into the ONT or modem.
You're not always at the mercy of the ISP's bandwidth shaper/policer in the way you imply. You're talking about the headline speed cap, which - yes - you're always subject to, but you're not considering the bigger picture or the role of {A,S}QM. No matter the package with the ISP, the ISP is 99% of the time going to be the bottleneck in the physical network link even when you're not carrying out a large/fast bulk download. For example 10G NICs locally, 10Gb ONT, ~8G effective goodput from the ISP (or 1Gb hardware and any plan up to 'gigabit' from the ISP, or whatever). Your local devices are sending and receiving data (even regular stuff, not just bulk TCP downloads) at line rate, which will be faster than the cap at the ISP end. You don't need to be downloading a 100GB file to hit this - even requesting a web page via the 2.5Gb NIC on your PC via your 2.5Gb NIC on the router is going to hit a bottleneck at the ISP's side when you hit the plan's cap.
There are now two possibilities:
- Your ISP has massive buffers on their BNG/edge (common these days) to avoid dropped packets, and it's FIFO. Your packets all hit your router NIC and ONT/modem at line rate (1G, 2.5G, 10G, whatever) and hit the ISP's edge at a slower rate (your plan speed). The ISP is the bottleneck and your packets sit in a huge dumb queue ISP-side, outside your control. Your game, voice chat, FaceTime call and stream packets sit helplessly behind 100ms to 500ms or worse worth of packet delay from all the bulk TCP data (downloads, javascript, etc) they're ingesting from you *and every other customer in your area* at that time. Whether you are a single person with one PC or a family of ten with 100 devices doesn't change the fact the ISP side buffers are ingesting likely thousands of customers' packets at once, and you are now at the mercy of *their* buffers and *their* packet priorities. The result is uncontrollable bloat and a rubbish experience in latency sensitive applications that you can do nothing about.
- Your ISP has regular sized or shallow buffers and relies on a dumb policer. Now your packets spew out of your (faster) WAN NIC and hit the too-small ISP buffer. In this scenario you hit the brick wall that is the dumb bandwidth policer, and your packets that exceed the cap (eg you send at 2.5Gb physical line rate but your plan is 2Gb) are simply dropped cold. You'll see saw-tooth download graphs, huge jitter, TCP retransmits and your speed will 'yo-yo' as your local devices crash their speed in response to dropped packets (sensing congestion) and slowly ramp back up.
That's even with just one local user and a single device. Now as I said add in a family, or even just a single user with multiple devices... Well, it's not pretty - and yes, you're relying on (at the mercy of) the ISP shaper/policer. However, when we run AQM or - preferably - SQM we take away those possibilities. We are no longer subject to the ISP shaper/policer in the way you meant, because now *we* control the flow of packets and will never actually bump into said shaper/policer. For example, on my 2Gb ISP plan with 2.5Gb NICs locally, CAKE is set to 1.95Gb and as such I will *never* be subject to the ISP shaper - because now I am the bottleneck in the link, and I have full control over the flow of packets and their (non) delay. That's exactly what fair queueing is.
Also, don't make the mistake of conflating fairness (sharing bandwidth between multiple users on a connection, or even multiple applications on a single user's single device) and
responsiveness. Maintaining responsiveness under load, even during microbursts, is paramount to a good user experience. That's equally true of just surfing the web as it is running multiple apps/streams/devices.
Modern protocols and applications are designed to probe and make full use of available capacity (whether it's a torrent, a website loading over QUIC or something else). The 'you'll never use the whole line/speed' is fallacious, as even when it's for a fraction of a second you'll hit microbursts of traffic that do indeed momentarily saturate the line and cause jitter and delays. Thus, you'll benefit from the responsiveness good SQM provides.
Both of the above ISP-controlled scenarios are independent of the plan's bandwidth cap, and the negative consequence of the ISP being the bottleneck on the link can be avoided by simply making
yourself the bottleneck and taking full control of the packet flows. This allows you to avoid delays, jitter and needless drops. For that, we need a shaper (SQM) like CAKE, which provides both fairness *and* maintains responsiveness under load. The best scenario is a good qdisc and congestion control algorithm on the local devices (eg plain fq_codel + bbr), and SQM like CAKE on the edge device.