> Is there a particular reason you believe it is reliable? I don't, nor do I think it is unreliable. Protocols exist in an abstract space, but they are instant

> Is there a particular reason you believe it is reliable? I don't, nor do I think it is unreliable. Protocols exist in an abstract space, but they are instantiated in a system that works within physical /constraints/ (noise, faults, oxidation, etc.). These constraints vary because different systems work in different environments. The systems we make also have to provide utility for the /purposes/ that it's made. Reliability is necessary to trust the utility of a system. If I'm playing a multiplayer FPS game and due to backoff I see players snapping back to the position of a lost packet once it is received, I will not think that the game is reliable (and I will be especially sad since this is known issue with known improvements). If I don't care about old packets and only care about the latest packet, I don't work with old information -- but the information is incomplete. Latency will still be noticeable on a noisy connection, but my brain can at least anticipate -- guess where to look next -- once the last packet is received. That incomplete information can be used to extrapolate movements. So the final step is to use a model to predict movements in (short) moments when a packet is not received. You can't do this when the information isn't relevant anymore. When that's done, I -- the player -- will feel like that game is more reliable than the first TCP case. (Games, and real-time interfaces in general, have some interesting aspects that I think is well covered in Game Feel by Steve Swink).