Presentation is loading. Please wait.

Presentation is loading. Please wait.

Cross-layer Cooperation to Boost Multipath TCP

Similar presentations

Presentation on theme: "Cross-layer Cooperation to Boost Multipath TCP"— Presentation transcript:

1 Cross-layer Cooperation to Boost Multipath TCP
Performance in Cloud Networks Matthieu Coudron (LIP6), Stefano Secci (LIP6), Guy Pujolle (LIP6), Patrick Raad (NSS), Pascal Gallard (NSS) IEEE Cloudnet 2013, 12 Nov. 2013, San Francisco Joint work with Non Stop systems who provided us with a multihomed virtual machine for our experiments

2 Outline Our goal Multipath TCP presentation
Our proposition: Augmented MPTCP Overview LISP presentation Testbed & Results Will start by describing our motiviations, Basic knowledge of mptcp needed to understand this work

3 Increase goodput via multipath communications
Our goal Increase goodput via multipath communications Between DataCenters Between endusers and DataCenters (DC) DCs are multihomed for reliability Cellphone example, Wifi, LTE.

4 Multipath TCP Introduction Subflow management
A High Level overview of the protocol, to understan

5 MPTCP presentation Multiple Path TCP is a TCP option
First acknowledges if destination is MPTCP compliant Creates TCP subflows associated with a master TCP connection Main characteristic: can send data concurrently Emphasis on backward compatibility, Should cope with middleboxes, Falls back to TCP Working version in linux kernel , iOS7, Citrix.

6 MPTCP introduction Defined in RFC 6824 as a TCP extension
Emphasis on backwards compatibility Works with most middleboxes Can send data concurrently on several subflows Single data stream transmitted at 51.8 Gbit/s. Available in: Linux iOS7 Citrix NetScaler almost as many middleboxes as routers in companies Could do even better now Many mechanisms to make sure it will work with NATs Experience done in a lab. They could do better Works pretty well Not a fantasy, Already deployed

7 MPTCP introduction First acknowledges if destination is MPTCP compliant during the 3 way handshake Creates additional subflows according to path management mechanism Classic 3 way handshake Falls back to legacy TCP All subflows must send the global Sequence Number via a TCP Option The question is, how to create those subflows ?

8 MPTCP path management RFC 6182 states path management should be modular By default 1 subflow per (src,dst) IPs 2 IPsrc and 2 IPdst => 2x2=4 subflows NB: Several subflows can originate from the same IP with different port numbers Worht mentioning... The last point is something we leverage later on this The path management is a separate function from the packet scheduling, subflow interface, and congestion control functions of MPTCP, as documented in Section 4. As such, it would be feasible to replace this IP-address-based design with an alternative path selection mechanism in the future, with no significant changes to the other functional components.

9 How many subflows to create ? How to achieve proper forwarding ?
By default 1 subflow 100MB/s 1GB/s 1GB/s 100MB/s 1 IP 1 IP Fake topology as an example No problem to share a link as long as it’s not the bottleneck We could create lots of subflows and hope some use a different paths and let MPTCP decide which are the good ones. But Inefficient Wouldn’t 2 subflows be better ? Not necessarily... , need to follow different physical paths

10 From previous example 2 problems arise How many subflows to create ?
How to achieve proper load balancing ? MPTCP does not know the topology Paths must be of the same quality

11 Our proposition: A-MPTCP
Overview Presentation of LISP Tesbed & Results

12 1/ SYN + MPTCP capable option
2/ SYN/ACK + MPTCP capable option 3/ ACK Eth0 Eth0 wlan0 wlan0 1/ SYN + MPTCP JOIN option 2/ SYN/ACK + MPTCP option 3/ ACK

13 Overview Enhance MPTCP path discovery with WAN topology information
LISP can give edge path diversity information LISP can enable multipath WAN forwarding Enforce per subflow forwarding Based on TCP ports in our case Relying on edge multipath forwarding nodes This could be OpenFlow, TRILL

14 Location/Identifier Separation Protocol : LISP
Defined in RFC 6830 Tunneling protocol between edge routers Allows us to get the WAN path diversity IPs classified in 2 groups: Endpoint IDentifier (EID) Routing Locators (RLOCs) EID associated to RLOC(s) via a mapping system « To some extent », allows us to Lots of usecases: Transition to IPv6, VM mobility

15 encapsulated & forwarded to RB1
Mapping Server EID RLOCs B RB1, RB2 4/ RB decapsulates and forwards inner packet to B 2/ RA retrieves RLOCs for B 1/ A wants to contact B RLOC RB1 3/ Packet from A encapsulated & forwarded to RB1 RLOC RA Host EID « B » RLOC RB2 ..and then same happens backwards Host EID « A »

16 Our testbed Our guess: Number of WAN paths = Number of RLOCs
Il est où le DC ? Paths of same quality (20ms and LISP beta network mainly run by Cisco Our guess: Number of WAN paths = Number of RLOCs

17 1/ First subflow established
2/ Retrieves number of RLOCs 3/ Creation of 2nd subflow with Specific source port number Paths of same quality (20ms and LISP beta network mainly run by Cisco (Subflow srcPortNumber) %2 = 0 (or 1) =>(Subflow srcPortNumber) %2 = 1 (or 0) G. Detal et al., « Revisiting Flow-Based Load Balancing: Stateless Path Selection in Data Center Networks »

18 5: Sends Map-Reply, i.e. list of RLOCs
Userspace daemon + lig program Specific Kernel module End-point C LISP router C LISP router S End-point S UDP/LISP tunnel 1: SYN + MP_CAPABLE 1: SYN/ACK + MP_CAPABLE 3: Request relayed to userspace via Netlink 2: Request RLOCs of EID S 1: ACK 4: Sends Map-Request 5: Sends Map-Reply, i.e. list of RLOCs 6: Sends number of RLOCs 6: relays the information 7: Creation of additionnal subflows if needed Could have done it on the server side

19 Results on 20 iterations

20 Results on 20 iterations

21 Results on 20 iterations 40% improval
Intereseting here => deterministic

22 3 subflows

23 Conclusion Significant gains in certain conditions
Work applicable to OpenFlow, TRILL etc... On a cellphone Future work End to end multipath Enforce forwading on the WAN segment via LISP proxies

24 Conclusion A-MPTCP gives significant gains in certain conditions
Directly proportional to the number of additional WAN paths given by LISP Available in opensource Future work Enforce disjoint paths on the WAN segment via LISP Traffic Engineering Further enhancement on the DC/LAN segment via Cloud fabrics TE (SDN, OVS, TRILL-TE) End to end disjoint path enforcement OVS=OpenVSwitch

25 Want to try MPTCP ? Install the MPTCP kernel (Debian/Ubuntu) Reboot
Reboot Go to Binaries for debian (or compiel it from source)

26 Source code available on :

27 LISP Traffic Engineering
1/ R1 recieves packet 2/ R1 looks for mapping 3/ R1 sends to next-hop R2 RB R1,R2 R3

28 Number of subflows Hypothesis: LAN is not the bottleneck
Number of subflows N=Max(WAN diversity, LAN diversity) N=Max(Product of EIDs, Product of RLOCs)

29 Subflow forwarding We get N available WAN paths We create N subflows
Each subflow i should have a i = srcPort % N

30 Coupled Congestion Control
Shared global window The TCP subflows are not independant and their congestion windows are coupled Try to use the least congested paths Probe other paths as well

31 References The fastest TCP connection with Multipath TCP C. Paasch, G. Detal, S. Barré, F. Duchêne, O. Bonaventure Revisiting Flow-Based Load Balancing: Stateless Path Selection in Data Center Networks G. Detal et al.

Download ppt "Cross-layer Cooperation to Boost Multipath TCP"

Similar presentations

Ads by Google