Toolkit

Story: Is a satellite-based WAN connection right for you?

• 
• 

In my opinion, this article contains incomplete, misleading and incorrect information.

Security: actually VPN methods such as L2TP, PPTP and IPSec are seldom used in the satellite industry because they disable the TCP Acceleration, Spoofing or PEP (performance enhancing proxy) technology built into most shared broadband satellite solutions. Most satellite communication systems are at least as inherently secure as Frame Relay or other unencrypted terrestrial leased line services. Generally, traffic is encrypted once it passes over the satellite link to the teleport, prior to being placed on the Internet. Instead of placing the VPN appliance at the remote, site, it is placed at the teleport or central hub. This also simplifies and reduces VPN management tasks, by the way.

Technology: TCP is a guaranteed delivery protocol. That means a sending device transmits a small amount of data and waits for an acknowledgment (ACK) before sending more data. Because of the latency (7 seconds is a ridiculous number to set expectations with), TCP cannot transmit at the full satellite bandwidth capacity, so software on either side of the link intercepts the TCP headers and responds with ACKs locally, thus allowing full speed transmission. When you encapsulate/encrypt data in a VPN packet, you lose the original TCP headers and the packet cannot be accelerated. It will top out at about 70 - 80 Kbps regardless of how fast the link is. You can play with TCP windows and so forth to control this a bit, but not much. SSL VPNs only encrypt data, and not the headers, so they operate at full speed over satellite links. If satellite link security is mandatory, solutions are available to support secure, encrypted communications over satellite that I won't go into here.

Latency: If one does the math - a round trip from remote site to satellite to teleport and back, with each satellite link being approximately 23,000 miles, you have a total of 92,000 miles that the signal has to travel. Dividing this by the speed of light yields .4946 seconds for the round trip. There is some small amount of additional latency depending on how far the sites are from the equator, since it is the total distance that matters, plus the latency added by the hardware on either end, but in general the actual round trip satellite latency time is about 550 - 600 ms. The author actually refers to a one-way latency of 7 seconds, thus implying a 14 second ping time over satellite - that is absolutely ludicrous!

Now it is true that some systems will have round trip pings as high as 3 seconds, however the additional delay is due to the bandwidth contention mechanisms used, mostly by low-end consumer-class services. Dedicated satellite service, or newer shared broadband enterprise-class systems will deliver consistent latency of about 1/3 second in each direction. This is just barely worse than the latency that two users on cell phones experience when talking with each other, and is very acceptable for business use. There are systems available that provide consistent, toll-quality service using G.723 and G.729 codecs for VoIP with very acceptable latency, in which calls are comparable to high quality cell-phone connections.

One final point on latency - it's not the length of the latency that kills voice quality - it's inconsistent latency, because that creates jitter. Advanced systems deliver consistent latency for VoIP, eliminating the need to further delay the voice in jitter buffers to smooth out the voice.

Cost: Cost is a relative subject. In the U.S. it is true that there are so many alternatives that it is often difficult to justify satellite service for VoIP unless the site is really remote; however in many places around the world, satellite service is the norm and terrestrial solutions cannot begin to compete because they are outrageously expensive due to their lack of availability.

Editorial: It is ridiculous to leave readers w

• 
• 

• 
• 
• 

Full Talkback thread