The physics of latency

Picture a student in Dhahran opening an app whose backend runs in the AWS Frankfurt region. His phone sends a request that must physically cross about 4,400 km of Earth, and the answer must cross it again on the way back. Nothing useful can happen on his screen until both trips are done.

Latency is transit time, paid in both directions

That travel time is Latency: the time data spends in transit between two points. In the Request-response loop you met earlier, the Client always starts, so every exchange pays latency twice: once from client to Server, once from server back to client. Total network latency is the sum of the two one-way figures. They are often close, but they need not be equal, because Internet routes are not always the same in both directions.

Putting the server in the Cloud is the default because it is convenient, elastic and cheap to operate. The natural next question is how much time that choice costs at the very least, before any engineering detail enters the picture.

The smallest latency physics allows

Start with a number. A server 3,000 km away, reached at the speed of light, needs 3,000 ÷ 300,000 = 0.01 s, which is 10 ms one way. So every 1,000 km costs at least 3.3 ms one way, or 6.7 ms for a round trip.

Generalising this gives the Latency lower bound: divide the Geodesic distance by the speed of light $c$. It is a lower bound for three reasons that stack. Nothing carries information faster than light. No cable between two cities can be shorter than the shortest path along the Earth. And the formula ignores every other delay a real packet meets. Because each simplification can only make the true figure larger, the result is a floor that no provider, protocol or hardware upgrade can break.

Real glass is slower than vacuum

“Speed of light” in the bound means light in a vacuum. Real links carry light through glass fiber with a refractive index of about 1.5, so the signal moves at roughly 200,000 km/s, about two thirds of $c$ (Grigorik, High Performance Browser Networking). Even a perfectly straight fiber therefore needs about 1.5× the bound. ITU-T G.114 plans 5 µs/km for optical fibre systems, which is 5 ms per 1,000 km, against 3.3 ms per 1,000 km at $c$. Keep both numbers in mind: the vacuum bound is the absolute floor, and the fiber floor is the realistic best case for a cabled network.

Try the simulator. Pick the Frankfurt preset and read the one-way bound, then read the round-trip value to see the number doubled. The presets use the distances implied by the lecture’s own figures (for example 11,100 km for Oregon), a choice examined closely when we compare bounds with measurements below.

The bound is only as good as the distance you feed it, so which distance is the right one? Stretch a string tight between London and Singapore on a real globe. It does not run across Arabia the way a ruler on a flat map suggests. It runs north, over Eastern Europe and Central Asia. Now flatten that globe into a rectangle: the string that was the shortest path turns into a curve.

Those are the two candidates. A straight line drawn on the flat map gives the planar distance. The curve that the string traces gives the Geodesic distance between the same two endpoints. Esri’s documentation defines planar distance as straight-line Euclidean distance in a 2D Cartesian coordinate system, and geodesic distance as distance across the curved surface of the world in 3D. Signals travel over the real Earth, not over a map, so latency lives in the second definition.

Map projections stretch the Earth, and the stretch grows with latitude and with the size of the area. Over a city block the two distances agree. Over continents they can disagree a lot, and near the equator they can be surprisingly close: Esri notes that for Singapore to Nairobi, about 7,440 km, the Web Mercator planar result is less than a metre longer. Because you cannot know in advance which case you are in, always use the geodesic when you compute a Latency lower bound. Using a planar distance that happens to be too short would even produce a “bound” that is not a bound at all.

With the right distance and the right formula in hand, the bound can finally meet reality. Put the client in Dammam and the server in three AWS regions: US West (Oregon, us-west-2), Europe (Frankfurt, eu-central-1) and Asia Pacific (Tokyo, ap-northeast-1). For each, compute the one-way Latency lower bound, then compare it with the Round-trip time (RTT) measured with aws-latency-test.com.

The rule behind the example: compare like with like. An RTT is a round trip, so compare it with twice the one-way bound, never with the one-way figure itself. Doing that for all three regions tells the same story each time: the measurements sit about 2.9× to 3.4× above the vacuum round-trip bound. A ratio that stable across very different distances is a hint that the extra cost is systematic, not bad luck on one path.

Where the factor of three comes from

• About 1.5× comes from glass alone, because light in fiber moves at about two thirds of $c$.
• Cables do not follow the geodesic. They follow coastlines and seabeds, land at a few stations, and backhaul over land to data centers.
• Each router on the way adds processing and queueing time, two of the four delays in the next concept.

Research agrees with this breakdown. Singla and colleagues measured Internet paths worldwide and found router paths about 2.3× the speed-of-light latency at the median. After removing the 1.5× fiber factor, path detours alone still leave about 1.53×.

The factor of three needs a precise vocabulary. Follow one 1,500-byte packet across one router onto a 4,390 km fiber link running at 1 Gbps. Pushing its 12,000 bits onto the wire takes 12,000 ÷ 10⁹ s = 12 µs. Travelling the fiber takes about 22 ms. The router’s own work takes microseconds. Waiting behind other packets takes anything from nothing to a very long time. Now slow the link to 10 Mbps: pushing the bits out now takes 1.2 ms, and the fiber trip is still 22 ms.

Those four pieces are the four packet delays, and Kurose and Ross (section 1.4) add them up at every node a packet crosses. Processing delay happens inside switches and routers. Queueing delay happens in buffers when traffic piles up. Transmission delay happens at the network interface and depends on bandwidth. Propagation delay happens on the physical channel and depends on distance. Only the last one is the physics behind the lower bound; the other three are what real equipment and real traffic add on top.

End to end, you add the nodal delay over every hop on the path, and an RTT adds it again for the return direction. That sum is exactly the measured RTT from Dammam, which is why it sits so far above 2d/c. Hold on to the contrast that exams love: transmission depends on packet size and bandwidth and has nothing to do with distance, while propagation depends on distance and the medium and has nothing to do with bandwidth.

Can it really be 100 times the bound?

The lecture claims Internet latency can reach 100× the Latency lower bound. For whole page loads, measurements support this. Singla and colleagues found that fetching just the HTML of popular web pages took 34× the round-trip speed-of-light latency at the median and 169× at the 90th percentile. Those fetches include more than the four per-hop delays: a DNS lookup, the TCP handshake and TCP’s slow start all add round trips. The lecture’s example of a 15 ms theoretical latency turning into 1,500 ms is best read the same way: an illustration of network delays stacked with protocol and application effects, not four delays on a single link.