> but changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything

> but changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything useful. About seven years ago, when unencrypted HTTP was still commonplace, I observed exactly this behavior (subscriber-wide QoS based on speedtest sensing) with my residential cable internet. My connection was nominally 100 Mib/s, but I would often observe downloads e.g. in Steam running at only 10-20 Mib/s. In those cases, I would open up a terminal and run while sleep 1; do curl http://<one-of-my-domains>/speedtest; done Didn't matter that this URL would give 404. Just because the URL contained "speedtest", the ISP machinery would adjust the QoS and the Steam download would immediately shoot up from 10 Mib/s to nearly the full 100 Mib/s. By now, this has not worked in a long time. I'm guessing they tore down the respective machinery once the important speedtest websites moved to HTTPS.