1 / 27

Cross-layer Cooperation to Boost Multipath TCP Performance in Cloud Networks

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. Outline. Our goal

enid
Download Presentation

Cross-layer Cooperation to Boost Multipath TCP Performance in Cloud Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cross-layer Cooperation to BoostMultipath TCP Performance in Cloud Networks Matthieu Coudron(LIP6), Stefano Secci (LIP6), Guy Pujolle (LIP6), Patrick Raad (NSS), Pascal Gallard (NSS) IEEE Cloudnet2013, 12 Nov. 2013, San Francisco

  2. Outline • Our goal • Multipath TCP presentation • Our proposition: Augmented MPTCP • Overview • LISP presentation • Testbed & Results

  3. Our goal Increase goodput via multipath communications • Between DataCenters • Between endusers and DataCenters (DC)

  4. Multipath TCP Introduction Subflow management

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

  6. MPTCP introduction • First acknowledges if destination is MPTCP compliant during the 3 way handshake • Creates additional subflows according to path management mechanism

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

  8. 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 Wouldn’t 2 subflows be better ? Not necessarily... ,need to follow different physical paths

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

  10. Overview • Enhance MPTCP path discovery with WAN topology information • LISP cangiveedgepathdiversity information • LISP can enable multipath WAN forwarding • Enforce per subflow forwarding • Based on TCP ports in our case • Relying on edgemultipathforwardingnodes

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

  12. Mapping Server 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 Host EID « A »

  13. Our testbed Our guess: Number of WAN paths = Number of RLOCs

  14. 1/ First subflow established 2/ Retrieves number of RLOCs 3/ Creation of 2nd subflow with Specific source port number (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 »

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

  16. Results on 20 iterations

  17. Results on 20 iterations

  18. Results on 20 iterations 40% improval

  19. 3 subflows

  20. Conclusion • A-MPTCP givessignificantgains in certain conditions • Directlyproportional to the number of additional WAN pathsgiven by LISP • Available in opensource • Future work • Enforce disjoint paths on the WAN segment via LISP Traffic Engineering • Furtherenhancement on the DC/LAN segment via Cloud fabrics TE (SDN, OVS, TRILL-TE)

  21. Want to try MPTCP ? • Install the MPTCP kernel (Debian/Ubuntu) • http://multipath-tcp.org • Reboot • Go to www.amiusingmptcp.com

  22. Source code available on : • http://github.com/teto/xp_couplage • Matthieu.coudron@lip6.fr

  23. LISP Traffic Engineering 1/ R1 recieves packet 2/ R1 looks for mapping 3/ R1 sends to next-hop R2

  24. 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)

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

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

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

More Related