The Hidden Journey of a Packet

You computed 60 ms for a one-way India-to-US trip through fiber. You measured 200 ms. The gap is 140 ms, and that gap is where most of real-world networking actually lives.

Let's enumerate where the missing milliseconds go.

Path, not straight line. Fiber cables do not run as the crow flies. They follow coastlines, avoid trenches, share landing stations with existing infrastructure, and meander to wherever the geopolitics and economics allow them to be. The packet is not traveling 12,000 km. It is traveling whatever the cable route is, which can easily be 20 to 50 percent further.

Hops. A packet on the public internet does not go from your laptop to a US server directly. It hops. It goes from your laptop to your switch, your switch to your router, your router to your ISP's edge router, their edge to a regional aggregator, the aggregator to a national core, the core to an undersea cable head, the head to the cable, the cable to the landing station on the other side, then up through a mirror image of that hierarchy on the other continent until it reaches the destination server. Every one of those touches is a hop.

A typical internet path between two continents has somewhere around 15 to 25 hops. Within a single country, you might see 5 to 10. The default maximum on the internet is 64 hops — the Time-To-Live (TTL) field on an IP packet typically starts at 64 (or 128, depending on the OS) and decrements at each router. If the packet has not arrived by the time TTL hits zero, the router drops it and sends an error back. This is what stops misrouted packets from circling the planet forever.

Each hop is a tiny computer. Every router on the path is, at its core, a computer running software. It reads the incoming packet, looks up the destination address in its routing table, decides which outbound interface to forward the packet on, rewrites a few header fields, and pushes the packet back out. Even a very fast router takes some non-zero time per packet — submillisecond on modern hardware, but multiplied across 20 hops, that adds up. A repeater that has to read the signal and rewrite it also adds processing time. None of this is free.

Routing algorithm choices. Routers run protocols like BGP and OSPF to decide which path is "best." They optimize for things like reachability, policy, and cost. They do not necessarily optimize for the latency of your specific packet. A path that looks straight on a map can be longer in practice because the routing decision sent your packet through an interconnect three countries away.

Encryption and decryption. If your traffic is TLS-encrypted (and almost all of it is now), every endpoint has to do cryptographic work. The handshake at the start of a new connection alone is multiple round trips. The per-packet overhead of encrypt/decrypt is small but real.

Buffering, queuing, and congestion. When a router gets a burst of traffic, packets queue up in its memory. If the queue is short, you barely notice. If the network is congested, the queue grows, and your packet sits there waiting. This is why your ping can be 80 ms one minute and 300 ms the next, even though no cables moved.

The two-way nature of measurement. Ping measures round trip. Your "200 ms" is the time for the request to go and the response to come back. The one-way floor of 60 ms becomes a two-way floor of 120 ms. Then add hops and queuing.

When you sum all of this up, the gap from 60 ms to 200 ms stops feeling mysterious. It feels inevitable.

The phone call to America.

You have probably noticed, if you have ever called somebody in another continent, that there is a faint delay in their replies. They speak a half-second after you stop, and you speak a half-second after they stop. It is not awkwardness. It is the speed of light, the routing topology of the planet, and the codec compression of the voice stream, all conspiring against you.

There is no way to make that delay zero. The only way to reduce it further would be a physical communication medium faster than light. As of today, we do not have one.

Multiplayer games and the 8-minute Earth-to-Mars problem.

Pause and imagine you are designing a multiplayer video game between players on Earth and players on Mars. Light from Earth to Mars takes between roughly 3 and 22 minutes one-way, depending on where the two planets are in their orbits.

This is not a software problem. You cannot just "optimize the server." A real-time, click-and-shoot multiplayer game across that distance is physically impossible. The packets simply cannot get there fast enough.

A turn-based game like chess? That works fine — the delay between turns matters less.

A live conversation? You would need to think of it differently. NASA's mission control does not have a "conversation" with rovers on Mars. They send commands and wait. The communication is asynchronous because the universe forces it to be.

I am bringing this up because the lesson generalizes. There are problems where the physics of the medium dictates the architecture of the software. The shape of your application is constrained by the shape of the world. A senior engineer notices this constraint before trying to solve the problem, because trying to solve a physically impossible problem with software is one of the most expensive mistakes in our industry.

What about quantum?

There is active research into quantum communication — entangled particles whose states can, in principle, be correlated instantaneously across any distance. There has been real experimental progress. There is also a lot of overclaiming in the press about what "instantaneous" means here, and whether useful information can actually be sent that way.

The honest summary: as of today, real-time low-latency communication between two distant points is still bounded by the speed of light. Quantum networking is a developing field. If it becomes practical for general communication in your career, the consequences for distributed systems will be enormous. Watch the space, but do not bet your architecture on it.

Push On It

1. Run traceroute (or tracert on Windows) to three different services on three different continents. Capture the per-hop latency. Identify the hop where the latency takes its biggest jump — that is usually the long-distance backbone or undersea segment.
2. Look up "TCP slow start" and explain to yourself why a fresh TCP connection feels slower for the first second or two than an established one.
3. Pick a real product you use that has a global audience — a chat app, a game, a video service. Sketch how you would architect it to feel snappy for users in five different continents simultaneously. What gets cached? What gets regional? What is forced to round-trip back to a central system, and why?