Presentation on theme: "Cross-layer Cooperation to Boost Multipath TCP"— Presentation transcript:
1Cross-layer Cooperation to Boost Multipath TCP Performance in Cloud NetworksMatthieu Coudron (LIP6), Stefano Secci (LIP6),Guy Pujolle (LIP6), Patrick Raad (NSS), Pascal Gallard (NSS)IEEE Cloudnet 2013, 12 Nov. 2013, San FranciscoJoint work with Non Stop systems who provided us with a multihomed virtual machine for our experiments
2Outline Our goal Multipath TCP presentation Our proposition: Augmented MPTCPOverviewLISP presentationTestbed & ResultsWill start by describing our motiviations,Basic knowledge of mptcp needed to understand this work
3Increase goodput via multipath communications Our goalIncrease goodput via multipath communicationsBetween DataCentersBetween endusers and DataCenters (DC)DCs are multihomed for reliabilityCellphone example, Wifi, LTE.
4Multipath TCP Introduction Subflow management A High Level overview of the protocol, to understan
5MPTCP presentation Multiple Path TCP is a TCP option First acknowledges if destination is MPTCP compliantCreates TCP subflows associated with a master TCP connectionMain characteristic: can send data concurrentlyEmphasis on backward compatibility,Should cope with middleboxes,Falls back to TCPWorking version in linux kernel , iOS7, Citrix.
6MPTCP introduction Defined in RFC 6824 as a TCP extension Emphasis on backwards compatibilityWorks with most middleboxesCan send data concurrently on several subflowsSingle data stream transmitted at 51.8 Gbit/s.Available in:LinuxiOS7Citrix NetScaleralmost as many middleboxes as routers in companiesCould do even better nowMany mechanisms to make sure it will work with NATsExperience done in a lab. They could do betterWorks pretty wellNot a fantasy, Already deployed
7MPTCP introductionFirst acknowledges if destination is MPTCP compliant during the 3 way handshakeCreates additional subflows according to path management mechanismClassic 3 way handshake Falls back to legacy TCPAll subflows must send the global Sequence Number via a TCP OptionThe question is, how to create those subflows ?
8MPTCP path managementRFC 6182 states path management should be modularBy default 1 subflow per (src,dst) IPs2 IPsrc and 2 IPdst => 2x2=4 subflowsNB: Several subflows can originate from the same IP with different port numbersWorht mentioning...The last point is something we leverage later on thisThe 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.
9How many subflows to create ? How to achieve proper forwarding ? By default 1 subflow100MB/s1GB/s1GB/s100MB/s1 IP1 IPFake topology as an exampleNo problem to share a link as long as it’s not the bottleneckWe could create lots of subflows and hope some use a different paths and let MPTCP decide which are the good ones. But InefficientWouldn’t 2 subflows be better ?Not necessarily..., need to follow different physical paths
10From previous example 2 problems arise How many subflows to create ? How to achieve proper load balancing ?MPTCP does not know the topologyPaths must be of the same quality
11Our proposition: A-MPTCP OverviewPresentation of LISPTesbed & Results
13Overview Enhance MPTCP path discovery with WAN topology information LISP can give edge path diversity informationLISP can enable multipath WAN forwardingEnforce per subflow forwardingBased on TCP ports in our caseRelying on edge multipath forwarding nodesThis could be OpenFlow, TRILL
14Location/Identifier Separation Protocol : LISP Defined in RFC 6830Tunneling protocol between edge routersAllows us to get the WAN path diversityIPs classified in 2 groups:Endpoint IDentifier (EID)Routing Locators (RLOCs)EID associated to RLOC(s) via a mapping system« To some extent », allows us toLots of usecases: Transition to IPv6, VM mobility
15encapsulated & forwarded to RB1 Mapping ServerEIDRLOCsBRB1, RB24/ RB decapsulates andforwards inner packet to B2/ RA retrieves RLOCs for B1/ A wants to contact BRLOC RB13/ Packet from Aencapsulated & forwarded to RB1RLOC RAHost EID « B »RLOC RB2..and then same happens backwardsHost EID « A »
16Our testbed Our guess: Number of WAN paths = Number of RLOCs Il est où le DC ?Paths of same quality (20ms andLISP beta network mainly run by CiscoOur guess: Number of WAN paths = Number of RLOCs
171/ First subflow established 2/ Retrieves number of RLOCs3/ Creation of 2nd subflow withSpecific source port numberPaths of same quality (20ms andLISP 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 »
185: Sends Map-Reply, i.e. list of RLOCs Userspace daemon+ lig programSpecificKernel moduleEnd-point CLISP router CLISP router SEnd-point SUDP/LISP tunnel1: SYN + MP_CAPABLE1: SYN/ACK + MP_CAPABLE3: Request relayedto userspacevia Netlink2: Request RLOCsof EID S1: ACK4: Sends Map-Request5: Sends Map-Reply, i.e. list of RLOCs6: Sends numberof RLOCs6: relays theinformation7: Creation of additionnal subflows if neededCould have done it on the server side
23Conclusion Significant gains in certain conditions Work applicable to OpenFlow, TRILL etc...On a cellphoneFuture workEnd to end multipathEnforce forwading on the WAN segment via LISP proxies
24Conclusion A-MPTCP gives significant gains in certain conditions Directly proportional to the number of additional WAN paths given by LISPAvailable in opensourceFuture workEnforce disjoint paths on the WAN segment via LISP Traffic EngineeringFurther enhancement on the DC/LAN segment via Cloud fabrics TE (SDN, OVS, TRILL-TE)End to end disjoint path enforcementOVS=OpenVSwitch
25Want to try MPTCP ? Install the MPTCP kernel (Debian/Ubuntu) Reboot RebootGo toBinaries for debian (or compiel it from source)
27LISP Traffic Engineering 1/ R1 recieves packet2/ R1 looks for mapping3/ R1 sends to next-hop R2RBR1,R2R3
28Number 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)
29Subflow forwarding We get N available WAN paths We create N subflows Each subflow i should have a i = srcPort % N
30Coupled Congestion Control Shared global windowThe TCP subflows are not independant and their congestion windows are coupledTry to use the least congested pathsProbe other paths as well
31ReferencesThe fastest TCP connection with Multipath TCP C. Paasch, G. Detal, S. Barré, F. Duchêne, O. BonaventureRevisiting Flow-Based Load Balancing: Stateless Path Selection in Data Center Networks G. Detal et al.