WAN Optimization for Satellite Networking

Masaryk University Faculty of Informatics

WAN optimization for satellite networking

Master’s Thesis

Patrik Rehuš

Brno, Spring 2019 Masaryk University Faculty of Informatics

WAN optimization for satellite networking

Master’s Thesis

Patrik Rehuš

Brno, Spring 2019 Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Patrik Rehuš

Advisor: doc. Ing. RNDr. Barbora Bühnová, Ph.D.

i Acknowledgements

I would like to express my gratitude to my supervisor doc. Ing. RNDr. Barbora Bühnová, Ph.D. for her comments and supervision of my thesis. I would also like to thank Ing. Petr Holášek for patience, guidance, support and provide input data for testing. Last but not least, I would like to thank my wife for support during my studies.

ii Abstract

The modern airplane provides satellite connectivity not only for operational data but also for Internet access for customers. However, satellite links are characterized by the long delay in contrast to terrestrial networks, which degrade the whole throughput connection. So the goal of my thesis is to explore approaches to accelerate satellite connection using a different way. Part of this thesis is alsoa virtual machine of satellite accelerator which contains installed tools used for testing. It can also be applied for other testing purposes or development of the new satellite accelerating technique. With a small modification, it can be deployed in the real link too. This thesis also includes tests results that compare the selected acceleration technique with the traditional approach.

iii Keywords

Accelerator, satellite link, PEP, proxy, compression, TCP

iv Contents

1 Introduction 1

2 Satellite communication 3

3 Transmission Control Protocol (TCP) 6 3.1 Congestion avoidance algorithm ...... 7 3.1.1 Compound TCP ...... 7 3.1.2 TCP Hybla ...... 8 3.1.3 TCP Cubic ...... 9 3.1.4 TCP Proportional Rate Reduction ...... 10 3.1.5 TCP-Peach ...... 11

4 Other transport protocols over satellite links 13 4.1 XTP ...... 13 4.2 SCPS-TP ...... 13 4.3 TCP-Noordwijk ...... 14

5 Performance Enhancing Proxies 16 5.1 Characteristics of PEPs ...... 16 5.2 Techniques of accelerating ...... 18 5.3 Problems of Performance Enhancing Proxies ...... 21 5.3.1 VPN tunnels ...... 21 5.3.2 HTTPS ...... 22 5.4 Additional techniques ...... 23 5.4.1 TCP Fast Open ...... 23 5.4.2 DNS Cache ...... 24 5.5 PEPsal ...... 26

6 Header compression 28 6.1 Van Jacobson Header Compression (VJHC) ...... 28 6.2 IP Header Compression (IPHC) ...... 29 6.3 Compressed Realtime Transport Protocol ...... 30 6.4 RObust Header Compression (ROHC) ...... 31 6.4.1 Operation modes and states ...... 32 6.5 SCPS Header compression ...... 33

v 7 Testing 35 7.1 Setup topology ...... 35 7.1.1 Simulator ...... 36 7.2 Test results ...... 38 7.2.1 PEPsal as intermediate node ...... 38 7.2.2 TCP Fast Open ...... 39 7.2.3 DNS cache ...... 41 7.2.4 RoHC Header compression ...... 42 7.3 Conclusion of testing ...... 45

8 Conclusion 47

Bibliography 49

A Appendix A 58 A.1 Electronic Attachment ...... 58

vi List of Figures

2.1 Example of TCP ACK handling with local retransmissions 4 4.1 Throughput comparison of TCP Noordwijk [52] 15 5.1 Splitting TCP connection in integrated and distributed PEP 17 5.2 Example of TCP ACK handling with local retransmissions 19 6.2 Packet size after compression using RoHC 31 6.3 ROHC modes with states transitions of compressor 32 7.1 Topology of testing network using virtual machines 35

vii 1 Introduction

The Internet is nowadays used more often than a few years ago. It is due to the increasing trend of "smart" devices, cloud services and IoT. The applications often run in the cloud, use various synchronization or can be controlled in real-time by remote access. Due to these changes, also networks had to adapt to this increasing trend. Appli- cations require more and more bandwidth with low latency. These requirements can be met in terrestrial networks more easier than in satellite networks. It is due to the fact that satellite links are limited by physical properties. Satellite connection that uses GEO1 satellite placed on the orbit 35 000 km above the Earth’s surface makes long Roud-Trip-Time (RTT). Along with high latency, there is another problem – Slow-Start. At the beginning of the TCP connection, there is no information about available bandwidth. TCP uses a method called Slow-Start for estimating available bandwidth. However, this method causes bandwidth cannot be fully utilized, mainly in small files transmission. Another property is the limitation of bandwidth, which in most cases are different for upload and download (asymmetry). The result of the properties mentioned above is linked with large bandwidth and delay product (BDP), which represent the total number of packets needed in flight while keeping the bandwidth fully utilized. This product represents the congestion window [48]. All these properties of satellite connection can be challenging for the standard implementation of TCP. To eliminate these negative ef- fects the satellite links needs to be accelerated – whether via higher bandwidth utilization, smaller latency or another improvement. There are different approaches to acceleration. Some techniques like[29] or [28] try to reduce the amount of transferred data by various compression methods, and others are focused on minimizing Slow-Start as much as possible to speed-up transmission. The aim of this thesis is to find possibilities of accelerating satellite links. Each method has its own scope of usage and also some advantages and disadvantages. The thesis summarize these properties for a

1. Geosynchronous Equatorial Orbit, also known as Geostationary satellites

1 1. Introduction

more comfortable choice of available methods, which can be used in the real implementation of satellite accelerator. This thesis is divided into eight parts. Chapter 2 introduces the reader into the basic principle of satellite communication and also used encoding and modulation technique. Chapter 3 describes Trans- port Control Protocol as the most used transport protocol in current networks. Next, it explains why the congestion avoidance algorithm degrades satellite link to full utilization and also an overview of selected algorithms. Chapter 4 examines other specific transport protocols that can be used on the satellite link. Chapter 5 is focused on Performance Enhancing Proxy (PEP) which tries to enhance the speed of the satellite link using different techniques and approaches. This part also includes a section about problems of PEP usage caused by improving the security of transmission. The next possibility to accelerate the satellite link is to use header compression, which is described in Chapter 6. This technique tries to reduce the size of transmitted headers by omitting static fields or field which can be deducted from previous packets. Chapter 7 includes results of tests performed based on previously described chapters. It also concludes these results and discusses the limitation of the whole testing. The last chapter 8 sum- marizes the problems connected with TCP on satellite and discusses potential future improvements of this thesis.

2 2 Satellite communication

Term satellite represents a small object in space which connects two points on Earth. It is something like a repeater because the received signal is amplified, frequency is changed and send back to other Earth station [1]. In the last decade, satellite communication is becoming more and more popular [2]. It is mainly due to the fact that satellite can transmit any kind of data such as television signal, internet access or telephone calls. In some situations, satellite link can be replaced by other communication media such as fiber cables, GSM network, ethernet link and so on, but not always is it possible. For example internet access on airplane board, communication with the area after a natural disaster, internet access to the island far from the mainland, marine communication or other cases. This thesis is focused only on Internet access via satellite link. For satellite communication, there is a used analog signal modified with encoding and modulation techniques. Encoding element of station prepares digital data for transmission through the link. Encoding consists of one or more numerical process that better match the data to the specific characteristics of the satellite link. Encoding can be performed on the last node before the satellite link or dedicated node in the path. Based on [3] the common encoding techniques are the following:

∙ Forward Error Correction – used for the reduction of errors by adding redundant bits into data. Advanced FEC techniques use combinations of specific error-correcting codes through the process of concatenation. The benefit is lower error rate and reduced power requirement. Also, it improves the quality of transmission in term of the bit error rate (BER). For FEC is responsible Data link layer of satellite transmitter and so it is not covered in this thesis.

∙ Encryption – make the data transfer via satellite safe (important for e.g. military transmission). On the other hand, it has complex management and could introduce a delay. This technique is not also included in this work because it does not enhance satellite traffic.

3 2. Satellite communication

∙ Protocol adaptation – enhance standard TCP/IP stack for satellite communication using improvement such as larger window size or adding some special extensions such as selective acknowledgment (SACK). This method is described in detail in Section 3 and Section 4.

∙ Compression – is used to reduce the total amount of bits to increase throughput. However, on the other hand, it can introduce additional delay and may reduce quality (in the case of lossy compression). The special type of compression is header compression that is examined in Section 6.

Modulation is used to transform the digital input signal into analog one suitable for a specific transmitting channel. The signal is modu- lated on carrier frequency (central frequency is different than zero). For satellite communication, there are used four basic bands1: L-band (central frequency 1 - 2 GHz), C-band (4 - 8 GHz), Ku-band (12 - 18 GHz) and Ka-band (24 - 40 GHz) [4]. There are three basic digital modulation schemes Amplitude Shift Keying (ASK), Frequency Shift Keying (FSK) and Phase Shift Keying (PSK). The combination of ASK and PSK is also known as the QAM (Quadrature Amplitude Modula- tion) [5]. Nowadays the most used modulation schemes of satellite link for internet access are QPSK (Quadrature PSK), 8PSK and 16QAM. More detailed information about modulation schemes can be found for example in [6].

l e l R n e e n n F tu a n o r h a rw n c h c c a h rn rd a u rd c n t h n e a a e R w n l r n o e F l Internet User Terminal Client station ISP hub (Gateway) Figure 2.1: Example of basic Internet access via satellite link

1. For satellite communication it is possible to use also other bands such as X-band, Q-band, V-bang, and others.

4 2. Satellite communication

In 2000 the DVB consortium published world-leading standard Digital Video Broadcasting – Return Channel via Satellite (DVB-RCS) [7] as vendor-independent bi-directional Internet communication. Cur- rently, improved version 2 (2014) was standardized by the European Telecommunications Standards Institute (ETSI). In DVB-RCS the forward channel (toward to client) encode IP packet into MPEG-2, similar to digital television. The return channel (direction from client station) uses a multi-frequency Time Division Multiple Access (MF-TDMA) transmission scheme which provides high bandwidth for multiple users. Using this technology user can use the bi-directional connection to the Internet. In other words, the packet from user client station trav- els into user terminal like VSAT (Very Small Aperture Terminal) which using some encoding and modulation scheme send data via return channel into internet service provider hub (gateway). This Hub uses reverse demodulation and decoding scheme to obtain origin packet that was sent by a client into the Internet. This basic connection via a satellite link is illustrated in Figure 2.1. The Transmission Control Protocol (TCP) as a transport protocol is used in most of the data transmissions over networks. However, TCP uses the congestion control algorithm to avoid the congestion of network elements. Together with physical properties of the satellite link and Slow-Start phase this approach rapidly gradates the speed of satellite connection.

5 3 Transmission Control Protocol (TCP)

TCP provides connection-oriented, reliable, ordered and error-checked service of delivering packets to host communicating via an IP network. TCP as a transport protocol is widely supported by many from popular services such as HTTP, SNMP, SSH, FTP, and others. This protocol creates an end-to-end connection to nodes (traditional router does not see this connection), and after the successful three-way handshake, it can be used for full-duplex communication between end-nodes. Data transmission is represented as a stream of bytes (octets). Since the speed of receiving and sending usually are not the same, both applications (sender-side and receiver-side) must have a buffer to hide this different speed. Implementation of TCP includes two mechanisms to control the amount of sending data. To avoid having the sender send data too fast for the TCP receiver to receive there is Flow control mechanism. The other one is Congestion control which is responsible for avoiding the collapse of the network due to congestion of link or network nodes for example by full input/output queues. It means that the amount of send data is limited by the minimum of receiver window size (rwnd) and congestion window size (cwnd). TCP uses for flow control explicit feedback from the receiver about free space in his buffer. This information is included in Acknowledg- ment packets (ACK). The decreasing window size in ACK means there is a need to reduce the speed of sending data. If rwnd is 0 that indicates full buffer at receiver side. The IP networks do not provide any feedback about congestion in the network so the sender must estimate the speed of sending data (size of cwnd). This value is calculated iteratively. For the best effectiv- ity of transmission, the cwnd should be as large as possible to avoid the congestion of the network. There exist a lot of different congestion avoidance algorithm for computation cwnd. The initial value of the congestion window is typically small ( 1 < cwnd < 4) but is increased by every acknowledged packet (Slow-Start). This growth can be very rapid in traditional networks with low latency, but in contrast to satellite networks with high delay, it can be a crucial factor limiting sender to reach a potential full speed of the link, especially in short connection. It is evident that the choice of a congestion avoidance algorithm

6 3. Transmission Control Protocol (TCP)

in satellite links is crucial. Specifically, TCP congestion control is designed neither for satellite link nor for web traffic, which composes most of today’s network load; this leads to very poor performance. Moreover, a lot of application protocol which uses TCP protocol (like HTTP) transfer small files, and so the whole transmission can be within the Slow-Start phase. Due to this fact it is possible that the network will not reach full utilization during transmission and TCP connection do not use all available network resources. There exist many TCP versions also called TCP variants, which use a different approach to compute window size and therefore different congestion window growth function. The main two types without modification of routers are loss-based and delay-based congestion control. The loss-based algorithm is a traditional approach which only uses packet loss an indication of congestion. It uses the observation that if packet loss occurs, it is due to congestion in the network. The examples of loss-based congestion control algorithm are BIC-TCP, Cubic, High-Speed TCP and others. Unlike the loss-based strategy, there is another method to detect congestion before the loss occurs – delay-based approach. The general idea of this technique is to watch for a sign from the network that some router’s queue is building up and that congestion will happen soon. That sign is a measurable increase in the RTT for each successive packet it sends [51]. The delay-based approach use, for example, TCP Vegas, FAST or BBR1 developed by Google. There also exist congestion algorithms such as Compound TCP that try to combine both approaches to compute the window size.

3.1 Congestion avoidance algorithm

3.1.1 Compound TCP Compound TCP was introduced in 2005 to create a new TCP approach, which is a synergy of delay-based and loss-based TCP. Firstly, it should have an aggressive, scalable increase rule when the network is sensed to be under-utilized. However, this scheme should also reduce the sending rate accordingly when the network is sensed to be fully utilized. The delay-based component is responsible for this speed reduc-

1. Bottleneck Bandwidth and RTT

7 3. Transmission Control Protocol (TCP)

ing to ensure TCP fairness of Compound TCP (CTCP) with other TCP flows. Last but not least it should also react to packet loss becausein case of heavy congestion the packet losses are the only one indicator [35]. Compound TCP implements a new scalable delay-based component within a standard TCP congestion avoidance algorithm, which use a loss-based component. For delay-based property there is added new variable Delay Window (dwnd). CTCP also uses cwnd from standard TCP, which controls the loss-based component. Then, the CTCP sending window (win) now is controlled by both dwnd and cwnd. For the final calculation, there is also Advertised window (awnd) from the receiver. The sending window is calculated by the formula: win = min(cwnd + dwnd, awnd) The Compound TCP was set up as default congestion control in MS Windows from Windows Server 2008 [36] to Windows Server 2016 1709 update [38] where was replaced by Cubic.

3.1.2 TCP Hybla Some standard TCP congestion control algorithm has a problem with the performance of the heterogeneous network with high RTT such as satellite links. TCP Hybla was designed to reduce this problem. The main idea of this is to obtain the same transmission rate of packets for long RTT connection as TCP connection in wired links [43]. It was designed mainly for satellite links, so it uses the idea that high RTT does not mean only high link error rate. For this purpose, Hybla removes the reliance on RTT. This TCP include multiple procedures which help for better satellite link utilization. For example, there is mandatory to use timestamps and SACK option which allow the receiver informs the sender about all the segments that have been successfully delivered. In other words, the sender can recover more than one packet per RTT [44]. It also uses the adoption of Hoe’s end-to-end-bandwidth estimation which is used to set the ssthresh value properly. This protocol also implements the packet spreading and spacing technique which reduce the probability of buffer overflow at intermediate routers due to transmission bursts [44]. Using this method these bursts can be smoothed out.

8 3. Transmission Control Protocol (TCP)

As long as Hybla does not require any modification at the intermediate point, it can be used without infringing the end to end semantics of TCP protocol [44]. There were also presented the improvements in TCP Hybla algorithm such as TCP Hybla+ or Improved TCP Hybla (TCP Hybla-I). For example, TCP Hybla-I uses a modified equation to increase the congestion window for Slow-Start and congestion avoidance phase by using normalized RTT. It also uses a different bandwidth estimation technique similar to TCP Westwood [47]. TCP Hybla-I continuously measures bandwidth used by connection2 at sender side and sets ssthresh and cwnd according to estimated bandwidth [45] [46].

3.1.3 TCP Cubic Cubic is a loss-based congestion control protocol for TCP and current default TCP algorithm in Linux. In contrast to standard TCP, the Cu- bic version uses a cubic function of window growth to improve the scalability of TCP over fast and long distance networks. As described in [48], it increases the window size very aggressively during a steady state when the window is far from saturation point and the slowly when it is close to the saturation point. Using this feature, the Cubic seems to be very scalable when the bandwidth and delay product of the network is large (such as satellite links) but at the same time congestion control ensure stability and fairness to other TCP flows. TCP Cubic is based on BIC-TCP. BIC-TCP use a binary search algorithm to find window size, because it uses property that capacity of the current path must be somewhere between last windows size (Wmax) where packet loss occurs and last window size (Wmin) with no losses for one RTT period. At this first phase, the window growth uses the logarithmic concave function. This function keeps the congestion window much longer to equilibrium than a convex or linear function. In case the of increasing path capacity, the window size can be increased beyond Wmax without packet loss. In this state, BIC-TCP uses the exponential function to window growth.

2. To calculate the utilized bandwidth it uses packet count received in some fixed period. After that period, it calculates utilized bandwidth by dividing received bytes to the time period [45].

9 3. Transmission Control Protocol (TCP)

The Cubic uses a more simple technique to estimate best window size by replacing both portion (convex and concave) of window growth by one cubic function. Since it is an odd order polynomial function, there is both convex and concave portion. Window growth function of TCP CUBIC is only depended on the time interval between two consecutive congestion events, and thus it is independent of round trip times (RTTs) [49]. The implementation takes some modification. Since the computation requires floating point operations in the kernel, there are needed some integer approximation. For that reason, the original bisection method was replaced by Newton-Raphson one which caused a reduction of computation cost almost by 10 times [48]. This algorithm also includes a feature called Hybrid Slow-Start (HyStart). This mechanism provides trust-worthy signals to Slow-Start for safely switching to Congestion Avoidance without incurring a huge number of packet losses. It uses two pieces of information – ACK train length and increase in packet delays. By measuring ACK train length, a TCP sender roughly infers the maximum number of packets in flight which is typically smaller than the Bandwidth Delay Product of the path if taken into account cross traffic and routing delays along the path. Increase in delays for the first few packets in each RTT round during Slow-Start strongly indicates the path is getting congested by other traffic50 [ ]. In other words, it allows to safety exit slow start to prevent overshoot the cwnd. Using this feature, the startup can be sped up very well. As mention before Cubic is used as default congestion control algorithm in Linux after version 2.6.18 (it replaced BIC-TCP)[48] and currently also default in Windows 10 from version 1709 Fall Creators Update [37][38].

3.1.4 TCP Proportional Rate Reduction Proportional Rate Reduction for TCP (PRR) is an improved fast recovery algorithm that recovers from losses quickly, smoothly and accu- rately by pacing out retransmissions across received ACKs. Specifically, PRR improves upon the existing fast recovery under several conditions including burst losses and losses near the end of short flows [39]. PRR has two main parts. The first step is to calculate an estimate for the amount of data still in flight, followed by a calculation of what,

10 3. Transmission Control Protocol (TCP)

according to the congestion control algorithm in use, the congestion window should now be. If the amount of data in the pipeline is less than the target congestion window, the system goes directly into the TCP Slow-Start algorithm to bring the congestion window back up. Thus, when the connection experiences a burst of losses, it will start trying to rebuild the congestion window right away instead of creep- ing along with a small window for an extended period. If instead, the amount of data in flight is at least as large as the new congestion window, an algorithm similar to rate halving is used [40]. Google has been running a test of PRR on India Youtube network with Google’s internal TCP testing tool. The results show 3-10 % reduction in average latency and recovery timeouts have been reduced by 5 % [41]. PRR was used by default in Linux kernels since version 3.2 [42].

3.1.5 TCP-Peach TCP-Peach is the congestion control scheme which was explicitly introduced for satellite IP networks. It contains new algorithms Sudden Start and Rapid Recovery which replace traditional Slow-Start or Fast Recovery respectively. These new algorithms are based on so-called dummy segments. There are low-priority segments generated by the sender to identify the availability of network resources and they do not carry any new information to the receiver. As long as they are tagged as low-priority segments, it does not decrease the throughput of real data segments, because in case of congestion low-priority packets are dropped earlier. Except for sender side modification also receiver requires simple one to use TCP Peach. The TCP-Peach sender can verify whether the receiver implements the necessary modification during the Sudden Start. If the required modification is not implemented, TCP-Peach sender stops transmitting dummy segments, i.e., TCP-Peach behaves like TCP-Reno [57]. If both of them support dummy segments, sender besides data packets sends also tagged dummy segments. The receiver also acknowledges these packets to the sender with tagged (low-priority) ACK. The sender interprets received tagged ACK for dummy segments as the evidence of available network resources, and so the sender can increase sending speed.

11 3. Transmission Control Protocol (TCP)

The disadvantage of this scheme is that it requires the support of the same priority discipline for all routers in the connection path. One of the solutions can be to use TCP splitting approach (will be explained in Section 5.1) and use TCP-peach only on internal satellite nodes which support priority discipline. There also exist improvements of this congestion control algorithm. The first one is called TCP-Peach+ which add selective acknowledgments (SACK). In 2005 there was introduced the next improvement named TCP-Peach++ which is the enhancement of TCP-Peach+. TCP- Peach++ includes a new feature the so-called Hold state which can improve throughput about 67 % over TCP-Peach+ [56].

12 4 Other transport protocols over satellite links

As was mention above, TCP is a reliable transport protocol, which works very well on terrestrial networks with relatively low latency. Traditional TCP are estimating the available bandwidth through a “window-based” approach by increasing its sending rate (size of cwnd) on a time scale proportional to RTT. The Slow-Start and Congestion Avoidance algorithms regulate the TCP window increase. Problem with this approach is long RTT in satellite link. It is due to the fact that TCP interprets both increases on RTT and packet losses as signals of network congestion and consequentially reduces its sending rate. It means that total utilization of bandwidth either will not be reached at all or after a relatively long time. From the client point of view, this leads to very poor performance of the connection. To avoid this there exist other variants of the transport protocol, other than TCP. Problem with these protocols is that both end-nodes must support it, which can be difficult at the client side. Due to this restriction, these specific transport protocols designed especially for satellite network are typically used with Integrated Performance Enhancing Proxy (I- PEP) (this technology is described in Chapter 5.1) which use Splitting TCP connection shown in Figure 5.1.

4.1 XTP

XTP is designed to increase throughput over satellite by replacing the TCP implementation in the transport layer. XTP was first developed by Protocol Engines, Inc and later by the XTP Forum and is now an open specification. XTP performs own congestion control and congestion avoidance and has a different design for handling errors, dropped or out-of-sequence packets [8].

4.2 SCPS-TP

The Space Communication Protocol Standards (SCPS) originated in 1992 when elements of NASA and the US Air Force jointly commis- sioned the development of a specialized suite of data transfer pro-

13 4. Other transport protocols over satellite links

tocols expressly designed for the stressed environment of satellite communications. The whole SCPS suite consists of 4 elements: SCPS Network Protocol (alternative for IP layer), SCPS Security Protocol, SCPS Transport Protocol (SCPS-TP) and SCPS File Protocol. The main goal for SCPS was Best possible use of limited bandwidth, High link utilization, Conservation of power, Prioritization of traffic, Tolerant of intermittent connectivity and High forward/return link asymmetry [54]. The SCPS-TP protocol consists of standard TCP augmented by a set of extensions and enhancements that include both implementation and specification changes. These modifications can be applied based for characteristics of the space environment, such as latency, asymmetry of bandwidth or link errors. However, some of the SCPS-TP extensions may affect interoperability with regular TCP. Therefore, the use of the nonstandard SCPS-TP options and behaviors is negotiated on connection establishment via an “SCPS-TP capable” option [55]. If the peer TCP endpoint does not return the “SCPS-TP capable” option when the connection initiator sends it on the SYN segment, SCPS-TP will behave like regular TCP [53]. SCPS suite was from the beginning designed to be used in a space environment where network resources are limited, SCPS include also support for own header compression. For more details about the Header compression see Section 6. To sum up, SCPS-TP provides proper congestion control, windows scaling, RTT measurement, Selective Negative Acknowledg- ments (SNACK), best effort communication, header compression for satellite communication, which reduce data re-transferring and improves network efficiency [25].

4.3 TCP-Noordwijk

TCP-Noordwijk is a new transport protocol designed to optimize performance in a controlled environment whose characteristics are fairly well known and managed, such as a satellite link between I-PEP. TCP Noordwijk is a TCP-compatible and TCP friendly protocol based on sender-only modifications, while receiver functionalities are kept unaltered. Its design is particularly aimed at providing high transmission rates in asymmetric satellite link running DAMA algorithms,

14 4. Other transport protocols over satellite links

(a) RBDC environment. (b) VBDC environment

Figure 4.1: Throughput comparison of TCP Noordwijk [52]

such as DVB-RCS systems. Furthermore, TCP Noordwijk is tailored to efficiently transmit the short amount of data without compromising reliability scalability provided by the standard TCP. TCP Noordwijk replaces TCP congestion control mainly based on Slow-Start and Con- gestion Avoidance algorithms with a rate control scheme where the traditional “TCP sliding window” concept is replaced by the “wave” concept. The key idea is to send data into bursts (waves) sized and spaced based on in-band information conveyed by the ACK flow.52 [ ] Authors of [52] implemented TCP Noordwijk on the Network Sim- ulator NS-21 and also test its performance. The comparison results of this protocol with TCP Vegas and standard TCP using RBDC2 and VBDC2 is shown at Figure 4.1. More details about comparison can be found in [52]. In addition, a prototype implementation of TCP Noordwijk is used for preliminary trials over a real DVB-RCS link.

1. The network Simulator NS-2 is an open source simulator of various computers network, MANETs, WSNs, etc. and can be found at http://www.isi.edu/nsnam/ns 2. RBDC (Rate Based Dynamic Capacity) or VBCD (Volume Based Dynamic Capac- ity) – slots are dynamically assigned to the return link, depending on the incoming traffic to the satellite terminal. RBDC considers the ingress data rate, whileVBDC use the cumulative volume of queued data capacity requests.

15 5 Performance Enhancing Proxies

As observed in [12], the Performance Enhancing Proxies is used to improve the performance of the Internet protocols on network paths where native performance suffers due to characteristics of the subnet- work or a link on the path. This includes, for example, satellite links on the path from user to end server, which has specific properties – high latency, significant jitter, limited and often shared bandwidth andso on. So PEP can be classified as the intermediary accelerating node in the network which can help improve performance on the links like a satellite. A PEP need not necessarily only enhance the performance of a network, but it can also be used to enhance security. However, this single term can be used to name many different solutions. There are four main characteristics which differentiate different types of PEPs: layering, distribution, symmetry and transparency.

5.1 Characteristics of PEPs

Layering This characteristic describes at which ISO/OSI layer Per- formance Enhancing Proxy work. Theoretically, the PEP can be implemented to operate at any of ISO/OSI layers. But in most cases, it works at the transport (TCP Proxy) and application layer (HTTP Proxy). Due to layering, the PEP opens many possibilities to improve performance on different layers.

Distribution Form the distribution point of view, the PEP can be classified as integrated or distributed solution. Integrated implementation include single node solution. It is only one point on the path which enhances the performance of link, so PEP split the original end-to-end connection into two connections (see Figure 5.1). Integrated PEP can be used for example at the boundary of wired and wireless networks when client use wireless connection and communicate with wired connected end-station. On the other hand, distributed PEP is generally used when on the path there is specific link or links for which performance enhancement is desired, for example, satellite links. This distributed one comprises two or more PEP implementation, typically

16 5. Performance Enhancing Proxies

implemented in multiple nodes. The advantage of distributed PEP is that original end-to-end connection is split into three connections (Figure 5.1), so between two PEPs, there can be arbitrary transport protocol (optimized for a particular network). In case of the path with satellite sub-path, communication can be passed through 2 PEPs – one at the point where traditional and satellite links meet and another one when it leaves satellite network.

k n S i a l t te e li ll l it te e a l S in k Client stations Internet

Integrated Server PEP Traditional TCP Optimized TCP

k n S i a l t te e li ll l it te e a l S in k Client stations Internet

Distributed Distributed Server PEP PEP Traditional TCP Specialized protocol for Satellite links Traditional TCP

Figure 5.1: Splitting TCP connection in integrated and distributed PEP

Symmetry A PEP implementation may be symmetric or asymmetric. The symmetric solution uses the same behavior in both directions, and asymmetric one operates differently in each direction. For example, an asymmetric PEP might be placed at the intersection of wired and wireless networks or an asymmetric application layer PEP might be used for the request-reply type of HTTP traffic. Whether a PEP implementation is symmetric or asymmetric is independent of whether the PEP implementation is integrated or distributed [12]. So for example, distributed PEP (two implementations) can operate symmetrically at each end of the link, but on the other hand, also distributed PEP might be configured asymmetrically – different implementation at each end of the link.

Transparency Last but not least, it is a degree of transparency. There are two main types transparent and non-transparent PEP. In case there

17 5. Performance Enhancing Proxies

is no necessary any modification applications, transport endpoints and also end systems, the PEPs are fully transparent. On the other hand, if PEP requires modification to one of the endpoints or even to both one, to be working, this implementation is characterized as non-transparent (at least to the endpoints).

5.2 Techniques of accelerating

TCP splitting TCP splitting uses performance enhancing proxy access node that divides the end-to-end TCP connection between the client and the server into a multi-overlay-hop path where each overlay hop is an independent TCP connection, such that the RTT of each overlay hop is lower than the direct RTT between A and B. One of the well-known problems of TCP splitting is that by breaking the end-to- end connection, a split TCP connection is no longer reliable or secure. The next one is that server failure may cause the client to believe that data has been successfully received when it has not [21].

TCP ACK handling Since TCP PEP use TCP splitting approach, implementations are generally based on the manipulation of TCP Acknowledgments. Since PEP split the original TCP end-to-end connection, it can act as a virtual end node, which hides real end systems. It means that after receiving data by the PEP, TCP acknowledgment is sent in that segment because in case of failure the data are locally stored by PEP in case of retransmission. Figure 5.2 shows an example of this situation using two PEP on the path. Due to the fact that PEP sends to client false ACK packet, it is sometimes also called TCP ACK spoofing.

TCP ACK Spacing In the situation where ACKs tend to bunch together, there is possible to use the TCP ACK Spacing method. In contrast to ACK handling, this technique delays certain ACK packets. It is the reason why it is sometimes also called "delayed acknowledgments". ACK spacing is used to smooth out the flow of TCP acknowledgments traversing a link [19]. In other words, it helps the sender to set the right rate of transmission by snooping the returning TCP ACK and

18 5. Performance Enhancing Proxies

Station Station PEP PEP Network Network

Data 1

ACK Sat Data 1 Data 2 Data 1 ACK Data 3 Sat Data 2 ACK Data 2 ACK ACK Data 4 Sat Data 3 ACK Data 5 Data 3 SACK ACK ACK Sat data 2+3 Data 4

ACK Data 4+5

ACK

Figure 5.2: Example of TCP ACK handling with local retransmissions

spread them out. This technique can be done by router or other intermediate node such as PEP. TCP ACK Spacing can also be used when transmissions are encrypted because the router can still figure out which segments are likely TCP ACKs and spread them out. There are also some issues with this approach such as determine the proper ACK spacing. This technique is not also possible if the ACKs do not return through the ACK-spacing (asymmetric routes) [20].

ACK filtering This technique is used mainly in high asymmetry satellite connection when the reverse link has very low bandwidth. The main idea is drop acknowledgments which are included in other ACK packet. In a situation when ACK packets are arriving faster than sending speed, router store them in the queue. In case of the ACK filtering mechanism is applied on the router and a new ACK arrives to queue, the router checks any previous ACK packet already stored in queue whether it belongs to the same connection as newer ACK. If so router removes all of them to reduce the amount of data transmission

19 5. Performance Enhancing Proxies

and keep only the latest one (newly arrived ACK). This operation is safe because Acknowledgments are cumulative. The disadvantage is that the router needs to examine and compare the TCP header, so routers need to be powerful enough. This technique also cannot be applied together with IPSec because of the encrypted TCP header.

Tunnelling A Performance Enhancing Proxy may encapsulate messages to carry the messages across a particular link or to force messages to traverse a particular path. A PEP at the other end of the encapsulation tunnel removes the tunnel wrappers before final delivery to the receiving end system. A tunnel might be used by a distributed split connection TCP implementation as the means for carrying the connection between the distributed PEPs. A tunnel might also be used to support forcing TCP connections which use asymmetric routing to go through the endpoints of a distributed PEP implementation. [12]

Compression The implementation of a Performance Enhancing Proxy can also use one or more types of compression methods. Compres- sion can help decrease the amount of transferred data that can reduce latency and response time, improve link efficiency, decrease overhead and can lead to higher effective link utilization. This may include for example different kind of TCP/IP Headers compression algorithms. Payload compression is also desirable, but this type of compression must be done before applying any security mechanism because after it IP payload looks like a random string for the PEP. When application PEP is used, there can be implemented application- specific compression mechanism which can be more efficient thanany generic one. For example binary encoding of HTTP headers, a lossy compression of the image that reduces the image quality base on settings and so on.

Caching This technique of acceleration uses mainly HTTP PEP,which uses cache for storing copies of a frequently-accessed web object, e.g., TXT files, JPEG, PNG, GIF, JavaScript, CSS files. Of course, this technique cannot be used on the dynamic object and so in most cases, also HTML files are not cached. Caching server must be able to serve the requests and in case of a cache hit it immediately returns requested

20 5. Performance Enhancing Proxies

object to the user. On the other hand, if this object is not stored in the cache (cache miss) or the validity time expired, then the server obtains the object from the origin server. The object is then simultaneously streamed to the client and the PEP server local cache [22]. Using this, user can receive a response for his HTTP request much sooner even in the time when the server does not receive request yet. It is due to the fact that the object is retrieved directly from the cache.

5.3 Problems of Performance Enhancing Proxies

5.3.1 VPN tunnels The most discussed negative implication of using PEPs is breaking the end-to-end connection which disables end-to-end security usage of IPsec. It can be a problem in some situations because it is a common element of widely used VPNs (Virtual Private Networks) running over the internet. As was mention in Section 5.1, PEP is based on splitting TCP end-to-end connection into two or three parts to enhance performance. If there is used end-to-end network layer security like IPsec, IP packet include encrypted TCP header and also user data. So in this case, PEP is not able to perform any performance enhancing operation such as TCP splitting, ACK reduction, TCP spoofing and so on. It is because of encryption (or authentication). Also, PEP operating at higher ISO/OSI layer for example HTTP proxy cannot enhance traffic using techniques such as HTTP pre-fetching, cookie handling or caching because of network layer security. One of the solutions may be using Transport Layer Security or Secure Socket Layer (TLS/SSL) instead of IPsec. Since TLS works directly on top of a reliable transport protocol, TLS provides confidentiality of data, but it does not encrypt transport layer headers (for example TCP header). So it means that required fields are in plain-text and can be modified by the PEPto enhance performance. Another way to solve this problem is to use intelligent switched PEP [15]. This means that unencrypted packet (transport header in plain-text) are handled with PEP and then accelerated using techniques described in Section 5.2. Other packets (encrypted) are allowed to bypass the PEP and continue without any change. The main disadvantage of this solution is the fact that the application must choose

21 5. Performance Enhancing Proxies

between network layer security and better performance, but both are not obtainable together. The next possible solution is use Transport Friendly ESP (TF-ESP) or Modified ESP (M-ESP) which proposes a modification to ESPheader to accommodate the necessary TCP header information in the ESP header outside the scope of encryption. [15]

5.3.2 HTTPS

As mention in Section 5.1 Performance Enhancing Proxy can operate at any ISO/OSI layer. With detailed knowledge of application protocol, there is a possibility to enhance satellite traffic even more. For that reason, some PEPs (for example HTTP PEP) also operate at the Application layer. This type of proxy manages application data such as HTTP headers or compression of images directly. It is because packet typically contains more data than the size of headers required to delivery and hence there are more possibilities to improve the speed of transmission. However, in case of using some security mechanisms like SSL, this proxy cannot enhance traffic because application data are encrypted. It is a similar problem to IPsec in the previous section. The result of usage encrypted application data is that user security is improved, but on the other hand, there is no possibility to accelerate traffic on higher than the Transport layer. In other words, HTTP PEP cannot use a technique such as caching or compression of data to accelerate satellite link. The total amount of encrypted HTTP traffic is more and more increasing. Based on the research [16] by Eset published in 2018, there was more than one-half (51.8 percent) of the one million most visited websites worldwide use HTTPS – secure version of HTTP. Authors also mention that the number of websites which use HTTPS is still increasing. The percentage was increased by 13.4% in just seven months. Expect for encryption of HTTP also other encrypted network traffic has an increasing trend. Based on the traffic traversing the Zscaler cloud [17], more than 80% of total traffic is now encrypted.

22 5. Performance Enhancing Proxies 5.4 Additional techniques

This section describes additional possibilities, which can be implemented in PEP to improve network performance even more. All of these techniques can be as part of PEP node or in some cases (e.x. Domain Name System (DNS) cache) it can be a separate node in the path from the client to satellite link.

5.4.1 TCP Fast Open This technique described in RFC7413[23] is an experimental update to TCP that enables data to be exchanged safely during TCP’s connection handshake. The core of this technique is a security cookie used by the server side to authenticate a client initiating a TCP Fast Open (TFO) connection. It saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake to complete before data can be exchanged. This additional RTT is a significant portion of overall network latency, especially for satellite links with high latency. In details, the first TCP session normally starts except Fast Open Cookie Request located in the header. The client using this field ask the server in initial SYN (3-way handshake) to send back also Fast Open Cookie in SYN+ACK packet. This cookie cannot client use immediately, but it stores them for the future TCP connection. The second session is started differently. The client uses the previously received cookie from the server in SYN packet to notify the server about Fast Open feature. This SYN frame contains also request to the server for data and so also Length field in the request is bigger than zero. If the server accepts cookie as valid, then data can be transferred even when the last ACK from the client has not received yet. As you can see in the communication flow in Figure 5.3, the client can receive data sooner. In case that the intermediate node drops the packet with TFO during the transmission, then client tries to connect again but without TCP Fast Open option or data included. Nowadays the TCP Fast Open feature supports many modern browsers like Mozilla Firefox (from version 58), Google Chrome and Chromium (on Linux, Chrome OS, and Android), but this feature is also directly supported in many operating systems, for example,

23 5. Performance Enhancing Proxies

Client Server Client Server SYN SYN + Request , Len=0 , TFO= , Len=X , TFO= R C C , Len=0 , TFO= SYN+ACK SYN+ACK

ACK+Request ACK , Len=0 DATA DATA DATA DATA DATA DATA

DATA

ACK DATA FIN ACK ACK FIN ACK

First TCP connection Next TCP connection Figure 5.3: Communication with TCP Fast Open feature

Linux (kernel 3.6 and newer), FreeBSD (from 12.0), iOS 9, OS X (10.11) or Windows 10 (Anniversary update) [62]. Despite wide support of TFO at the client side, there is a lot of older application or Operating systems without support of TFO. In that case, PEP with TCP Fast Open capabilities can be very helpful to speed up the transmission. This feature has many advantages, but there also can be some problems when TFO is used. As was mention before, not all devices support this relatively new feature. Also, the intermediate nodes such as NATs or firewall can have problem with new parameter and can drop the packet. When the packet is dropped, the client needs to wait on timeout and send the SYN packet again. So the initialization phase is longer than sending SYN packet without TCP Fast Open. Server support of TFO feature is also needed to use this.

5.4.2 DNS Cache

As everybody knows, the current Domain Name System has a hierar- chical tree structure. Most of the systems and services use the DNS system before sending any data. Based on the research [63], in the network of Masaryk University, there is more than 21% of all traffic to port 53, which is registered well-known port to the DNS system. It is

24 5. Performance Enhancing Proxies

the reason why DNS cache can be very helpful in accelerating satellite traffic. DNS caching is the technique of local storing the DNS entries, which improves initial delay caused by resolving a name. It is because DNS cache (proxy) is closer to the user and so DNS reply can be delivered faster. In the case of satellite network DNS caching are very welcomed due to high RTT. This DNS proxy can be located between the user node and satellite link, to avoid transferring DNS queries via a satellite network. In this case, the only first new request is slow, but other repeated DNS requests are responded based on cache entries. There are two types of caches Passive and Proactive. Passive one store only copies of DNS entry after the request is performed. On the other hand, Proactive cache means that copy of DNS object is stored even before request are routed through those nodes [64]. This works only when the client uses the DNS server located before a satellite link as a primary server. This can be achieved for example using correctly set up a DHCP server. In case the user node uses a different DNS server, DNS cache is not used, and each DNS query is routed out via satellite link, which can be interpreted as lack of network performance. For that reason, there is a possibility to use so-called Transparent DNS proxy. It is the technique to intercept DNS request designed for a specific recursive DNS server, and sending the DNS requests to an entirely different DNS server [65]. Also, it is possible running the DNS server at the same node as the transparent DNS (forwarding to localhost) to reduce the number of hopes. In the satellite network, it is mainly due to performance reasons, but Transparent DNS proxy can also be used for Government Regulation or Security reason (e.x. content filtering service), etc. Term transparent means that the client machine does not explicitly configure proxy and user do not have to notice that the proxy node is used in the network. In other words, there is not necessary to change the clients’ configuration. Example of using a transparent proxy is illustrated in Figure 5.4. Similar to PEP also Transparent DNS proxy are not usable together with VPN or other encryption methods. If application data or even transport layer header are encrypted then none of the traffic optimization can be performed.

25 5. Performance Enhancing Proxies

DNS query - cache hit DNS query - cache miss Original DNS query Satellite link Wired link DNS server (user deﬁned) DNS cache

User Terminal Transparent Internet Client station ISP hub DNS proxy (Gateway) Figure 5.4: Handling DNS query using Transparent DNS proxy

5.5 PEPsal

At first, the PEPsal was developed for academic purposes but then was adopted by a US one-way satellite broadband Internet provider to offer Internet access in the US and Latin America18 [ ]. Nowadays it is an open source solution of Performance Enhancing Proxy for the GNU/Linux operating systems (Sourceforge.net1). For the classifica- tion of this Performance Enhancing Proxy, there can be used categories described in Section 5.1. From the layering point of view, PEPsal belongs to the category of multi-layer proxy. It is because it uses some transport mechanism such as TCP splitting. It also must operate at Network and Application layers of ISO/OSI model. PEPsal runs as one single box on the forward link satellite gateway, so it is a typical representative of the integrated PEP. The next characteristic is symmetry. Depending on the network layer configuration, PEPsal can be either symmetric or asymmetric. In a typical configuration, it is placed in a forward direction, but itcan also act in the return route (in this case, with proper modifications on the receiver side). Finally, if we focus on transparency, PEP is considered as transparent proxy. That means there is no modification required at the endpoints – neither sender nor receiver. In other words, TCP users are unaware of the connection splitting performed at the PEP (satellite gateway).

1. https://sourceforge.net/projects/pepsal/

26 5. Performance Enhancing Proxies

The main purpose of PEPsal is splitting the original end-to-end TCP connection into two new TCP connections (Figure 5.1). One from client to PEPsal and other from PEPsal to the server where is the network with satellite link. In TCP, the congestion window is one of the factors that determine the number of bytes that can be outstanding at any time. [10]. Since the sender maintains the congestion window, second TCP connection (from PEPsal to sender) can use a different more suitable congestion-avoidance algorithm for satellite links. For this second part, it uses TCP Hybla, which has been conceived with the primary aim to solve a problem with long RTT especially on networks incorporating satellite links.

27 6 Header compression

Each packet traveling through the network contains not only pure data but also several layers of encapsulation. The headers such as the network or the transport header are necessary for the delivery of the data to the receiver, but they also inevitably introduce unwanted overhead. Header compression can help reduce this encapsulation overhead which can also lead to saving significant amounts of bandwidth. For example during transmitting multimedia the IPv4 (20 bytes) / IPv6 (40 bytes), UDP (8 bytes) and RTP (12 bytes) header are present which is total at least 40 bytes overhead for IPv4 (60 bytes for IPv6 respectively) for each packet.

uncompressed Packets with uncompressed packets compressed headers packets Compresor Decompresor

Figure 6.1: Header compression principle

In general, the main idea of header compression is the fact that in one flow some fields in the header (such as port number, sourceor destination address) does not change during transmission and can be safely omitted because it can be deducted from previously transferred master packet. Some other fields in the header can be delivered from information elsewhere or can be obtained incrementally from the previous packet (for example total packet length or TCP sequence number). Hence each compressed packet needs to be also decompressed any header compression technique requires two nodes in the network (similar to distributed PEP). In addition, all these compression schemes are designed to point-to-point network. In other words, at least network layer header is replaced with compressed one. The header compression scheme is illustrated in Figure 6.1.

6.1 Van Jacobson Header Compression (VJHC)

The first header compression introduced by the IETF is Van Jacobson Header Compression[27] in 1990. This technique is detailed described in RFC1144. This compression is specific mainly to TCP/IP datagrams because in that time UDP/IP datagrams were too infrequent. For

28 6. Header compression

more efficiency VJHC compress IP and TCP header together andnot individually. VJHC expect that certain field in the header does not change at all or it occurs very rarely. So these values can be omitted from the compressed header. In case the change occurs, only small increment (in most cases by 1) can be sent. This incremental value (so-called delta encoding) are often smaller than the field’s actual value, and therefore it can be represented in a smaller amount of bytes. The compressed header also includes unmodified value (same as an uncompressed packet) for example the TCP checksum (due to end-to-end integrity of the data). Each flow (unique source and destination address and ports) is identified with Connection number. This number are present also in uncompressed header1 to establish or refresh the content of the stream. Since Connection number is limited to a single byte, there is a limitation of maximum 256 simultaneously active TCP connection. In the beginning, first packet (SYN) is sent original without compression because they usually contain a TCP option (the max. segment size) which the following packets do not. The decompressor store this header which is used for decompressing next packet from same flow. Since this stored header is needed for calculating differences at both the compressor and decompressor, successful transmission of an uncompressed packet is required to (re-)synchronize the decompressor [24]. The next packets can be sent with a compressed header. This mechanism can reduce the TCP/IPv4 header from 40 Bytes to 4 Bytes. The disadvantage of this method is that it supports only TCP/IP headers and susceptibility to error due to the delta encoding.

6.2 IP Header Compression (IPHC)

The next technique is IP Header Compression[28] from 1999. This is an improvement of original Van Jacobson’s concept which supports compression of UDP header, IPv6 header and extension headers. It also satisfies several goals, including better response time, line efficiency, loss rate, and bit overhead. The specification also allows the extension to multicast, multi-access links, and other compression schemes which

1. Uncompressed header is identical to the original IP packet header except for the IP protocol field which is replaced with a Connection number

29 6. Header compression

ride over UDP [24]. It uses the same concept as VJHC consisting of omitting unchanged fields and sending incremental values. Unlike VJHC this method introduces two methods to mitigate the problem associated with incremental fields: Twice algorithm and Header request (for more detail see [28]). Due to these two improvements, IPHC is more resistant to the damage caused by packet loss or the damaged context than Van Jacobson Header Compression. Similarly to VJHC, IP Header Compression use Connection identifier (CID) for decompression and context association (identify flow). For TCP flow it is the 8-bit number, the same as VJHC. However, for non-TCP headers, CID can be up to 16-bit long number. The CID spaces for TCP and non-TCP are separate, so a TCP CID and a non-TCP CID with the same value never identify the same context. The context for a packet stream is associated with a context identifier and a generation field (this is only for non-TCP). This is kept at both the compressor and decompressor. To allow the decompressor to recover quickly from the loss of a full header that would have changed the context, full headers are sent periodically with an exponentially increasing period after a change in the context [28]. IP Header Compression can reduce the IP header up to 2 bytes for a non-TCP session and 4 bytes for TCP session [26]. The next advantage of IPHC is that it can be used irrespective of the transport layer protocols.

6.3 Compressed Realtime Transport Protocol

This compression method is based on the IPHC described above. In contrast to IP Header Compression, there is added support of RTP header compression. It is due to the fact that multimedia traffic was increasing and RTP enable interoperability among applications and services such as VoIP and video over IP. Since RTP header adds next 12 bytes long overhead, this compression enables reducing bandwidth even more than only IP/UDP compression with IPHC. The main disadvantage of this concept is that it was designed to relatively error-free links with low RTT. So this method does not make sense to satellite links. For that reason the scheme was extended and released as En- hanced CRTP in RFC 3545.

30 6. Header compression

This compression compresses RTP headers typically down to 2 to 4 bytes. It is designed to work well over low bandwidth links such as dial-up modems [34]. Additional information about Compressed RTP can be found in RFC 2508 [31] and RFC 3545 [32].

6.4 RObust Header Compression (ROHC)

ROHC is a general header compression framework that is used to enable compression and decompression of different types of traffic (protocols). It was specially designed to efficient work with error-prone links (high Bit Error Rate – BER), long RTT and link with bandwidth-limited capacities, such as 2G, 3G or satellite links. Due to these properties, ROHC must offer high robustness and reliability. This compression scheme is built on a profile approach for different protocols. Itsup- ports various types of traffic such as IP/TCP, IP/UDP/RTP, IP/ESP, IP/UDP or Uncompressed. I addition it was developed to be easily extensible for the new protocol, that means there is no need to design entirely new compression technique to add new protocols. On the other hand, the penalty for this flexibility is the complexity of the whole framework (more complicated than other methods) and complicated compression profiles.

14B 8B20B 12B 4B CRC Ethernet IP header UDP RTP Data header

Header Compression RoHC CRC Ethernet Data header

14B 1-4B 4B Figure 6.2: Packet size after compression using RoHC

31 6. Header compression

6.4.1 Operation modes and states ROHC defines three operation modes [29]. The first one is Unidirec- tional Mode (U-mode) which makes use of periodic refreshes and timeouts to keep the context current (as in IPHC for UDP). All ROHC schemes start in U-mode and may transition to any of the two remain- ing modes upon reception of feedback from the decompressor. This mod does not require any feedback, so it is also suitable for unidirectional links. The second mode is Bidirectional Optimistic Mode (O-mode) which use the feedback channel to send recovery requests (for error correction). The final mode, Bidirectional Reliable Mode (R-mode), utilizes all resources of the feedback channel to a greater degree than the previous two modes to best prevent context loss or loss of synchronization. All context updates are acknowledged in this mode [24]. All kinds of mode changes are possible as illustrated in Figure 6.3 (e.g., U-mode to O-mode or R-mode, from O-mode to U- mode or R-mode, etc.). The operator can set the preferred mode of operation, and it can be changed at any time.

Unidirectional mode

FO SO

IR IR

FO SO FO SO

Optimistic mode Reliable mode Figure 6.3: ROHC modes with states transitions of compressor

Compression and decompression are treated as finite state machines each of which is broken into three states. Whatever the mode is, both the compressor and the decompressor work in one of them (Figure 6.3). The first of the three compressor’s states is Initialization andRe- fresh (IR) state of the decompressor’s context. In this state, the full packet headers are sent. The compressor stays in the IR state until it is fairly confident that the decompressor has received the static informa-

32 6. Header compression

tion correctly. The next compressor’s state is First Order (FO) State. The purpose of the FO state is to communicate irregularities in the packet stream efficiently. When operating in this state, the compressor rarely sends information about all dynamic fields, and the information sent is usually compressed at least partially. Only a few static fields can be updated [29]. The last state which offers the optimal compression is Second Order (SO) State. The compressor is in this state when it is sufficiently confident that the decompressor is able to generate and verify the headers predictively. In contrast to FO, in this state, there are compressed all dynamic fields, and therefore only logical sequence numbers and partial checksum can be sent. The transition between SO and FO state is done dynamically based on the link error conditions observed and reported by the decompressor. The decompressor’s states are indications of the quality of the decompressor’s context and can either be No context, Static context, or Full context. Initially, the decompressor has not yet successfully decompressed a packet, and so it is in the No Context state. Once a packet has been decompressed correctly (for example, upon reception of Initialization and Refresh packet containing static and dynamic information), the decompressor can transit to the Full Context state [29]. The transition to lower states happens only after repeated failures. If it still fails to decompress, it moves to the No Context state. In this case, it needs to send IR packets again to restore the context at the decompressor side. Only after successfully transmitted packet in Static context it can be changed to Full context.

6.5 SCPS Header compression

This compression technique is different than the previous one because its compression scheme can be used mainly with SCPS protocol suite. This header compression can be classified as loss-tolerant because the receiver can with no problems decompress each correctly received packet even without previous knowledge packet in the sequence. In contrast to Van Jacobson Header Compression in this scheme, there are not used delta-encoding, and it means that SCPS header compression is more robust against packet loss during transmission.

33 6. Header compression

In detail, the SCPS-TP header compression is negotiated in the initial uncompressed three-way handshake and must be agreed by both sender and receiver. Usage of Header compression is marked in SCPS-NP header (alternative for IP header). It also uses the first byte of the header for connection ID, which identify the connection the packet is associated with. Presence of other fields within the header indicates the 8-bit vector. In case of less frequent headers fields are present in bit vector there are also More bit which can extend bit vector to double size. [24] Compressed header must also contain checksum which is mandatory, and it is located at the last element of header. Nevertheless, it is not so efficient as Van Jacobson Header Com- pression, but typically it can still reduce TCP headers by 50%.

34 7 Testing

7.1 Setup topology

For the testing purpose, the network infrastructure was created using Virtualbox instances. It is mainly due to the fact that virtual machine setup is very easy for the traditional user and so anyone interested in this area can try it. The basic testing topology consist of 4 virtual machines as illustrated in Figure 7.1:

∙ Client – It simulates user trying to download different content from Server via the emulated satellite link.

∙ PEP – This machine act as Performance Enhancing Proxy which represents satellite accelerator. This is the point where traffic enhancement techniques can be implemented. For testing purpose the PEPsal implementation was used.

∙ Gateway with simulator – Node simulating satellite link using editing network properties such as adding delay, bandwidth limitation, adding jitter and so on.

∙ Server – On this machines, there is running a simple HTTP server. For simplicity, there was used python implementation SimpleHTTPServer and also NGINX server with TFO feature.

Internet

enp0s8 DHCP - NAT

enp0s3 enp0s3 enp0s3 192.168.4.1/24 192.168.5.2/24 GW with 10.0.0.10/24 Client PEP Server enp0s3 enp0s8 simulator enp0s9 192.168.4.25/24 192.168.5.1/21 10.0.0.1/24

Figure 7.1: Topology of testing network using virtual machines

All of these machines are running on Ubuntu 18.04 except for PEP- sal, which use Debian OS. Links are configured via Internal Network,

35 7. Testing

and all interfaces are set up as static IP addresses. For the maximal simplicity of the network, there is only one static route from Gateway to the client’s network, and therefore no dynamic routing protocol is used.

7.1.1 Simulator In contrast to terrestrial links, the satellite ones have different properties. As was mention before the satellite network are characterized with long RTT, bigger jitter, relatively small bandwidth, which are in many cases even different for upload and download. These characteristics of the link must be emulated using the simulating tool, that tries to edit existing link behavior to looks like a real satellite connection. The most used tools for simulating various networks are tc together with netem and Dummynet.

tc is the user-space utility program used to configure Traffic Control in the Linux kernel. This utility is usually included in the iproute2 package. Traffic Control consists of shaping (for example. lowering the available bandwidth or smoothing outbursts), scheduling (prioritization), policing and dropping. [59] Together with tc there is also kernel component with name netem. This is used to simulating various types of networks with different characteristics. Using these utilities wecan simulate limitation of bandwidth and adding delay for simulating satellite connection. There are also more possibilities like packet loss, corruption or reordering, adding duplicate packets and so on. Also, there is also possible to add jitter using some distribution function1, that can make the simulated link more realistic. Example of usage of this tool is illustrated in Code 7.1. Code 7.1: Commands for configuration satellite link using tc-netem $ sudo tc qdisc add dev enp0s3 root handle 1: tbf rate \ 432kbit burst 1600 limit 30000 $ sudo tc qdisc add dev enp0s3 parent 1:1 handle 10: \ netem delay 600ms 100ms distribution normal

1. There are some built-in distribution functions like uniform, normal, pareto or paretonormal, but there is also possible to make own distribution based on experimental data [61]. 36 7. Testing

$ $ sudo tc qdisc add dev enp0s9 root handle 1: tbf rate \ 432kbit burst 1600 limit 30000 $ sudo tc qdisc add dev enp0s9 parent 1:1 handle 10: \ netem delay 600ms 100ms distribution normal

Dummynet is a FreeBSD system facility that simulates network delay and loss by manipulating the IP queue inside the kernel. Dum- mynet makes use of " ipfw" which supports various types of IP filters for system network interfaces. The general idea is to create a "pipe" object and configure it with the desired delay and loss parameters. The pipe gets added to a list of filtering "rules" which are used by dummynet to modify the treatment of IP packets in desired ways. [58] Dummynet can simulate bandwidth limitation, packet losses, add additional delays, limit queue size and so on. In contrast to tc this system has an easy and clear configuration. The main disadvantages are the absence of jitter configuration and no support for probability function. Example of usage Dummynet is illustrated in Code 7.2. Code 7.2: Bash script for basic configuration of a link using Dummynet #!/bin/sh

# load module kldload dummynet # clean rules ipfw -q flush ipfw -q pipe flush # download limit ipfw pipe 1 config delay 600ms bw 432Kbit/s ipfw add pipe 1 ip from any to any out recv em0 # upload limit ipfw pipe 2 config delay 600ms bw 432Kbit/s ipfw add pipe 2 ip from any to any out recv em1

# pass traffic after processing ipfw add 10000 allow ip from any to any

37 7. Testing

For all tests there where used the following properties of the network to simulate satellite link2: ∙ Bandwidth – 432 kbit/s ∙ Delay – fixed 600 ms ∙ Jitter – normal distribution function with mean 100 ms ∙ Corruption of packet – fixed to 0, 001 % These properties were applied to both upload and download the direction of link – symmetric satellite channel. For all tests there was used tc together with NetEm as simulator tool. The reason is that tc in contrast to Dummynet provide distribution function for jitter, which is more realistic.

7.2 Test results

7.2.1 PEPsal as intermediate node The first test tries to examine the impact of usage PEPsal as intermediate node before the satellite connection. For this test, there was used topology described in Figure 7.1. The user station uses Ubuntu with the default configuration. The script tries to download from the web server the regular text file with random bytes and size 1024 KB.For time measure there was used Linux utility time[60]. Each of this measurement was due to accuracy repeated 50 times, and the result value is the average time of all attempts. The goal of this measurement was to find out the average time required to download file with PEPsal node and without. The PEPsal station split TCP connection so from user to PEPsal there was used default congestion control algorithm (Cubic), and from PEPsal to the server, there was the TCP Hybla. In case of testing without PEPsal node whole path use TCP Cubic. The testing includes different values of Packet Error Rate (PER) to show howthe TCP congestion control algorithm can deal with the erroneous link.

2. The properties of satellite link was chosen based on simulator used by Honeywell Aerospace

38 7. Testing

No PEP (TCP Cubic) With PEP (TCP Cubic + Hybla)

34,5 34,28 s 33,79 s

33,5

32,5

31,5

30,5

29,5 Seconds 28,40 s 28,5 28,18 s

27,5

26,5

25,48 s 25,5 25,14 s

24,5 0,1% 0,5% 1% Packet Error Rate

Figure 7.2: Comparison of average transmission time

Result of test: Figure 7.2 shows average time with and without using PEPsal. Although there is used Performance Enhancing Proxy with TCP splitting, the acceleration is negligible in contrast to direct TCP. It is probably due to the Hybrid Slow-Start feature included in TCP Cubic, which improve Slow-Start phase. Unfortunately, this feature is not included in TCP Hybla. Nevertheless, the vanilla PEPsal improves transmission speed very poor, it can be very helpful for additional enhancing techniques because it handles TCP sessions.

7.2.2 TCP Fast Open

This test is focused on examining the effect of using experimental feature TCP Fast Open described in Section 5.4. This test case consists of 3 different scenarios – enabled TCP Fast Open on both sides (client and PEPsal), only on the client side (without using PEPsal) and only on PEPsal side. For this test, there was used a simple python program based on the client-server architecture. The TCP socket on both client and server application must be set to support TCP Fast Open and

39 7. Testing

also this feature must be enabled by operating System. TFO feature in Linux for PEPsal can be enabled using command3: # sudo sysctl-w net.ipv4.tcp_fastopen=3 The network topology for this test was used the same as Figure 7.1. This test was focused on measuring the elapsed time of downloading the file from the server by the client. The testing scheme was used similar to measurement in 7.2.1 except file size. In this test transferred file had 512 KB. Also for accuracy, each measurement was repeated 100 times, and the results represent the average value of these measurements. The chart of results from the testing is illustrated in Figure 7.3.

15,500s

15,250s 100% 15,000s 15,073s

14,750s

14,500s

14,250s 93,2% 93,1% 14,000s 14,046s 14,039s 13,750s

13,500s

13,250s

13,000s

12,750s

12,500s

12,250s

12,000s No TFO TFO enabled only on PEPsal TFO enabled on Cliend and PEPsal

Figure 7.3: Effect of TCP Fast Open on average downloading time

Result of test: As you can see, downloading file with TFO enabled and without has a significant impact. Using this feature user canget the result more than one second earlier with TCP Fast Open feature in contrast to a basic downloading scenario. As was mention earlier TFO can reduce the initialization delay from 3 RTT to 1 RTT. In other words, if RTT is about 1200 ms (satellite link), the theoretical speed-up

3. TFO value 1 enables TFO only for outgoing connection (client), value 2 enables TFO only for incoming connection (server) and value 3 enable for both in and out direction (client and server)

40 7. Testing

is 2,4 seconds per connection. This test shows that the time of one TCP connection was decreasing approximately about 1 second. In the case of a file with the 512 KB size, it corresponds to 6,9 %. This deviation was probably due to some re-transmissions.

7.2.3 DNS cache This test was focused on speeding up resolving DNS queries. The first phase consists of analyzing satellite traffic to find out howmany DNS queries it contains. Unfortunately, for analyzing there could not be used real captured data from link due to GDPR4 restriction. And so all processing of personal data of individuals (also include network traffic) can be performed only after receiving an unambiguous and individualized affirmation of consent from the data subject66 [ ]. In other words, the network traffic (encrypted or unencrypted) can include data defined as private (telephone number, address, bank account number, etc.) and so it falls under GDPR compliance. For that reason, the analysis of network traffic was based on the simulated user. The second phase consists of measuring the time required to resolve DNS queries using standard configuration – DNS server located on the Internet (beyond satellite link). This time was compared to the DNS cache server located before satellite link. If results of DNS queries were stored in the cache server, query needn’t travel via satellite link. Only in case of a cache miss, the queries were answered by the external DNS server.

Result of test: In the captured traffic of simulated user which take approximately 1 hour, there was 6,2 % DNS traffic (requests and re- sponses). After analysis of the captured file, there was found 4093 DNS requests to remote DNS server which represent 3,1 % of all traffic. The simulated user uses Client station (Ubuntu) connected to the internet and performs standard web browsing. Result of this test is different from [63] which can be caused that in this case there was only one

4. General Data Protection Regulation (EU) 2016/679 ("GDPR") is a regulation in EU law on data protection and privacy for all individuals within the European Union (EU) and the European Economic Area (EEA) [66].

41 7. Testing

user whereas result from the paper consist of statistics from the whole network of Masaryk University. The second part of this test was focused on elapsed time during DNS name resolving. Due to the accuracy of measurement each test consists of resolving5 same DNS name repeated 100 times. Results are summarized in the table 7.1.The first column shows the required time to resolve the name using the external DNS server. It is clear that the measured time approximately corresponds with RTT of transmission via satellite link. The second column illustrates resolving time using DNS cache located before the satellite link. From the table, it is obvious that the median is close to zero, because each query except first is responded by DNS cache. In other words, only the firstquery is transmitting via satellite link. This technique can reach the best enhancement in the situation where multiple users want to resolve the same domain name.

Table 7.1: DNS response time

External DNS DNS cache Median 1248 ms 1 ms Min 952 ms 0 ms Max 1644 ms 2356 ms

7.2.4 RoHC Header compression The goal of this test was to explore the impact of usage Robust Header Compression on the total amount of transferred bytes. As described before, this technique reduces the size of headers, and so data can be transferred more effectively because there is much less overhead caused by added headers. However, this test was not focused on speeding up data transfer but only to show how much data can be saved. It is because ROHC can be used only on Point-to-Point network and so it cannot be used together with the simulator node. For performing the test, there was used The OpenSource ROHC library [67].

5. Local DNS caching was disabled.

42 7. Testing

The testing topology consisted of one client station connected to a node with an installed ROHC library. This ROHC node was then directly connected to the Internet. Measuring of total saved data was performed using a simple tool included inside the library. It captures traffic from the interface and try to compress and then decompress incoming packets. Later from the operational data, it computes the total amount of saved data with respect to header size and also total packet size. The captured data was from the simulated user and program compress and decompress traffic for 1 hour.

60,00% 56,72%

50,00%

40,00%

30,00%

20,00%

13,37%

10,00% 8,05% 6,04% 5,93% 4,17% 2,87% 2,85% 0,00% 0,00% 0,00% 0 - 19 20 - 39 40 - 79 80 - 159 160 - 319 320 - 639 640 - 1279 1280 - 2559 2560 - 5119 5120 + Packet size in bytes

Figure 7.4: Packet size distribution from captured file

Result of test: The analysis was performed base on raw output data from the RoHC testing tool. There were captured 214164 packets in total for approximately 1 hour. The analysis of captured data shows that the majority of the packet has a relatively small size. Packet size distribution is illustrated in Figure 7.4. As long as the testing tool works only on one interface, the compressor works only in Unidirectional Mode (U-mode) for the whole time. From decompress point of view, it was in Initialization and Refresh (IR) State most of the time. The distribution of decompressor state is illustrated in Figure 7.5. The performance of RoHC compression technique illustrate table 7.2. The table is divided into two parts: Average Header size and

43 7. Testing

0,00% 1,12%

98,88%

IR FO SO

Figure 7.5: Types of RoHC context states

Average size of the whole Packet. Both of these values represent the size in percentage after compression. For more details, the table also divides the results based on the Context state and packet type6. As the table 7.2 shows, the average compressed packet has 97,76 % of its original size, which corresponds to 2.24 % saving of transferred bytes. This relatively low saving is connected with decompressor state which was in most of the time in IR state where full packet headers are sent. Only 1,12 % of traffic was decompressed by SO state which offers optimal compression. From the table 7.1 it is evident thatin this optimal state the average packet saves up to 42,9 % of bandwidth. This state distribution was probably caused by relatively short flows, generated by standard Internet browsing. Detailed analysis of flows shows that only in 2,8 % cases there were exchanged more than 100 packets. In other words, from the captured data the decompressor context had to be created or refreshed many times, and so the compression was not so effective compared with ideal conditions. The effectiveness of RoHC compression mechanism should be better ifthe traffic also contains longer stream like VoIP or other RTP traffic.

6. Detailed information about profiles can be found in [30].

44 7. Testing

Table 7.2: Average Header and Packet size after compression

Context state and packet type Avg Header size Avg Packet size SO 24,00% 57,10% co_common 29,41% 77,26% ROHCv1/TCP/rnd_3 20,00% 54,93% ROHCv1/TCP/rnd_5 25,00% 25,00% ROHCv1/TCP/seq_1 15,85% 85,40% ROHCv1/TCP/seq_2 12,50% 95,87% ROHCv1/TCP/seq_3 15,19% 15,19% ROHCv1/TCP/seq_4 10,25% 10,25% ROHCv1/TCP/seq_5 22,50% 22,50% ROHCv1/TCP/seq_7 20,23% 21,64% ROHCv1/TCP/seq_8 25,01% 51,96% IR 97,17% 98,22% IR 97,17% 98,22% Total 96,35% 97,76%

7.3 Conclusion of testing

Performed tests illustrate differences between traditional usage of satellite link without any special improvement and usage of specific techniques which tries to enhance the performance of satellite link. Some methods like TCP Hybla vs. TCP Cubic comparison or performance of TFO show better results in papers [68][23] than this testing. It may be due to the fact that all tests were used only with basic simulator tool, not real satellite link. Although in the case of TFO the measured real speedup was only 1 second per transmission (in the ideal condition it should be about 2,4 s) it still shows pretty good improvement for users who use satellite connection. Because real data from satellite communication cannot be used due to the GDPR restriction described above, only data from one simulated user were used for some tests. So due to this, the test results can be distorted in contrast to tests performed based on real satellite data.

45 7. Testing

Also, the last measurement (RoHC Header compression) was performed only with the simulating tool included in the used library. As was mention above this technique is possible to use it only on the Point-to-Point links. Although this testing cannot be used with the simulator, the dedicated compression and decompression of real traffic is performed the same way as the tool does. So except the physical link properties such as packet corruption or reordering, the result of compression should be similar to a real satellite link. However, the real deployment of RoHC can reach even better results because in the testing case there was quite monotonous traffic generated only by standard browsing. The real traffic includes more various types of packets including RTP streams, downloading files and so on. Because the results of this test depend on the current traffic, the repeated test can give different results. Despite the limitation of testing, the results give a quite interest- ing overview of possible performance enhancement when selected methods are used on the satellite link.

46 8 Conclusion

The aim of this thesis was to research techniques of network traffic acceleration for satellite links. There exist many possibilities for enhancing the performance of the network at various ISO/OSI layers. The research shows that enhancing at higher layers like HTTP PEP or DNS caching can be more powerful, but on the other hand it acceler- ates only specific kind of traffic. Nowadays, enhancement at higher than layer 4 of the ISO/OSI layer is more meaningless due to increasing encrypted traffic. This kind of traffic looks like a random stringfor the PEP, and so it cannot be accelerated. In this case, the application must choose between better security for the user and more powerful transmission, but both are not obtainable together. From that reason, it is better to choose some other technique like Performance Enhancing Proxy with a special transport protocol or any Header compression. It is also possible to combine multiple accelerating methods at different layers to reach even better results. The performed tests show that a simple TCP splitting approach using one PEP is not so effective in comparison with modern TCP congestion control algorithm. In this case, the PEP cannot use any other specific transport protocol because end-nodes may not support it. This limitation can be overcome by using a distributed solution of PEP which allows replacing standard TCP with more optimized transport protocol for satellite network between them. This thesis also focused on modern header compression technique such as ROHC and tried to test its performance. ROHC offer high robustness and reliability which can be welcomed in the satellite links. Also, it can be extended for new protocols which can be relatively easily added into the existing library. Also, performed tests confirmed that this solution could save transmitting bytes by omitting some fields in headers. It causes that satellite link can transmit evenmore packets and so the speed of data transmission via satellite can be raised. However, on the other hand, it is necessary to use additional nodes exactly at the border of the existing and satellite network because it can be used only on the point-to-point network. The aim of this thesis was also to try to create network accelerator for satellite link as a virtual machine. For that purpose, there was used

47 8. Conclusion

PEPsal implementation, which offers the only open-source solution of Performance Enhancing Proxy. The virtual machine also includes installed open-source RoHC Library. Both of these solutions were also used during testing and can be found as an electronic attachment. This master thesis can be extended in various ways. Since all tests were performed only using the simulator, it will be better in future to repeat the measurement with real satellite connection. It will provide more reliable results based on real satellite traffic. Since there are still developing a new more powerful methods of accelerating satellite links, it will be necessary to extend this work about these techniques. The result of this research also can be used as a basis for future implementation of satellite accelerator which can encapsulate several enhancing method into one single node.

48 Bibliography

[1] KOTA, S.L., LEPPÄNEN, P.A., PAHLAVAN, K., Broadband Satellite Communications for Internet Access. Springer Science & Business Media, 2011, 421 p. ISBN 9781441988959, doi: 10.1007/978-1-4419- 8895-9

[2] Satellite Industry Association, State of the Satellite Industry Report. Bryce Space and Technology, June 2017. Available at:

[3] ELBERT, B., Introduction to Satellite Communication. , Artech House, 2008, 620 p., ISBN 9781596932104.

[4] JO, K.Y., Satellite Communications Network Design and Analysis. Artech House, 2011, 505 p., ISBN 9781608071944.

[5] UKEssays, Modulation Systems Used In Satellite Communica- tions Ii Computer Science Essay. November 2018 [online] (18. 4. 2019). Available at:

[6] Data Communication Fundamentals: Digital Data, Analog Signals. IIT, Kharagpur, Version 2 CSE, [online] (18. 4. 2019). Available at:

[7] GIAMBENE, G., Resource Management in Satellite Networks: Opti- mization and Cross-Layer Design. Springer Science & Business Media, 2007, 338 p., ISBN 9780387539911, doi: 10.1007/978-0-387-53991-1

[8] DOFFOH, J., MEREISH R., PUCKETT, M. Analysis and comparisons of acceleration protocols for TCP over satellite. MILCOM 2005 – 2005 IEEE Military Communications Conference, Atlantic City, NJ, 2005, pp. 279-285 Vol. 1. doi: 10.1109/MILCOM.2005.1605698

[9] CROW, B., FEIGHERY, P., JURIK, M., SCOTT, K., TCP congestion control in shared satellite environments. MILCOM 2002. Proceed-

49 BIBLIOGRAPHY

ings, Anaheim, CA, USA, 2002, pp. 46-50 vol.1. doi: 10.1109/MIL- COM.2002.1180412

[10] BOUTABA, R., DE SOUZA, J.N., Managing QoS in Multimedia Networks and Services. Springer US, 2013, ISBN 978-0-387-35532-0, doi: 10.1007/978-0-387-35532-0

[11] RICHHARIA, M., WESTBROOK, L. D., Satellite Systems for Per- sonal Applications: Concepts and Technology. 2nd edition , Wiley Publishing, 2011. 476 p. ISBN 9781119956105

[12] BORDER, J.,GRINER, J., KOJO, M., MONTENEGRO, G., SHELBY, Z. Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations. IETF, RFC 3135, 2011. Available at:

[13] CAINI, C., FIRRINCIELI, R., LACAMERA, D. PEPsal: A Perfor- mance Enhancing Proxy for TCP Satellite Connections IEEE Aerospace and Electronic Systems Magazine, vol. 22, no. 8, pp. B9-B16, Aug. 2007. doi: 10.1109/MAES.2007.4301030

[14] ATHANASIOS, V., SPYROPOULOS, T., ZHANG, Y. Delay Tolerant Networks: Protocols and Applications CRC Press, Inc., Boca Raton, FL, USA., 1 edition, 2011, 362 p., ISBN 1439811083

[15] ANANDA, A.L., JACOB, L., OBANAIK, V., Secure performance enhancing proxy: To ensure end-to-end security and enhance TCP performance over IPv6 wireless networks. Computer Networks, Volume 50, Issue 13, p. 2225-2238, 2006, ISBN 1389-1286. Available at:

[16] FOLTYN, T., Majority of the world’s top million websites now use HTTPS. [online] (23. 4. 2019), September 2018 Available at:

[17] DESAI, D., What’s hiding in encrypted traffic? Millions of advanced threats. [online] (23. 4. 2019), February 2019 Available at:

50 BIBLIOGRAPHY

[18] CAINI, C., FIRRINCIELI., R., LACAMERA, D., PEPsal: a Performance Enhancing Proxy for TCP satellite connections (and future research directions at UoB). University of Bologna Italy, 2008 Available at: [19] MARCHESE, M., SITHAMPARANATHAN, K., Personal Satellite Services. International Conference, pp. 61-67, PSATS 2009, Rome, Italy, ISBN 9783642042607 [20] CHENG, Y., CHU, J., JAIN, A., RADHAKRISHNAN, S., ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering. IETF, Internet Draft, Aug 1998, Available at: [21] How Does TCP Splitting Work? [online] (13. 2. 2019) Available at: [22] HTTP Proxy Caching [online] (4. 5. 2019) Available at: [23] CHENG, Y., CHU, J., JAIN, A., RADHAKRISHNAN, S., TCP Fast Open. IETF, RFC 7413, 2014, doi: 10.17487/RFC7413, Available at: [24] ISHAC, J. A., Survey of Header Compression Techniques. NASA/TM– 2001-211154, 2001, Available at: [25] PING, W. et al., Design and Performance Analysis of Accelerator to Enhance TCP in Satellite IP Networks. Proceedings of 2011 Interna- tional Conference on Computer Science and Network Technology, Harbin, 2011, pp. 323-327. doi: 10.1109/ICCSNT.2011.6181967,

51 BIBLIOGRAPHY

[26] TYE, C. S., FAIRHURST, G., A Review of IP Packet Compression Techniques. Electronics Research Group, Department of Engi- neering, Aberdeen University, Scotland, 2003, ISBN: 1902560094, Available at:

[27] JACOBSON, V., Compressing TCP/IP Headers for Low-Speed Serial Links. IETF, RFC 2507, 1990, doi: 10.17487/RFC1144

[28] DEGERMARK, M., NORDGREN, B., PINK, S., IP Header Com- pression. IETF, RFC 2507, 1999, doi: 10.17487/RFC2507

[29] BORMANN, C., BURMEISTER, C., et al., RObust Header Com- pression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. IETF, RFC 3095, 2001, doi: 10.17487/RFC3095

[30] JONSSON. L-E., PELLETIER, G., SANDLUND, K., WEST, M., RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC- TCP). IETF, RFC 6846, 2013, doi: 10.17487/RFC6846

[31] CASNER, S., JACOBSON, V., Compressing IP/UDP/RTP Head- ers for Low-Speed Serial Links. IETF, RFC 2508, 1999, doi: 10.17487/RFC2508

[32] CASNER, S., GEEVARGHESE, J., KOREN, T., RUDDY,P.,THOMP- SON, B., Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering. IETF, RFC 3545, 2003, doi: 10.17487/RFC3545

[33] ROHC Library wiki: The ROHC protocol. [online] (12. 4. 2019) updates April 2018. Available at:

[34] Effnet AB, An introduction to IP header compression (white paper). February 2014. Available at:

[35] SRIDHARAN, M. et al., A Compound TCP Approach for High-speed and Long Distance Networks. July 2005, 12 p. Available at:

52 BIBLIOGRAPHY

[36] DAVIES, J., Performance Enhancements in the Next Generation TCP/IP Stack. [online] (22. 4. 2019), March 2010, Available at:

[37] BALASUBRAMANIAN, P., HAVEY, D., Core Network Stack Features in the Creators Update for Windows 10. [online] (22. 4. 2019), July 2017, Available at:

[38] BALASUBRAMANIAN, P., Updates on Windows TCP., Available at:

[39] GENG, Y., WANG, B., CS244’13: Proportional Rate Reduction for TCP. [online] (4. 5. 2019), March 2013, Available at:

[40] CORBET, J., LPC: Making the net go faster. [online] (4. 5. 2019), September 2011, Available at:

[41] DUKKIPATI, N. et al. https://conferences.sigcomm.org/imc/2011/docs/p155.pdf. Proceedings of the 11th ACM SIGCOMM Conference on Internet Measurement, Berlin, Germany, November 2011, Available at:

[42] KernelNewbies: Linux 3.2. [online] (22. 4. 2019), December 2017, Available at:

53 BIBLIOGRAPHY

[43] JAISWAL, S., KUMAR, R., RAO, S., TRIVEDI, S., Comparative performance evaluation of TCP Hybla and TCP Cubic for satellite communication under low error conditions. 2010 IEEE 4th International Con- ference on Internet Multimedia Services Architecture and Appli- cation, Bangalore, 2010, pp. 1-5. doi: 10.1109/IMSAA.2010.5729424

[44] CAINI, C., FIRRINCIELI, R., TCP Hybla: a TCP enhancement for heterogeneous networks. International Journal of Satellite Communi- cations and Networking, 2004, pp. 547-566. doi: 10.1002/sat.799

[45] DAYMA, R., VANZARA, R., Improved TCP Hybla: A TCP enhancement for link with high RTT and error rate. 2012 Nirma University International Conference on Engineering (NUiCONE), Ahmed- abad, 2012, pp. 1-6. doi: 10.1109/NUICONE.2012.6493205

[46] KIM B., LEE J., OH D., PARK M., SHIN M., TCP Hybla+: Making TCP More Robust against Packet Loss in Satellite Networks. Computa- tional Science and Its Applications - ICCSA 2011, Springer, Berlin, Heidelberg, vol 6785, 2011,. doi: https://doi.org/10.1007/978-3- 642-21898-9_36

[47] CASETTI, C., GERLA, M., MASCOLO, S., SANADIDI, M. Y., WANG, R., TCP Westwood: Bandwidth Estimation for Enhanced Trans- port over Wireless Links. Wirel Netw, vol. 8, pp. 287-297, 2001, doi: 10.1145/381677.381704

[48] HA, S., RHEE, I., XU, L., CUBIC: A New TCP-Friendly High-Speed TCP Variant. SIGOPS Oper. Syst. Rev., vol. 42, no. 5, 2008, 64-74pp. doi: http://dx.doi.org/10.1145/1400097.1400105

[49] AHMAD, M. et al., TCP CUBIC*: A Transport Protocol for Improv- ing the Performance of TCP in Long Distance High Bandwidth Cyber- Physical Systems. 2018 IEEE International Conference on Commu- nications Workshops (ICC Workshops), Kansas City, MO, 2018, pp. 1-6. doi: 10.1109/ICCW.2018.8403545

[50] HA, S., RHEE, I., Hybrid Slow Start for High-Bandwidth and Long-Distance Networks. Dept. of Computer Science, North Carolina State University, 2008, Available at:

54 BIBLIOGRAPHY

[51] DAVIE, B., PETERSON, L. Computer Networks: A Systems Approach. Elsevier, 2012 Available at:

[52] KRISTIANSEN, E., ROSETI, C., TCP Noordwijk: optimize TCP- based transport over DAMA in satellite networks. June 2008, doi:10.2514/6.2008-5524

[53] FAZIO, P., TROPEA, M., Evaluation of TCP versions over GEO satellite links. 2013 International Symposium on Performance Evaluation of Computer and Telecommunication Systems (SPECTS), Toronto, ON, 2013, pp. 86-90. Available at:

[54] SCPS User Guide V2.1. The MITRE Corporation, 2015Available at:

[55] Consultative Committee for Space Data Systems, Recommenda- tion for Space Data System Standards: Space Communications Protocol Specification (SCPS) Transport Protocol (SCPS-TP). CCSDS 714.0-B-2, 2006, Washington DC, USA.

[56] AKYILDIZ, I. F., MORABITO, G., PALAZZO, S., TCP-Peach: a new congestion control scheme for satellite IP networks. IEEE/ACM Transactions on Networking, vol. 9, no. 3, pp. 307-321, June 2001, doi:10.1109/90.929853

[57] GÜNGÖR, T., GÜRGEN, F., ÖZTURAN, C., YOLUM, P., Computer and Information Sciences – ISCIS 2005: 20th International Symposium, Istanbul, Turkey, October 26 – 28, 2005, Proceedings. Springer-Verlag Berlin Heidelberg, Istanbul, Turkey, 2005, ISBN 978-3-540-32085-2, doi: 10.1007/11569596

[58] DummyNet [online] (4. 4. 2019) Available at:

55 BIBLIOGRAPHY

[59] Linux man page: tc(8) [online] (6. 4. 2019) Available at:

[60] Linux man page: time(1)) [online] (12. 4. 2019) Available at:

[61] Traffic Control Manual For Lab1 [online] (6. 4. 2019) Available at:

[62] Wikipedia contributors, TCP Fast Open [online] (6. 4. 2019), Wikipedia, The Free Encyclopedia, Revision 17.8. 2018, Available at:

[63] CELEDA, P. et all, Network Traffic Characterisation Using Flow-Based Statistics. Institute of Computer Science, Masaryk University, Brno, Czech Republic, 2006, Available at:

[64] RAMASUBRAMANIAN, V., SIRER, E., Proactive Caching for Better than Single-Hop Lookup Performance. Cornell University, Ithaca NY, 2004 Available at:

[65] Transparent Proxying [online] (14. 4. 2019). Available at:

[66] Wikipedia contributors.General Data Protection Regulation. [online] (27. 4. 2019), Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 18 Apr. 2019, Available at:

[67] The OpenSource ROHC library. [online] (28. 4. 2019), Available at:

56 BIBLIOGRAPHY

[68] BERTHOU, P. et al. Which Transport Protocol for Hybrid Terrestrial and Satellite Systems?. Personal Satellite Services, PSATS 2012, Mar 2012, Bradford, United Kingdom. paper 30. Available at:

57 A Appendix A

A.1 Electronic Attachment

∙ Accelerator.ova – virtual machine with installed PEPsal and RoHC library

– User: pepsal, Password: satellite – Readme file with examples of commands is located inthe folder /home/pepsal/Accelerator

∙ scripts.zip – archive of basic scripts used in testing phase

– generate_file.sh – bash script to generate text file of exact size filled with random content – DNS_test.sh – bash script to test speed of DNS response – TFO_client.py – python script to download one file from server with TFO feature – TFO_server.py – basic python script used as simple server with TFO feature – TFO_test.sh – test script for TFO testing multiple times – general_test.sh – simple bash script (template) to download file from server