UDP Packet Loss: Why Freshness Beats Completeness

UDP doesn't recover lost packets. That's the point.

TCP treats every lost packet as a crisis, halting transmission until the gap is filled. For a file download, that's correct. For a video call, it's catastrophic. A video frame from 500 milliseconds ago isn't late—it's extinct. The viewer has moved on. In a multiplayer game, knowing where a player was half a second ago doesn't help when you need to know where they are.

UDP's philosophy: send and forget. No connection state, no tracking, no recovery. This makes UDP fast, but it means packet loss is your problem. The right solution depends on one question: does this data still matter by the time recovery happens?

Detecting Loss with Sequence Numbers

Before you can handle loss, you need to know it's happening.

Add a sequence number to every packet—a counter that increments with each send. When your receiver sees packet 1,043 arrive after packet 1,041, it knows packet 1,042 vanished. The gap tells you exactly how much disappeared.

Sequence numbers also catch duplicates (networks occasionally clone packets) and reordering (packet 1,045 arriving before 1,044). For streaming data, they let you reconstruct proper order even when the network scrambles delivery.

Implementation: add a 32-bit or 64-bit field to your packet header. The sender increments it. The receiver tracks what it's seen. Any gap means loss.

Selective Recovery with Acknowledgments

Some UDP applications build their own acknowledgment systems—borrowing from TCP but adapting to real-time constraints.

The receiver periodically sends status reports: "I received packets 1,040-1,042 and 1,044-1,048, but I'm missing 1,043." The sender then decides whether retransmitting 1,043 makes sense. If it contained a chat message, yes. If it contained one frame in a 60-fps video stream, the moment has passed—skip it.

The difference from TCP: these systems understand what the data represents. They make intelligent decisions about whether recovery is worthwhile. A chat message is worth waiting 200ms to retransmit. A voice packet isn't.

Preventing Loss with Redundancy

Forward Error Correction (FEC) doesn't wait for loss. It sends redundant data proactively, letting the receiver reconstruct lost packets without asking.

The simplest technique: XOR packets 1-4 together and send the result as packet 5. If any single packet from that group vanishes, XOR the survivors with the parity packet to recreate it. More sophisticated schemes like Reed-Solomon codes can recover from multiple losses within a block.

For critical data, an even simpler approach: send it twice. VoIP applications might transmit each audio packet twice with a slight offset. If one copy gets lost, the other probably arrives. This works when losses are random and uncorrelated. Burst losses from a congested router? Less helpful—both copies vanish together.

Many real-time applications use partial redundancy: include a low-quality copy of previous data alongside current data. A VoIP packet carries high-quality audio for the current 20ms plus low-quality audio for the previous 20ms. If the previous packet was lost, the backup fills the gap acceptably.

FEC shines for one-way communication or high-latency links. Satellite broadcasts use it extensively—asking for retransmission over a satellite link adds seconds of delay. The trade-off is bandwidth: you're sending extra data even when the network is perfect.

Faking It with Prediction

Here's the strange part: for continuous motion or audio, sometimes the best response to loss is making things up.

Video packets 100 and 102 arrive, but 101 is lost. Interpolate—generate a frame halfway between 100 and 102. For slow-moving scenes, this is often imperceptible. You're watching something that never existed, and you can't tell.

Game clients predict constantly. If the server sends player positions every 50ms and a packet vanishes, the client extrapolates from last known position and velocity. It shows you where the player probably is. When the next update arrives, it smoothly corrects any drift. The game feels responsive even during brief outages. You're seeing positions the server never reported, and the illusion holds.

Audio applications synthesize missing chunks by repeating or blending adjacent audio. A lost 20ms of speech during a vowel sound? Often undetectable. Your brain doesn't notice.

Prediction works because reality is usually continuous. Objects don't teleport. Sounds don't randomly change. The next moment tends to resemble the last moment. Exploit that, and loss becomes invisible.

Choosing Your Strategy

Three questions determine the right approach:

How time-sensitive is the data? A chat message can wait for retransmission. A live video frame cannot.

What's the impact of loss? A dropped frame in 60fps video is invisible. A dropped "player scored" event breaks the game state.

What's the cost of each strategy? FEC burns bandwidth constantly. Retransmission adds latency. Prediction requires computation and only works for continuous data.

Real-world applications mix strategies:

Real-time video accepts loss—skip the missing frame, keep playing. The brief glitch beats pausing.

High-speed file transfer over UDP requires perfect delivery but retransmits aggressively—multiple simultaneous requests rather than waiting for timeouts.

Multiplayer games stream player positions without acknowledgment (the next update arrives shortly anyway) but acknowledge and retransmit critical events like "weapon acquired" or "point scored." State changes can't be guessed.

VoIP uses FEC for baseline protection, prediction for small gaps, and gives up gracefully on large gaps—a moment of silence beats a delayed conversation.

The pattern: use the simplest strategy that keeps the data useful. When freshness matters more than completeness, let the old data go.