Latency you cannot engineer away

A geostationary satellite sits roughly 35,786 km above the equator. Radio travels at the speed of light. Up and down is about 240 ms of propagation before anything else, and a round trip is therefore around 480 ms at best. In practice, with processing and scheduling, 550 to 650 ms is normal.

No amount of bandwidth changes this. It is a property of the distance.

What it breaks

Anything conversational. A protocol that exchanges several messages before doing useful work pays the round trip each time. A file transfer that negotiates, authenticates and then transfers may spend most of its time waiting.

TCP suffers particularly. Its throughput is bounded by the window size divided by the round-trip time, so on a long path even a large window yields modest throughput unless window scaling is negotiated correctly. A 64 KB window over 600 ms gives about 850 kbit/s, no matter how wide the link is.

What to do about it

Reduce round trips. Cache aggressively at the remote site. Batch operations. Prefer protocols that pipeline requests over those that wait for each reply.

Enable window scaling and generous buffers, and confirm from a capture that scaling was actually negotiated, rather than assuming.

Terminate locally. Anything a remote site can do without crossing the link, it should. Local DNS resolution and local authentication caching remove entire round trips from every user action.

Set expectations honestly

Users describe high latency as “slow”, which leads people to buy more bandwidth. More bandwidth does not reduce latency and will not change the experience. Being able to explain the difference — and show that the link is not congested — is most of the job.

Low-earth-orbit constellations change the arithmetic substantially, since the distance is a fraction of geostationary. Where a service is genuinely interactive and geostationary latency is the limiting factor, that is the change worth considering rather than another tuning exercise.