MPTCP D. Wing Internet-Draft R. Ravindranath Intended status: Standards Track T. Reddy Expires: April 10, 2014 Cisco A. Ford Unaffiliated R. Penno Cisco October 07, 2013 Multipath TCP (MPTCP) Path Selection using PCP draft-wing-mptcp-pcp-00 Abstract MultiPath TCP (MPTCP) allows a host to use multiple interfaces to transfer data. Without knowledge of the characterisitcs of each network path, the MPTCP stack has to send data to learn those characteristics. This document communicates network characteristics using Port Control Protocol(PCP) to allow the MPTCP stack influence its functions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 10, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Wing, et al. Expires April 10, 2014 [Page 1] Internet-Draft MPTCP Path Selection using PCP October 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 3. MPTCP stack using PCP . . . . . . . . . . . . . . . . . . . . 4 4. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 6 4.1. Interface Availability . . . . . . . . . . . . . . . . . 6 4.1.1. consolidate subflows . . . . . . . . . . . . . . . . 7 4.1.2. migrating an existing subflow . . . . . . . . . . . . 7 5. Switch-over . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Using MP_PRIO mechanism of MPTCP along with PCP . . . . . . . 7 7. PCP Instance ID usage in MPTCP flows . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Multipath Transmission Control Protocol (MPTCP) [RFC6182] pools multiple TCP paths within a transport connection, and is transparent to the application. Multipath TCP is primarily concerned with utilizing multiple paths end-to-end, where one or both of the end hosts are multihomed. It may also have applications where multiple paths exist within the network and can be manipulated by an end host. An MPTCP connection begins similarly to a regular TCP connection and if extra paths are available, additional TCP subflows are created on these paths, and are combined with the existing session, which continues to appear as a single connection to the applications at both ends. MPTCP provides greater throughput by using multiple paths, and also resilience against path failure. The latter property additionally provides mobility functionality. Wing, et al. Expires April 10, 2014 [Page 2] Internet-Draft MPTCP Path Selection using PCP October 2013 MPTCP identifies multiple paths by the presence of multiple addresses at hosts. The discovery and setup of additional subflows will be achieved through a path management method. Section 3.3.8 of [RFC6824] discusses MPTCP policies to share traffic over the available paths. MPTCP may use all paths (for maximum throughput) or a subset of paths (for network resiliency). The path selection is mostly based on local policy, OS behavior, and the MP_PRIO option. The MPTCP API document [RFC6897] discusses the requirements for MPTCP-aware applications to select multiple paths that can provide the required flow characteristics; for example, 5Mbps of upstream/ downstream bandwidth, low loss, low delay, etc. Appendix A.3 of [RFC6897] lists two requirements (REQ-8, REQ-9) for an advanced MPTCP API which would enable the application to select paths based on the link characteristics like bandwidth, latency, etc. This draft defines the on-the-wire protocol for such an advanced MPTCP API. It uses PCP flow extensions [I-D.wing-pcp-flowdata] to select the best path when multiple paths are available. This would be particularly relevant for applications that are highly interactive but require specific link characteristics such as certain minimum upstream or downstream bandwidth, delay, loss, or jitter characteristics. In such a situation, the MPTCP stack can use PCP to find a interface that provides the necessary characteristics. The network could even acquire the required charactertics (e.g., by assigning bandwidth to the user). The MPTCP stack may start one or more additional subflows that are not immediately used, but are available as "hot standby" for resilience and recovery purposes. PCP can be used to find those additional paths that meet the flow characteristics to handle future failover. Readers are assumed to be familiar with MPTCP and PCP [RFC6887]. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses the terminology defined in MPTCP Architecture [RFC6182], Multipath TCP [RFC6824] andPort Control Protocol [RFC6887]. Wing, et al. Expires April 10, 2014 [Page 3] Internet-Draft MPTCP Path Selection using PCP October 2013 3. MPTCP stack using PCP This section describes the algorithm a MPTCP stack can use with PCP extensions. The application would signal the flow characteristics to the MPTCP stack. For example, the MPTCP stack would receive an abstract request from the application to provide a low-latency, low- jitter, n-Mbps of upstream bandwidth and m-Mbps of downstream bandwidth service. The MPTCP stack would send PCP flow extension requests to the default router on each interface, receive PCP flow extension responses indicating the network characteristics, and tune the MPTCP stack accordingly to favor certain interfaces over other interfaces. Host +-----------------------------------------+ | | | | | +-------------------------------+ | | | Application | | | +-------------------------------+ | | ^ | | | | | v | | +---------------+---------------+ | | | MPTCP | PCP Client | | | | stack <------> | | | + - - - - - - - + - - - - - - - + | | | Subflow (TCP) | UDP | | | +-------------------------------+ | | | IP | IP | | | +-------------------------------+ | +-----------------------------------------+ Figure 1: MPTCP stack using PCP The below steps briefly describe how a MPTCP stack uses the PCP FLOWDATA option: 1. The application requests the MPTCP stack to setup a connection towards a server/remote peer. The MPTCP stack discovers all the available interfaces and gathers the source addresses from these interfaces. This includes addresses from different interfaces (in the case of the host having multiple interfaces), or from the same interface (Multihoming), and also confirms that PCP Flow Extensions is supported. Wing, et al. Expires April 10, 2014 [Page 4] Internet-Draft MPTCP Path Selection using PCP October 2013 2. The application signals the required flow characteristics to the MPTCP stack via a API (such as the abstract API described in Appendix A of [RFC6897]). After getting the flow characteristics, the MPTCP stack uses the PCP client to send PCP MAP opcode with FILTER (section 11 of [RFC6887]) and FLOWDATA options (section 3 of [I-D.wing-pcp-flowdata]) to signal the flow characteristics like bandwidth, loss, delay, etc to multiple PCP servers. 3. After receiving the PCP Flow extension responses from multiple PCP servers, the MPTCP stack sorts the source addresses according to the link characteristics. 4. The MPTCP stack picks the source address from the above sorted list and uses the procedures explained in [RFC6824] to send a SYN with MP_CAPABLE flag set to indicate to the server (peer) that this host is MPTCP capable, in order to initiate the primary subflow. 5. If the server supports MPTCP then the stack will either choose to create subsequent subflows using the sorted source address list from step 3 for resiliency purposes, or for use in parallel with the primary subflow to exchange data at a higher throughput. The choice here will likely depend on the stack's interpretation of the application's required flow characteristics. 6. Any changes to the path characteristics that the PCP client receives will be indicated to the MPTCP stack which then may chose to migrate a subflow or consolidate subflows. 7. MPTCP stack can use PCP to communicate with PCP-controlled NAT to learn external IP address, port and adverstise in ADD_ADDR MPTCP option to the remote peer. MPTCP stack can also use PCP to communicate with PCP-controlled firewall to permit incoming TCP connections from the remote peer. +--------+ +-----------+ | +---------- { ISP-A } | App |---+ router | +-----------+ | +---------- { ISP-B } +--------+ App with MPTCP stack PCP server PCP Server and PCP client (ISP A) (ISP B) TCP server ------------------------ | | | Wing, et al. Expires April 10, 2014 [Page 5] Internet-Draft MPTCP Path Selection using PCP October 2013 Address A Address B | | | --------- ---------- | | | | | | | | | | | | | |-PCP MAP + FLOWDATA-------->| | | | | | | | | |--PCP MAP + FLOWDATA------->| | | | | | | |<-SUCCESS-------------------| | | | | | | | | |<-SUCCESS-------------------| | | | | | | | ISP A is the best path indicated by PCP| | | | | | | |------------TCP SYN(MP_CAPABLE)--------------------------->| |<-----------TCP SYN+ACK (MP_CAPABLE)---------------------->| |------------TCP ACK (MP_CAPABLE)-------------------------->| | | | | | | | | | | | Setup additional subflows | | | | | | | | |------------TCP SYN(MP_JOIN)--------------->| | |<-----------TCP SYN+ACK (MP_JOIN)-----------| | |------------TCP ACK (MP_JOIN)-------------->| | | | | | Figure 2: MPTCP stack using PCP 4. Multiple Interfaces An MPTCP session begins similarly to a regular TCP connection. If multiple paths are available, the MPTCP stack can use PCP flow extensions [I-D.wing-pcp-flowdata] to determine the best path. The advantage is PCP can be used to select the most suitable paths instead of having MPTCP stack try out all paths. When a host has multiple interfaces available (for example 3G/4G, WiFi, VPN etc), an MPTCP application or the MPTCP stack can choose the interface for the primary subflow and interfaces for subsequent subflows according to the path characteristics, as discussed in the previous two sections. 4.1. Interface Availability A MPTCP stack using the procedures described in [I-D.deng-mif-api-session-continuity-guide] will be notified whenever existing interfaces become unavailable or new interfaces are available. For example the MPTCP stack implementation in the Linux kernel is aware of the changes in the availability of interfaces and can react accordingly. Wing, et al. Expires April 10, 2014 [Page 6] Internet-Draft MPTCP Path Selection using PCP October 2013 In such cases the MPTCP stack can use PCP to consolidate sublows or migrate an existing subflow, as described below. 4.1.1. consolidate subflows When a new interface is discovered, the MPTCP stack can use PCP flow extensions to determine the link characteristics of the new path. If the new path can provide the required flow characteristics then MPTCP could reduce the number of subflows in use. For example, assume three subflows were in use to meet the application bandwidth demand: the primary path providing bandwidth of 2Mbps, the secondary path providing 1Mbps, and the tertiary paths 2Mbps. If PCP determines that the new path can provide 3Mbps, then one subflow can be set up in the new path and, and some of the subflows can be migrated to this new path and thus reduce the number of subflows by closing the old ones. Other factors like jitter, delay, and loss MAY also be considered in the decision to migrate subflows. 4.1.2. migrating an existing subflow When a existing interface becomes unavailable, the MPTCP stack picks the unused interfaces and uses PCP flow extensions to determine the interfaces which can provide the required flow characteristics. MPTCP stack will follow the previously described steps to pick one or more of the unused interfaces for creating additional subflows. 5. Switch-over It is possible that the characteristics of a link might change over time, and the MPTCP stack might want to move the subflow to a different interface. For example, if a competing high-bandwidth flow has finished, more bandwidth is available for the MPTCP flow; the DSL line rate might have improved (or degraded); the link speed may have been dynamically increased (or decreased). When link quality changes in such a fashion, a PCP server will send PCP response which could carry a FLOWDATA option where the data fields contain different values from the first response. Upon receiving PCP response, the MPTCP stack can tune its behavior (e.g., increase or decrease traffic on the interface that is now more or less favorable). 6. Using MP_PRIO mechanism of MPTCP along with PCP MPTCP has a priority mechanism, MP_PRIO, for setting a path to be backup flow. This allows additional subflows to be set up but not used until no higher priority subflows are available, allowing fast fail-over. The MP_PRIO value of a subflow can be changed during the lifetime of the session. A PCP server could send a notification to the PCP client whenever path characteristics change, thus the PCP Wing, et al. Expires April 10, 2014 [Page 7] Internet-Draft MPTCP Path Selection using PCP October 2013 client can indicate the same to the MPTCP stack which could change the MP_PRIO values for the associated subflow(s) and trigger switch- over appropriately. 7. PCP Instance ID usage in MPTCP flows The instance identifier field in PCP flow extensions would help the PCP server to co-relate multiple subflows that are part of the same MPTCP session. The instance ID can be also be used by the service provider to co-relate all the subflows of a MPTCP session. 8. IANA Considerations None. 9. Security Considerations Security considerations discussed in [RFC6887] are to be taken into account. Security considerations discussed in [RFC6824] are to be taken in to account when creating new TCP subflows. 10. References 10.1. Normative References [I-D.ietf-pcp-proxy] Boucadair, M., Penno, R., and D. Wing, "Port Control Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-04 (work in progress), July 2013. [I-D.wing-pcp-flowdata] Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", draft-wing-pcp-flowdata-00 (work in progress), July 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. Wing, et al. Expires April 10, 2014 [Page 8] Internet-Draft MPTCP Path Selection using PCP October 2013 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, March 2013. 10.2. Informative References [I-D.deng-mif-api-session-continuity-guide] Deng, H., Krishnan, S., Lemon, T., and M. Wasserman, "Guide for application developers on session continuity by using MIF API", draft-deng-mif-api-session-continuity- guide-03 (work in progress), October 2012. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011. [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011. Authors' Addresses Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA Email: dwing@cisco.com Wing, et al. Expires April 10, 2014 [Page 9] Internet-Draft MPTCP Path Selection using PCP October 2013 Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: rmohanr@cisco.com Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Alan Ford Unaffiliated Email: alan.ford@gmail.com Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose 95134 USA Email: repenno@cisco.com Wing, et al. Expires April 10, 2014 [Page 10]