Software Defined Multi-Path TCP Solution for Mobile Wireless Tactical Networks Qi Zhao , Pengyuan Du, Mario Gerla, Adam Brown, Jae Kim Department of Computer Science, UCLA Boeing Research & Technology, Seattle 10/31/2018
Outline ▪ Introduction ▪ Background ▪ Solution Design ▪ Evaluation ▪ Conclusion 2 of 26
Introduction ▪ Naval Battlefield Network (NBN) ▪ Shipboard satellite communication ▪ Multi-path TCP & Software Defined Networking ▪ Bandwidth sharing and load balancing 3 of 26
Introduction ▪ Modern NBN network ▪ Naval entity: Ship, Soldier, Aircraft … ▪ Communication media: Satellite, UAV ▪ Static --> Dynamic 4 of 26
Introduction ▪ Does the old solution still work? ▪ Answer: No, because of: ▪ Node mobility ▪ Dynamic link connection ▪ Dynamic traffic flow allocation ▪ SATCOM / UAV links ▪ Link capacity: large / small ▪ Link latency: high / low ▪ Signal range: wide / narrow 5 of 26
Outline ▪ Introduction ▪ Background ▪ Solution Design ▪ Evaluation ▪ Conclusion 6 of 26
Background ▪ Multipath TCP (MPTCP) [1] ▪ Presenting a single TCP connection to the application ▪ Utilize different interfaces underneath ▪ Work over today’s networks 7 of 26 [1] Wischik, Damon, et al. "Design, Implementation and Evaluation of Congestion Control for Multipath TCP."NSDI. Vol. 11. 2011.
Background ▪ Software Defined Networking ▪ SDN controller manages sub-flows globally Network� Virtualization Well-defined� API Other� Traffic� Routing Application Plane Security Engineering Applications Network� Map� Abstraction Network� Operating� System Control Plane Instructions Instructions Instructions Instructions Separation� of� Data� Forwarding and� Control Plane Forwarding Forwarding Data Plane Forwarding 8 of 26
Outline ▪ Introduction ▪ Background ▪ Solution Design ▪ Evaluation ▪ Conclusion 9 of 26
Problem analysis ▪ Mobile naval network scenarios ▪ Ship to Ship Ship to Shore Satellite UAV Satellite UAV Ship Ship Ship Soldier Ship Ship ▪ Data transmission must not be interrupted: Smooth network handover and reliable communication ▪ Traffic flow allocation must be able to reconfigure: Real-time traffic engineering and network configuration 10 of 26
Proposed solution ▪ Multi-path TCP ▪ Smoother reaction to network changes ▪ Immediate utilization of available links ▪ Low overhead and no interruption to existing sessions ▪ Software defined networking ▪ Controller defined by our own ▪ Real-time traffic flow calculation and configuration ▪ Avoid congestion due to MPTCP’s greedy scheduler 11 of 26
System Architecture SDN-Controller Calculating flow allocation Stats Collecting FDM Alloc deploying User movement Naval Entity Naval Entity UAV UAV Naval Entity 12 of 26
SDN Controller with FDM module ▪ Traffic engineering in SDN can be formulated as an Multi-Commodity Flow problem [1] ▪ Solve with the solution to the “Routing Assignment” problem in the Flow Deviation Method [2] ▪ Objective: minimize total packet delay while satisfying both capacity and bandwidth demand constraints. Bandwidth SDN� Controller capacity SDN� Switch Flow� Table Flows Ac8on User demand Src_ip:� 10.0.2.0 Queue1,� Output:� 3 Src_ip:� 10.0.2.1 Queue2,� Output:� 4 Src_ip:� 10.0.3.0 Queue3,� Output:� 3 Link delay SDN� AP Queue4,� Output:� 4 Src_ip:� 10.0.3.1 FDM Topology SDN� Base� Sta8on [1] S. Paris, A. Destounis, L. Maggi, G. S. Paschos, and J. Leguay. Controlling flow reconfigurations in sdn. In Computer Communications, IEEE INFOCOM 2016-The 35th Annual IEEE International Conference on, pages 1 – 9. IEEE, 2016. 13 of 26 [2] L. Fratta, M. Gerla, and L. Kleinrock. The flow deviation method: An approach to store-and-forward communication network design. Networks, 3(2):97 – 133, 1973
Outline ▪ Introduction ▪ Background ▪ Solution Design ▪ Evaluation ▪ Conclusion 14 of 26
Mininet-WiFi-based Emulation Testbed ▪ Process-based nodes Server (“Host”) SDN Controller ▪ Linux kernel implementation MPTCP on sender & receiver ▪ Traffic control link ▪ Enable link capacity and delay configuration Flow Table ▪ Node mobility is supported Flow Table Queue Queue ▪ Self-implemented SDN controller and FDM module OVS Switch OVS AP Control Plane ▪ Flow table: Data Plane ▪ Decides routing ▪ OVS queues to restrict User bandwidth (“Stations”) ▪ Traffic generator: ▪ iPerf3 (custom rate) Traffic Generator ▪ Capture packets with Wireshark 15 of 26
More Details ▪ Testbed platform: ▪ Linux Ubuntu 14.04 with 8GB RAM ▪ MPTCP v0.92 and Open vSwitch installed ▪ Experiment with 3 different protocols for every scenario to evaluate the performance of our proposed solution ▪ Single-path TCP (SPTCP) – baseline ▪ Multi-path TCP without FDM (MPTCP) ▪ Multi-path TCP with FDM (FDM) 16 of 26
Evaluation Scenario I ▪ Direct move experiment ▪ 2 Mobile users & 1 host ▪ 3Mbps sending rate SATCOM ▪ 1 OVS switch – SATCOM user1 ▪ 250ms delay Host ▪ 50Mbps bandwidth UAV Communication link ▪ 1 OVS AP – UAV Mobility trace Signal range ▪ 10ms delay user2 ▪ 1Mbps bandwidth ▪ 100s total execution time ▪ 2 users enters UAV’s range at 60s 17 of 26
Experiment Results I ▪ ~4 seconds communication interruption caused by network handover in SPTCP case ▪ Average throughput ▪ 0.4875Mbps – SPTCP ▪ 0.3728Mbps – MPTCP ▪ 0.4188Mbps – FDM 18 of 26
Results Summary I ▪ MPTCP vs SPTCP ▪ Reliable continuous communication is guaranteed by MPTCP protocol ▪ SPTCP’s overall throughput is slightly higher due to Infrequent network handover ▪ MPTCP only vs MPTCP with FDM ▪ FDM’s overall throughput and throughput variation is better ▪ FDM’s optimizer allocates bandwidth more efficiently than greedy heuristics of MPTCP’s default scheduler 19 of 26
Evaluation Scenario II ▪ Random walk experiment ▪ 2 Mobile users & 1 host SATCOM ▪ 3Mbps sending rate ▪ 1 OVS switch – SATCOM ▪ 250ms delay Host ▪ 50Mbps bandwidth user1 ▪ 1 OVS AP – UAV UAV Communication link Mobility trace ▪ 10ms delay user2 Signal range ▪ 1Mbps bandwidth ▪ 100s total execution time ▪ 2 users randomly move 20 of 26
Experiment Results II ▪ Multiple communication interruptions caused by network handover in SPTCP case ▪ Average throughput ▪ 0.3121Mbps – SPTCP ▪ 0.4738Mbps – MPTCP ▪ 0.4602Mbps – FDM 21 of 26
Results Summary II ▪ MPTCP vs SPTCP ▪ As expected, SPTCP’s overall throughput is degraded comparing to scenario I and MPTCP case ▪ MPTCP only vs MPTCP with FDM ▪ FDM’s overall throughput is slightly worse presumably due to the frequency of the network handover ▪ FDM’s throughput variation is much better because of the fairly allocated bandwidth of FDM 22 of 26
Outline ▪ Introduction ▪ Background ▪ Solution Design ▪ Evaluation ▪ Conclusion 23 of 26
Conclusion ▪ Supporting dynamic bandwidth allocation in real time ▪ Handling the mobility management of heterogeneous naval networks for both sparse and dense network handover cases ▪ In terms of overall throughput, dense network handover outperforms sparse network handover ▪ In terms of bandwidth fairness, FDM outperforms all non- FDM cases 24 of 26
Contributions ▪ A dynamic SDN controller to allocate traffic flows in mobile wireless tactical networks ▪ FDM-based flow allocation module ▪ Support dynamic flow adjustment ▪ Support multi-scenario, e.g., sparse and dense handover ▪ A complete MPTCP-enabled Mininet-WiFi-based emulation testbed integrated with our dynamic SDN controller 25 of 26
26 of 26
Recommend
More recommend
