Packets: How Data Actually Moves

VoIP From the Ground Up: Part 3 of 10

We have established that the internet is a shared network where all traffic competes for the same resources. But we have not explained how data actually gets from one place to another. The answer is the single most important concept in modern networking, and it is the reason VoIP works the way it does.

The mailing analogy

Imagine you need to send a 300-page book to someone across the country. You have two options.

Option one: put the entire book in a box and ship it. Simple. But if the box gets lost, you lose everything. If the delivery route is congested, your entire book is stuck waiting. And nobody else can use that delivery truck while your box is on it.

Option two: tear out each page, put it in its own envelope, number the envelopes, and mail them individually. Each envelope can take a different route. If one gets lost, you only resend that single page. The postal system can handle your envelopes alongside everyone else's mail without dedicating any vehicle exclusively to you. The recipient collects all the envelopes and puts the pages back in order.

The internet chose option two.

What is a packet?

Every piece of data sent across a network gets broken into small chunks called packets. An email, a webpage, a video stream, a voice call. All of it is split into packets before it leaves your device.

Each packet contains two things: a header and a payload. The header is the addressing information. It says where the packet came from, where it is going, what order it belongs in, and other bookkeeping details the network needs to route it correctly. The payload is the actual data, the chunk of the email or webpage or audio that this particular packet is carrying.

A single packet is small, typically somewhere between a few hundred and about 1,500 bytes. To put that in perspective, a single photo from your phone might require hundreds or thousands of packets to transmit.

How packets travel

When your device sends a packet, it does not know or care about the full path to the destination. It only knows the next step: the router. Your device hands the packet to your router, and the router looks at the destination address in the header and decides where to send it next.

That next device does the same thing. It reads the header, looks up the best route it knows about, and forwards the packet to the next hop. This continues, device by device, until the packet reaches its destination. Each device along the way makes its own independent routing decision.

This means that two packets going to the exact same destination might take completely different paths. Packet one might go through Chicago. Packet two might go through Dallas. They both arrive at the same place, but they took different routes and may have experienced different conditions along the way.

This is fundamentally different from the old phone system. There is no dedicated circuit. There is no guaranteed path. Each packet is on its own.

Reassembly

When packets arrive at the destination, they may be out of order. Packet 47 might arrive before packet 12 because it happened to take a faster route. The receiving device uses the sequence numbers in the headers to put everything back in the correct order.

For most types of data, this works beautifully. If you are downloading a file, it does not matter if the packets arrive out of order or if some take longer than others. Your device just waits until it has all of them, assembles them in the right sequence, and hands you the completed file. A few milliseconds of reordering is invisible because you were not expecting the result in real time.

This is why web browsing, email, and file transfers work so well on the internet. The slight disorder of packet-based delivery is completely hidden from you.

The two transport methods

Networks use two main approaches for delivering packets, and the difference between them is critical for understanding VoIP.

The first approach is reliable delivery. Before sending data, your device establishes a connection with the destination. Every packet that gets sent is tracked, and the receiving device sends back an acknowledgment for each one. If a packet goes missing, the sender automatically resends it. This guarantees that every piece of data arrives, in order, with nothing lost. Web browsing, email, and file downloads all use this method. It is called Transmission Control Protocol.

The second approach is fast delivery. Your device just sends packets without establishing a connection first and without waiting for acknowledgments. If a packet gets lost, nobody resends it. It is simply gone. This sounds reckless, but it is faster because there is no overhead of tracking, acknowledging, and resending. This method is called User Datagram Protocol.

VoIP uses the fast delivery method. And the reason is time.

If a packet carrying a piece of your voice gets lost, by the time the network detected the loss, requested a resend, and delivered the replacement packet, the conversation would have moved on. That packet is no longer relevant. Resending a word you said 500 milliseconds ago would be worse than just skipping it. So VoIP accepts the loss and moves on.

This trade-off, speed over reliability, is what makes internet voice calls possible. It is also what makes them vulnerable. You can measure how well your connection handles this trade-off with a VoIP quality test. For more on how packet loss specifically affects call quality, see our dedicated guide.

Why this matters for voice

Everything we have covered in this post creates a specific set of challenges for voice traffic.

Packets can arrive out of order. Packets can be delayed by congestion. Packets can be lost entirely with no resend. And all of this is happening to your live conversation, where gaps, stutters, and delays are immediately noticeable to the human ear.

For a web page, none of this matters. For a file download, none of this matters. But for a real-time voice conversation, every one of these behaviors is a potential quality problem.

The next post digs into exactly why voice is uniquely difficult on a packet-based network and what the specific failure modes sound like on a real call.

This is Part 3 of the VoIP From the Ground Up series. Part 4: Why Voice Is the Hardest Thing to Send Over a Network explains what makes real-time audio so demanding compared to every other type of internet traffic.