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

Game Lag White Paper › Root causes of TCP retransmission

Late or lost ACKs (saturated upload) ACK path congestion on asymmetric links

Cause ID rt-ack-path · Primary owner External (External) · Also Game team (Client development)

Open the interactive card with figures and simulations →

Data arrives fine, but if the “got it” ACK is delayed or dropped in a full upload queue, the sender treats the data as lost and retransmits.

Why Video uploads or cloud backups at home saturate the upload → Effect ACKs sit in the router’s queue for hundreds of ms or get dropped when it overflows → On screen Game packets from the server mostly arrive on time. Your inputs, stuck in the same upload queue, go out late, causing input lag and rubber-banding, with occasional spurious retransmissions

Symptoms
Input lag, Rubber-banding
Factors
Latency, Packet loss
Who’s affected
Same household
When
Randomly, Evening peak hours
Owner
Primary owner External (External) · Also Game team (Client development)
Game team action items
Show network status on screen when ping spikes, display a hint to “check for programs that are uploading.”
External action items
Tell players to keep the upload queue short with SQM on their router, prioritize small packets (ACKs), and cap upload speed (video uploads, cloud backups).
Ballpark numbers
A later ACK confirms everything an earlier one did, so losing a few ACKs is usually fine. The real trouble is ACKs delayed in the queue.
On the graph
Outliers only · Per-connection RTT (ping)
Where to look
Ping to the game server from the player’s PC with an upload (video upload, cloud backup) running and stopped, compared. On the server, rtt for that player’s connection in ss -ti
Confirmed if
Ping climbs to hundreds of ms only during the upload, with input lag and rubber-banding, and recovers soon after the upload stops. From the server, that connection’s rtt rises at the same time
Ruled out if
Loss and latency regardless of uploads: “Wireless link loss” or a path-side cause. Only the server-to-player direction slow, with no link to uploads: “Bottleneck queue overflow (congestion loss)”
Check with
The player’s own environment

Sources

  1. RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF
    On asymmetric links with a narrow upload, delayed or lost ACKs hurt TCP performance; ACKs are cumulative, so a later ACK covers for lost ones; remedies such as ACK-prioritizing scheduling
  2. Smart Queue Management Bufferbloat.net
    Keeping router queues short with queue management and shaping
  3. tc-cake(8) — Linux manual page iproute2
    CAKE separates flows and minimizes latency for flows that send sparsely (sparse flows)
  4. ss(8) — Linux manual page iproute2
    rtt (average round-trip time) and rttvar (deviation) in ss -i

See also

Same layer: Root causes of TCP retransmission

Same symptom (Input lag), other layers

View the interactive card with figures and simulations