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, and other bookkeeping details the network needs to route it correctly. One thing the IP header does not carry is a general "what order it belongs in" number: the IPv4 and IPv6 headers (RFC 8200) have no end-to-end sequence field. Ordering is the job of whatever protocol rides inside the packet: TCP numbers the bytes of its stream, and voice packets carry their own sequence numbers in RTP. 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.

In principle, two packets going to the exact same destination could take different paths: one through Chicago, one through Dallas. In practice, networks work hard to avoid that. Where multiple equal-cost routes exist, routers and load balancers hash each flow (the addresses and ports of a connection) onto a single path, so all the packets of one conversation follow the same route. Packets do not roll the dice at every hop; paths shift when routing changes, not packet by packet, precisely because reordering a live stream causes trouble.

This is still fundamentally different from the old phone system. There is no dedicated circuit. There is no guaranteed or reserved path. Each packet is delivered on a best-effort basis.

Reassembly

When packets arrive at the destination, they may occasionally be out of order: a route change mid-transfer, or parallel links inside one hop, can let a later packet slip ahead. The receiving device uses the sequence numbers that the transport or application protocol put in each packet (TCP's byte numbering, or RTP's sequence numbers for voice) 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. The data is tracked as a numbered stream of bytes, and the receiver sends back acknowledgments: cumulative ones that say "I have everything up to here," often deliberately delayed to cover several packets at once rather than one acknowledgment per packet (RFC 9293). If data goes missing, the sender automatically resends it. This guarantees that every piece of data arrives, in order, with nothing lost. Email, file downloads, and much of web browsing use this method. It is called Transmission Control Protocol. (Web traffic is no longer synonymous with TCP, though: HTTP/3 (RFC 9114) runs over QUIC, which builds its own reliability on top of UDP.)

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: voice rides in RTP packets over UDP, and RTP adds sequence numbers and timestamps so the receiver can spot gaps and reorder, but RTP itself never retransmits. 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.