Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Redesigning MPTCP in Edge clouds

69 views

Published on

Student Research Competition presentation for 24th ACM MobiCom 2018. Paper is available at: https://dl.acm.org/citation.cfm?id=3267738

Published in: Science
  • Be the first to comment

  • Be the first to like this

Redesigning MPTCP in Edge clouds

  1. 1. Redesigning MPTCP for Edge Clouds ACM Mobicom 2018 Student Research Competition Delhi, India Nitinder Mohan ⊥ Tanya Shreedhar ∤ Aleksandr Zavodovski ⊥ Otto Waltari ⊥ Jussi Kangasharju ⊥ Sanjit K. Kaul ∤ ⊥ University of Helsinki, Finland ∤ IIIT Delhi, India
  2. 2. Edge Networks • Small-scale server(s) equipped with multiple NIC at network “edge” • Distribute data with other edge servers over last-mile wireless links • Support for cloud technologies and scenarios such as container/VM migration etc. developed for managed networks Edge-to-Edge networks must ensure network reliability from A1 A2 Core  Network B2 B1 VM 2
  3. 3. • Standardized kernel extension to TCP • Forms multiple TCP flows over all available network interfaces to simultaneously utilize them Improvements: Increased robustness, bandwidth aggregation, seamless handovers etc. Multipath-TCP on Edge MPTCP TCP  Flow 1 A1 A2 Core  Network B2 B1 TCP  Flow 1 TCP  Flow 2 TCP  Flow 2 VM MPTCP SRTTflow1 SRTTflow2 ?SRTTflow1 < SRTTflow2? 3
  4. 4. Default MPTCP Performance How does MPTCP perform in real Edge ↔ Edge scenario? Setup: Both Sender and Receiver are equipped with two 802.11g WiFi over MPTCP v0.94 Network test: B2 interface at receiver starts to experience packet loss with 20% probability MPTCP TCP  Flow 1 A1 A2 Core  Network B2 B1 TCP  Flow 1 TCP  Flow 2 TCP  Flow 2 MPTCP 4
  5. 5. Default MPTCP Performance t1 t2 t1: Packet errors start on flow 2 t2: MPTCP stops using flow 2 as SRTTflow1 << SRTTflow2 5
  6. 6. Default MPTCP Performance After t1: → 43% new packets injected on flow 2 → 74% packets re-transmitted 6
  7. 7. MPTCP Sub-optimal Flow Decisions 1. SRTT is a delayed metric for estimating network conditions • Cannot pin-point exact source of delay in network • Cannot react to cause of delay 2. Little to no interaction between individual flows • Highly dependent on individual TCP flow throttling and adjustment 3. Sender is King! Current MPTCP is a dumb collection of multiple individual TCP connections 7
  8. 8. Receiver-Assisted MPTCP (RAMPTCP) “Reliability-first” extension to MPTCP by reducing packet re-transmission and re-ordering 1. Enables receiver to send its readily-available last-mile characteristics to sender in ACK e.g. channel utilization, signal strength, path loss% etc. 2. Sender can use extra information along with SRTT to better estimate network conditions 8
  9. 9. RAMPTCP in Action Data Delivery Reverse-Path Information Delivery Per-Segment Delay Estimation Flow Control Actions 9
  10. 10. Path 2 A2 A1 B1 B2 Path 1 Data Delivery Reverse-Path Information Delivery Per-Segment Delay EstimationFlow Control Actions Seq: 1 Data Seq: 2 Data 10
  11. 11. Path 2 A2 A1 B1 B2 Path 1 Seq: 1 B1: B2: Data Delivery Reverse-Path Information Delivery Per-Segment Delay EstimationFlow Control Actions 10
  12. 12. Path 2 A2 A1 B1 B2 Path 1 RTTpath = Tsender + Tcore + Treceiver Data Delivery Reverse-Path Information Delivery Per-Segment Delay EstimationFlow Control Actions 10
  13. 13. Path 2 A2 A1 B1 B2 Path 1 Data Delivery Reverse-Path Information Delivery Per-Segment Delay EstimationFlow Control Actions Seq: 3 DataSeq: 4 Data Possible control actions: Limit packets on flow, Out-of-order injection, Packet duplication, Change TCP send rate, Boycott flow usage, … 10
  14. 14. Preliminary Evaluation ns3 Simulation based on Direct Code Emulation (DCE) B1 interface suffers packet losses due to interference from 2-5sMPTCP TCP  Flow 1 A1 A2 Core  Network B2 B1 TCP  Flow 1 TCP  Flow 2 TCP  Flow 2 MPTCP 11 0 5 10 15 Throughput(Mbps) 0 1 2 3 4 5 6 7 8 9 10 Time (secs) 0 5 10 15 Flow 1 Flow 2 MPTCP RAMPTCP ≈19% increase in throughput ≈ 58% reductions in retrasmissions
  15. 15. Discussion and Future Work 1. Incorporate any access-layer technology i.e. WiFi, Ethernet, LTE, 5G etc. 2. How to effectively send receiver-side information to sender? 3. Effective RAMPTCP control decisions? RaspberryPi Battery LTE modem 12
  16. 16. Thank You! nitinder.mohan@helsinki.fi
  17. 17. Rise of Edge Clouds Network DatacenterEdge Server User → Small servers deployed at network edge to compute user data → Equipped with multiple NIC with different access technology e.g. WiFi, LTE, Ethernet etc. Motivation: Decreased latency and network traffic Computing data of local relevance Low network delay requirements 17
  18. 18. Preliminary Evaluation ns3 Simulation based on Direct Code Emulation (DCE) 1. Both sender and receiver are running MPTCP v0.89 2. B1 interface suffers packet losses due to interference from 2- 5s RAMPTCP configuration: → Sender is aware of receiver channel utilization, SNR, path loss % MPTCP TCP  Flow 1 A1 A2 Core  Network B2 B1 TCP  Flow 1 TCP  Flow 2 TCP  Flow 2 MPTCP 11
  19. 19. Preliminary Evaluation RAMPTCP achieves: 1. ≈19% increase in application goodput 2. ≈ 58% reductions in retrasmissions 0 5 10 15 Throughput(Mbps) 0 1 2 3 4 5 6 7 8 9 10 Time (secs) 0 5 10 15 Flow 1 Flow 2 MPTCP RAMPTCP 12

×