4.1. PEPsal classification¶
As far as layering is concerned, PEPsal can be considered as a multi layer proxy, because in order to implement the TCP splitting, which is of course a transport mechanism, it must also operate at IP and Application layers. Considering distribution, PEPsal can be classified as an integrated PEP, since it runs only on a single box on the forward link satellite gateway. PEPsal can be either asymmetric or symmetric, depending on its network layer configuration. It can act in the forward direction but also in the return one. Finally, PEPsal is transparent in the customary asymmetric configuration. Since modifications are not required in both endpoint connections, TCP users are unaware of the connection splitting performed at the satellite gateway.
4.2. PEPsal description¶
PEPsal operates at three different layers (IP, TCP, and Application). At the network layer, PEPsal uses “netfilter” to intercept the connections that involve the satellite link (it “steals” the TCP SYN packet in the three-way handshake phase of a TCP connection). Then, it works at transport layer, pretending to be the opposite side of the TCP connection for each of the two end points involved. It acts as the TCP receiver with the source, by acknowledging the incoming packets, while at the same time it sets up a new TCP connection towards the real end point receiver. It is important to stress that on this second connection an enhanced TCP variant can be used. Finally, to exchange data between the two connections, it is necessary to make use of an application that directly copies data between the two sockets.
Now we can see how it allows a real performance improvement. First of all, an important improvement is achieved by simply splitting the connection. In this way, the impairments introduced by the satellite link (long RTTs and losses) are removed from the first connection, which becomes short-RTT and error free. A path with short RTT and no errors makes the connection speed grow fast for two reasons :
- The TCP congestion control algorithm is fundamentally driven by the ACK flow, a short RTT is a requisite for a fast opening of the congestion window (cwnd), which implies a fast increase of the transmission rate.
- The reductions of the transmission rates caused by losses are avoided. Indeed, TCP standard assigns any loss to congestionso it reacts in dividing by 2 the congestion window. Consequently it will divide by 2 the transmission rate. We avoid this phenomenon with error free link.
Although useful, the splitting technique itself is not able to counteract losses and long delay on the satellite segment. To cope with them, it is necessary to use a transport protocol designed to deal with these problems. While distributed architectures can use transport protocols different from TCP (with the addition of a PEP agent on the receiver side), integrated architectures, as PEPsal, must still rely on TCP. Instead of using TCP standard (NewReno, SACK), they can benefit the advantages provided by advanced TCP versions. This is the case, for instance, of TCP Westwood, TCP Hybla and others. In particular, TCP Hybla, which is the TCP variant adopted by the PEPsal architecture, was conceived to counteract performance deterioration caused by the long RTTs on satellite links. It consists of a set of procedures, which includes an enhancement of the standard congestion control algorithms, the mandatory adoption of the SACK policy, the use of timestamps, etc. You can find a complete description of this TCP variant on http://www.mathcs.emory.edu/~cheung/Courses/558/Syllabus/Papers/TCP-Hybla.pdf.
4.3. PEPsal implementation¶
The bottom area (“Linux”) represents the Linux kernel, which is accessed to set up the netfilter targets and to make use of a modified protocol for all TCP connections. Incoming TCP segments are mangled, so the TCP SYN segment is passed to the PEPsal user application via the ipqueue library, while the rest of the packets containing segments for that connection are redirected to local TCP port 5000.
The small area on the right side (“Libs”) shows which system libraries have been used to implement PEPsal. Shared memory is a fast and powerful inter-process communication method, used by the PEPsal processes to share information about incoming and outgoing connections, their state and their original end points. Ipqueue library is commonly used to pass a whole IP packet, including network and transport headers, to user space applications. PEPsal uses it to read information from incoming TCP SYN packets, which contain no useful data except for the headers themselves, and would be normally forwarded by the gateway to their destinations to initiate new connections.
The top area (“PEPsal”) represents the user space application itself, which is completely written in C using the two libraries described above.
One process, the “queuer”, constantly waits for data coming from netfilter, by blocking on the ipqueue read routine. When Linux netfilter reads incoming TCP SYN segments and copies them into a queue, the queuer annotates the information (IP addresses and TCP ports) on the two end points in a known zone of the shared memory. Then, the SYN packet is released and continues its path through the netfilter chain. Just after that, the SYN packet, as well as all every subsequent packet containing a segment of that connection, is redirected by netfilter to TCP port 5000, where a TCP daemon, the “connection manager” is listening for it.
Another process, the “proxy server”, accepts the connection and searches in the shared memory for the instance matching the source address and the TCP port of the host that has started the connection. Once the destination IP address and port have been found in the connection array, a new TCP connection is attempted towards the real destination. After establishing the two connections, the proxy starts reading from one TCP socket and writing all the data in the other one. When one of the two connections ends, its twin socket is closed and its memory zone is released.