한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game Lag White Paper › L8 Sockets and protocols

TCP RTO and exponential backoff RTO and exponential backoff

Cause ID sk-rto · Primary owner Game team (Server development) · Also Game team (Client development)

Open the interactive card with figures and simulations →

Each time a retransmission fails again, the wait doubles, so a brief connection drop turns into a long stall.

Why The connection drops briefly, and retransmissions fail one after another → Effect The wait before the next attempt doubles each time: 0.3 → 0.6 → 1.2 → 2.4 s (at 100 ms ping) → On screen The connection was down for 1 second, but the game stalls for over 2 seconds. A longer drop eventually ends in a disconnect

Symptoms
Freeze, Disconnect
Factors
Packet loss, Stall
Who’s affected
Just me
When
Randomly, While moving or changing zones
Owner
Primary owner Game team (Server development) · Also Game team (Client development)
Game team action items
Server: answer heartbeats and close the connection yourself if nothing arrives for a set time (bring the give-up point forward with TCP_USER_TIMEOUT), resume sessions with a session token, use reliable UDP. Client: send heartbeats at short intervals and reconnect quickly when responses stop, without waiting on TCP retransmission.
Ballpark numbers
The Linux RTO (retransmission timeout) has a floor of “ping + 200 ms”, and starts at 1 second while a connection is being set up. With the default setting (tcp_retries2=15), the connection is abandoned only after about 15 minutes of failed retransmissions.
On the graph
Gap then burst · Per-connection RTO and backoff, RTO expirations
Where to look
rto (retransmission wait in ms) and backoff (consecutive expirations) of the stalled connection from ss -ti; for the whole server, the increase in TcpExtTCPTimeouts (retransmission timer expirations) from nstat -az
Confirmed if
The stalled connection shows backoff of 1 or more with rto grown to seconds, and TCPTimeouts rises at that time
Ruled out if
If retransmissions finish as fast retransmits with no RTO expiration, stalls are short. That points to “TCP head-of-line blocking”
Check with
Infra tools (no game code needed)

Sources

  1. RFC 6298: Computing TCP's Retransmission Timer IETF
    Initial RTO 1 s, doubled on every timer expiration (exponential backoff)
  2. net/ipv4/tcp_input.c (Linux v6.12) Linux kernel
    Linux RTO = smoothed RTT + RTT variation, and the variation term has a floor of tcp_rto_min (200 ms), so RTO is at least RTT + 200 ms
  3. IP Sysctl Linux kernel
    tcp_rto_min_us defaults to 200 ms, initial RTO for connection requests is 1 s, with tcp_retries2=15 it takes at least 924.6 s (about 15 minutes) to give up
  4. ss(8) — Linux manual page iproute2
    rto (retransmission timer, ms) and backoff (exponential backoff count) in -i
  5. net/ipv4/proc.c (Linux v6.12) Linux kernel
    Counter name shown by nstat: TCPTimeouts in the TcpExt group
  6. net/ipv4/tcp_timer.c (Linux v6.12) Linux kernel
    Each time the retransmission timer expires, TCPTimeouts goes up, backoff increases by one, and RTO doubles (up to the maximum)

See also

Same layer: L8 Sockets and protocols

Same symptom (Freeze), other layers

View the interactive card with figures and simulations