> On Jun 22, 2015, at 3:11 PM, William Herrin <b...@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-sy/ir-15-sy-book/ir-rt-bsd-sat.html) 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".
signature.asc
Description: Message signed with OpenPGP using GPGMail
