Earlier quoted context omitted.
One cool trick you could try (although you are probably doing it already) is to include all inputs for some long period (like 1-2 seconds!) in every input packet the client sends to the server. This way if one input packet gets lost, the very next one getting through will have all the inputs for the last 1-2 seconds, and this greatly improves how well your game will play under packet loss. When you do this, you can e…
No need to resend inputs with seq IDs <= the last one acknowledged by the server, right? 1-2 seconds sounds like overkill. Unless the server updates themselves are lower than 0.5-1 Hz, but what kind of game is that? A very sparse world where chances of misprediction are very low?
I would see rare bursts of packet delay for ~1 second, that would quickly resolve. In a rollback game where inputs are predicted well, often times this would be unnoticeable.
I send up to 2s worth of input history every frame to handle these lag spikes. I also confirm inputs received, so in practice usually players are only sending a handful of recent unconfirmed inputs (with the 2s buffer available if unconfirmed inputs pile up due to lag).
My guess is their 2s window is for similar reasons, as buffer for rare connection issues. Even if lag spikes are incredibly rare, they need to be handled for a reliable player experience