masters dissertation tcp performance enhancing proxy based...

Masters Dissertation

TCP Performance Enhancing Proxy

Based on Cross-Layer Design in

Satellite Communication Systems

Department of Electrical and

Computer Engineering

Graduate School of Ajou University

Nathnael Gebregziabher Weldegiorgis

TCP Performance Enhancing Proxy

Based on Cross-Layer Design in

Satellite Communication Systems

Supervisor: Professor Jae-Hyun Kim

by

Nathnael Gebregziabher Weldegiorgis

A thesis submitted to the Graduate School of Ajou

University in Partial Fulfillment of the Requirements

for the Degree of Master of Science

Department of Electrical and

Computer Engineering

Graduate School of Ajou University

June, 2015

i

Acknowledgement

First of all, I would like to deliver my genuine gratitude to my

supervisor, Professor Jae-Hyun Kim, for his advice, support, guidance

and encouragement for the past two years. Professor Jae-Hyun Kim

cared about me a lot, not only in academic status but also about living

in Korea. Professor Jae-Hyun Kim also give me a chance to participate

in a project from which I experienced significant advantages. His

entertainments were also additional and great chances to enjoy living

in Korea and to understand its culture. Once again I am very thankful

to Professor Jae-Hyun Kim for all what you did for me and for your

unlimited kindness.

Beside my supervisor, I would like to thank you my thesis

committee members: Professor Kyo-Beum Lee and Professor Young-

June Choi for their encouragement and insightful comments.

I am also very grateful to Dr. Kyu-Hwan Lee for his continuous

assistance and support in my research area. He shared me his valuable

experience to improve my knowledge in the research career.

My sincere thanks extend to the devoted and hardworking of

alums and WINNER lab members. Thank you so much for all alumni

members that give me courage and respect. WINNER Lab members,

they are good colleagues in helping me to improve quality of my work.

ii

They are all my good friends and I spent a great time in WINNER Lab.

Dr. Hyun-Jin Lee, Dr. Choong-Hee Lee, Dr. Shin-Hun Kang, Dr. Ji-Su

Kim, Dr. Kyu-Hwan Lee, Sung-Hyung Lee, Dr. Kwang-Chun Go,

Hye-Rim Cheon, So-Yi Jung, Jin-Ki Kim, Hee-In Yang, Hyun-Ki Jung,

Ki-Hun Kim, Heung-Sik Kim, Seung-Lyong Lee, Suk-Won Kang,

Jung-Ho Kang, Dong-Yeol Choi, Seung-Su Yoo, Won-Kyung Kim,

Jong-Mu Kim, Moonmoon Mohanty and Min-Kyo Jung: 나는

당신들을 모두 기억할 것입니다.

My great thanks also goes to all Space Electronics and

Information Engineering Lab members: Dal Geun Lee, Seung Yong

Kang, Jin Hong An, Hae Won Jung, Kyeong Rok Kim and Young Deuk

Kim. It was a fun time with you during sport match together with

WINNER Lab. Thanks also to Min Lee and Chen Yiliang from

Communication System lab.

In addition, I would like to thank my friends and all the people

who touched my life. Without their friendship, my life would have

been no fun at all.

Finally, I pass my deepest and sincere gratitude to all my lovely

family members: mother, brothers and sisters for their encouragement,

love and patience. Thank you my mother for giving birth to me at the

first place and supporting me throughout my life. My brothers and

iii

sisters, thank you so much for your unlimited advice and support and

cared about me a lot. I am proud of you. My great thanks goes also to

my aunts, my uncles and all my relatives. I will never forget your

advice and contribution. Thank you all!

iv

Abstract

Satellite communication system is an ideal medium to provide

Internet connectivity to wide area coverage. Most of the Internet

applications and services run over TCP/IP protocol to deliver data to

destinations. New satellite system architectures like Digital video

broadcasting-return channel via satellite (DVB-RCS) are being

designed to be fully IP based. However, geosynchronous orbit (GEO)

satellite channels are characterized by long round-trip time (RTT),

large bandwidth delay product (BDP) and high bit error rates (BER)

that cause to degrade standard TCP performance in satellite links.

In this thesis, we propose a cross-layer design scheme in TCP

splitting connections on DVB-RCS networks. A cross-layer

architecture allows for interaction between TCP and the resource

allocation (RA) scheme in the link layer. TCP congestion window

(CWND) is tuned using information on the RA in layer 2. To evaluate

the performance, we implement the tuned CWND on TCP Linux

kernel over TCP-splitting based performance enhancing proxy (PEP)

test-bed. The results show that TCP CWND can be adjusted by RA

information in the proposed cross-layer design. In all the results,

especially in higher link error rate, the performance of the customized

TCP is very impressive in both single and multiple sessions.

v

Contents

List of Figures…..………………………………………………... vii

List of Tables………………………………………………………. ix

List of Abbreviations……………………………………………… x

Chapter 1. Introduction ............................................................................................. 1

1.1 Background and Motivation ..................................................... 1

1.2 Contributions ........................................................................ 5

1.3 Overview ............................................................................. 6

Chapter 2. Related Works ......................................................................................... 7

2.1 Overview of Satellite Networks ................................................ 7

2.2 TCP Fundamentals ................................................................. 9

2.3 TCP Limitations in Satellite Communications ........................... 13

2.4 New TCP Modifications ........................................................ 15

2.5 Performance Enhancing Proxy(PEP) ....................................... 18

2.5.1 Overview .................................................................. 18

2.5.2 TCP-Splitting Based PEP Scheme ................................. 19

2.5.3 Multi-Session in TCP-Splitting Based PEP ..................... 20

2.6 Cross-Layer Approach .......................................................... 22

Chapter 3. TCP-Splitting Based on Cross-Layer Design ........................................ 25

3.1 System Architecture .......................................................................... 25

3.2 TCP Initiation Procedure .................................................................. 26

3.3 TCP Demand Rate Request .............................................................. 28

3.4 Resource Allocation and Contention Window Tuning ...................... 30

Chapter 4. Implementation ..................................................................................... 32

4.1 TCP Linux Kernel ............................................................................. 32

4.2 Tuned CWND Implementation ......................................................... 33

4.3 Test-bed Description ......................................................................... 34

4.3.1 Test-bed Architecture ........................................................... 36

4.3.2 PEP Software ....................................................................... 38

vi

4.3.3 Dummynet ........................................................................... 39

Chapter 5. Performance Evaluation .............................................. 42

5.1 Single Session Performance ............................................................. 43

5.1.1 CWND Performance ............................................................ 44

5.1.2 Throughput Performance ..................................................... 45

5.2 Multi-Session Performance .............................................................. 50

5.2.1 CWND Performance ............................................................ 50

5.2.2 Throughput Performance ..................................................... 50

Chapter 6. Conclusion .................................................................... 55

Reference …………………………………………………………. 57

vii

List of Figures

Figure 1. Broadband satellite system ..................................... 8

Figure 2. Connection setup and termination ........................ 10

Figure 3. TCP slow start mechanism .................................... 11

Figure 4. Generation of duplicate ACKs ............................. 12

Figure 5. TCP operation ....................................................... 13

Figure 6. Proxy architecture in satellite Internet networks .. 20

Figure 7. Multi–connection network architecture ............... 21

Figure 8. Cross-layer interactions ........................................ 23

Figure 9. The proposed protocol stack architecture ............. 26

Figure 10. PEP initiation and cross-layering information

exchange ...................................................................... 28

Figure 11. Real test-bed enhancing pair of PEP .................. 35

Figure 12. Experimental setup architecture ......................... 38

Figure 13. CWND in satellite networks at error-free channel

..................................................................................... 47

Figure 14. CWND in satellite networks at 610BER ....... 48

Figure 15. Average TCP throughput in satellite networks at

1010BER ................................................................. 48


610BER .................................................................. 49

viii

Figure 17. Average TCP throughput Vs. BER in satellite links

..................................................................................... 49


with five simultaneous TCP sessions ........................... 52

Figure 19. CWND in satellite networks at 610BER with

five simultaneous TCP sessions ................................... 52

Figure 20. Average TCP throughput of multi-sessions in

satellite networks (at BER = 0).................................... 53

Figure 21. Average TCP throughput of multi-sessions in

satellite networks (at 610BER ) ................................ 53

Figure 22. Average TCP throughput Vs. BER in presence of

five connections ........................................................... 54

ix

List of Tables

Table 1. Sample TCP throughput ......................................... 36

Table 2. Test-bed environment ............................................. 41

Table 3. Setup configuration parameters ............................. 43

Table 4. TCP throughput (RTT = 0ms, PER = 0, 1Gbps) .... 44

x

List of Abbreviations

ACK: Acknowledgement

AQM: Active queue management

ASTP: Advance satellite transport protocol

BDP: Bandwidth delay product

BER: Bit error rate

CA: Congestion avoidance

CWND: Congestion window

DAMA: Demand assigned multiple access

DVB-RCS: Digital Video Broadcasting-Return Channel via

Satellite

DVB-S2: Digital Video Broadcasting Satellite-second Generation

E2E: End-to-end

ETSI: European Telecommunication Standards Institute

GEO: Geosynchronous orbit

NACK: Negative acknowledgment

NCC: Network control center

PEP: Performance enhancing proxy

PER: Packet error rate

xi

RCST: Return channel satellite terminal

RF: Radio frequency

RTT: Round-trip time

SS: Slow start

STP: Satellite transport protocol

SYN: Synchronize

TBTP: terminal burst time plan

TDMA: Time division multiple access

1

Chapter 1. Introduction

1.1 Background and Motivation

Satellite communication technology has been used for many years.

It is viable medium for broadcasting information to different users,

linking remote geographical locations, and providing connectivity to

wide coverage areas. In the last past years, the development of DVB-

RCS protocol and the use of new satellite networks allowed to provide

Internet access to wide areas. The DVB-RCS standard is stated in ETSI

[1]. It uses forward link, following the DVB-S2 standard [2] and an

interactive return link shared among a group RCSTs. The return link is

composed of a set of frequencies and uses TDMA access mechanism

to avoid collisions. In the specification of DVB-RCS, DAMA has been

included as a resource allocation mechanism capable of dynamic

channel assignment [3].

Currently most of the Internet applications and services in satellite

networks run over the TCP/IP protocol to deliver data to destinations

over long propagation delay and wireless channel. Originally, TCP was

designed for wired networks which have short propagation delay and

error-free property. In satellite networks, however, these conventional

TCP protocols are inadequate. Because satellite communications are

2

characterized by long RTT and high PER on the radio link that causes

to degrade the TCP performance [4]. TCP interprets all segment losses

as congestion signal, thus forcing the transmission rate to be

unnecessary reduced, by halving the current contention window [5].

To address TCP problem in satellite networks, many researches

have been done [5-13]. One of the solutions is link layer solution which

involves the use of forward error correction (FEC) and automatic

repeat request (ARQ) [5]. It can reduce the packet loss due to

transmission errors via satellite link. However, this method may not

address the impact of the long propagation delay.

Multiple an E2E TCP protocols have been proposed for the

satellite environment [6-8]. Comparative analysis of several

techniques to improve the E2E performance of TCP over lossy wireless

links have been studied [9]. Standard TCP does not fully utilize the

network capacity in large BDP links due to the weak control

mechanism on its congestion algorithm. Many aggressive loss-based

congestion control algorithms have been developed and ongoing to

improve the TCP throughput in satellite links [4]. They typically

involve tuning TCP so that the long RTTs representative of satellite

links do not negatively impact performance [10]. Two versions that

perform well over high-speed networks are Hybla[6] and TCP CUBIC

3

[7]. These enhanced TCP protocols achieve high throughput even in

long propagation delay. However, they decrease their performance

aggressively as the transmission error increases [4],[9-10].

ASTP has been designed to adapt satellite characteristics [11]. It

attains high throughput which is very close to the available satellite

capacity. It exploits the knowledge of the bandwidth allocated to each

terminal, as available from the satellite network operator. Due to the

specialized nature of the protocol, however, every node on the network

needs to modify its protocol and has some issues related to fairness

with other TCP variants.

The third solution to mitigate the effect of satellite delay and

packet loss problems on TCP is PEP. There are many literatures on PEP

to improve TCP performance in satellite networks [12-15]. PEP

exploits the advantages of advanced or customized TCP versions over

satellite links. In satellite communication, mostly PEP is configured to

TCP splitting to isolate the satellite portion from the terrestrial

networks. The terrestrial segments ensures compatibility with all the

end users, while protocol for the satellite segment matches the

characteristics of the satellite link. This scheme keeps the protocol

stack of end–users unchanged and the RTT felt by them is smaller than

the real RTT. Therefore RTT of satellite segment will not affect the

4

transmission rate of the sender. However, if the satellite resource for a

satellite terminal is not correctly allocated in the link layer, the

customized protocol in splitting connections cannot be properly

operated [16]. The effect of the packet loss on the satellite segment

causes to inappropriate treatment of the return message which leads to

degrade TCP performance [17]. Therefore, TCP splitting is not enough

to achieve desirable throughput due to limited bandwidth and presence

of erasure channel in satellite networks.

Space communication links are prone to bit inversion and changes

based on the link parameters. TCP sender reduces its CWND according

the packet loss. Due to high probability of error rates on satellite

channel, this assumption may lead to under resource utilization. There

is no NACK mechanism to distinguish the cause of packet loss on the

PEP scheme. It degrades its throughput as the link error rate becomes

large. Therefore, the satellite resource in a satellite terminal need to

allocate correctly in the link layer to operate the customized protocol

in splitting connections properly. Once the information of resource is

allocated, the CWND of TCP needs to keep its tuned value until a true

congestion occurs.

In this thesis, we propose a TCP splitting solution based on cross-

layer design for TCP that directly uses information of resources

5

allocation (RA) in the link layer. TCP uses information in the satellite

resource allocation to tune the CWND accurately by requesting a

demand rate. This improves TCP performance over isolated satellite

segment by adjusting the CWND using the information of the RA.

1.2 Contributions

The goal of this thesis is a cross-layer design for TCP Splitting

connections in DVB-RCS networks. It describes a new architecture for

interaction between TCP splitting connection and the information of

resource allocation in link layer. We implement tuned CWND on TCP

Linux kernel and compare its performance with that of E2E high-speed

TCP variants in satellite link. It improves TCP performance in satellite

networks especially in bandwidth limited and high link error channels.

The following is our main contribution of this thesis:

Architecture of the new protocol stack of satellite link is

described.

TCP CWND adjusting algorithm and Tuned CWND

implementation on TCP Linux kernel are presented.

Test-bed architecture for performance evaluation of the

proposed protocol in single and multiple sessions is presented.

6

1.3 Overview

The remainder of this thesis is organized as follows. In Chapter 2,

an overview of satellite networks, TCP fundamentals, TCP limitations

in satellite communications, TCP modifications, PEP and cross-layer

approach are described. We present the proposed scheme in Chapter 3.

It describes the proposed architecture, TCP initiation, TCP demand rate

request and resource allocation procedure. An overview of the TCP

Linux kernel, tuned CWND implementation and an experimental test-

bed architecture are followed in Chapter 4. Performance evaluation of

TCP over satellite links is presented in Chapter 5. Finally, thesis is

concluded in Chapter 6.

7

Chapter 2. Related Works

2.1 Overview of Satellite Networks

Operational satellite networks around the world provide variety

of missions such as television, voice communications, meteorology,

research, defense, and so on. For example, GEO satellite

communications are useful for scenarios such as rural areas,

airplane/ship that have no terrestrial infrastructure to communicate.

DVB-RCS defines the complete air interface specification for

two-way satellite broadband system [1]. It includes gateway (ground

station), NCC), satellite terminal, GEO satellite, and end user terminals.

A simple broadband satellite link model is shown in Figure 1. Control

and monitoring functions in DVB-RCS protocol is provided by NCC.

One of the control functions is resource management. Gateway

interfaces the satellite system and the terrestrial networks or Internet.

GEO satellite reflects or repeats received traffic from transmitter to

receiver on the ground. Satellite terminal shares time-frequency

resources in the return link through a DAMA scheme. The NCC

assigns the resources request by the satellite terminal. It notifies the

satellite terminal in the forward link using a TBTP message.

8

Figure 1. Broadband satellite system

In the DVB-RCS, the standard can allocate resource according to

the satellite terminal capacity request. There are four types:

Continuous Rate Assignment (CRA): CRA allocates a fixed

slot for the entire duration of satellite terminal connection.

Rate-Based Dynamic Capacity (RBDC): Dynamic rate capacity

granted in response to explicit satellite terminal requests. It allows for

statistical multiplexing and results efficient bandwidth usage.

Volume-Based Dynamic Capacity (VBDC): VBDC is

requested by the satellite terminal to the NCC. It requires for a certain

amount of volume capacity to transmit information. VBDC is the

default mode in DVB_RCS.

Free Capacity Allocation (FCA): It is volume capacity that shall

be assigned satellite terminal which is unused by CRA, RBDC and

VBDC.

9

Satellite communication applications are growing fast to provide

wider range of services with Internet. However, the TCP performance

in satellite links is limited due to presence of the radio link channel.

Satellite channels are characterized by long RTT (around 500ms), large

BDP and high bit error rates (BER) measured typically in 10 .

2.2 TCP Fundamentals

In today's networks, TCP/IP communication protocol has become

the most commonly used. TCP provides a reliable connection-oriented

transport service over the IP network. It is accessible through an

application programming interface (API) implemented in the operating

system kernel level [19].

Generally, three segments are required to establish a TCP

connection between client and server. Client initiates TCP connection

by transmitting SYN segment. Server responds ACK together with its

own SYN. The client sends an ACK back to the received SYN from

server. Four segments are required to terminate TCP connection by

exchanging FIN and ACK segments (see Figure 2).

As TCP was first introduced, BER at the link layer and

disconnections on the link layer have been assumed negligible. So for

10

wired links, the BER is typically in a range of 10 and has very less

probability of lack of connection on the link layer. So it was supposed

that packet drop only occurs in case of congestion in the network layer.

Figure 2. Connection setup and termination

Congestion window control mechanism of TCP consists of SS

phase, CA phase, fast retransmission and fast recovery phase. SS and

CA are used by a TCP sender to control the amount of data injected

into the network, while the other two are used to recover from packet

losses without the need for excessive retransmission timeouts (RTOs).

In SS phase, if packet does not loss, CWND increased exponentially

SYN

Client Server

SYN‐ACK

ACK

FIN

ACK

ACK

FIN

Data Transfer Phase

Connection Initiation Phase

Connection TerminationPhase

11

until it reaches a slow start threshold ( ssthresh ). The SS mechanism is

revealed in Figure 3.

Figure 3. TCP slow start mechanism

If the CWND reaches ssthresh , TCP enters the CA phase. During

this phase, CWND linearly increases by one maximum segment size

for each RTT until a packet loss event occurs i.e. CWND increases

linearly. In TCP, there are two indications of packet loss; duplicate

ACKs and retransmission timeouts. When the TCP sender discovers

that a packet has been dropped by network, it sets the ssthresh equal

to one-half of the current value of CWND.

TCP generates duplicate ACKs when an out-of-order segment is

received or lost segment (see Figure 4). Then, TCP performs a

cwnd = 1

cwnd = 2

cwnd = 4

cwnd = 8

Host A Host BRT

T

Time

cwnd

SS

12

retransmission of what appears to be the missing segment, without

waiting for a retransmission timer to expire or reduces its CWND to

half in order to decrease its transmission rate.

Figure 4. Generation of duplicate ACKs

Fast retransmit sends segment seen as the missing in CA, instead

of SS is performed. This is the fast recovery algorithm that prevents

the TCP session pipe from being completely empty after the fast

retransmission of a single lost segment. If timeout occurs, TCP enters

to SS. Figure 5 illustrates the operation of TCP.

cwnd = 1

cwnd = 2

cwnd = 4

3 Duplicate ACKs

cwnd = 1

cwnd = 2

cwnd = 4

3 Duplicate ACKs

A B A B

13

Figure 5. TCP operation

2.3 TCP Limitations in Satellite

Communications

TCP in GEO satellite networks is affected by a number of

problems that limit its performance. Factors that are inappropriate to

TCP mechanisms over satellite links are the following:

Latency: GEO satellites are located at high altitude around 36,000km

from earth, so that they take long time to convey. In long propagation

delay, TCP requires a large window and a more accurate RTT

assessment. Regardless of the channel capacity, the receiver’s window

size is very important because throughput is upper bounded by the RTT

value:

Time

cwnd

Timeout

SSFast Retransmit/Recovery

y

y/2 ssthresh

Point of network congestion

Sender receives a duplicate ACK

CA CA

14

min , , (1)

where and represent send buffer size and

receive buffer size respectively. The maximum throughput, maxT is

given in (2).

. (2)

Transmission errors: Higher powered satellites employ new

modulation and coding techniques to make BER very low over GEO

systems. However due to dynamic channel property, link failures affect

the entire TCP throughput by retransmission of corrupted data packet

and wrong interpretation packet loss that reduces sending rate

accordingly. This leads poor resource utilization and this issue is

amplified in long propagation delays.

Congestion: The bandwidth of the bottleneck link between earth and

satellite basically depends on the uplink/downlink spectrum. However

the satellite gateway can be easily congested because of the interface

from the satellite and the Internet. This will happen especially if

admission controls were loose.

Symmetry problem: In satellite communication, bandwidth is

asymmetric. In other word, the bandwidth available in the forward link

is much higher than in the return link. In the return link, ACK packets

15

may congest and to be delayed and lost. Due to the low rate of the

received ACK, it will decrease the speed of SS and CA phases. Delayed

ACK also triggers the unnecessary retransmission.

In general, conventional TCP’s congestion control algorithms are

inadequate to satellite networks, because it does not provide special

ACK for bit errors in the arriving segments. TCP assumes that every

missing ACK indicates network congestion. This misinterpretation of

packet losses causes to reduce the transmission rate which leads to

underutilization of the satellite channel.

2.4 New TCP Modifications

The two major problems that impair internet satellite

communications are long RTTs and segment losses on the satellite

radio links [4]. To cope with these problems, new TCP modifications

dedicated to characteristics of wireless networks are proposed, among

all: TCP Westwood [18], TCP Hybla[6], CUBIC[7] and some others

designed more efficiently to adapt satellite characteristics like

ASTP[11].

TCP Westwood limits the impact of the losses introduced by a

wireless channel due to congestion [18]. It tries to choose ssthresh

16

accordant with the actual available bandwidth. The bandwidth is

approximated by averaging the rate of return measured ACK. TCP

Westwood uses a discrete-time filter that calculates the available

bandwidth; the value of the filtered available bandwidth kb

at time

kt t is given by:

11 1

2k k

k kk k

b bb b

, (3)

where kb is the sampled value of the available bandwidth,

( / ) )2 2(k k k and 1 / is the cutoff frequency of the

filter. From this, the ssthresh and CWND are calculated in a RTT

minimum, minRTT as

kb∗ . (4)

1

ssthresh CWND ssthreshCWND

after timeout

. (5)

TCP Hybla avoids the performance difference that arises from

long RTTs. The basic idea is to obtain the same instantaneous segment

transmission for long RTT links (e.g. satellite). It introduces many

process steps including change of the CWND increase rate in both the

SS and the CA phases, the channel estimation, the selective ACK

(SACK) policy and required the adoption of a time stamp and the

packet interval recommend to use. It introduces a reference connection

aims to the same performance. The normalized round trip time,

17

ρ, given as

. (6)

The congestion window in both SS and CA phase in TCP Hybla is

replaced in (7).

ρ

21

2

ρ

i

ii

i

W SS

WW CA

W

. (7)

TCP Hybla does not slowdown in i.e. connection

speeds in connection with the , and sets the minimum value of ρ

is 1. For longer RTT, the advertised window at the receiver side

increases. In general, TCP Hybla ensures a sufficient transfer rate for

the standard long RTT connection using more effective congestion

control algorithm.

CUBIC modifies window control and improves its TCP-

friendliness and RTT-fairness [7]. It uses a cubic increase function in

terms of the elapsed time since the last loss event. If a cubic function

is less than the standard TCP window it grows to provide a fairness of

the standard TCP. In addition, all real-time characteristics of the

protocol keeps the window growth rate independent of RTT. Currently,

it is the default TCP algorithm in Linux OS.

STP [20] and ASTP [11] are specifically designed for the satellite

18

environment. STP is implemented in the kernel. It makes use of the

same socket layer and IP code, and has the same API like TCP. STP is

relatively performed like TCP-SACK on forward side. However, it

uses a much smaller bandwidth in the return path and attractive

candidate in asymmetric networks. ASTP is already built around the

concept of integrated injection control theory in active AQM control.

ATSP uses the knowledge of the bandwidth allocated to each terminal

such as from the satellite network operator.

2.5 Performance Enhancing Proxy(PEP)

2.5.1 Overview

PEP is a network agent that improves the network performance

between E2E nodes. It can be inserted at any layer of TCP/IP protocol,

it means that it is particular network architecture. PEP divides the E2E

TCP into segments where native performance suffers due to the

characteristic of the environment [21]. It uses to optimize TCP

performances in satellite networks.

PEP classification and types are defined [22]. It can be classified

as TCP splitting or TCP snooping. Other type of classification property

may be integrated or distributed. Integrated PEP runs on a single node

19

of the network, while distributed PEP requires to install on both end of

the dissimilar network that causes performance degradation. Other

property of PEP is symmetric property. Symmetric PEPs use identical

behavior in forward and reverse link, whereas the asymmetric PEP

operates differently in each direction. The most commonly used type

of proxy’s architectures in satellite communication is TCP connection-

splitting based PEP. It isolates the satellite segment from the terrestrial

network.

2.5.2 TCP-Splitting Based PEP Scheme

The TCP-splitting proxy is inserted at the end legs of the satellite

to partition the satellite network. Majority of the traffic flow on the

satellite network passes through it. The main purpose of this scheme is

transparently splitting the E2E TCP connection between source and

destination into three separate connections (distributed) as shown in

Figure 6. The two proxies exist between the end hosts, and they

intercept the data on the client and server side of the satellite link. The

three connections are established between the two proxies, server and

client. The transport layer protocol for middle segment will be either

optimized TCP or another.

20

Figure 6. Proxy architecture in satellite Internet networks

2.5.3 Multi-Session in TCP-Splitting Based PEP

In this scheme, multiple TCP connections are interfaced to the

two proxies. They use common bandwidth i.e. the bottleneck which is

the satellite link. In this scenario, it needs to share the available

resource among simultaneous connections [23]. Thus, the speed of

each connection is adjusted in real time so that the total bandwidth

allocated fairly. However, both RTT and link error will still penalize

the transmission of packets. The architecture for multiple connections

in satellite network is shown in Figure 7.

Internet Satellite Link

Internet

1 Transmitted Data (intercepted by Proxy)

2 ACK for the Intercepted Data

4 Transmitted Data

5 ACK for the Intercepted Data3 Data Transmitted

to the next Proxy

Server Proxy 1 Proxy 2 Client

TCP Connection Customized TCP/ Accelerated TCP or other

Transport Connection

TCP Connection

21

Figure 7. Multi–connection network architecture

In the system without PEP solution, the native terminals (client

and server) use an E2E TCP protocols. Various TCP protocol schemes

use the common channel. These TCP protocols may use different

congestion detection mechanism that led unfairness issue on the

available bandwidth. In the use of transparent PEPs, it requires no

modifications to end users. The terrestrial segments can use

conventional (default) TCP deployed at client and server, and satellite

segment exploits customized TCP between the gateway and satellite

terminal. All the simultaneous connections may use a common

congestion detection mechanism in connection splitting PEP solution

on the bottleneck link.

In many literatures, they use difference mechanisms to implement

TCP splitting [14-15]. For example, in [14] uses PEPsal software

22

which is an integrated, transparent and multilayer open source software

on Linux OS that enhances TCP performance by splitting the

connection at the satellite gateway. It allows to use advanced protocol

over satellite link to optimize TCP of the satellite portion.

In general, the use of PEP does not require modification of

existing TCP stack implementations of the end nodes, which in turn

allows this mechanism to be backward compatible with existing TCP

stack implementations. However, this technique has disadvantage.

Because it can hide the information of TCP header in the network layer

of IPSec security solution. When using the split TCP connection, it is

not possible to maintain security mechanisms.

2.6 Cross-Layer Approach

Cross-layer design approach exploits the dependence of protocol

layers to obtain performance gains. It allows direct communication

between protocols at non-adjacent layers, sharing variables between

layers, creating new interfaces between layers and joint tuning of

parameters across layers. The new interfaces are used for information

sharing between the layers at runtime. The interaction of non-adjacent

layers permit to improve the higher-layer throughput, meet new

23

services and application requirements as well as user satisfaction [24].

The direction of information flow along cross-layer may be upward

direction, downward direction or back and forth. For example in

upward information flow, if higher-layer protocol requests some

information from the lower layer, the lower send the requested

information through the interface directly. Figure 8 shows the bottom-

up and top-down signaling architecture in cross layer design.

Figure 8. Cross-layer interactions

The introduction of DVB-RCS encourages designers to adapt

cross-layer design for joint optimization of layers. Many literatures

have been published on cross-layer design approach in satellite

networks to enhance the interaction among protocols in different layers

of satellite networks [25-28]. According to [25], a scheduler design

have been proposed on the basis of cross-layer design between the

Application Layer

Top‐downsignaling

Bottom‐upsignaling

Transport Layer

Network Layer

Data link Layer

Physical Layer

24

physical and MAC layers. In [26], by the exchange of information

between the TCP and the link layer, the CA method was proposed to

prevent queue overflow without a long delay. By using the size of the

queue in a lower layer, the CWND of TCP is adjusted in [27], [28].

However, to adjust TCP CWND more accurately, a cross-layer design

for TCP that directly uses information on the satellite resource

allocation (RA) in the link layer has not been covered before. In this

thesis, we implement the tuned CWND on TCP Linux kernel over

isolated satellite segment using TCP splitting.

25

Chapter 3. TCP-Splitting Based on

Cross-Layer Design

In this chapter, we describe the proposed system architecture, the

procedure in the proposed protocol that includes the connection setup

between the client and server, TCP request for resource allocation as

well as the resource allocation procedure between NCC and satellite

terminal.

3.1 System Architecture

In this section, we define the protocol stack of TCP splitting based

on the cross-layer design which is shown in Figure 9. It adapts a pair

of TCP splitting connection to divide an E2E TCP connection into

three partitions. Terrestrial segments comply with the standard TCP

protocol to ensure compatibility with the server and the client, while

the protocol for the satellite segment can be customized to the

characteristics of the satellite links. A cross-layer approach allows

direct information exchange between non-adjacent layers, here

between TCP and link layer. The link layer is logically situated directly

above the physical medium, and it delivers data across the satellite link.

26

Direct communication between the two layers is more advantageous

so as to effect the compression of the network state. To set the optimum

TCP CWND through a satellite link, TCP sends the information

according to its need to the agent in the link layer and link layer provide

immediate cross-layer feedback to it.

Figure 9. The proposed protocol stack architecture

3.2 TCP Initiation Procedure

Figure 10 shows procedure in the proposed protocol. It illustrates

connection setup between the client and server, TCP demand rate

request as well as the resource allocation procedure between NCC and

satellite terminal.

In TCP initiation procedure, the gateway intercepts TCP SYN

TCP

Network

Link

PHY

Application

TCP

Network

Link

PHY

TCP

Network

Link

PHY

Application

TCP

Gateway

Wired

Satellite Channel

Server

Wired

TCP

Network

Link

PHY

TCP

Satellite Terminal

Client

InformationExchange

Standard TCP Standard TCPCustomized TCP

27

message using the TCP splitting based PEP. The gateway saves the

intercepted message and forward it to the client, and the PEP builds an

ACK packet and sends it to the server. When the server receives the

ACK from the gateway, it will send the next data packet immediately.

Similarly the satellite terminal also intercepts TCP SYN message

received from the gateway over the radio link and generates TCP

splitting. The satellite terminal sends an actual ACK to confirm and

clear the buffer and PEP free at the gateway. It also forwards the

intercepted TCP SYN to destination and waits for ACK from it. The

impact of long RTT on the terrestrial networks is avoided using this

configuration. In addition it allows to use optimized TCP between the

gateway and satellite terminal. These are the advantages of

implementing TCP splitting based PEP solution at the satellite legs

which totally isolate the satellite channel impairments.

28

Figure 10. PEP initiation and cross-layering information exchange

3.3 TCP Demand Rate Request

Satellite terminal may release the capacity request in special time-

slots or in data time-slots to the NCC. Each slot is characterized by a

frequency band, the start time and duration, and the communication

resources allocated to the control message through the forward channel

RCSTs. Resource allocation to satellite terminal is informed through

the TBTP message. DAMA algorithm is responsible for establishing a

Server Gateway/NCCSatelliteTerminal

Client

TCP SYN

TCP SYN

Request message of resource allocation

Resource allocation rate, RA

CWND Tuning

TCP SYN

TCP requests RD

RADecision

29

connection over the air interface of the DVB-RCS to assist the resource

allocation and control the amount of RF resources allocated to the

terminal according to its traffic demand. In the link layer, satellite

terminal uses the dynamic time slot allocation of RBDC.

Frequency-time resources may be configured freely according to

the standard. The NCC via DAMA method shares the frequency

resource-terminal time in the return link. If the satellite terminal

requests resources from NCC, NCC assigns the resources and informs

in the forward link. The resource allocation is determined by the

DAMA controller on the basis of the channel conditions and the

available resources. Each satellite terminal has DAMA agent at the link

layer.

Using the cross-layer design, TCP demands information from the

link layer. TCP requests information on its demand resource allocation

called demand rate (RD) to the link layer. The DAMA agent at the link

layer assigns the request demand and allocates the resource according

to it. TCP resource allocation rate, RD is calculated as

, (8)

where oW is the default value of CWND and rRTT is RTT of the

reference connection which aims to achieve the performance.

30

3.4 Resource Allocation and Contention

Window Tuning

In the customized TCP of the satellite terminal, it requests for

information, RA from the DAMA agent at the link layer by sending

resource allocation of rate, RD using the direct interface. Upon

receiving the request from TCP, the DAMA agent sends the request

message of RA including RD and protocol overheads to the DAMA

controller of the NCC. The DAMA controller then decides the resource

allocation of RA and its information is reported through TBTP in the

forward link. Upon receiving TBTP, the DAMA agent of the satellite

terminal reports RAto the TCP. TCP directly uses the assigned rate

information, RA from the link layer and tunes the CWND based on RA

information on the layer 2. Finally, rate RA is informed to TCP and

TCP adjusts its CWND. Therefore, the customized TCP calculates

CWND using RA in equation (9).

*

1 *ARTT R

CWNDK TCPsgmsize

, (9)

where RTT and are round-trip time and resource allocation

respectively. K is ratio of overhead including headers of the TCP/IP

and the link layer andTCPsgmsize is size of TCP segment.

CWND size is a key parameter that reflects the effect of network

31

conditions. CWND adjusts the transmission rate of the TCP segment;

in other words, it is an implicit indication of how to detect the status of

the network state through the entire data transmission path. It

determines the amount and the rate of packets arriving on the link layer.

Since the satellite band has resource scarcity, the scheduler is important

to optimize the resource allocation for the desired connection. TCP

requests the information on the link layer, the link layer assigns a

frequency-time slot frequency based on the network conditions gets

from the forward link. Thus, by incorporating the demanded rate,

into the link layer to adjust CWND parameter is capable of allocating

its resources in a more intelligent fashion. There is less probability of

packet drop by congestion on satellite segment. Therefore,

transmission rate will not unnecessary decreased due to packet loss on

the radio link.

32

Chapter 4. Implementation

This chapter presents overview of TCP Linux kernel and

implementation of tuned CWND on it. It also describes the test-bed

architecture that is used to evaluate the TCP performance in satellite

networks.

4.1 TCP Linux Kernel

TCP is implemented on the Linux kernel of the network code and

its congestion control is designed by reducing the transfer rate when

the congestion is detected [29]. In Linux kernel, TCP codes are found

in net/ipv4. TCP header files are located in include/net. Some of the

source files and header file: tcp_input.c, tcp_output.c, tcp_cong.c, tcp.c,

tcp_ipv4.c, tcp_timer.c and tcp.h. TCP algorithm increases or decreases

the size of the transmission window to adjust its transmission rate.

Upon receiving ACK, tcp_cong_avoid function calls to a linear or

exponential increase of the CWND depending on the phase state (CA

or SS). When it detects the packet loss on the network, it responses by

reducing the window accordingly.

33

4.2 Tuned CWND Implementation

In this thesis, we implement tuned CWND on TCP Linux kernel.

The modification of TCP Linux kernel is done on the sender side of the

traditional TCP (TCP Reno) congestion control algorithm. The tuned

CWND of TCP assumes that most indications of congestion by the

current TCP connection used in the satellite network does not

necessitate a reduction in the transmission rate of the connection, as

such, the CWND size should remain constant until some other satellite

terminal is connected and causes to occur true congestion. This makes

to have constant congestion window by avoiding the CWND probing

mechanism in SS phase in standard TCP as well as the blindly

reduction of the sending window to adjust the transmission rate.

We calculate the maximum number of segments that the channel

can accommodate based on the available capacity (bandwidth = 8Mbps,

in our case).

*maxcw BW RTT , (10)

where are bandwidth and round-trip time respectively

and maxcw is maximum CWND. Then the number of segments is

calculated in (11).

34

max

*8h h h

cwnumber of segments

MSS IP MAC PHY

, (11)

where MSS is maximum segment size in bytes (1460bytes).

, h hIP MAC and hPHY represent headers of the layers which totally

account around 70bytes.

We modify the source codes of TCP Linux kernel to change the

congestion window algorithm. On the source codes of TCP Linux

kernel: tcp_metrics.c, tcp_cong.c, tcp_input.c and tcp_output.c, we

update the sending rate to be static. snd_cwnd command is assigned

with the calculated number of segments that need to achieve the

maximum transmission rate on the satellite channel. We assume that

this transmission rate remains constant until the satellite terminal is

requested for new resource allocation or true congestion is happened.

In addition in TCP header of the Linux kernel, tcp.h: we modify also

the TCP initial congestion (TCP_INIT_CWND) with maximum

number of segments. After modifying the source files and header file,

we compile and install the Linux kernel.

4.3 Test-bed Description

Before we describe our test-bed implemented to evaluate our

35

proposed scheme, we introduce first the real test-bed shown in Figure

11. It enhances a pair of PEP on the server and client side. We

conducted an experiment on it to evaluate the performance of TCP

splitting and various TCP variants like TCP Hybla, CUBIC, TCP Reno

and Compound TCP (CTCP) [30] which is default TCP on Windows

OS. PEP technique improves TCP throughput over E2E TCP protocols.

Table 1 shows sample results taken from this experiment. The end

terminals (client and server) use Window OS. The PEP client and PEP

server use Linux OS because the PEP software (PEPsal)[31] which acts

as TCP splitting works on Linux. The enhanced TCP between the PEP

server and PEP client is TCP Hybla.

Figure 11. Real test-bed enhancing pair of PEP

36

Table 1. Sample TCP throughput

Configuration TCP throughput

(Mbps)

E2E (one session) 0.858

PEP enabled (one session) 3.48

E2E (four sessions) 0.387

PEP enabled (four sessions) 1.2295

In this thesis, we implement our test-bed environment to quantify

the performance of the proposed scheme in emulated satellite link. In

the following sections, we will describe our test-bed architecture, PEP

Linux software, satellite link emulator (Dummynet) [32], performance

measuring software (iperf) [33] and Linux versions installed on the end

user nodes.

4.3.1 Test-bed Architecture

The test-bed architecture which is implemented for our

experiment is shown in Figure 12. It contains five boxes. The two end

boxes are server and client and act as end terminals. The overall TCP

throughput is measured on these terminals. The second box from the

left and from the right represent the satellite gateway and satellite

terminal respectively. They apply the TCP splitting scheme to divide

37

E2E TCP connections into three segments. The middle box (third from

left) emulates the wireless satellite link using Dummynet.

The proposed TCP Linux kernel is installed on the second box

from the left (gateway sometimes called ground station). A TCP flow

is generally terminated at the gateway to the satellite link, and the

proposed TCP session is enabled as customized TCP on the other side

of the satellite link to complete the connection. The ACK is generated

by the gateway instead of waiting for the end-user. Terrestrial segments

(server to gateway or vice versa and client to satellite terminal or vice

versa) employ a standard TCP whereas the satellite segment

implements customized protocol which is the proposed TCP with

tuned CWND. Similarly the satellite terminal (box 4 from the left)

generates TCP splitting to isolate the satellite segment from the

terrestrial networks. With this settings, we can have the benefits of

TCP/splitting in both directions, from the server to the receiver

(forward) and from the client to the server (reverse). In this case, the

gateway as well as satellite terminal performs as a proxy.

38

Figure 12. Experimental setup architecture

4.3.2 PEP Software

PEPsal [31] as TCP-splitting based PEP solution which is

installed on both the end legs of the satellite segment. It is open source

software for Linux OS. Its aim is to split the E2E connection into

segments. It isolates the satellite portion from the terrestrial networks

and enables to confine the satellite link impairments on the satellite

segment. PEPsal uses also Netfilter [34] to intercept incoming

segments and copies them into a queue and the queuer annotates the

information (IP addresses and TCP ports) on the two end users. These

segments may be modified in the user area before re-injected back into

the kernel. For each supported protocol, the kernel module has a queue

handler can be registered with the netfilter to perform dynamics to

forward packets from user space. PEPsal gives opportunity to choose

39

which hosts or networks can benefit of performance enhancements and

needs to set the iptable rules for the netfilter to connect the test

application with it.

iptables setup:

① sudo iptables -A PREROUTING -t mangle -p tcp -s

172.18.0.0/16 --tcp-flags SYN SYN -j QUEUE

② sudo iptables -t nat -A PREROUTING -p tcp -s

172.18.0.0/16 -j REDIRECT --to-port 5000

The queue target in the PREROUTING chain of the mangle table

is imposed to SYN packets for TCP connections we want to split and

enhance, while a REDIRECT target (to the port 5000 of the PEPsal

box) in the same chain of the nat table is imposed to all packets

containing a TCP segment Packets can redirect.

In addition, PEPsal has transparency properties; the end users do

not notice the connection splits. After compiling and installing the

PEPsal, we can enable it on the Linux terminal using default

configuration: sudo ./pepsal –v.

4.3.3 Dummynet

The satellite segment is emulated using a network emulating

40

tool, Dummynet [32] that was developed to test network protocols. It

enforces queue and bandwidth limitations, delays, packet losses and

multipath effects. It also implements various scheduling algorithms.

Dummynet can be used on the machine running the user's application,

or on external boxes acting as routers or bridges. It can run in different

operating systems, but in our case it runs on FreeBSD OS.

To measure network performance in our test-bed, we install iperf

[33] in both the client and the server. It is a modern alternative tool

written in C for network performance measurement. It measures the

throughput of a network that is carrying them.

Iperf server side:

$iperf3 –s –p 5202

Iperf client side:

$iperf3 –c 182.18.2.2 –p 1 –i 1 –p 5202 –f m –t 60

where 182.18.2.2 : server IP number, -p : parallel stream, -i: report

interval in seconds, -p: running port number, -f: format in M or K bits

and –t: transmit time. In general, experimental environments that are

used to verify TCP performance are listed and described in Table 2.

41

Table 2. Test-bed environment

Network Components Detailed Description

Client 1 x Wired Giga LAN interface

Iperf (Version 3.0.6)

Linux kernel Version: 3.17.4

TCP: CUBIC

PEPsal #1 OS: Linux (Kernel 3.17.4)

Customized TCP

2 Giga LAN interface cable

PEPsal (Version 2.0.1)

Satellite emulator OS: FreeBSD


DummyNet

PEPsal #2 OS: Linux (Kernel 3.17.4)


PEPsal (Version 2.0.1)

Server OS: Linux (Kernel 3.17.4)

1 x Wired Giga LAN interface

Iperf (Version 3.0.6)

42

Chapter 5. Performance Evaluation

This chapter presents the results obtained from the conducted

experiment in different test scenario. We compare the performance of

TCP variants (TCP Reno, CUBIC, Hybla), TCP-splitting based PEP

connection and the proposed scheme in terms of the CWND and TCP

throughput. The TCP variants are configured on server and client for

E2E TCP performance evaluation. Moreover, we evaluate TCP

performance in presence of multiple connections.

As TCP splitting (PEPsal) is transparent to the end users, we use

TCP Reno on these nodes (client and server). In TCP-split scheme, we

use TCP Hybla as customized TCP between the two PEPs i.e. between

gateway and satellite terminal. To apply the proposed scheme, we

install the proposed TCP on satellite segment (at the gateway) to use

as customized TCP on the satellite link (replacing TCP Hybla). With

this settings, we can have the benefits of TCP/splitting by using the

tuned CWND TCP on the radio link and improves the performance.

On the test-bed channel, the satellite band is configured to band

limited with 8Mbps and the maximum number of segments

accommodated in this capacity is calculated. The setup parameters

considered in this experiment are as shown in Table 3. As the table

43

shows the number of calculated segments and assigned to the

congestion window parameter in TCP Linux kernel is 326. The other

remaining parameters are configured on the Dummynet.

Table 3. Setup configuration parameters

Parameter Value

Bandwidth 8 Mbps

RTT 500 ms

Maximum number of segments 326

Queue size 500 bytes

5.1 Single Session Performance

Before we apply the proposed protocol on the satellite link, we

examine first the basic performance and validation of TCP at wired

link (total RTT = 0.57ms i.e. no satellite segment) and error-free

channel with Ethernet link (1Gbps). Throughput of each TCP variant,

TCP-split (PEPsal) and the customized TCP is depicted in Table 4. All

the TCP variants and PEPsal (TCP-split) including the proposed one

achieves almost the same throughput. This indicates that the proposed

protocol works properly.

44

Table 4. TCP throughput (RTT = 0ms, PER = 0, 1Gbps)

TCP version TCP throughput

(Mbps)

TCP Reno (Linux) 94.1

TCP CUBIC (Linux) 94.2

Hybla(Linux) 94.2

TCP-split 94.2

Proposed (Linux) 94.2

5.1.1 CWND Performance

We evaluate the performance of the CWND of the proposed

protocol to compare with congestion window of TCP variants and split

connection for an elapsed time of 30 seconds over qusi error-free

channel condition ( 1010BER ) claimed in [1]. This is shown in

Figure 13. The figure shows that TCP Reno, CUBIC, TCP Hybla and

TCP-split have slow convergence to the available CWND due to

probing phases such as SS and CA. In particular, these probing phases

in satellite networks can have negative influence on the performance

of the short-lived TCP sessions. For some instant of times, CUBIC and

TCP Hybla increases the transmission rate very high but they cannot

45

attain stable transmission rate, it decreases their congestion window

rapidly. The congestion window property of TCP-split shows almost

the same to the CWND in Hybla. However, the proposed protocol uses

the available CWND without probing phase because in CWND tuning,

it directly uses information on the link layer. Actually, some initial

delay occurs in the proposed protocol because the PEP needs for

buffering TCP segments received from the source node via wired link.

However, it is insignificant because RTT in wired link is very short as

compared with RTT in satellite link.

The transmission rate of the TCP variants as well as the split

connection is reduced as the radio link error increases. Figure 14 shows

the comparison of CWND of proposed scheme, TCP-split and E2E

TCP protocols according to the elapsed simulation time at channel

error of BER=10 . As the figure reveals, especially, CWND of the

TCP Reno and CUBIC is very sensitive to the bit error. However, the

CWND of the proposed protocol remains constant until new resource

allocation is requested or a real congestion is occurred.

5.1.2 Throughput Performance

The performance comparison of the proposed TCP, connection

46

splitting based PEP solution and three TCP variants in terms of

throughput will be discussed in this topic. In this experiment, we

conduct performance evaluation at quasi-error-free condition channel

and at 610BER . We compare also the throughput as function of the

BER in satellite link with RTT of 500ms.

Figure 15 shows the average throughput of the proposed protocol

comparing with TCP-split and TCP variants in error-free channel. As

the figure shows, the customized TCP achieves stable throughput. It

fully explores the available resource in TCP although it is slightly less

than the 8Mbps due to overheads of the protocol headers. We examine

also the variation of throughput with loss rate for the three TCP

variants compared with proposed protocol. Figure 16 displays the

average throughput of the E2E TCP protocols, connection splitting and

the proposed protocol at 610BER . As the result shows the proposed

protocol outperforms the TCP variants and has a large throughput gain.

In this BER, throughput of TCP protocols degrades dramatically,

averagely less than 3Mbps.

For the dynamic channel, we evaluate the proposed protocol in

terms of TCP throughput as function of the link error rate. As Figure

17 shows the proposed protocol outperforms the TCP variants and

TCP-split PEP. On the satellite segment, most of the packet loss is due

47

to the radio link error. Standard TCP protocols have no mechanism to

identify the cause of packet loss. Their congestion control mechanism

is affected by radio link errors. By contrast, the use of PEP provides a

benefit to adopt the customized TCP on the satellite portion which

improves the performance shown in the figure (TCP-split). In the

proposed scheme, the customized TCP is replaced with the proposed

protocol which is properly tuned CWND using information rate, AR .

As the link error worsen, the throughput performance of proposed

protocol is more impressive.


0 5 10 15 20 25 300

200

400

600

800

1000

1200

1400

Elapsed time (sec)

cwnd

(K

Byt

es)

Proposed

TCP-split

CUBIC

Hybla

Reno

48

Figure 14. CWND in satellite networks at


0 5 10 15 20 25 300

100

200

300

400

500

600

700

800

Elapsed time (sec)

cwnd

(K

Byt

es)

Proposed

TCP-split

CUBIC

Hybla

Reno

0 5 10 15 20 25 300

2

4

6

8

10

12

14

16

18

20

Elapsed time (sec)

Thr

ough

put

(Mbp

s)

Proposed

TCP-split

CUBIC

Hybla

Reno

49


Figure 17. Average TCP throughput Vs. BER in satellite links

0 5 10 15 20 25 300

2

4

6

8

10

12

Elapsed time (sec)

Thr

ough

put

(Mbp

s)

ProposedTCP-splitCUBICHyblaReno

10-10

10-9

10-8

10-7

10-6

10-5

10-4

0

1

2

3

4

5

6

7

8

BER

Thr

ough

put

(Mbp

s)

Proposed

TCP-split

CUBIC

Hybla

Reno

50

5.2 Multi-Session Performance

In this section, we compare the performance of the proposed

scheme, connection splitting solution and TCP variants in multi-

session with same experiment scenario in single session above.

5.2.1 CWND Performance

We evaluate the performance of the CWND in multiple sessions.

Figure 18 and 19 illustrates the performance of CWND in error-free

and erratic channel. They compare with congestion window of TCP

variants, TCP-split connection and the proposed protocol. As the

results show that the available CWND can be used without probing

phase in the proposed protocol. The congestion window of the TCP

variants and PEP severely reduced to adjust the transmission rate in the

presence of link error. This is wrong interpretation of packet loss due

to channel error.

5.2.2 Throughput Performance

The performance of TCP in multiple sessions(2, 3, 5, 7 and 10

connections) at error-free channel is depicted in Figure 20. As the

51

figure shows the proposed scheme achieves higher throughput

compared to the other TCP variants in each group of the simultaneous

sessions. Simlarly, we conduct an experiment with same configuration

and number TCP sessions except channel error is set to 10 .

As the Figure 21 illustrates, the customized TCP tolerates the link error

even in multiple connections. TCP Reno and CUBIC are severely

affected by link error in all groups of the TCP sessions.

In five simultaneous TCP connections, we evaluate the

performance of the proposed TCP over dynamic channel. Figure 22

illustrates the throughput as the function of BER on satellite link. As

the result shows the proposed protocol achieves higher average

throughput than that of the TCP variants and PEPsal.

52

Figure 18. CWND in satellite networks at error-free channel with five

simultaneous TCP sessions

Figure 19. CWND in satellite networks at with five simultaneous

TCP sessions

0 5 10 15 20 25 300

100

200

300

400

500

600

700

800

900

Elapsed time (sec)

cwnd

(K

Byt

es)

Proposed

TCP-split

CUBIC

Hybla

Reno

0 5 10 15 20 25 300

100

200

300

400

500

600

700

800

Elapsed time (sec)

cwnd

(K

Byt

es)


53

Figure 20. Average TCP throughput of multi-sessions in satellite networks (at

BER = 0)

Figure 21. Average TCP throughput of multi-sessions in satellite networks

(at )

2 3 5 7 100

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

Number of TCP sessions

Thr

ough

put

(Mbp

s)


2 3 5 7 100

0.5

1

1.5

2

2.5

3

3.5

4

Number of TCP sessions

Thr

ough

put

(Mbp

s)


54

Figure 22. Average TCP throughput Vs. BER in presence of five connections

10-10

10-9

10-8

10-7

10-6

10-5

10-4

0

0.5

1

1.5

2

2.5

3

3.5

BER

Thr

ough

put

(Mbp

s)

Proposed

TCP-split

CUBIC

Hybla

Reno

55

Chapter 6. Conclusion

The purpose of this thesis is to improve the performance of TCP

in DVB-RCS networks. As it discussed in this paper, the main reasons

for the poor response of the TCP throughput over satellite links are

long RTT and packet loss on the radio link. Long propagation delay

directly affects E2E performance because of TCP’s ACK algorithm.

Link failure due to errors causes to decrease the transmission rate.

Many solutions have been proposed to alleviate TCP problems in

satellite communication. However, these solutions cannot mitigate all

the reasons for poor TCP performance in satellite networks.

In this thesis, we proposed the TCP splitting based on cross-layer

design to exchange information between non-adjacent layers of the

protocol stack, i.e. between TCP and link layer. TCP tunes the CWND

accurately using tuning algorithm on satellite segment based on the

information of resource allocation on layer 2. To evaluate the

performance of the proposed approach, the tuned CWND implemented

on TCP Linux kernel. We conducted an experiment on our test-bed to

compare the performance of the proposed TCP, TCP-split connection

and an E2E TCP variants. As the results indicate that the proposed

scheme maintains unreduced CWND in high BER over the satellite

56

link. Similarly, it has higher throughput comparing with TCP variants

and connection splitting based PEP solution in both single and multiple

TCP sessions in high link errors. This scheme tries to explore the

available resource in TCP and the cross layering between TCP and the

link layer is contributing to utilize the available resource even in high

PER.

The end user’s terminals are not required to modify or deploy new

TCP protocols due to the enhancing of pair TCP splitting based PEP

solution architectures at the end of satellite legs (gateway and satellite

terminal). However, PEP has some issues and disadvantages that can

reduce the quality of performance. When using the TCP splitting

connection, keeping the security mechanism is not possible to achieve

because it violates the E2E semantics. IPsec prevents the use of the

PEP and thus, it is necessary to introduce new security requirements

for the proxy.

57

Reference

[1] ETSI, “Digital Video Broadcasting (DVB): Interaction Channel for

Satellite Distribution Systems,” ETSI EN 301 790 v. 1.5.1, May.

2009.

[2] ETSI, “Digital Video Broadcasting (DVB): Second generation

framing structure, channel coding and modulation systems for

broadcasting, interactive services”, EN 302 307 v1.1.2, 2006.

[3] S Rappaport, Demand assigned multiple access systems using

collision type request channels: traffic capacity comparisons. IEEE

Trans. Commun. 27(9), 1325–1331 (1979).

[4] A. Pirovano and F. Garcia, “A New survey on improving TCP

performances over Geostationary Satellite Link,” Network and

Communication Technologies, vol. 2, no. 1, Jan. 2013.

[5] M. Allman, Enhancing TCP Over Satellite Channels using

Standard Mechanisms, RFC 2488, Jan. 1999.

[6] C. Caini and R. Firrincieli, “TCP Hybla: A TCP Enhancement for

Heterogeneous Networks,” International Journal of Satellite

Communications and Networking, vol. 22, no. 5, 2004.

[7] S. Ha, I. Rhee, and L. Xu, “CUBIC: a new TCP-friendly high-speed

TCP variant,” SIGOPS Oper. Syst. Rev., vol. 42, pp. 64–74, July

2008.

58

[8] R.H. Wang, S. Horan, "Performance evaluation of TCP and its

extensions over lossy links in a small satellite environment," ICC,

2005 IEEE International Conference on , vol.3, no., pp.1478,1482

Vol. 3, 16-20 May 2005

[9] J.V. Maisuria, R.M. Patel "Overview of Techniques for Improving

QoS of TCP over Wireless Links," Communication Systems and

Network Technologies (CSNT), 2012 International Conference on ,

vol., no., pp.366,370, 11-13 May 2012.

[10] S. Trivedi, S. Jaiswal, R. Kumar, S. Rao, "Comparative

performance evaluation of TCP Hybla and TCP Cubic for satellite

communication under low error conditions," Internet Multimedia

Services Architecture and Application (IMSAA), 2010 IEEE 4th

International Conference on, vol., no., pp.1,5, 15-17 Dec. 2010.

[11] M. Muhammad, F. Kasmis, and T. de Cola, “Advanced Transport

Satellite Protocol,” in Global Communications Conference

(GLOBECOM), 2012 IEEE, Anaheim, CA, USA, 2012.

[12] J. Border, Performance Enhancing Proxies Intended to Mitigate

Link-Related Degradations, RFC 3135, June 2001.

[13] P. Fei, A.S. Cardona, K. Shafiee, V.C.M Leung, "TCP

Performance Evaluation over GEO and LEO Satellite Links

between Performance Enhancement Proxies," Vehicular

59

Technology Conference (VTC Fall), 2012 IEEE , vol., no., pp.1,5,

3-6 Sept. 2012.

[14] C. Caini, R. Firrincieli, and D. Lacamera, “PEPsal: A

Performance Enhancing Proxy for TCP Satellite Connections,”

IEEE Aerospace and Electronic Systems Magazine, vol. 22, no. 8,

pp. B–9–B–16, 2007.

[15] P. Davern, N. Nashid, C. J. Sreenan, and A. Zahran, “HTTPEP: a

HTTP Performance Enhancing Proxy for Satellite Systems,”

International Journal of Next Generation Computing (IJNGC),

vol. 2, 2011.

[16] M. Luglio, C. Roseti, and F. Zampognaro, “Performance

Evaluation of TCP-based Applications over DVB-RCS DAMA

Schemes,” international Journal of Satellite Communications and

Networking, vol. 27, no. 3, pp. 163–191, 2009.

[17] G. W. Nathnael, K. H. Lee, Y. J Choi, and J. H. Kim, "Testbed

and Discussion for PEP in Satellite Communications," in Proc.

ICEIC 2015, Singapore, 28-31. Jan. 2015.

[18] C. Casetti, M. Gerla, S. Mascolo, M. Y. Sanadidi, and R. Wang,

“TCP Westwood: E2E congestion control for wired/wireless

networks”, Wireless Networks, Kluwer Academic Publisher, 8,

467-479, 2002.

[19] Network Socket, available at:

60

http://en.wikipedia.org/wiki/Network_socket

[20] T. R. Henderson and Y. H. Katz, “Satellite Transport Protocol

(STP): An SSCOP-based Transport Protocol for Datagram

Satellite Networks,” in proc. of 2nd Workshop on Satellite-Based

Information Systems, Budapest, Hungary, Oct. 1997.

[21] K. Selén, “Evaluation of Performance Enhancing Proxies in a

Global Network”, Master’s Thesis, Helsinki University of

Technology, Faculty of Information and Natural Sciences,

Department of Computer Science and Engineering, (2008) March

9th.

[22] Performance Enhancing Proxy, available at:

http://en.wikipedia.org/wiki/Performance_Enhancing_Proxy.

[23] S. Poojary, and V. Sharma, “Theoretical analysis of high-speed

multiple TCP connections through multiple routers,” in Proc. IEEE

ICC, 2013

[24] G. Giambene, S. Kota “Cross-layer protocol optimization for

satellite communications networks: A survey” Int. J. Satell.

Commun. Network. 2006.

[25] E. Rendon-Morales, J. Mata-Diaz, J. Alins, J. L. Munoz, and O.

Esparza, “Cross-layer Packet Scheduler for QoS Support over

Digital Video Broadcasting-Second Generation Broadband

61

Satellite Systems,”International Journal of Communication

Systems, pp. 1–20, 2012.

[26] F. Peng, L. Wu, and V. C. M. Leung, “Cross-layer Enhancement

of TCP Split-connections over Satellites Links,” International

Journal of Satellite Communications and Networking, vol. 24, no.

5, pp. 405–418,2006.

[27] M. Luglio, F. Zampognaro, T. Morell, and F. Vieira, “Joint

DAMA TCP Protocol Optimization through Multiple Cross Layer

Interactions in DVB RCS Scenario,” in Proc. IEEE IWSSC 2007,

Sep. 2007.

[28] XPLIT: A Cross-layer Architecture for TCP Services over

DVBS2/ETSI QoS BSM,” Computer Networks, vol. 56, no. 1, pp.

412–434,2012.

[29] M. Rio, M. Goutelle, T. Kelly, H. J. Richard, Jean, T. L. Yee “A

Map of the Networking Code in Linux Kernel 2.4.20” Technical

Report DataTAG-2004-1, 31 March 2004

[30] K. Tan, J. Song, Q. Zhang, and M. Sridharan, “A Compound TCP

Approach for High-Speed and Long Distance Networks,” in Proc.

IEEE INFOCOM, 2006.

[31] PEPsal Source Code, available at:

http://www.sourceforge.net/projects/pepsal/

62

[32] DummyNet, available at: http://info.iet.unipi.it/~luigi/dummynet/

[33] Iperf source software, available at: http://software.es.net/iperf/

[34] The Netfilter/iptables project, firewalling, NAT and packet

mangling for Linux, available at: http://www.netfilter.org.

masters dissertation tcp performance enhancing proxy based...

Documents