Set the RTO minimum too low and even small delays cause spurious retransmissions; leave the default (200 ms) and it’s too long for games, so every loss means a long freeze.
Why RTO minimum lowered sharply for data center use, or the default left as is on internet paths → Effect Too low: retransmission storms on momentary delays. Too high: a long wait on every loss → On screen At the default, each loss means a freeze of hundreds of ms then fast-forward; set too low, freezes get shorter, but spurious retransmissions surge and waste bandwidth
Primary owner Infra team (Server infrastructure) · Also Game team (Server development)
Game team action items
On Linux 6.15 and later, consider lowering the RTO cap for game connections with TCP_RTO_MAX_MS (this also shortens the time until the connection gives up, so set the disconnect detection time with TCP_USER_TIMEOUT alongside it), lower the RTO minimum only on internal server-to-server connections with the TCP_RTO_MIN_US socket option (6.15 and later), consider the TCP_THIN_LINEAR_TIMEOUTS socket option so that consecutive RTOs don’t double on game connections.
Infra team action items
Lower rto_min per route only for internal server-to-server connections, keep the default on internet paths and compensate with RACK-TLP and the thin stream setting (tcp_thin_linear_timeouts).
Ballpark numbers
Linux RTO = round-trip time + max(200 ms, RTT deviation × 4). It doubles on every failure, up to 120 seconds. On Linux 6.15 and later, TCP_RTO_MAX_MS can lower this cap to as little as 1 second.
On the graph
Always high · Per-connection RTO, spurious RTOs
Where to look
The server’s RTO minimum setting (rto_min in ip route show; on Linux 6.11 and later, sysctl net.ipv4.tcp_rto_min_us), rto and rtt in ss -ti, and deltas of nstat TcpExtTCPSpuriousRTOs
Confirmed if
On a server with a lowered minimum, rto on internet connections hugs rtt and TcpExtTCPSpuriousRTOs climbs sharply. At the default, rto on game connections sits 200 ms or more above rtt, and every loss freezes the game for that long
Ruled out if
rto follows the default calculation (about rtt + 200 ms) and spurious RTOs are few, yet freezes are unusually long: points to consecutive losses or the recovery method (“Slow recovery on thin streams,” “Middlebox strips TCP options”)
IP SysctlLinux kernel tcp_rto_min_us defaults to 200000 (the route option rto_min and the socket option TCP_RTO_MIN_US take precedence), tcp_rto_max_ms 1,000–120,000 (default 120,000), tcp_thin_linear_timeouts
ip-route(8) — Linux manual pageiproute2 Per-route rto_min option: the RTO minimum used when communicating with that destination
Thin-streams and TCPLinux kernel TCP_THIN_LINEAR_TIMEOUTS can turn off exponential backoff for thin stream connections only
tcp(7) — Linux manual pageLinux man-pages TCP_USER_TIMEOUT: how long to wait for unacknowledged data before closing the connection