Multipath TCP (MPTCP) Path Selection using PCP
draft-wing-mptcp-pcp-00

Versions: 00                                                            
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       |-<network>--+ 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]