Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
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
Figure 16. Average TCP throughput in satellite networks at
610BER .................................................................. 49
viii
Figure 17. Average TCP throughput Vs. BER in satellite links
..................................................................................... 49
Figure 18. CWND in satellite networks at error-free channel
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
2 Giga LAN interface cable
DummyNet
PEPsal #2 OS: Linux (Kernel 3.17.4)
2 Giga LAN interface cable
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.
Figure 13. CWND in satellite networks at error-free channel
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
Figure 15. Average TCP throughput 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 16. Average TCP throughput in satellite networks at
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)
ProposedTCP-splitCUBICHyblaReno
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)
ProposedTCP-splitCUBICHyblaReno
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)
ProposedTCP-splitCUBICHyblaReno
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.