Software Defined Multi-Path TCP Solution for Mobile Wireless - - PowerPoint PPT Presentation

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

8 of 26

Network Operating System Routing

Traffic Engineering Other Applications

Well-defined API Network Map Abstraction Forwarding Forwarding Forwarding Forwarding Separation

• f

Data and Control Plane Network Virtualization

Security

Data Plane Control Plane Application Plane

Instructions Instructions Instructions Instructions

Outline

▪ Introduction ▪ Background ▪ Solution Design ▪ Evaluation ▪ Conclusion

9 of 26

Problem analysis

▪ Mobile naval network scenarios

▪ Ship to Ship Ship to Shore

▪ 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

Satellite UAV Ship Ship Ship

Satellite UAV Ship Ship Soldier

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

12 of 26

Naval Entity Naval Entity Naval Entity UAV UAV

FDM SDN-Controller

Calculating flow allocation Stats Collecting Alloc deploying User movement

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.

13 of 26

[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. [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

FDM

Bandwidth capacity User demand Link delay

Flow Table

Flows

Src_ip: 10.0.2.0 Src_ip: 10.0.2.1 Src_ip: 10.0.3.0 Src_ip: 10.0.3.1

Ac8on

Queue1, Output: 3 Queue2, Output: 4 Queue3, Output: 3 Queue4, Output: 4

Topology

SDN Switch SDN AP SDN Base Sta8on SDN Controller

Outline

▪ Introduction ▪ Background ▪ Solution Design ▪ Evaluation ▪ Conclusion

14 of 26

Mininet-WiFi-based Emulation Testbed

Server (“Host”) SDN Controller OVS Switch OVS AP User (“Stations”) Flow Table Queue Flow Table Queue Traffic Generator Control Plane Data Plane

15 of 26

▪ Process-based nodes

▪ Linux kernel implementation MPTCP on sender & receiver

▪ Traffic control link

▪ Enable link capacity and delay configuration

▪ Node mobility is supported ▪ Self-implemented SDN controller and FDM module ▪ Flow table:

▪ Decides routing ▪ OVS queues to restrict bandwidth

▪ Traffic generator:

▪ iPerf3 (custom rate)

▪ Capture packets with Wireshark

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

user2

user1

UAV

SATCOM

Host

Communication link Mobility trace Signal range

17 of 26

▪ Direct move experiment

▪ 2 Mobile users & 1 host ▪ 3Mbps sending rate ▪ 1 OVS switch – SATCOM ▪ 250ms delay ▪ 50Mbps bandwidth ▪ 1 OVS AP – UAV ▪ 10ms delay ▪ 1Mbps bandwidth ▪ 100s total execution time ▪ 2 users enters UAV’s range at 60s

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

20 of 26

▪ Random walk experiment

▪ 2 Mobile users & 1 host ▪ 3Mbps sending rate ▪ 1 OVS switch – SATCOM ▪ 250ms delay ▪ 50Mbps bandwidth ▪ 1 OVS AP – UAV ▪ 10ms delay ▪ 1Mbps bandwidth ▪ 100s total execution time ▪ 2 users randomly move

user2

user1

UAV SATCOM

Host

Communication link Mobility trace Signal range

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

24 of 26

▪ 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

• utperforms sparse network handover

▪ In terms of bandwidth fairness, FDM outperforms all non- FDM cases

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