Multipath TCP over Satellite Mesh Network
Yijia Liu, Yanbin Ren, Qing Xie, Pengyuan Du
Henry Samueli School of Engineering and Applied Science
Department of Computer Science
University of California, Los Angeles
[email protected], [email protected], [email protected], [email protected]
Abstract—Low earth orbit (LEO) satellite networks like
Iridium have played a pivotal role in providing ubiquitous
network access services to areas without terrestrial infrastructure because of their potential for global coverage and
high bandwidth availability. Compared to geostationary
satellites, LEO satellites have lower orbit and short ranges.
Also, LEO satellites are accessible by mobile devices with
confined transmission power and small gain antennas. But
the downside is that this kind of satellites move so fast that
it requires frequent handover from one single satellite to
the next, thus resulting in a challenge in routing over the
constellation. In order to exploit the utility of constellation
capacity efficiently, it is important to maintain parallel,
simultaneous connections between terrestrial hand points
via multiple satellites by emergency of mobile devices that
possess multiple wireless interfaces. Based on previous
researches, TCP is widely used in end-to-end applications.
In this case, Multiple Path TCP (MPTCP) is a promising
alternative.
This report mainly introduces the experiment and algorithm design related to using MPTCP in LEO systems
in this quarter. First, we design an On-demand Multipath Source Routing (OMSR) scheme to support MPTCP.
Traffic is split on different MPTCP sub-flows and allocated
to disjoint paths by OMSP. Then, we introduce a new
algorithm - LRX Algorithm for OMSR and implement the
code in NS-2 with simulation. Besides, the performance of
the proposed MPTCP-OMSR strategy is evaluated through
simulation. In the simulation, we compare the performance
between traditional single-path TCP and MPTCP and the
result show that MPTCP significantly improves throughput
and prevents the interruption of transmission during
handover. Moreover, the MPTCP-OMSR interaction is
essential for the end-to-end session to quickly recover from
handover.
Keywords: MPTCP, Satellite Network, OMSR,
LRX Algorithm
I. I NTRODUCTION
Satellite systems have been a prevailing candidate for
ubiquitous communication because of its capability of
providing global coverage and consistency of services.
In recent years, the telecommunication community has
drawn attention to satellite systems deployed at low earth
orbit (LEO) satellite systems [1]. Another advantage
of LEO satellites is that it requires lower transmission
power. Due to constant rotation of the LEO satellites, the
topology of LEO satellite networks, however, changes
from time to time, which results in frequent satellite handover if the current serving satellite fades out or blocked
and the on-going connection has to be transferred to the
next satellite visible to the ground terminal [2]. Despite
of handover problem, it is widely known that the performance of TCP is seriously descended in the mentioned
LEO satellite systems, mainly caused by long Round
Trip Times (RTTs) and possible presence of channel
error based packet losses [3], [4]. What’s worse, in LEO
networks, RTT problem could be worsened because of
the fact that end-to-end delay varies as satellites move
along orbits. Besides, sometimes if our wish is to speed
up the transmission, the bandwidth of the path becomes
the bottleneck.
Therefore, we attempt to adopt Multi-path TCP
(MPTCP) over LEO satellite system as a potential solution to the practical issues mentioned above or diminish
the negative effect on the LEO system networks. MPTCP
becomes a promising protocol to match the needs of
today’s multi-path networks due to the increase of highly
connected mobile devices with multiple wireless interfaces, compared to traditional TCP protocol. Not only
does it increase the potential transmission bandwidth,
but also helps with load balancing by using a coupled
congestion control algorithm [5]. Additionally, various
experiments have been conducted to verify that MPTCP
smoothly transfers traffic on a breaking sub-flow to other
flows during vertical handovers [6]. All these beneficial
characteristics of MPTCP motivate us to apply it as
part of project experiment. Besides, we also exploit the
on-demand multi-path source routing (OMSR) scheme.
After MPTCP sub-flows are initiated, they branch out
from the gateway satellite into multiple disjoint paths
OMSR discovered. We define the necessary interactions between transport and routing layers to ensure
that MPTCP sub-flows are split into different paths.
Specifically, our project is to find a way to create
the multi-path TCP connection. We first develop our
algorithms to create two disjoint paths. And then we
implement the algorithm in the simulation tool. Then
we design simulation to verify the correctness of our
algorithms and see the performance of our connection
in terms of throughput. Simulation results shows that the
MPTCP-OMSR protocol improves throughput and delay
performance and handles handover gracefully.
The paper is presented as following: the general parts
of LEO Satellite System and Multipath TCP are listed
in Section II. The authors also include problem analysis
in this section. The problem solution design with OMSR
and algorithm design is provided in Section III. Section
IV provides the simulation result and analysis of Multipath TCP over LEO satellite system. Section V gives a
conclusion of the paper.
II. M OTIVATION & P ROBLEMS A NALYSIS
In this part, we briefly introduce some background
knowledge and motivation of our project. Satellite system is increasingly important to both today’s telecommunication networks and next generation Internet. LEO
satellite network is chosen in our project mainly because
of less propagation delay and packet loss as compared
to other choices of satellite systems. Its involvement in
Internet protocol networks will be a new trend in global
Internet communications.
But the challenge of TCP over LEO satellite is long
propagation delay, high packet loss rate and frequent
satellite handovers. For example, the long propagation
delay will defer the increment of congestion window
and packet loss will cause a series of unnecessary
retransmission. Therefore, all these bad performance will
result in low throughput and high latency. To solve these
problems, a great many improved versions of TCP are
studied and proposed by researchers from all over the
world. However, it’s still questionable to apply these
enhanced version of TCP to satellite networks [7]–
[10]. We are still not sure how much benefit we can
gain from them. Besides, all these TCP overlook the
impact of satellite handover, which happens to be a key
characteristic that distinguishes LEO satellite networks
from other satellite systems thus resulting in the superiority of LEO satellite networks being impaired. Satellite
handover causes path change from end to end, associated with packet reordering, dropping and retransmission
[11]. Consequently, TCP performance will suffer and fail
to maintain connection without gap, which is the main
problem we expect to solve. So we introduce and adopt
the Multi-path TCP protocol to tackle the difficulties
mentioned above.
MPTCP, the protocol we use in our project, is a new
transport layer protocol, which allows exploiting several
efficient Internet paths between a pair of hosts, while
presenting a single TCP connection to the upper layer.
With multiple network interfaces, MPTCP can establish multiple sub-connections and in creed redundancy
and performance. Intuitively MPTCP in LEO satellite
networks would increase bandwidth and compensate
the impacts of long RTT. Meanwhile during handover,
MPTCP would be able to gracefully transfer traffic from
a breaking link to other available links.
Another important thing is that LEO satellite networks
actually can reasonably and nicely support MPTCP.
First of all, LEO satellite constellation is basically a
mesh network, meaning that these exists multiple disjoint
paths among the satellites in such a network. On the
other hand, when going through handover, it possesses
multiple GSL interfaces to build up connections with
distinguished gateway satellites because the ground terminal covers multiple satellites.
III. P ROBLEM S OLUTION D ESIGN
A. On-demand Multi-path Source Routing
To support MPTCP in LEO satellite network, the underlying routing mechanism has to be modified. That is
why we refer to On-demand Multi-path Source Routing
(OMSR) scheme, an on-demand routing algorithm that
builds multiple disjoint paths between satellite pairs. By
selecting multiple routes, we can prevent congestion on
a certain link or node and exploit network bandwidth
more effectively and efficiently. Typically, a simple linkdisjoint multi-path routing design would significantly
relieve the traffic congestion in network, because the
throughput and computing capacity of the satellite node
are high enough to deal with data packets forwarding in
Satellite Network. Simultaneously, MPTCP can allocate
traffic on different sub-flows to these routes.
The design of On-demand Multi-path Source Routing
can be divided into three parts: First, it should be able to
find out at least two link-disjoint paths between source
node and destination. Secondly, it should be able to
select two link-disjoint paths with maximum throughput
or minimum transmission latency. Finally, the source
end should allocate packets to both of these routes with
certain quota based on the throughput or latency of each
route.
B. Disjoint Routing
1) Disjoint Routing Classification:
According to Meghanathan’s paper [12], multiple disjoint routes can be classified into three types: linkdisjoint, node-disjoint and zone disjoint. Link-disjoint
routes may share a common node in the routes, but
they cannot share any part of the routes. Node-disjoint
routes have higher level of independence since any two
paths cannot share any intermediate node in the routes.
According to this definition, we can infer that nodedisjoint domain is included in link-disjoint domain. In
another word, if two routes are node-disjoint, they must
be definitely link-disjoint. Zone-disjoint routes have the
highest ranking of independence since the routes are
decoupled with each other. In this paper, the authors
didn’t include zone-disjoint schema into discussion because this schema is kind of complicated and hard to
implement, which needs additional device to support its
functionality.
2) Current link-disjoint multipath routing algorithms:
There are several current-existed link-disjoint multipath routing algorithms in literature. Mahesh K. Marina
and Samir R. Das had proposed an on-demand multipath
distance vector protocol for mobile ad hoc networks
AOMDV (Ad hoc On-demand Multipath Distance Vector
routing) [13], which extends a prominent on-demand
single path protocol called AODV (Ad hoc On-demand
Distance Vector routing). They simulated two routing
schema in NS-2 and compared their performance in
throughput and latency. Results showed that AOMDV
improves the latency by a factor of two and reduces
overhead in routing by around 20%.
Another multi-path routing protocol, presented by
Luciano Bononi and Marco Di Felice in University of
Bologna, is CS-AOMDV (Concurrent Separated pathsAd hoc On-demand Multipath Distance Vector routing)
[14], which is based on AOMDV. They also exploited
a Cross-Layered Multipath Routing schema with the
composition effect of a MAC forwarding mechanism
called Fast Forward (FF), which helps to reduce effects of self-contention in MAC frames. They simulated
and compared the performance of CS-AOMDV routing
schema with combination solution FF-CS-AOMDV and
AOMDV routing. Results show that a concurrent multipath routing scheme (CS-AOMDV) with a fast forward
MAC scheme greatly reduce the end-to-end latency by
increasing the spatial reuse of channel resources and
communication performances.
Sung-Ju Lee in Hewlett-Packard Laboratories and
Mario Gerla in UCLA authored a paper ”Split Multipath Routing with Maximally Disjoint Paths in Ad hoc
Networks” and proposed an on-demand routing scheme
called Split Multipath Routing (SMR) [15] for ad hoc
networks that establishes and utilizes multiple routes of
maximally disjoint paths. This scheme utilized flooding
requests for route discovery and they implemented the
algorithm with two routes for each session. One route
is the shortest path and the other is maximally disjoint
with the shortest delay route. Simulation results turned
out that this scheme helps minimizing route recovery
process and control message overhead.
C. LRX Algorithm
In this paper, the authors propose an On-demand
Multipath Source Routing Algorithm in LEO Satellite
System. We named it LRX Algorithm, typically after
the initials of the last names of the three authors. This
algorithm is based on Dijkstra’s Algorithm, which solves
the single-source shortest path problem for a graph
with non-negative edge path costs. We extend Dijkstra’s
Algorithm to a multi-path routing scheme, which could
discover a shortest path and a second shortest path
from source to destination. The running time of LRX
Algorithm is O(n2 ). The algorithm is implemented in
NS-2 source codes, which can totally replace the original
routing algorithm. The pseudo code of LRX OMSR
algorithm is presented in Algorithm 1.
1) Neighbor Discovery:
LEO Satellite Systems are stable, relatively static
mesh networks. All 66 satellites rotate constantly in
lower orbits and each satellite keep connection with
several neighbors around it. In NS-2 simulator, the orbits
and movements of all satellites are predictable. Thus, it
is not difficult for the system to figure out the connection
status and distance between each of two satellites in the
system.
Each time when the function (with LRX algorithm)
is called, it consults the system for initial link states
Algorithm 1: LRX Algorithm for On-Demand
Multi-path Source Routing
input : src, dst
output: ROUTE(src,dst)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
N ← number of nodes in network;
for i = 0 to N do
Pick up a nearest unvisited neighbor w of source
node;
visited[w] = true; //mark as visited
for j = 0 to N do
if hop count[src][w] + hop count[w][j] <
hop count[src][j] then
if route 1 then
if ROUTE(src,w) not in route 2 then
ROUTE(src,j) = ROUTE(src,w);
hop count[src][j] =
hop count[src][w] +
hop count[w][j];
else if route 2 then
if ROUTE(src,w) not in route 1 then
ROUTE(src,j) = ROUTE(src,w);
hop count[src][j] =
hop count[src][w] +
hop count[w][j];
else
ROUTE(src,j) = ROUTE(src,w);
hop count[src][j] = hop count[src][w]
+ hop count[w][j];
if ROUTE(src,dst)==null then
//Dijkstra0 s Algorithm;
recompute ROUTE(i,j) without condition
check;
Return ROUTE(src,dst);
of the source satellite with its neighbors. We use this
information to initialize the initial routing states for the
algorithm.
2) Route Discovery and Selection:
In our algorithm, the source selects two routes that
are node-disjoint or link-disjoint. This algorithm is a
kind of source-driven multi-path routing schemes, which
discovers and selects route (next hop) dynamically.
First, we initialize the original routing table with the
distance of each satellite nodes. Secondly, pick up a nearest unvisited neighbor from the source node and mark
it as visited. Then, starting from current node, consider
all of its unvisited neighbors and calculate their tentative
distances from source to this node. Compare this newly
calculated distance with current distance in routing table.
If this newly calculated distance is shorter than current
distance in routing table, we do the conditions check
here:
1. If this node has already been taken as part of the
path for the other route, (in order to get a node-disjoint
path), we skip this node and continue.
2. Otherwise, we update the routing table with the
shorter distance and set next hop to current node. Then,
continue these calculation and comparison steps back
and forth until all the nodes in the graph are visited. After
this, we have updated the routing table with shortest path
from source to every reachable node in the graph with a
node-disjoint path.
At last, we should check if we get a node-disjoint
path from source to destination. If not, we use Dijkstra’s
Algorithm to compute the route again without condition
check.
In most of the cases, our algorithm can figure out two
node-disjoint paths from source to destination. Sometimes, in a worse case, two disjoint paths have to share
some common node in their routes (The illustration in
the following part shows this scenario). In the worst
case, two paths are totally overlapped. Say there exists
only one route between source and destination, then our
algorithm will figure out this only-existed route for both
TCP sub-flows. But this kind of scenarios is really rare
in Satellite Mesh Networks.
3) Allocation Granularity:
In this paper, we didn’t implement allocation granularity pattern due to the lack of time. We just simply
allocate packets evenly to the two disjoint paths. But here
we have conceived an allocation pattern for TCP subflows. Similarly to TCP congestion window, we maintain
a buffer window for each TCP sub-flow and adjust the
window size according to transmission rate and packets
loss rate. The design of this part may be finished and
added to the algorithm in future work.
4) Algorithm Illustration:
Figure 1 is an illustration for LRX OMSR algorithm,
and it shows how to find out two disjoint paths from
source to destination simultaneously.
In the graph, grey nodes represent satellites, which
are currently out of service. The nodes in green color
represent vacant satellites. There are also two paths from
source to destination; one path follows the red nodes and
the other follows the yellow ones. We don’t guarantee the
serialization of the two disjoint paths. In another word,
we may assume that two paths interleave with each other
and figure out which is the next node to forward packets
to.
First step, we assume S1 starts routing at first. S1
computes the route with LRX algorithm and finds out
the next hop to forward its packet is satellite node 1,
and we mark node 1 as red. Next, node 1 applies with
LRX algorithm and it figures out there are three nodes
available to forward its packets: node 0, node 4 and node
5. According to the shortest path first, it picks up node 4
for next hop. Then, at this point, node S2 starts routing
and there are two choices to forward packets: node 1
with a weight of 2 and node 2 with a weight of 4.
Since node 1 has been adopted in route 1, S2 has to take
an alternative node, node 2 with a higher weight. After
several steps, we assume route 2 takes node 8 as part
of the route. Then route 1 reaches node 4. At this time,
route 1 does not have an alternative choice; it has to share
node 8 with route 2. In this case, node-disjoint pattern
is damaged, but the two routes still remain link-disjoint.
Then, similarly to the previous steps, two routes follow
LRX Algorithm and finish routing. The final routes are:
route 1: S1 - 1 - 4 - 8 - 11 - 15 - D1; route 2: S2 - 2 5 - 8 - 12 - 16 - 15 - D2. From the graph, we can make
a simple judge that two routes are link-disjoint.
TABLE I
NS-2 I RIDIUM SYSTEM PARAMETERS
Parameter
Altitude
Planes
Satellites per plane
Inclination
Inter-plane separation
Seam separation
Elevation mask
ISLs per satellite
ISL bandwidth
Up/downlink bandwidth
Value
780km
6
11
86.4°
31.6°
22°
8.2°
4
9Mb/s
2Mb/s
A. Simulation Environment
In our project, we choose Iridium constellation as
a representative of LEO satellite networks. A satellite
networking extension module has been used in NS-2 to
simulate the movement of LEO satellite constellation.
Great amount of types of satellite links, satellite routing
mechanism as well as the handover management scheme
are embedded in this extension as well. During the
simulation, we adopt NS-2 default settings for Iridium
satellites system.
The detailed parameters for the Iridium system like
altitude, inclination, number of planes and satellites
per plane, etc. are listed in the Table 1 as following.
Jiawei Tao and Zhibang Ge designed these parameters,
and we are permitted to utilize the same configuration
parameters as them.
Besides the above simulation parameters, the configuration of Iridium satellites plays the paramount role in the
simulation. There are totally sixty-six satellites around
the earth. The distribution of these satellites is shown in
the Figure 2 as following.
Fig. 1. An illustration for LRX OMSR Algorithm
IV. S IMULATION AND P ERFORMANCE E VALUATION
In this section, to verify the correctness and compare
the performance of multipath TCP with that of single
path TCP, we simulate the data transmission using multipath TCP and single path TCP on NS-2 (Network
Simulator 2), which has long been widely used for
research and education on Internet and other networking
systems.
Fig. 2. Satellite Network at time 1.00
We number these satellites from 0 to 65. The black
line in the figure means that there is a connection
between these two satellites, and no direct communication is allowed between the satellites without black line
connecting.
In the eastern hemisphere, i.e. on the right hand side of
the figure, there are some underlining TCP connections
that are always existing on the earth to serve the purpose
of simulating the background traffic, which could make
the our network simulation more like the real world
communication.
Among a great number of test cases we made during
the simulation, we choose three most representative scenarios to show in this report. The transmission paths for
these three scenarios are shown in Figure 3 as following.
Fig. 4. Routing trace of scenario 1
Fig. 3. Satellite Network with experiment paths
Scenario 1 in our project is a short transmission that
is approximately vertical, and there is traffic applied
in this simulation. Scenario 2 is a long transmission
across the western hemisphere, and there is no simulated
TCP traffic in the background. Scenario 3 is a long
transmission across the eastern hemisphere, and there is
traffic during the transmission and the case of handover
will be involved at some point as well.
The next few subsections will present the simulation
result of these three scenarios. Also, there will be the
explanation of the reason that specific result occurs.
For the sub-flow 1, i.e. from S1 to D1, the routing
mechanism is as the single path TCP: choosing the
shortest path from source to destination. The shortest
path is S1 - 0 - 1 - D1.
For the sub-flow 2, i.e. from S2 to D2, the different
routing mechanism is applied. It chooses the second
shortest path from source to destination that is disjoint
with the shortest path, i.e. S2 - 0 - 11 - 12 - 1 - D2. Since
both interfaces of the source can only access to satellite
number 0, the two paths share the first satellite node,
and the similar condition is applied on the interfaces of
the destination.
B. Simulation Results
The throughput of the transmission in this scenario is
show in Figure 5 as following. The blue line stands for
the total throughput, red line stands for the throughput
of sub-flow 1, and green line stands for the throughput
of sub-flow 2.
1) Scenario 1:
For scenario 1, the source locates at the position (3°N,
0°) and the destination locates at the position (30°N, 0°).
We create two interfaces for both source and destination
and do the simulation to observe the routing result first.
According to the file of routing trace of the simulation,
we draw the picture as Figure 4.
As shown in the figure, the total throughput is approximately the sum of the throughput of sub-flow 1 and
sub-flow 2. For the sub-flow 1 (red line), there are four
significant drops during the transmission. This is because
we intentionally add some underlining TCP connections
as the background interference and they cause traffic at
these four points.
Fig. 5. Throughput performance comparison between MPTCP and
TCP sub-flows for scenario 1
However, the overall throughput does not have 4 significant drops as the sub-flow 1 has. When the throughput
drops occur in the sub-flow 1 due to traffic, the number
of packets transmitting via sub-flow 1 decreases a lot. In
this case, sub-flow 2 will compensate the drop of subflow 1, and is responsible to transmit extra packets that
should be transmitted by sub-flow 1 initially. Therefore,
the total throughput maintains stable.
Fig. 6. Throughput performance comparison between MPTCP and
Single TCP for scenario 1
According to the file of routing trace of the simulation,
we draw the picture as Figure 7.
We also simulate this scenario using single path TCP,
and compute the throughput. As we evaluate both performance, the comparison of the throughput is show in
Figure 6 as following.
The comparison is quite straightforward. The throughput of multipath TCP is almost double as that of single
path TCP. The single path TCP choose the path that
has potential traffic problem, so its throughput has four
significant drops as the sub-flow 1 of the multipath TCP
does. It is easy to see that, since multipath TCP has two
paths to transmit data, it has more stable performance,
and will not be influenced by traffic too much.
2) Scenario 2:
For scenario 2, the source locates at the position (15°S,
178°W) and the destination locates at the position (32°N,
25°W). We create two interfaces for both source and
destination and do the simulation to observe the routing
result first.
This scenario is more complicated than scenario 1 but
less complicated than scenario 3, since more satellites
involve in this transmission.
Fig. 7. Routing trace of scenario 2
For the sub-flow 1, i.e. from S1 to D1, the routing
mechanism is as the single path TCP: choosing the
shortest path from source to destination. The shortest
path is S1 - 6 - 17 - 16 - 27 - 38 - 49 - 60 - 59 - D1. For
the sub-flow 2, i.e. from S2 to D2, the different routing
mechanism is applied. It choose the second shortest
path from source to destination that is disjoint with the
shortest path, i.e. S2 - 6 - 5 - 4 - 15 - 26 - 37 - 49 59 - D2. Since both interfaces of the source can only
access to satellite number 6, the two paths share the first
satellite node, and the similar condition is applied on the
interfaces of the destination.
Fig. 8. Throughput performance comparison between MPTCP and
TCP sub-flows for scenario 2
The throughput of the transmission in this scenario is
show in Figure 8 as following. The blue line stands for
the total throughput, green line stands for the throughput
of sub-flow 1, and red line stands for the throughput of
sub-flow 2.
Fig. 9. Throughput performance comparison between MPTCP and
Single TCP for scenario 2
It is the most complicated scenario among these three.
It involves a long path transmission, background traffic,
and handover as well. The source and destination may
lose the connection to the original satellite due to the
movement of the Iridium system.
According to the file of routing trace of the simulation,
we draw the picture as Figure 10.
In this scenario, it still holds that the total throughput
is approximately equal to the sum of the throughput
of sub-flow 1 and sub-flow 2. This shows that the
bottleneck in this network is the bandwidth of the path.
The three lines are all smooth than the result of the first
scenario, because the transmission occurs in the western
hemisphere, and there is no underground traffic in this
hemisphere in our simulation.
We also simulate this scenario using single path TCP,
and compute the throughput. As we evaluate both performances, the comparison of the throughput is show in
Figure 9 as following.
While the source sends packets in a nearly perfect
environment, the transmission is very stable, the throughput being almost unchanged. In addition, since multipath
TCP has one more path, the total throughput is hence as
double as the throughput of single path TCP.
3) Scenario 3:
For scenario 3, the source locates at the position
(17.4°N, 127.55°E) and the destination locates at the
position (15.51°N, 1°W). We create two interfaces for
both source and destination and do the simulation to
observe the routing result first.
Fig. 10. Routing trace of scenario 3
For the sub-flow 1, i.e. from S1 to D1, the routing
mechanism is as the single path TCP: choosing the
shortest path from source to destination. The shortest
path is S1 - 45 - 34 - 23 - 12 - 1 - D1. For the sub-flow
2, i.e. from S2 to D2, the different routing mechanism is
applied. It choose the second shortest path from source to
destination that is disjoint with the shortest path, i.e. S2
- 45 - 44 - 33 - 22 - 11 - 0 - 1 - D2. Since both interfaces
of the source can only access to satellite number 45, the
two paths share the first satellite node, and the similar
condition is applied on the interfaces of the destination.
The throughput of the transmission in this scenario is
show in Figure 11 as following. The blue line stands for
the total throughput, green line stands for the throughput
of sub-flow 1, and red line stands for the throughput of
sub-flow 2.
There is a handover in about the 60th second, but
in our project, we will not focus on the handling of
handover, instead, we concentrate on the steady state
of the transmission. However, one can still observe that
multipath TCP recover quicker after the handover than
single path TCP.
the compensation of sub-flow 1, the total transmission
maintains stable.
We also simulate this scenario using single path TCP,
and compute the throughput. As we evaluate both performances, the comparison of the throughput is show in
Figure 12 as following.
Fig. 12. Throughput performance comparison between MPTCP and
Single TCP for scenario 3
Fig. 11. Throughput performance comparison between MPTCP and
TCP sub-flows for scenario 3
In this complicated scenario, it is not always the case
that the total throughput is doubled. The improvement
of the throughput of multipath TCP before the handover
is not significant.
The throughput of sub-flow 2 is much smaller than
that of sub-flow 1. The main reason for this situation
is that the second shortest path is not that optimal, that
is to say, the second shortest path is much longer then
the shortest path that is applied by sub-flow 1, so the
throughput of sub-flow 2 is not as expected. However,
after the handover, the throughput of sub-flow 2 grows
significantly. Due to the movement of satellite, the length
of path of sub-flow 2 is almost as long as the path of
sub-flow 1, so they almost make equivalent contribution
to the total throughput.
Since the transmission occurs in eastern hemisphere,
there is underground traffic, and this is the explanation
of three significant drops of sub-flow 2. Thanks to
According to the simulation result, there is no large
improvement of the throughput between the 5th second
and the 55th second. During the handover, throughput of
single path TCP drops to 0, which means the transmission interrupts for a period. Multipath TCP deals with
the case of handover much better. There is only a drop in
the handover, but the transmission keeps working during
this period.
After the handover, the multipath TCP performs as
we expected. The throughput of multipath TCP is almost
as double as that of single path TCP, which is a good
improvement.
4) Latency:
Figure 13 (in the next page) shows the latency comparison among MPTCP, single TCP and TCP sub-flows
in scenario 3 (the latency histograms of the other two
scenarios are quite similar). According to the histogram,
the delay of MPTCP is slightly higher than single TCP.
Partly because one TCP sub-flow of MPTCP takes a
detour route in order to be link-disjoint with the shortest
path. Apparently, TCP sub-flow 1 is the shortest path
from source to destination and it shares similar transmission delay with single shortest-path TCP. The average
latency of MPTCP comes to a compromise due to a
detour route (TCP sub-flow 2) with reasonable higher
latency.
Fig. 13. Latency comparison among MPTCP, Single TCP and TCP
sub-flows
C. Summary
We simulate Multi-path TCP over Satellite Network
with NS-2 simulator in three scenarios. The results
verify the correctness of our algorithm. The performance comparison shows that MPTCP gained almost
double throughput than single TCP by utilizing linkdisjoint paths with slight penalty of transmission delay.
Moreover, the transmission with MPTCP is more stable
than single TCP, especially in scenarios with handover
situation.
V. C ONCLUSION & F UTURE W ORK
In this project, we mainly evaluated the performance of applying the Multi-path TCP and On-demand
Multi-path Source Routing (MPTCP-OMSR) protocol
into LEO satellite system networks. To better support
MPTCP, we designed the OMSR routing scheme and
proposed a LRX algorithm, which is named by the first
letter of the last names of our group members. The basic
function of OMSR is to select multiple link-disjoint paths
to accommodate MPTCP sub-flows. We also studied that
during the handover state, OMSR provides MPTCP with
two shortest paths by taking advantage of the common
fact that the ground terminal covers multiple satellites
in the overlapped area. Moreover, we figured out the
way to change routing path smoothly and gracefully
in the procedure of stable and handover states. Via
simulations and performance evaluation, the simulation
results verified that the proposed MPTCP-OMSR framework successfully increase throughput compared to that
of single-path TCP protocol. Meanwhile, it gracefully
deal with situation of handover, preventing transmission
interrupts and making transmissions with no gap. More
significantly, we also did comparison with an MPTCP
implementation using single shortest path routing. From
the result, it’s clear that OMSR path selection strategy
can significantly improve the throughput performance
and decrease the latency during handover. In summary,
the comparative simulation results positively the effectiveness and superiority of MPTCP applying in LEO
satellite system networks.
Via this project in CS218, we tried our best to explore
a relative new area and deepen our understanding of
networking, applying the knowledge in and outside the
lecture to solve practical problems independently. It is
such an interesting an unforgettable experience to us.
Despite of the academic knowledge we learned through
this project, the most meaningful part that this project
brings to us is that we learn, study and do research
together,which not only strengthens our sense of cooperation and team-work, but also enhances our mutual
understanding and friendship tremendously.
For future work, we will refine our algorithm and
improve its efficiency. Also, we will extend current 2path routing schema to real ”multiple path” routing, and
design an allocation granularity pattern to allocate certain
ratio of packets according to the throughput and latency
of each TCP sub-flow.
ACKNOWLEDGMENT
Foremost, we would like to express the deepest appreciation to our Professor Mario Gerla, who has shown
the attitude and the substance of genius: he continually
and persuasively conveyed a spirit of adventure in regard
to research and scholarship. His patience, and profound
knowledge consistently motivate us to be insightful to
the problems and he always put forward the constructive
suggestion and innovative idea to our project. Without
his supervision and constant instruction, this project
would not have been possible.
Furthermore, we would also like to acknowledge
with much appreciation the significant role of the tutor
Pengyuan Du, who give us the instruction and assistance
to the detained design and implementation methods,
and the necessary materials to complete multipath TCP
simulation.
In addition, my sincere also go to Jiawei Tao and
Zhibang Ge, for assisting us on the simulation environment design.
R EFERENCES
[1] E. Papapetrou, S. Karapantazis, and F.-N. Pavlidou. Distributed
on-demand routing for leo satellite systems. Computer Networks, 51(15):43564376, 2007.
[2] P. K. Chowdhury, M. Atiquzzaman, W. D. Ivancic, et al.
Handover schemes in satellite networks: State-of-the-art and
future research directions. IEEE Communications Surveys and
Tutorials, 8(1-4):214, 2006.
[3] M. Allman and J. Griner. Tcp behavior in networks with
dynamic propagation delay. In Global Telecommunications
Conference, 2000. GLOBECOM ’00. IEEE, volume 2, pages
11031108 vol.2, 2000.
[4] Y. Chotikapong and Z. Sun. Evaluation of application performance for tcp/ip via satellite links. In Satellite Services and the
Internet (Ref. No. 2000/017), IEE Seminar on, pages 4/14/4,
2000.
[5] C. Paasch, G. Detal, F. Duchene, C. Raiciu, and O. Bonaventure.
Exploring mobile/wifi handover with multipath tcp. In Proceedings of the 2012 ACM SIGCOMM workshop on Cellular
networks: operations, challenges, and future design, pages 3136.
ACM, 2012.
[6] C. Raiciu, M. Handley, and D. Wischik. Coupled congestion control for multipath transport protocols. draft-ietf-mptcpcongestion-01 (work in progress), 2011.
[7] S. Ha, I. Rhee, and L. Xu. Cubic: a new tcp-friendly highspeed tcp variant. ACM SIGOPS Operating Systems Review,
42(5):6474, 2008.
[8] T. Kelly. Scalable tcp: Improving performance in highspeed
wide area networks. ACM SIGCOMM Computer Communication Review, 33(2):8391, 2003.
[9] S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi, and R.
Wang. Tcp westwood: Bandwidth estimation for enhanced
transport over wireless links. In Proceedings of the 7th annual
international conference on Mobile computing and networking,
pages 287297. ACM, 2001.
[10] A. Baiocchi, A. P. Castellani, and F. Vacirca. Yeah-tcp: yet
another highspeed tcp. In Proc. PFLDnet, volume 7, pages 3742,
2007.
[11] H. Tsunoda, K. Ohta, N. Kato, and Y. Nemoto. Avoiding
tcp false retransmission in leo satellite network using ttl information. Electronics and Communications in Japan (Part I:
Communications), 88(1):6471, 2005.
[12] N. Meghanathan. Performance comparison of link, node and
zone disjoint multi-path routing strategies and minimum hop
single path routing for mobile ad hoc networks. arXiv preprint
arXiv:1011.5021, 2010.
[13] Marina, Mahesh K., and Samir R. Das. ”Ad hoc ondemand
multipath distance vector routing.” Wireless Communications
and Mobile Computing 6.7 (2006): 969-988.
[14] L. Bononi and M. Di Felice. Performance analysis of crosslayered multipath routing and mac layer solutions for multi-hop
ad hoc networks. In Proceedings of the 4th ACM international
workshop on Mobility management and wireless access, pages
190197. ACM, 2006.
[15] S.-J. Lee and M. Gerla. Split multipath routing with maximally
disjoint paths in ad hoc networks. In Communications, 2001.
ICC 2001. IEEE International Conference on, volume 10, pages
32013205. IEEE, 2001.
[16] C. Caini and R. Firrincieli. Tcp hybla: a tcp enhancement
for heterogeneous networks. International journal of satellite
communications and networking, 22(5):547566, 2004.
[17] C. Chen and E. Ekici. A routing protocol for hierarchical
leo/meo satellite ip networks. Wireless Networks, 11(4):507521,
2005.
[18] H. S. Chang, B. W. Kim, C. G. Lee, S. L. Min, Y. Choi, H. S.
Yang, D. N. Kim, and C. S. Kim. Fsa-based link assignment
and routing in low-earth orbit satellite networks. Vehicular
Technology, IEEE Transactions on, 47(3):10371048, 1998.
[19] C. Caini, R. Firrincieli, and D. Lacamera. Comparative performance evaluation of tcp variants on satellite environments. In
Communications, 2009. ICC’09. IEEE International Conference
on, pages 15. IEEE, 2009.