Presentation on theme: "MPTCP Enhancements to Improve Applicability to Wireless Access Networks draft_hampel_mptcp_applicability_wireless_networks_00 Georg Hampel, Thierry Klein."— Presentation transcript:
1 MPTCP Enhancements to Improve Applicability to Wireless Access Networks draft_hampel_mptcp_applicability_wireless_networks_00 Georg Hampel, Thierry Klein – Bell Labs + Discussions on ML
3 MPTCP + Wireless Access Networks “What do we gain when using MPTCP in wireless access networks”
4 How well does this go with wireless? MPTCP: Goals & Constraints (RFC 6182)ServerPrerequisite:Availability of multiple pathsGoalImprove throughput- resource pooling (“not worse than best path”)- load balancingIncrease resilience- segments can be (re-) send over every pathConstraintsApp compatibility: TCP-like, transparentNwk compatibility: middle-box complianceCompatibility with other users: fairnessSecurity3G/4GWLANMobileHow well does this go with wireless?
5 Little gain from resource pooling MPTCP + Wireless Access Networks: Typical Environment2.5G/3G/4G - Macrocellular – Outdoor deploymentOutdoors: Optimized for coverageIndoors: Wall penetration low rateAccess: Mostly single-subscribershipWiFi - Hotspot, in home/company – Indoor deploymentIndoors: Optimized for rateOutdoors: Wall penetration effectively no coverageAccess: Closed user groupOneoutdoornetworkindoorDatarateWiFiWiFi3GLittle gain from resource pooling
6 TP Gain: Multipath over Path-select: 10 – 15% MPTCP Applied to Wireless Access Networks: TP SimulationsOpportunistic Mobility with Multipath TCPCostin Raiciu, Dragos Niculescu, Marcelo Bagnulo, Mark HandleyMultipathPath-selectTP Gain: Multipath over Path-select: 10 – 15%Assumptions:100% Wifi coverageOpen user groupSmall gains even under optimistic assumptions
7 Outdoors: 3G only option. Indoors: 3G too inefficient. MPTCP Applied to Wireless Access Networks: Power consumptionOpportunistic Mobility with Multipath TCPCostin Raiciu, Dragos Niculescu, Marcelo Bagnulo, MarkHandleyWIFI = 5.8 Mb/J3G = 0.8 Mb/JOutdoors: 3G only option. Indoors: 3G too inefficient.
8 “Just pick the best path!” MPTCP + Wireless Access Networks: IssuesSmall gain from resource poolingIncreased delayAlways maximum delay given by slowest pathHead of line blocking due to periodic outage on weak pathsHigh resource usageLarge receiver bufferProcessing & air-interface overhead due to DSS optionsHigher battery & spectrum usage due to multiple radiosNo solution for incremental deployment Transparent Proxy“Just pick the best path!”Throughput aggregation: High cost – little gain
9 Local link information promises to find best path Path Selective Operation: How to Pick the Best Path?Local wireless linkWorst link (throughput, fluctuations)Most expensive linkInformation on local wireless linkMeasurements: SINR, signal strengthCost per MBUse this information to:Select your own interfaceCommunicate to peerLocal link information promises to find best path
10 Signaling optimization Path-Selective Operation = “Just-pick-the-best-path”: Value & CostsValue: Seamless session migration across access networksThroughput: “Not worse than best path”Resilience: Same as MPLoad balancing: Same as MPApplication-, middlebox-, fairness-, security compliance: Same as MP Meets the goals & constraints of RFC 6182Cost: MINLower complexitySmaller buffer space ( conventional TCP)Reduced air-interface/battery usageReduced processing/air-interface overheadLow complex hostOne radio at a timeSignaling optimizationMPTCP: Enabler rather than performance differentiator
11 Low Complexity Realization “How cheap can we make path-selective operation”
12 Performance impact seems acceptable Low Complexity MPTCP Host: Principal ConceptUse only one flow- & congestion engineBetween path-reselection windows FineDuring path-reselection window:Seamless since multiple subflows are upEngine needs to adapt to new channelRetransmissions on old path or cross flow?Performance impactSame as for: Mobile IP family, 3GPP, HIP, SHIM6, etc.Full-fledged MPTCP host: Needs to adapt to new channel conditions Performance impact seems acceptable
14 Signaling compliant with MPTCP protocol Low-Complex MPTCP Host: Signaling PlaneTCPEngineMPTCPModuleSYNSYN + MP_CAPEstablishment of connection & 1st subflowSYN/ACKSYN/ACK + MP_CAPACKACK + MP_CAPSYN + MP_JOINSYN/ACK + MP_JOINEstablishment of add subflowsACK + MP_JOINPacketPacket + DSS, etcMPTCP-specificsignaling+ ACKFINTermination of add subflowsFINFIN + Data FIN on DSSTermination of connectionSignaling compliant with MPTCP protocol
15 Processing high if both senders active and not in synch Low-Complex MPTCP Sender - Data PlaneSN_tcpAN_tcp DSN_loc SFL i SFL SN_i DSN_rem SFL k SFL AN_kTCP EngineIf i=kSenders are in synchBoth use the same pathRewrite segment:SN_tcp SN_iAN_tcp AN_iIPsrc_tcp IPloc_iIPdst_tcp IPrem_iSFL iIf i!=kSenders are not in synchDuring path re-selection orif remote sender does multipathPacket Splitting !Rewrite segment:SN_tcp SN_iAN_tcp last AN_iIPsrc_tcp IPloc_iIPrem_tcp IPrem_iSFL iCreate ACK:SN_tcp last SN_kAN_tcp AN_kIPsrc_tcp IPloc_kIPdst_tcp IPrem_kSFL kMPTCP Module Processing high if both senders active and not in synch
16 Availability of mapping crucial for low-complexity ! Low-Complex MPTCP Receiver - Data PlaneMPTCP ModuleRewrite segment:SN_i SN_tcpAN_i AN_tcpIPsrc_i IPloc_tcpIPdst_i IPrem_tcpTCP EngineSN_tcp IncomingAN_tcp segmentIPsrc, PRTsrcIPdst, PRTdstSFL SN_i DSN_rem = SN_tcpSFL AN_i DSN_loc = AN_tcpSFL iConnection-level buffering + reordering: Done by TCP EngineMultipath-compliantLarge buffer if remote sender does multipathSubflow-level buffering: Only if mapping unknownAdds unnecessary complexity! To be avoided!Availability of mapping crucial for low-complexity !
17 Full-fledged Full-fledged Low-complex Low-complex Interoperability: Full-Fledged Host Low-Complex HostFull-fledgedFull-fledgedDL MultipathUL Path-SelectDL & ULPath-SelectLow-complexAssert peer does path-selectAssert same path is usedLow-complexAccommodate frequent packet splitAccommodate large TCP buffer
18 Low-Complex MPTCP Implementation: Linux 2.26.38 – Ubuntu 11.xx cmdAppMPTCP ModulemangleUser spacefilterfunctionsownpacketsmangledpacketsinput/outputpacketsKernel spaceTCPIP TabRAWNetlinkFilter functions:Pc, IPsrc, IPdst, PRTsrc, PRTdstFlags: SYN, ACK,…Target:ACCEPT, DROP, QUEUEACCEPT/DROPNetfilterQueuefiltered packetsIPSequential processingNo buffering or reordering possible in user space!
20 Interface Availability Signaling “How to tell the server that my interface is down”
21 Issue addressed in draft-ietf-mptcp-multiaddressed-04 New Signaling: Client Announces Interface Availability to ServerUse caseMobile client central serverClient must inform server about its interface availabilityProblem with (old) MP_PRIOPath- rather than interface-specificOption must be sent on path it refers to No way to signal “interface is down” !ProposalProvide explicit interface-availability signalingML discussion: Add ADDR-ID to MP_PRIOServerWLAN3G/4GMobile Issue addressed in draft-ietf-mptcp-multiaddressed-04
23 Serves multipath- and path-selective operation Policy Required: Conflict Resolution for Path SelectionQuestion: Why set up a path in backup mode?Reason: Enjoy resilience Avoid path costProposed policies:Differentiate between Paths and InterfacesLocal Interface is the main “cost” factor1) Peers mutually respect local interface selection No conflict!Host tries to accommodate peer’s path selection If no path left, pick one!A wants only these paths.Host AHost BB wants only these paths.A wants only this path.Host AHost BB wants only this path. Serves multipath- and path-selective operation
24 “How to avoid unnecessary cost” DSS Issues“How to avoid unnecessary cost”
25 Flag is vital for low-complex realization Signaling Proposal: Bulk Transfer “Optimization” OptionalDSS “optimization” on bulk transfers is a tradeoffAdvantagesReduces number of DSSDisadvantagesRequires additional queuing on subflow levelAdds delay on sender sideProposal:Make feature optionalAdd “Bulk Transfer Optimization”-Flag to MP_CAPABLE Flag is vital for low-complex realization
26 Necessary for wireless MPTCP Feature requirement: “Temporary Fallback” ModeUse case: Mobile sees only one (dominant) pathDSS: Adds overhead, no valuePropose: “Temporary Fallback”If only one path active, MPTCP becomes as low-cost as TCP No DSS!Resume multipath operation when neededProblems:How to do the signaling?How to deal with payload modifying middle boxes?Proposals Necessary for wireless MPTCP
27 Problem with Present Fallback Mode draft-ietf-mptcp-multiaddressed-04.txt: Section 3.5“…When a connection is in fallback mode, only one subflow can send data at a time. …However, subflows can be opened and closed as necessary, as long as a single one is active at any point.”ML discussions: This does not seem to work!
31 Transparent MPTCP Proxy Purpose: Incremental DeploymentGeneric proxy: FlexibleCan reside anywhereNeeds signaling to authenticate hostNeeds signaling on how to route packetsTransparent proxy: SimpleResides on central router of initial pathImplicitly authenticated via network accessDerives route from packet inspectionRelevant use case:Transparent proxy on macro-cellular networkLTEWLANMPTCPTerminalServerTransparentProxy
32 Proposal: “JOIN” Flag + “NEW_TARGET” Flag on ADD_ADDR Problem: ADD_ADDR is overloaded: Add Address + Join AddressNew NEW_TARGET flag: “Use this address for future subflows”MN-LTEProxyServerMN-WiFiMN-LTEProxyServerMN-WifiMPTCPTCPMPTCPTCPMP_JOINMP_JOINADD_ADDR(IP proxy)ADD_ADDR(IP proxy)New TargetMP_JOINREMOVE_ADDR(IP server)RSTMPTCPTCPMP_JOINMP_JOIN
34 Summary: Proposed Signaling, Policies, Features Propose: Path-selection conflict resolution policyPropose: Make bulk-transfer “optimization” optionalAdd BULK_TRANSFER_OPTIMIZATION flag to MP_CAPABLEPropose: Feature for temporary fallback & return to MPWith payload rewriting middle boxesWithout payload rewriting middle boxesNeed clarification of subflow re-selection in Fallback modePropose: Support for transparent proxyAdd JOIN flag to ADD_ADDRESSAdd NEW_TARGET flag to ADD_ADDRESS