On Wed, 27 Feb 2002, Dickson, Brian wrote:
Another latency factor is something not normally factored in land-based systems. Doppler shift! Satellites are seldom in perfect orbits - they drift up and down, returning to zero (thus in stable orbit), but the relative motion results in clocking issues.
Satellite modems usually have 8ms receive buffers to accommodate drift,
8 ms is enough to acommodate a 2 ms * c = 600 km drift in both directions. Unless Kepler is letting me down, this would mean a 30 minute difference in the time it takes the satellite to orbit the earth. Somehow I'm fairly sure they manage to keep this much closer to 23 hrs, 56 min. All of this stuff is only of interest to applications with very strict bit rate requirements, we can easily do without it for IP.
What factors should be considered in end to end connectivity architecture when utilizing a satellite link?
If you have end users, put in a huge web cache, as big as you can afford.
Hmmm, maybe put one on board the satellite?
Not only will it reduce bandwidth usage, it lowers average latency considerably. Doesn't help non-cacheable content, or other applications, directly, but lowering usage minimizes latency at least.
It also helps in the latency * window size = bandwidth problem, because you get to terminate the TCP connection in a place which is also under your control, so you can forego slow start, use the TCP high performance extensions and the large window sizes they make possible between the client and the proxy.
Another approach is asymmetric - buy a low-speed terrestrial link for return path. Round-trip time is the sum of transmit and receive paths, so reducing even one of them helps most applications.
And you can tunnel interactive traffic over the low bandwidth terrestrial connection and only use the satellite path for bulk.