The author of the original RFC 896 from 1984 and namesake of Nagle's algorithm is John Nagle who is an active user here on Hacker News:
CSMA/CD works pretty well on a shared wire, but not very well on a single radio frequency where you cannot "hear" other people trying to reach the same mountain-top receiver. I'm glad that aspect of congestion is now a thing of the past. (Now that everything (wired) is switched, it's all point-to-point, so the only congestion we get is from insufficient bandwidth on the trunk, and we have ECN for that.)
Yes. As I wrote in 1985, in [1], under "Game Theoretic Aspects of Network Congestion" and "Fairness in Packet Switching Systems", about fair queuing,
We would like to protect the network from hosts that are not well-behaved. More specifically, we would like, in the presence of both well-behaved and badly-behaved hosts, to insure that well-behaved hosts receive better service than badly-behaved hosts. We have devised a means of achieving this.
The goal of fair queuing is not to improve network performance overall. The goal of fair queuing is to reward well-behaved hosts over badly-behaved hosts. If everyone is well-behaved, the queue lengths are the same, usually 1 or 0, and fair queuing does little.
There is an inherent conflict between this goal and achieving maximum data transfer rates. If you try for near 100% utilization, the problems become much worse. You can run comfortably at maybe 70%. This was an accepted tradeoff for DoD systems. DoD wants things to keep working in a crisis, even if normal operation is a bit slower.
This is why I'm not a big fan of HTTP/3. It's a attempt to get about 10% more performance in the good case, at the cost of considerable extra complexity and less immunity to gaming the system.
I never wrote about that much at the time, because if I had, people would have realized earlier that traffic shaping is possible, which implies that you can sell and bill for bandwidth and quality of service. We might have ended up with pay per packet.
To be clear, are you mainly complaining about the multiple streams aspect here, or do you have other concerns? Because while I'm no expert, using HTTP/3 (or QUIC, I'm ignoring the terminology differences here to avoid confusion with pre-standard QUIC, though I guess maybe we're past that point by now?) with just a single stream seems to be the only scalable solution to a certain problem.
The main problem I've had with TCP is that anybody can maliciously inject an RST, and for long-lived active connections, the chances of this happening approach 1. If you control both ends you can just tell your firewall to drop all RST packets so the applications can keep talking to each other, but ...
Dealing with this at the application layer is ... marginally possible I guess, but not easy unless your application looks a lot like a web browser (and even those tend to usually force the end user to manually fix it). Creating a new TCP connection sucks and you have no idea how much data got dropped after it left the application's buffer.
So we need a UDP reliability layer, since that's the only other general-purpose protocol that actually gets routed (and SCTP is flawed anyway). And dozens of those exist ... but almost none have major use, so I can't trust that they will play nice with the wider internet.
With HTTP/3, if there are major flaws found, I have confidence that - like TCP - it has enough users that someone will come up with an acceptable solution. (admittedly, since it's not part of the kernel it will be harder to actually deploy the fix)
(I guess TCP-over-VPN is also viable for some users)
https://github.com/muxamilian/fair-queuing-aware-congestion-...