IPSec VPN Optimization over Satellite

Set VPN to use UDP instead of TCP protocol. This reduces the amount of traffic passed over the satellite. TCP requires acknowledgement packets and UDP does not. Satellite has less than 1% packet loss, usually 0%.

Set the timeout on applications to the longest time allowed. This reduces retransmissions of data which take longer than normal to reach the destination. Because satellite is shared media some packets have longer than normal latency when waiting their turn to transmit data.

Set the packet size to the largest size possible. This reduces the amount of trips data need to traverse the satellite link. Small packets = several trips and large packets = one trip. This only works on applications which allow this to be done. Most do not.

The problem with satellite communications is high latency. In order for a two-way satellite service to perform properly in conjunction with traditional terrestrial networks (Internet, Intranet), satellite data networks must employ special techniques to deal with the extra 44,600-mile space segment of the connection. Without those steps, the increased latency, the time required to traverse the extra distance, means that TCP severely limits performance.

Terrestrial networks typically have round-trip latencies in the range of 35 to 100 ms. Satellite networks, due to the distance of geo-synchronous satellites above the equator, require 550 ms or more. Some satellite connections have much higher latencies. Depending upon the satellite hardware and subscription policy of the service provider, latencies of 800 ms to as much at 2,000 ms or more can occur. TCP interprets the additional satellite transit time as network congestion. If uncorrected, this effect causes the network to send all additional packets at the slow-start rate.

Current satellite data networks employ a technique referred to as TCP acceleration or IP spoofing to compensate for the extra time required to transit the space segment. Special equipment at the carrier’s main satellite hub appears to terminate the TCP session, so it appears to the sender as the remote location. In actuality the device at the satellite hub acts as a relay or forwarder between the originating terrestrial location and the remote satellite unit.

When the spoofing equipment receives Internet traffic destined for a remote satellite location, it immediately acknowledges receipt of the packet to the sender so more data packets will follow promptly. This way the sender never experiences the actual latency to the remote site because acknowledgments return rapidly. As a result, TCP moves out of slow-start mode quickly and builds to the highest practical speed.

To prevent packets from being acknowledged twice, the spoofing equipment suppresses acknowledgments from the remote site. In this way, computers behind a satellite link communicate seamlessly and efficiently with servers on the terrestrial Internet.

IPsec VPNs not only encrypt the data portion of packets, they also encrypt the TCP port number and IP address of the sender’s computer. (Think of TCP port as the apartment number while the IP address is that of the building.) Consequently, only the VPN software at the remote site can decipher where packets originated and acknowledge receipt of data.

Popular IPsec VPNs, therefore, defeat TCP acceleration over satellite links because ground stations cannot adjust the fields in the header when those fields are encrypted. This situation requires that acknowledgments transit the space segment twice (over and back) and results in substantial performance degradation. The impact on performance increases as the latency rises.

For additional information visit:
http://www.broadskynetworks.net/VPN_over_satellite.html
or please contact:
Vince Lewis
Director of Technical Support
Broad Sky Networks
Phone 541-678-5981
VLewis@broadskynetworks.net