The raw controller input latency / controller polling rate.
The time it takes for your packet to get to the server.
The number of packets per second you're sending to the serve (e.g. 100pps).
The server processing time per frame.
The server frame rate.
The time it takes for the packet to get back.
The frame rate of the client machine.
Whether Vsync is enabled (more latency).
The time it takes to transfer a frame of rgb data to the monitor.
The monitor frame rate and processing time per frame.
The pixel response time of the pixels on the monitor.
If we're doing cloud gaming. we also need to add latency stages for encoding and decoding video and how long it takes to download each frame of video.
By simulating everything client side you remove a ton of stages in this latency pipeline.
> Cloud gaming substitutes reconciling these n+1 simulations with some input latency for each player.
You're just pitching the naive networking model that every developer starts with (because it's trivial) until they realize how horrendous it is to wait 100ms on every single input.
Also, it's not "some input latency", it's the full latency of the entire round trip. From input to server (40ms) and then video to client (40ms) just to see how an action you did 80ms ago panned out.
You've eliminated none of the trade-offs, just exchanged one frustration (dying even though you shot someone before they shot you) with another (watching a delayed video feed of them shooting you while you wait for your input to cross the network).
There's a reason why client simulation is ubiquitous. Btw, lag compensation is really hard and nobody would want to do it if they could get away with the naive networking model.