3 ms·

It mentions that the video game industry uses UDP but then fails to further address that use case. So, should competitive shooter video games switch to QUIC? I

It mentions that the video game industry uses UDP but then fails to further address that use case. So, should competitive shooter video games switch to QUIC? Is that even supported across all the various gaming platforms?

swiftcoder 2y ago
> It mentions that the video game industry uses UDP but then fails to further address that use case Video games tend to use UDP for the same reason everyone else mentioned does: timeliness. You want the most recent position of the various game objects now, and you don't give a shit about where they were 100ms ago. The proposed solution of segmenting data into QUIC streams and mucking with priorities should work just fine for a game. > Is that even supported across all the various gaming platforms? QUIC itself is implemented in terms of datagrams, so if you have datagrams, you can have QUIC.
- Tuna-Fish 2y ago
  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.
  - swiftcoder 2y ago
    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
    - forrestthewoods 2y ago
      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.
      - swiftcoder 2y ago
        Yeah, I don't know how many games actually use a fully custom layer, versus forking something like enet/RakNet
    - paradox460 2y ago
      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
    - marcosdumay 2y ago
      Why not make a second connection using another protocol (possibly TCP)? You also don't want to share the routing performance, congestion treatment, OS queue, and probably a lot of other stuff.
      - swiftcoder 2y ago
        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.
- chrisfarms 2y ago
  > Video games tend to use UDP for the same reason everyone else mentioned does: timeliness. You want the most recent position of the various game objects now, and you don't give a shit about where they were 100ms ago. This is only true for games that can replicate their entire state in each packet. There are many situations where this is infeasible and so you may be replicating diffs of the state, partial state, or even replicating the player inputs instead of any state at all. In those cases the "latest" packet is not necessarily enough, the "timliness" property does not quite cover the requirements, and like with most things, it's a "it depends".
  - swiftcoder 2y ago
    With those requirements raw datagrams also don't fit the bill, so you'll need to build some sort of reliable stream abstraction over UDP (with optional unreliable delivery for the state which you can replicate quickly)... and now we're closing in on QUIC territory
- CJefferson 2y ago
  I thought QUIC promised you get your data eventually? In that case it wouldn't be great for games, because you usually don't want packets that got dropped, as the next packet will replace it anyway?
  - swiftcoder 2y ago
    > I thought QUIC promised you get your data eventually? QUIC optionally promises you that, you are free to opt out. For example, take a look at the QUIC_SEND_FLAG_CANCEL_ON_LOSS flag on Microsoft's QUIC implementation.
intelVISA 2y ago
No, QUIC is mostly for Google to enforce E2E advertisment.
Retr0id 2y ago
QUIC is implemented in userspace, it doesn't need platform support beyond the basic networking stack.

swiftcoder 2y ago

> It mentions that the video game industry uses UDP but then fails to further address that use case Video games tend to use UDP for the same reason everyone else mentioned does: timeliness. You want the most recent position of the various game objects now, and you don't give a shit about where they were 100ms ago. The proposed solution of segmenting data into QUIC streams and mucking with priorities should work just fine for a game. > Is that even supported across all the various gaming platforms? QUIC itself is implemented in terms of datagrams, so if you have datagrams, you can have QUIC.

Tuna-Fish 2y ago
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.
- swiftcoder 2y ago
  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
  - forrestthewoods 2y ago
    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.
    - swiftcoder 2y ago
      Yeah, I don't know how many games actually use a fully custom layer, versus forking something like enet/RakNet
  - paradox460 2y ago
    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
  - marcosdumay 2y ago
    Why not make a second connection using another protocol (possibly TCP)? You also don't want to share the routing performance, congestion treatment, OS queue, and probably a lot of other stuff.
    - swiftcoder 2y ago
      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.
chrisfarms 2y ago
> Video games tend to use UDP for the same reason everyone else mentioned does: timeliness. You want the most recent position of the various game objects now, and you don't give a shit about where they were 100ms ago. This is only true for games that can replicate their entire state in each packet. There are many situations where this is infeasible and so you may be replicating diffs of the state, partial state, or even replicating the player inputs instead of any state at all. In those cases the "latest" packet is not necessarily enough, the "timliness" property does not quite cover the requirements, and like with most things, it's a "it depends".
- swiftcoder 2y ago
  With those requirements raw datagrams also don't fit the bill, so you'll need to build some sort of reliable stream abstraction over UDP (with optional unreliable delivery for the state which you can replicate quickly)... and now we're closing in on QUIC territory
CJefferson 2y ago
I thought QUIC promised you get your data eventually? In that case it wouldn't be great for games, because you usually don't want packets that got dropped, as the next packet will replace it anyway?
- swiftcoder 2y ago
  > I thought QUIC promised you get your data eventually? QUIC optionally promises you that, you are free to opt out. For example, take a look at the QUIC_SEND_FLAG_CANCEL_ON_LOSS flag on Microsoft's QUIC implementation.

intelVISA 2y ago

No, QUIC is mostly for Google to enforce E2E advertisment.

Retr0id 2y ago

QUIC is implemented in userspace, it doesn't need platform support beyond the basic networking stack.