If the largest packet size a link along the way can carry shrinks and the “too big” notice (ICMP) is blocked, large packets keep vanishing no matter how many times they’re resent.
Why The maximum size shrinks on a VPN or tunnel segment, and a firewall blocks the “too big” notices → Effect The sender, with no idea why, keeps retransmitting the same large packet, and the RTO doubles each time → On screen Fine normally, but when large data moves (inventory, crowded areas, loading into a zone), everything stops, including the small packets behind it, ending in a disconnect or infinite loading
During specific actions, Right after login or maintenance
Owner
Primary owner Infra team (Network infrastructure) · Also Infra team (Server infrastructure), Game team (Server development)
Game team action items
To lower it from the server side, set the socket’s maximum segment size (TCP_MAXSEG); just splitting messages into smaller pieces in game code won’t prevent it (TCP re-packs the outgoing data into MSS-sized segments).
Infra team action items
Network: clamp the MSS on edge devices, allow the “too big” ICMP (type 3 code 4, fragmentation needed) through firewalls and cloud network ACLs. Servers/OS: set the path MTU, make sure the server firewall and cloud security groups don’t block “too big” ICMP either, and as a last safety net set Linux tcp_mtu_probing=1.
Ballpark numbers
Usually 1,500 bytes; around 1,400 through a tunnel. If the same packet is retransmitted 5–6 times, the freeze exceeds 10 seconds.
On the graph
Outliers only · Per-connection RTO and backoff, disconnects per region and ISP
Where to look
Retransmissions on the problem connection from a server-side packet capture or bcc tcpretrans -s (shows sequence numbers), plus mss, pmtu, and backoff for that connection from ss -ti. From the server to that player’s address, a small ping compared with a 1,500-byte ping with DF set (ping -M do -s 1472)
Confirmed if
Full MSS-sized packets are retransmitted over and over with the same sequence number at doubling intervals, while smaller packets get through. No “too big” ICMP arrives (Wireshark filter icmp.type == 3 and icmp.code == 4), and the small ping gets replies while only the large DF ping vanishes without one
Ruled out if
Small packets vanishing too points to loss unrelated to size (“Bottleneck queue overflow (congestion loss),” “Route change / bad ECMP path”). If “too big” ICMP arrives and pmtu in ss -ti drops, path MTU discovery is working properly
Check with
Infra tools (no game code needed)
Learn more
tcp_mtu_probing=1 declares a black hole and lowers the MSS to 1,024 bytes only after retransmission timeouts have gone on for a few seconds (the equivalent of tcp_retries1=3). The connection is frozen until then, so keep it as a last safety net and put MSS clamping, which prevents the problem up front, first.
Sources
RFC 1191: Path MTU discoveryIETF Path MTU discovery: a packet that is too large triggers ICMP “fragmentation needed and DF set” (type 3 code 4)
IP SysctlLinux kernel tcp_mtu_probing: 0 off, 1 only when a black hole is detected, 2 always (starting MSS is tcp_base_mss). tcp_retries1 defaults to 3
net/ipv4/tcp_timer.cLinux kernel When RTO retransmissions go on for tcp_retries1 times, treats it as a detected black hole, turns on MTU probing, and lowers the MSS
iptables-extensions(8) — Linux manual pagenetfilter TCPMSS --clamp-mss-to-pmtu: works around large packets stalling on segments that block ICMP by adjusting the MSS in the SYN
tcp(7) — Linux manual pageLinux man-pages TCP_MAXSEG: maximum segment size for outgoing packets; set before connecting, it also changes the MSS advertised to the peer
MTU considerations | Cloud VPNGoogle Cloud Cloud VPN gateway MTU is 1,460 bytes, and the payload MTU of an IPv4 tunnel is 1,406 bytes (around 1,400 through a tunnel)
ss(8) — Linux manual pageiproute2 mss, pmtu (path MTU), and backoff (how many times the RTO has doubled) in ss -i
ping(8) — Linux manual pageiputils -M do sets DF and won’t send packets larger than the path MTU the kernel knows; -s is the data size (the 8-byte ICMP header comes on top)