Undoubtedly, the role of the Internet in our day to day life has been continuously increasing over the recent decades. It is noteworthy that the Web becomes more and more accessible and taps new territories. In regard to traffic supply to remote areas unreachable by traditional methods, geostationary satellites are to be mentioned as the most efficient technology.
The well-known irresolvable issue of networks using GEO satellites is the round trip time that cannot be reduced below 500ms due to the distance between the points. The problem gets less critical when a satellite is used for broadcasting (e.g. TV), but when it comes to providing Internet access (or to any TCP/IP based network), the issue causes minor performance problems mainly resulting from pecularities of the TCP protocol, namely:
1. TCP window size limitations
With the parameter limited to 16 bits in the TCP specification, the maximum window size is equal to 65535 bytes. Given this size and the delay of 500ms, the maximum connection speed will be about 1Mbps. The actual figure depends on the OS implementation and on the application that uses TCP for data transfer; note that popular OS’s have an even lower value of the above mentioned parameter bringing the upper speed limit further down. Later on, as users required faster connections, TCP window scaling came into being; yet, this extension often requires advanced settings in both application and the OS.
2. TCP connection setup pecularities (3-way handshake)
To establish a TCP connection, the passive and the active sides have to exchange 3 TCP packets. Given the delays, it results in a considerable QoE impairrment, especially with modern web-services in place, as these require starting dozens and hundreds of new connections for a single operation.
3. Pecularities of the TCP retransmission strategy
Although in theory the RTT limitation is about 500ms, actual delays in satellite networks can be higher and vary in time owing to pecularities of a specific architecture and load. With many TCP frameworks basing a segment retransmission decision on average RTT values, repetitive sending of the delivered data is likely to reduce channel utilization efficiency. Also, TCP retransmission is closely related to the congestion control mechanism that is covered in detail below.
4. Limitations related to the TCP slow-start and congestion control
The TCP design derives from the fact that the peer-to-peer connection speed is unknown at the point when the connection is established; thus, any connection starts with the data being sent at the minimum speed. While the rate of further speed increase depends on the specific TCP framework at the source, most of such frameworks have this rate linked to the channel delay. Thus, even with a free channel, high speed will be either achieved with a considerable delay or never achieved during a session involving a small data amount.
Moreover, congestion control algorithms interpret TCP retransmission events (some also take into account RTT dynamics) as congestion signs and reduce the TCP connection speed in response. Yet, in satellite networks packets loss and RTT changes may have other reasons, and an effective TCP connection speed is likely to suffer more.
Taken together, the above issues complicate the use of GEO satellites as TCP transports impairing QoE, causing the sub-optimal, inefficient use of frequency resources and even blocking the use of some applications that are totally available in terrestrial networks.
To remedy for the above, Evanti developed a comprehensive solution mainly targeted at setting up a flexible system suitable for various network configurations including areas served by GEO satellites and supporting integration with a wide range of equipment.
The solution is based on a proprietary protocol used in network segments with high delays. Tailored to satellite environments, this protocol allowed us to resolve all the above issues and rule out almost all TCP-related limitations resulting in higher general QoE in networks using GEO satellites.
For the description purposes, the Evanti protocol can be represented as two layers. The first is a versatile transport protocol exhibiting the following parameters:
Depending on specific tasks, the second layer may contain various protocol combinations for the required optimization.
A TCP operation uses a solution based on RFC-3135 and applies a transparent TCP PEP with a split-connection.
For best bandwidth utilization of the second layer can also contain a data compression module.