It's about letting the TCP implementations on the end-points know early that the capacity of the link has been reached; so that they adjust their bandwidth usage before a long queue (which would cause latency) accumulates on the router before the bottleneck link.
Active queue management can achieve this with "explicit congestion notification" (ECN, a bit in the IP header) if supported by the endpoints; or alternatively by probabilistically dropping some packets early.
lastly, it is not just TCP that AQMs can control, but any TCP-friendly congestion control - Quic - which is udp based - plays by those rules. Most of our videoconferencing applications in their bandwidth seeking phase, also.
QUIC's original congestion controller was based on Reno. Other versions use BBR or Cubic congestion controls:
Usually games use UDP, though I guess if the TCP links all get notified of congestion that could effectively ensure there is enough bandwidth available for all the UDP traffic.
most games run at 64Kbits/sec or 120Kbits and FQ helps those "mice" flows a lot, by giving them their own lane.
If also, the greedy protocols like TCP or QUIC back off on filling up buffers (via an AQM) before a gamer would notice (20ms of jitter/buffering is about right, 60ms is teetering on wrong) gamers and downloaders can co-exist happily on the same link.
Thank you for the steer to that article, it has some errors.
ECN is not in use at starlink (yet), so far as I can tell. The AQM in place just uses conventional - and timely - packet drop, which is the principal signal for congestion control across the internet. (so I would say " alternatively" in the Wikipedia article about ECN, and drop principally)
To this day, so many people (including the early engineers at starlink), do not get that dropping packets is how we manage latency across it for greedy flows. I have given so many talks about how this works - lose 2 minutes of your life to this, please: https://www.youtube.com/watch?v=TWViGcBlnm0&t=995s
Starlink folk now deeply get that buffering for 100s of Ms is counter productive, and have put in play many "bufferbloat" mitigations over the past year, focusing on P99 metrics in particular.
...
More importantly than AQM, their stuff does "flow isolation" and "Fair queuing" so that fat flows interfere with lighter weight flows less. https://en.wikipedia.org/wiki/Fair_queuing
The starlink wifi now does fq_codel in particular, which combines fair (flow) queuing with the codel AQM. While I do not have any benchmarks of their implementation it should show up on tests where two or more stations are trying to "do stuff" at the same time.
...
There has been a lot of hype about ECN lately (because it does not require dropping packets) but it needs to be enabled at the endpoints, and at the congested routers in-between running an AQM algorithm that also has it turned on. I do keep hoping more enable it on their OSes (apple has it on for some sites, Apple Quic does now), and more routers enable it also.
Stunningly widely supported is RFC3168 ECN across 68% or so of all websites, but few clients turn it on. Here's how you can try it:
https://en.wikipedia.org/wiki/Active_queue_management