Для полноценной работы с сайтом в вашем браузере должен быть включен JavaScript.

Evanti PEP

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.

Method

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:

  • Guaranteed data delivery
  • Support of all message based protocol for transport, including the Data Link Layer operation option
  • No strict unacknowledged data window limitations
  • NACK tool for retransmission of the unacknowledged data
  • Flexible congestion control tool based on the integration with our QoS and hardware components of the user terminal

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.

Key Advantages

  • Fast connection establishment. TCP over satellite features a very slow ramp up time, but with the Advantech Wireless PEP this ramp up is dramatically accelerated to reach the maximum speed allowed for the connection.  Response is obtained within just 2RTT
  • Seamless integration with QoS that drives the utilization of the available channel capacity to 100% immediately after the connection is established; it reduces the load time manifold and dramatically increases the QoE
  • DNS catching on the client side can reduce the number of DNS requests sent over the satellite link
  • Stream Compression rates can vastly differ depending on the content type. One can expect up to 40-50% compression on HTML pages
  • Acknowledge Frequency Reduction allows to reduce the number of ACKs sent back to the server. Thanks to this feature, the PEP performs in a more efficient manner when return channel policies are not granted (e.g. in VBDC) enhancing the overall efficiency of the band utilization. When generic TCP is used alone or with a standard PEP, the ratio between the required return link capacity compared to the forward one (and reverse) amounts to 1:20. Evanti PEP allows for the use of dozens of bytes/second ensuring a return/forward link ratio of 1:1000 or above
  • In addition to other benefits and optimization opportunities, TCP-header compression provides for additional traffic saving in forward and return channels