MPTCP Enhancements to Improve Applicability to Wireless Access Networks draft_hampel_mptcp_applicability_wireless_networks_00 Georg Hampel, Thierry Klein.

Slides:



Advertisements
Similar presentations
Multi-Access Services in Heterogeneous Wireless Networks Kameswari Chebrolu, Ramesh R. Rao Abstract Today's wireless world is characterized by heterogeneity.
Advertisements

mptcp proxies Mark Handley
MPTCP Application Considerations draft-scharf-mptcp-api-01 Michael Scharf Alan Ford IETF 77, March 2010.
WELCOME! Multipath TCP Implementors Workshop Saturday 24 th July Maastricht Philip Eardley MPTCP WG Co-chair.
TCP--Revisited. Background How to effectively share the network? – Goal: Fairness and vague notion of equality Ideal: If N connections, each should get.
Switching Techniques In large networks there might be multiple paths linking sender and receiver. Information may be switched as it travels through various.
Opportunistic Mobility with Multipath TCP
Umut Girit  One of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer.
IUT– Network Security Course 1 Network Security Firewalls.
UMA (Unlicensed Mobile Access) El Ayoubi Ahmed Hjiaj Karim.
Jennifer Rexford Fall 2014 (TTh 3:00-4:20 in CS 105) COS 561: Advanced Computer Networks Multipath.
TDTS21 Advanced Networking
1 Chapter 3 TCP and IP. Chapter 3 TCP and IP 2 Introduction Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) User Datagram Protocol.
BZUPAGES.COM 1 User Datagram Protocol - UDP RFC 768, Protocol 17 Provides unreliable, connectionless on top of IP Minimal overhead, high performance –No.
Options or payload? Costin Raiciu UCL IETF 78, Maastricht.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 OSI Transport Layer Network Fundamentals – Chapter 4.
CSEE W4140 Networking Laboratory Lecture 6: TCP and UDP Jong Yul Kim
Department of Electronic Engineering City University of Hong Kong EE3900 Computer Networks Transport Protocols Slide 1 Transport Protocols.
Reliable Transport Layers in Wireless Networks Mark Perillo Electrical and Computer Engineering.
TCP. Learning objectives Reliable Transport in TCP TCP flow and Congestion Control.
Routing of Outgoing Packets with MP-TCP draft-handley-mptcp-routing-00 Mark Handley Costin Raiciu Marcelo Bagnulo.
Gursharan Singh Tatla Transport Layer 16-May
ECCP A Formally-Verified Migration Protocol For Mobile, Multi-Homed Hosts Matvey Arye Joint work with: Erik Nordström, Robert Kiefer Jennifer Rexford, Michael.
Firewalls CS432. Overview  What are firewalls?  Types of firewalls Packet filtering firewalls Packet filtering firewalls Sateful firewalls Sateful firewalls.
Process-to-Process Delivery:
Common Devices Used In Computer Networks
6.1. Transport Control Protocol (TCP) It is the most widely used transport protocol in the world. Provides reliable end to end connection between two hosts.
Chapter 5 Transport layer With special emphasis on Transmission Control Protocol (TCP)
Multipath TCP Signaling Options or Payload? Costin Raiciu
TCP : Transmission Control Protocol Computer Network System Sirak Kaewjamnong.
Fundamentals of Computer Networks ECE 478/578 Lecture #19: Transport Layer Instructor: Loukas Lazos Dept of Electrical and Computer Engineering University.
TCP1 Transmission Control Protocol (TCP). TCP2 Outline Transmission Control Protocol.
Transport Layer Moving Segments. Transport Layer Protocols Provide a logical communication link between processes running on different hosts as if directly.
MPTCP Proxies & Anchors Georg Hampel & Thierry Klein Bell Labs – Alcatel-Lucent draft_hampel_mptcp_proxies_anchors_00.
Congestion control for Multipath TCP (MPTCP) Damon Wischik Costin Raiciu Adam Greenhalgh Mark Handley THE ROYAL SOCIETY.
Multipath TCP Update Philip Eardley, MPTCP WG Co-Chair tsvarea 1 st August, IETF-87, Berlin 1.
CISC856 University of Delaware
MultiPath TCP Proxy Presented by: Yongzhi Zhuang, Wei Zeng, Jianlei Zhang.
Networking Fundamentals. Basics Network – collection of nodes and links that cooperate for communication Nodes – computer systems –Internal (routers,
Department of Electronic Engineering City University of Hong Kong EE3900 Computer Networks Protocols and Architecture Slide 1 Use of Standard Protocols.
Multipath TCP ACM Queue, Volume 12 Issue 2, pp. 1-12, February 2014 Christoph Paasch and Olivier Bonaventure University College London 1.
Multipath TCP Signaling Options or Payload? Costin Raiciu
MPTCP Protocol draft-ietf-mptcp-multiaddressed-02 Update and Open Issues Alan Ford IETF79 – Beijing 1.
4343 X2 – The Transport Layer Tanenbaum Ch.6.
Michael G. Williams, Jeremey Barrett 1 Intro to Mobi-D Host based mobility.
MPTCP proxy mechanisms (draft-wei-mptcp-proxy-mechanism-00)
Multi-addressed Multipath TCP draft-ford-mptcp-multiaddressed-02 Alan Ford Costin Raiciu, Mark Handley.
1 Three ways to (ab)use Multipath Congestion Control Costin Raiciu University Politehnica of Bucharest.
11 CS716 Advanced Computer Networks By Dr. Amir Qayyum.
MPTCP Proxy MPTCP Client MPTCP Proxy Server.
3. END-TO-END PROTOCOLS (PART 1) Rocky K. C. Chang Department of Computing The Hong Kong Polytechnic University 22 March
Mobile IP THE 12 TH MEETING. Mobile IP  Incorporation of mobile users in the network.  Cellular system (e.g., GSM) started with mobility in mind. 
BANANA BOF Scope & Problem Description
RCP (Receiver Centric Transport Protocol)
Chapter 9: Transport Layer
Instructor Materials Chapter 9: Transport Layer
By, Nirnimesh Ghose, Master of Science,
MPTCP Lower Layer Implementation & Measurements
5. End-to-end protocols (part 1)
Long-haul Transport Protocols
Multipath TCP Yifan Peng Oct 11, 2012
Multi-addressed Multipath TCP
BANANA BOF Scope & Problem Description
ECF: an MPTCP Scheduler to Manage Heterogeneous Paths
Transport Protocols Relates to Lab 5. An overview of the transport protocols of the TCP/IP protocol suite. Also, a short discussion of UDP.
TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.
COS 561: Advanced Computer Networks
Process-to-Process Delivery:
IT351: Mobile & Wireless Computing
Process-to-Process Delivery: UDP, TCP
Presentation transcript:

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

Topics MPTCP + Wireless Access Networks 2. Low-complexity MPTCP host 3. Signaling & policy enhancements 4. Transparent proxy 5. Summary

MPTCP + Wireless Access Networks “What do we gain when using MPTCP in wireless access networks”

How well does this go with wireless? MPTCP: Goals & Constraints (RFC 6182) Server Prerequisite: Availability of multiple paths Goal Improve throughput - resource pooling (“not worse than best path”) - load balancing Increase resilience - segments can be (re-) send over every path Constraints App compatibility: TCP-like, transparent Nwk compatibility: middle-box compliance Compatibility with other users: fairness Security 3G/4G WLAN Mobile How well does this go with wireless?

Little gain from resource pooling MPTCP + Wireless Access Networks: Typical Environment 2.5G/3G/4G - Macrocellular – Outdoor deployment Outdoors: Optimized for coverage Indoors: Wall penetration  low rate Access: Mostly single-subscribership WiFi - Hotspot, in home/company – Indoor deployment Indoors: Optimized for rate Outdoors: Wall penetration  effectively no coverage Access: Closed user group One outdoor network indoor Datarate WiFi WiFi 3G Little gain from resource pooling

TP Gain: Multipath over Path-select: 10 – 15% MPTCP Applied to Wireless Access Networks: TP Simulations Opportunistic Mobility with Multipath TCP Costin Raiciu, Dragos Niculescu, Marcelo Bagnulo, Mark Handley Multipath Path-select TP Gain: Multipath over Path-select: 10 – 15% Assumptions: 100% Wifi coverage Open user group Small gains even under optimistic assumptions

Outdoors: 3G only option. Indoors: 3G too inefficient. MPTCP Applied to Wireless Access Networks: Power consumption Opportunistic Mobility with Multipath TCP Costin Raiciu, Dragos Niculescu, Marcelo Bagnulo, MarkHandley WIFI = 5.8 Mb/J 3G = 0.8 Mb/J Outdoors: 3G only option. Indoors: 3G too inefficient.

“Just pick the best path!” MPTCP + Wireless Access Networks: Issues Small gain from resource pooling Increased delay Always maximum delay given by slowest path Head of line blocking due to periodic outage on weak paths High resource usage Large receiver buffer Processing & air-interface overhead due to DSS options Higher battery & spectrum usage due to multiple radios No solution for incremental deployment  Transparent Proxy “Just pick the best path!” Throughput aggregation: High cost – little gain

Local link information promises to find best path Path Selective Operation: How to Pick the Best Path? Local wireless link Worst link (throughput, fluctuations) Most expensive link Information on local wireless link Measurements: SINR, signal strength Cost per MB Use this information to: Select your own interface Communicate to peer Local link information promises to find best path

Signaling optimization Path-Selective Operation = “Just-pick-the-best-path”: Value & Costs Value: Seamless session migration across access networks Throughput: “Not worse than best path” Resilience: Same as MP Load balancing: Same as MP Application-, middlebox-, fairness-, security compliance: Same as MP  Meets the goals & constraints of RFC 6182 Cost:  MIN Lower complexity Smaller buffer space ( conventional TCP) Reduced air-interface/battery usage Reduced processing/air-interface overhead Low complex host One radio at a time Signaling optimization MPTCP: Enabler rather than performance differentiator

Low Complexity Realization “How cheap can we make path-selective operation”

 Performance impact seems acceptable Low Complexity MPTCP Host: Principal Concept Use only one flow- & congestion engine Between path-reselection windows  Fine During path-reselection window: Seamless since multiple subflows are up Engine needs to adapt to new channel Retransmissions on old path or cross flow? Performance impact Same as for: Mobile IP family, 3GPP, HIP, SHIM6, etc. Full-fledged MPTCP host: Needs to adapt to new channel conditions  Performance impact seems acceptable

MPTCP Module: Flexible realization in- or outside kernel Low-Complex MPTCP Host: Protocol stack MPTCP full-fledged (multi engine) MPTCP low-complex (single engine) Stream socket Stream socket MPTCP Connection Flow/Cong Conventional TCP Connection Flow/Cong Internal interface Conventional TCP segment MPTCP SFL Flow/Cong MPTCP SFL Flow/Cong MPTCP Module SFL Map/Sgnl SFL Map/Sgnl Conventional TCP segment Conventional TCP segment MPTCP Module: Flexible realization in- or outside kernel

Signaling compliant with MPTCP protocol Low-Complex MPTCP Host: Signaling Plane TCP Engine MPTCP Module SYN SYN + MP_CAP Establishment of connection & 1st subflow SYN/ACK SYN/ACK + MP_CAP ACK ACK + MP_CAP SYN + MP_JOIN SYN/ACK + MP_JOIN Establishment of add subflows ACK + MP_JOIN Packet Packet + DSS, etc MPTCP-specific signaling + ACK FIN Termination of add subflows FIN FIN + Data FIN on DSS Termination of connection Signaling compliant with MPTCP protocol

 Processing high if both senders active and not in synch Low-Complex MPTCP Sender - Data Plane SN_tcp AN_tcp  DSN_loc  SFL i  SFL SN_i  DSN_rem  SFL k  SFL AN_k TCP Engine If i=k Senders are in synch Both use the same path Rewrite segment: SN_tcp  SN_i AN_tcp  AN_i IPsrc_tcp  IPloc_i IPdst_tcp  IPrem_i SFL i If i!=k Senders are not in synch During path re-selection or if remote sender does multipath Packet Splitting ! Rewrite segment: SN_tcp  SN_i AN_tcp  last AN_i IPsrc_tcp  IPloc_i IPrem_tcp  IPrem_i SFL i Create ACK: SN_tcp  last SN_k AN_tcp  AN_k IPsrc_tcp  IPloc_k IPdst_tcp  IPrem_k SFL k MPTCP Module  Processing high if both senders active and not in synch

Availability of mapping crucial for low-complexity ! Low-Complex MPTCP Receiver - Data Plane MPTCP Module Rewrite segment: SN_i  SN_tcp AN_i  AN_tcp IPsrc_i  IPloc_tcp IPdst_i  IPrem_tcp TCP Engine SN_tcp Incoming AN_tcp segment IPsrc, PRTsrc IPdst, PRTdst SFL SN_i  DSN_rem = SN_tcp SFL AN_i  DSN_loc = AN_tcp SFL i Connection-level buffering + reordering: Done by TCP Engine Multipath-compliant Large buffer if remote sender does multipath Subflow-level buffering: Only if mapping unknown Adds unnecessary complexity! To be avoided! Availability of mapping crucial for low-complexity !

Full-fledged Full-fledged Low-complex Low-complex Interoperability: Full-Fledged Host  Low-Complex Host Full-fledged Full-fledged DL Multipath UL Path-Select DL & UL Path-Select Low-complex Assert peer does path-select Assert same path is used Low-complex Accommodate frequent packet split Accommodate large TCP buffer

Low-Complex MPTCP Implementation: Linux 2.26.38 – Ubuntu 11.xx cmd App MPTCP Module mangle User space filter functions own packets mangled packets input/output packets Kernel space TCP IP Tab RAW Netlink Filter functions: Pc, IPsrc, IPdst, PRTsrc, PRTdst Flags: SYN, ACK,… Target: ACCEPT, DROP, QUEUE ACCEPT/DROP Netfilter Queue filtered packets IP Sequential processing No buffering or reordering possible in user space!

Low-Complex MPTCP Implementation: Signaling + Trials Temporary Fallback mode No bulk-transfer optimization Path-selection conflict resolution policy New MP_PRIO Trials: Interoperability with MPTCP full-fledged (Both hosts path-selective) (Multipath peer) LTE/3G vs. WiFi

Interface Availability Signaling “How to tell the server that my interface is down”

 Issue addressed in draft-ietf-mptcp-multiaddressed-04 New Signaling: Client Announces Interface Availability to Server Use case Mobile client  central server Client must inform server about its interface availability Problem with (old) MP_PRIO Path- rather than interface-specific Option must be sent on path it refers to  No way to signal “interface is down” ! Proposal Provide explicit interface-availability signaling ML discussion: Add ADDR-ID to MP_PRIO Server WLAN 3G/4G Mobile  Issue addressed in draft-ietf-mptcp-multiaddressed-04

Path-Selection Conflict Resolution “I want paths 1 & 2, you want 3 & 4”

 Serves multipath- and path-selective operation Policy Required: Conflict Resolution for Path Selection Question: Why set up a path in backup mode? Reason: Enjoy resilience  Avoid path cost Proposed policies: Differentiate between Paths and Interfaces Local Interface is the main “cost” factor 1) 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 A Host B B wants only these paths. A wants only this path. Host A Host B B wants only this path.  Serves multipath- and path-selective operation

“How to avoid unnecessary cost” DSS Issues “How to avoid unnecessary cost”

 Flag is vital for low-complex realization Signaling Proposal: Bulk Transfer “Optimization”  Optional DSS “optimization” on bulk transfers is a tradeoff Advantages Reduces number of DSS Disadvantages Requires additional queuing on subflow level Adds delay on sender side Proposal: Make feature optional Add “Bulk Transfer Optimization”-Flag to MP_CAPABLE  Flag is vital for low-complex realization

 Necessary for wireless MPTCP Feature requirement: “Temporary Fallback” Mode Use case: Mobile sees only one (dominant) path DSS: Adds overhead, no value Propose: “Temporary Fallback” If only one path active, MPTCP becomes as low-cost as TCP  No DSS! Resume multipath operation when needed Problems: How to do the signaling? How to deal with payload modifying middle boxes? Proposals     Necessary for wireless MPTCP

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!

… … Proposal: Temporary Fallback + Return --- NO CHECKSUMS SFL1 DSS_infinity DSN = X, SSN = Y SSN = Z, DSN = X DSN = X+100, SSN = Y+100 SSN = Z+100, DSN = X+100 DSN = X+200, SSN = Y+200 SSN = Z+200, DSN = X+200 DSN = X+300, SSN = Y+300 SSN = Z+300, DSN = X+300 SFL2 DSS DSN = X+400, SSN = A SSN = B  DSN=X+400 DSS … … Temporary Fallback: DSS + infinity setting Return to Multipath: DSS on any path Since no payload rewriting, DSN is always absolute reference

Proposal: Temporary Fallback + Return –-- WITH CHECKSUMS SFL1 DSS_infinity CS1 DSN = X, SSN = Y SSN = Z, DSN = X CS’1 + CS2 DSN = X+100, SSN = Y+100 SSN = Z+100, DSN = X+100 + CS’2 + CS3 DSN = X+200, SSN = Y+200 SSN = Z+200, DSN = X+200 + CS’3 + CS4 DSN = X+300, SSN = Y+300 SSN = Z+300, DSN = X+300 + CS’4 Retroactive DSS DSN= X+400 SSN = 400 Range = 0 Checksum = S CSi Verify S CSi = S CS’i If match  return to MP (via DSS) Otherwise  terminal FB (via MP_FAIL) DSN = X+400, SSN = A Catches payload rewriting Return to MP must occur on present subflow Procedure must be done “reliably” and in both flow directions

Transparent Proxy

Transparent MPTCP Proxy Purpose: Incremental Deployment Generic proxy: Flexible Can reside anywhere Needs signaling to authenticate host Needs signaling on how to route packets Transparent proxy: Simple Resides on central router of initial path Implicitly authenticated via network access Derives route from packet inspection Relevant use case: Transparent proxy on macro-cellular network LTE WLAN MPTCP Terminal Server Transparent Proxy

Proposal: “JOIN” Flag + “NEW_TARGET” Flag on ADD_ADDR Problem: ADD_ADDR is overloaded: Add Address + Join Address New NEW_TARGET flag: “Use this address for future subflows” MN-LTE Proxy Server MN-WiFi MN-LTE Proxy Server MN-Wifi MPTCP TCP MPTCP TCP MP_JOIN MP_JOIN ADD_ADDR (IP proxy) ADD_ADDR (IP proxy) New Target MP_JOIN REMOVE_ADDR (IP server) RST MPTCP TCP MP_JOIN MP_JOIN

Summary

Summary: Proposed Signaling, Policies, Features Propose: Path-selection conflict resolution policy Propose: Make bulk-transfer “optimization” optional Add BULK_TRANSFER_OPTIMIZATION flag to MP_CAPABLE Propose: Feature for temporary fallback & return to MP With payload rewriting middle boxes Without payload rewriting middle boxes Need clarification of subflow re-selection in Fallback mode Propose: Support for transparent proxy Add JOIN flag to ADD_ADDRESS Add NEW_TARGET flag to ADD_ADDRESS