TCP PEP and QoS Software Modules for the HTS Satellite Communication System
ClientÂ
A global supplier of satellite telecommunications equipment.
Â
Challenge
The client approached us to develop a QoS module and implement Transmission Control Protocol (TCP) through a performance-enhancing proxy (PEP) that enables optimal TCP performance over geostationary satellites.
The large distance of the geostationary orbit from the Earth's surface (about 36,000 km) leads to a considerable signal delivery delay from the satellites, equal to ~ 0.5 s. In this case, TCP connections may be inside VLAN, GTP, and GRE tunnels, which must be recovered on the remote side.
It is possible to have a situation when identical TCP connections (with the same combination of IP addresses and TCP ports) are located inside different tunnels; and it is necessary to ensure that they are processed correctly.Â
Approximate speed requirements for the software are 5 Gbit/s on a 4-core Intel Xeon processor with a base frequency of 2 GHz.
The next phase of our project involved the development of a high-performance QoS software module for high-throughput satellites (HTS). The main tasks of this stage were to develop a new QoS kernel for the ASAT-III PHS software and replace the old kernel used in the ASAT-II QPS server.
The final task was the implementation of the developed QoS system using the CISCO CONFD toolkit into the customer's software development kit (SDK) based on Intel's Data Plane Development Kit (DPDK).
Â
Pic 1. QoS module in the customer's general SDK structure
Â
Solution
1. Concept development
When designing the architecture and the development plan for future software, we considered possible engineering problems and solutions in advance. For example, to prevent TCP connections from different VLANs and tunnels from crossing each other within the performance-enhancing proxy, we would need to replace the IP addresses and TCP ports of each TCP connection with a unique combination. Then, on the remote side, these values would be replaced with the original ones — after the performance-enhancing proxy was passed. If needed, we would recover IP addresses, TCP ports, and VLAN, GRE, GTP tunnels.Â
All information about the original IP and TCP port values, VLAN, GTP and GRE parameters and tunnels are passed through the performance-enhancing proxy while the TCP connection is established.
2. Software development
The project consisted of two stages: first, we developed and prototyped the Transmission Control Protocol (TCP) software; and second, we integrated it into the customer's SDK.
We developed the software to implement TCP on a free software basis and checked it for compliance with the basic functional and speed requirements.Â
We built the software prototype based on the Linux eBPF technology.
Also, our engineering team developed the basic QoS ASAT-II module on the OS image provided by our customer. The Linux 3.16.7 kernel and libnetfilter_queue 1.0.2 library were used as the main components for writing the module, including custom settings of the kernel solution and NetLink interface that provided performance optimisation and advanced L2 features. The ASAT-II QoS kernel used the iptables NFQUEUE utilities and the libnetfilter library to handle packets in the user space application.
In the second phase, we implemented the QoS system in the customer's SDK using DPDK technology. The throughput of the system reaches ~1 million pps.
Pic 2. The basic HTS QoS architecture
Â
Pic 3. Example of a QoS architecture
Â
Business Value
Our client received new software that provides TCP connections within VLANs, GTP, and GRE tunnels via a performance-enhancing proxy. We also developed and verified the QoS module with unit and performance tests and implemented it in the customer's SDK. Based on the test results, we prepared the project documentation.
The finished software will be used in communication systems via geostationary satellites.
Â
Â