Satellite Internet Protocols – TCP/IP over satellite

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.

The Internet relies on the Transmission Control Protocol (TCP) to ensure packet delivery without errors. TCP works by sending a certain amount of data, the “window size,” then waiting for the receiver to send an acknowledgment of receipt. With TCP, the sender cannot transmit more data until it has received an acknowledgment. If an acknowledgment does not arrive in a timely manner, TCP assumes the packet was lost (discarded due to network congestion) and resends it. When packets go unacknowledged, TCP also slows the transmission rate to reduce congestion and to minimize the need for retransmissions.

TCP/IP sessions start out sending data slowly. Speed builds as the rate of the acknowledgments increases which verifies the network’s capacity to carry more traffic. This is known as slow-start, followed by a ramp-up in speed. The speed of the connection builds until the sender detects packet loss from a lack of an acknowledgment. This allows TCP to achieve the fastest practical data transfer rate for the conditions present on the network.

The standard TCP/IP protocol does not understand that a satellite is involved and operates as if the satellite latency was caused by congestion whereas the true reason is the distance involved. If uncorrected, this effect causes all packets over a satellite network to be sent 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. Inspite of acceleration techniques, some applications are latency sensitive.

Applications that generally do not work well on high latency networks include the following:

  • Interactive online gaming.
  • Generally, any application that requires client software loaded at the remote site are latency sensitive unless adjustments are made at both the client and server end.
  • UDP – The UDP protocol cannot be accelerated because it is not a connection-based protocol.
  • NetBIOS – This is a LAN technology that cannot be accelerated as it is not designed to function in a WAN environment.
  • Drive-mapping is not supported over satellite except through a VPN tunnel.
  • RDP (Citrix) and RCP (Exchange) can also be slow over a satellite connection.
  • Citrix  is also latency sensitive and will generally function poorly over satellite.A Citrix engineer should be consulted prior to its use over satellite to determine how a particular customer-specific application will perform.
  • Multi-site configurations requiring remote-to-remote communications will have twice the latency (due to the double hop through the satellite), and may have difficulty communicating directly with each other, although it is possible to successfully use the system in this manner.A mesh configuration may be a more appropriate solution for your needs.
  • Terminal emulators must have local-echo enabled at the remote site in order to perform properly.