Why waiting can make a message less useful
UDP is a transport protocol: it carries small packets of data between applications across a network. It does not set up a delivery conversation for each packet. A sender can hand a packet to the network and move on; the receiver does not have to send back an acknowledgment, and UDP itself will not resend a packet that disappears along the way.
That saves the time and extra traffic that acknowledgments and retries require. But it also means delivery is not guaranteed, and packets can arrive late or out of order. UDP is not making the network more reliable; it is leaving the application to decide what to do when the network is imperfect.
Fresh information can beat complete information
Consider a voice call. If one packet contains a small slice of speech and gets lost, waiting for a replacement may deliver it only after the conversation has moved on. The app can instead conceal the brief gap and play the next slice on time. In a game, a player’s newest position may matter more than an older update that arrived late, so the game can discard stale information rather than pause for it.
This is a tradeoff, not a universal rule that lost data does not matter. Applications using UDP can add their own checks, recovery, or buffering when they need them. Others choose a protocol that handles reliable, ordered delivery for them. The important distinction is who manages the consequences: UDP keeps the transport’s delivery machinery light, while the application decides whether to recover missing data or keep going.
