Congestion Control — UDP Won't, So You Must
A Manja Arena player's sister is on a video call in the next room, sharing the same home Wi-Fi. Every evening at match time her call breaks up. The game is not doing anything forbidden. It is doing exactly what UDP allows: sending as much as it likes, whatever state the network is in.
The rule
UDP never slows down by itself — measure, then back off fast.
TCP has congestion control built in. It probes for spare capacity, and when it sees signs of loss it cuts its sending rate sharply, then grows it back slowly. That behaviour is how millions of connections share the internet without drowning it.
UDP has none. A UDP program that ignores congestion makes things worse for everyone, itself included: router queues fill, round-trip time climbs, packets start to drop, and the game's own snapshots arrive late or not at all.
So the game watches two signals, both of which its own ack system already provides:
- RTT rising above its usual value. Queues are filling somewhere on the path. This is the early warning, often before any loss.
- Loss rising — more packets going unacknowledged.
And it has levers to pull:
- A fixed bandwidth budget per player, for example never more than 8,000 bytes a second, whatever is happening in the match.
- Fewer updates: drop from 20 snapshots a second to 10 while the path is struggling.
- Priority: send nearby kites in every snapshot and distant ones every second or third time.
The pattern is borrowed from TCP: back off quickly, recover slowly. Cut the rate as soon as the signals turn bad; raise it again only after the path has stayed healthy for a while.
The shortcut
Turn the budget into a per-packet limit: bytes per packet = budget ÷ packets per second. Then pick the sending mode from the two signals.
Normal budget
8,000 bytes a second ÷ 20 packets a second = 400 bytes per packet.
Drills
Answer fast — trust the rule.
The path to a player becomes congested. What does UDP itself do about it?
A player's budget is 8,000 bytes a second, sent as 20 packets a second. What is the most each packet may carry?
RTT climbs steadily from 40 ms to 200 ms, but nothing is lost yet. What is the likely cause?
Which recovery pattern follows the rule?
Which change cuts bandwidth without lowering the server's tick rate?
Remember
- UDP never slows down by itself — measure RTT and loss, then back off fast.
- Bytes per packet = budget ÷ packets per second.
- Trap: blasting at a fixed high rate. It hurts every app on the path, the game included.