But the proposed solution provides no value over datagrams, while it has plenty of downsides.
Let me rephrase the problem here for a simple FPS game:
The entire world state (or, the subset that the client is supposed to know about) is provided in each packet sent from the server. The last few actions with timestamps are in each packet sent from the client. You always want to have the latest of each, with lowest possible latency. Both sides send one packet per tick.
You do not want retransmission based on the knowledge that a packet was lost (the RTT is way too long for the information that a packet was lost to ever be useful, you just retransmit everything every tick), you do not want congestion control (total bandwidth is negligible, and if there is too much packet loss to maintain what is required, there is no possible solution to maintain sufficient performance and you shouldn't even try), and none of the other features talked about in the post add anything of value, either.
It reads like someone really likes QUIC, it fit well into their problems, and they are a bit too enthusiastic about evangelizing it.
In practice most games also need reliable side channels for control messages/chat/etc, and so they end up building optional reliable streams over UDP... and at the end of this path lies something that looks a lot like a (less thoroughly designed/tested) version of QUIC
My spidey sense is that almost all games used a custom UDP solution. I could be wrong! I made a Twitter poll to try and get info.
You’re right that a custom reliable UDP solution is going to wind up QUIC-like. On the other hand it’s what games have been doing for over 20 years. It’s not particularly difficult to write a custom layer that does exactly what a given project needs.
I don’t enough about QUIC to know if it adds unnecessary complexity or not.
Tribes, and various quake mods, used to use a TCP side channel for chat and control messages. Tribes famously used irc, and you could connect to a tribes server with any irc client to chat with your friends in game
NAT traversal, historically. Reliably punching one hole through the local NAT gateway is bad enough, adding a second protocol into the mix was asking for trouble.
Let me rephrase the problem here for a simple FPS game:
The entire world state (or, the subset that the client is supposed to know about) is provided in each packet sent from the server. The last few actions with timestamps are in each packet sent from the client. You always want to have the latest of each, with lowest possible latency. Both sides send one packet per tick.
You do not want retransmission based on the knowledge that a packet was lost (the RTT is way too long for the information that a packet was lost to ever be useful, you just retransmit everything every tick), you do not want congestion control (total bandwidth is negligible, and if there is too much packet loss to maintain what is required, there is no possible solution to maintain sufficient performance and you shouldn't even try), and none of the other features talked about in the post add anything of value, either.
It reads like someone really likes QUIC, it fit well into their problems, and they are a bit too enthusiastic about evangelizing it.