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

Game Lag White Paper › L5 Data center network equipment

DDoS protection detours and false positives DDoS scrubbing latency, false positives

Cause ID dc-ddos · Primary owner Infra team (Network infrastructure) · Also Game team (Server development)

Open the interactive card with figures and simulations →

Diverting traffic to a scrubbing center to stop attacks makes the route longer, and legitimate players are sometimes mistaken for attackers and blocked.

Why After an attack is detected (or all the time), inbound traffic is diverted to a scrubbing center → Effect The route gets longer, and some legitimate packets are flagged as attack traffic → On screen Ping rises for everyone; players in certain regions or on certain ISPs can’t connect

Symptoms
Input lag, Can’t connect / infinite loading, Teleporting
Factors
Latency, Packet loss
Who’s affected
Whole server, Specific region/ISP
When
When crowds gather, Randomly
Owner
Primary owner Infra team (Network infrastructure) · Also Game team (Server development)
Game team action items
Document the game’s traffic pattern (ports, packet sizes, packets per second) and share it with the infra team, keep UDP packets at 1,200 bytes or less.
Infra team action items
Write protection rules that fit the game’s traffic pattern, use regional scrubbing locations, reduce TCP packet size on tunnel segments (MSS clamping), check for false positives with connection failure rates per region and ISP.
Ballpark numbers
A scrubbing location in the same country adds a few ms; going through a location in another country adds 30–100 ms or more. Usually only inbound traffic takes the detour, and the server’s responses go straight out. If the filtered traffic comes back through a tunnel, the largest packet size that can be sent at once (MTU) also shrinks, which can lead to a problem where only large packets vanish.
On the graph
Step change · RTT (ping), connection failure rate by region/ISP
Where to look
Put the protection device’s or service’s diversion (scrubbing) start and end records and its block logs on the same timeline as the RTT graph and the connection failure rates per region and ISP. From the affected region, check with mtr or traceroute whether a scrubbing location shows up in the path
Confirmed if
RTT steps up when diversion turns on, stays there, and comes back down when it turns off. Or legitimate player addresses show up in the block log, and only that region or ISP sees its connection failure rate rise
Ruled out if
RTT rises at times with no diversion or block records: “Detour routing” or “BGP route changes and convergence.” Only large packets vanish: “MTU mismatch (only large packets vanish)”
Check with
Infra tools (no game code needed)

Sources

  1. Maximum transmission unit and maximum segment size Cloudflare
    Inbound traffic is delivered after filtering over a GRE tunnel (MTU 1,476) while outbound responses go straight to the internet (DSR); limiting TCP MSS to 1,436 or less is recommended, and without it large packets are dropped or fragmented
  2. Azure network round-trip latency statistics Microsoft Azure
    Round-trip latency by location (PoP): Seoul–Busan area 8 ms, Seoul–Tokyo 30 ms, Seoul–Singapore 68 ms

See also

Same layer: L5 Data center network equipment

Same symptom (Input lag), other layers

View the interactive card with figures and simulations