TCP treats loss as a sign of congestion and cuts its sending rate by 30–50%. It reacts the same way to Wi-Fi loss.
Why A little loss on Wi-Fi or the connection while there’s a lot to send → Effect TCP cuts its sending rate sharply and recovers slowly (CUBIC, the Linux and Windows default, cuts by 30%) → On screen Updates fall behind in crowded areas: fast-forward, input lag
Primary owner Infra team (Server infrastructure) · Also Game team (Server development)
Game team action items
Send less (area of interest, changes only), spread sends out so they don’t go out in one burst.
Infra team action items
Switch to a congestion control algorithm such as BBR (tcp_congestion_control).
On the graph
Sawtooth · Per-connection congestion window (cwnd) and sending rate
Where to look
Several ss -ti snapshots of a lagging player’s connection for changes in cwnd and ssthresh and the congestion control name (cubic, bbr), plus whether Send-Q builds up
Confirmed if
After each loss, cwnd drops sharply and climbs back slowly, and Send-Q builds up while it’s low, lining up with the times of fast-forward and input lag reports
Ruled out if
cwnd is ample, yet updates still fall behind: the receiver’s window (“Zero window (a stall that looks like retransmission)”) or the server’s sending side
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Recv-Q and Send-Q in ss: for a listening socket, connections waiting for accept and the backlog limit; for a connected socket, bytes the app hasn’t read yet and sent bytes not yet ACKed