On Jun 22, 2015, at 3:11 PM, William Herrin <bill@herrin.us> wrote:
Two-way satellite systems based on SV's in geostationary orbit (like the two you're considering) have high latency. 22,000 miles out, another 22,000 miles back and do it again for the return packet. You'll start around 500ms latency and go up from there. Any kind of interactive session (like SSH and RDP) will be excruciating.
It is indeed. This is first-hand in the sense that I once worked for an earth station manufacturer and did a fair bit of work related to this environment, and second-hand in that my sister, for a while, used VSAT connectivity to her home. The trick in the context is what's called a "performance-enhancing proxy", or PEP. What it does, in concept, is terminate a TCP connection at each earth station and use some form of private protocol over the bird. Cisco RBSCP (which maps TCP connections to SCTP sessions over the bird, http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/configuration/15-...) is an example of such a technology. The obvious benefit of a PEP is that it can convince a TCP sender to keep enough data in flight to make good use of the throughput rate of the satellite - you have a start-up issue with the first RTT, but after that it has essentially figured out what the effective window should be and makes that happen. The downside of a PEP is when the application is itself interactive (it's not about rate, it's about responsiveness clocked by end-to-end RTT) or the protocol in question isn't TCP (noting that TCP in IPsec ESP isn't TCP to the PEP - it's IPsec ESP, and can't be goosed along). In my sister's case, her description of the service was somewhat colorful, and included the word "slow".