E.g. "Low Latency DOCSIS"[0] and related, WiFi[1], support it and with the former it's about non-exclusive scarce uplink capacity where cross-customer capacity sharing may rely on post-hoc analysis of flow behavior to check for abuse, switching to forced fairness if caught by such heuristics. For downstream it's even more natural to have shared capacity with enough congestion to matter, but often only the WiFi side would have a large discretionary range for bandwidth scheduling/allocation to matter much.
Apple already opportunistically uses L4S with TCP-Prague and there are real-world deployments/experiments [2] with end-to-end L4S.
Fixed-
[0]: https://github.com/cablelabs/lld
[1] relevant excerpt from [0]:
Applications that send large volumes of traffic that need low latency, but that are responsive to congestion in the network. These applications can benefit from using a technology known as "Low Latency, Low Loss, Scalable Throughput (L4S)". Support for this technology is including in the LLD feature set, but is beyond the scope of what we have in this repository. Information on L4S can be found in this IETF draft architecture.
[2]https://www.vodafone.com/news/technology/no-lag-gaming-vodaf...