Patch changes the traffic pattern Patch changes traffic pattern
Cause ID sp-patch-traffic · Primary owner Game team (Server development) · Also Infra team (Server infrastructure), Infra team (Network infrastructure)
When new content, effects, or synced fields raise packet size and frequency, a server that ran fine starts hitting MTU, bandwidth, and packet-rate limits after the patch.
Why The patch adds new skill effects, synced fields, or item data, making packets bigger or more frequent → Effect Large packets exceed the MTU and get fragmented, and the extra volume runs into bandwidth limits, cloud PPS limits, and send buffers → On screen Teleporting, skills not going off, and input lag in crowded places, starting right after the patch. Nothing changed in the infra, yet loss goes up
Whole server, Specific zone/channel, Specific region/ISP
When
When crowds gather, Evening peak hours, Always
Owner
Primary owner Game team (Server development) · Also Infra team (Server infrastructure), Infra team (Network infrastructure)
Game team action items
Split packets yourself to 1,200 bytes or less, send only changes for new synced fields and lower their rate by distance and importance, compare packets and bytes per second per player and the largest packet size against the previous build on a test server before deploying, tag traffic metrics with the build version.
Infra team action items
Servers/OS: mark deploy times on graphs and compare packets and bytes per second per player and average packet size before and after the deploy, alert on instance allowance-exceeded counters, move to a bigger instance if needed. Network: check the capacity limits of firewalls, load balancers, and DDoS protection gear, and whether they block fragments.
Ballpark numbers
UDP packets are safe at 1,200 bytes or less; the path MTU on the internet is usually 1,500 bytes, and smaller through tunnels (1,476 bytes through a GRE tunnel). Packets larger than the path MTU are fragmented or dropped, and a fragmented packet is lost entirely if even one fragment is lost. If packets per second per player rise 20%, the server total rises 20% too, and an instance running close to its limit overflows right away.
On the graph
Step change · Packets and bytes per second per player, average packet size
Where to look
Packets and bytes per second on the server NIC (rxpck/s, txpck/s, rxkB/s, and txkB/s from sar -n DEV; NetworkPacketsOut and NetworkOut on EC2) divided by concurrent users, compared before and after the deploy. Average packet size is bytes ÷ packets; for the size distribution, run Wireshark’s Packet Lengths statistics on a packet capture
Confirmed if
From right after the deploy, packets and bytes per player or average packet size step up and stay there, and from the same moment the number of fragments the server creates (fragcrt/s in sar -n IP) or the instance allowance-exceeded counters (pps_allowance_exceeded and bw_out_allowance_exceeded on AWS ENA) rise
Ruled out if
Traffic pattern the same before and after the deploy, but only latency and loss went up: look at infra changes made at the same time (configuration, routing, equipment, OS or kernel updates)
Check with
Infra tools (no game code needed)
Learn more
When a report says “it worked fine before the patch,” this is the game-side cause to check first, along with infra changes. Even if the patch notes list no network changes, one new effect or synced field gets multiplied by hundreds of players in crowded places. Where the extra traffic actually hits a limit is covered in “IP fragmentation of UDP packets,” “Cloud PPS limit exceeded,” “NIC bandwidth saturation,” “Kernel socket buffers too small,” and “Middlebox over capacity (firewall, IPS, DDoS protection).” This entry covers the case where a game patch is what pushed traffic into those limits, so cut the traffic the patch added before raising the limits. If the OS or kernel was also updated at the same time, tell this cause apart from “Performance changes after OS, kernel, driver, or firmware updates” by whether per-player traffic changed.
Sources
RFC 8085: UDP Usage GuidelinesIETF UDP apps SHOULD NOT send datagrams larger than the path MTU; losing one fragment loses the whole fragmented packet, and some NATs and firewalls drop all fragments
sar(1) — Linux manual pagesysstat rxpck/s and txpck/s (packets per second) and rxkB/s and txkB/s (KB per second) in sar -n DEV; fragcrt/s (IP fragments created per second, ipFragCreates) in sar -n IP