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.
© Copyright 2024