<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wing-mptcp-pcp-00" ipr="trust200902">
  <front>
    <title abbrev="MPTCP Path Selection using PCP">Multipath TCP (MPTCP) Path
    Selection using PCP</title>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Ram Mohan Ravindranath" initials="R."
            surname="Ravindranath">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park,</street>

          <street>Kadabeesanahalli Village, Varthur Hobli,</street>

          <street>Sarjapur-Marathahalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>rmohanr@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Alan Ford" initials="A." surname="Ford">
      <organization>Unaffiliated</organization>
<address>
        <email>alan.ford@gmail.com</email>
      </address>
    </author>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region/>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone/>

        <email>repenno@cisco.com</email>

        <uri/>
      </address>
    </author>

    <date/>

    <workgroup>MPTCP</workgroup>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Multipath Transmission Control Protocol (MPTCP) <xref
      target="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.</t>

      <t>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 <xref
      target="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.</t>

      <t>The MPTCP API document <xref target="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
      <xref target="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.</t>

      <t>This draft defines the on-the-wire protocol for such an advanced
      MPTCP API. It uses PCP flow extensions <xref
      target="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.</t>

      <t>Readers are assumed to be familiar with MPTCP and PCP <xref
      target="RFC6887"/>.</t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <t>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 <xref
      target="RFC2119"/>.</t>

      <t>This document uses the terminology defined in <xref
      target="RFC6182">MPTCP Architecture</xref>, <xref
      target="RFC6824">Multipath TCP</xref> and<xref target="RFC6887"> Port
      Control Protocol</xref>.</t>
    </section>

    <section anchor="mptcp5" title="MPTCP stack using PCP">
      <t>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.</t>

      <figure anchor="figure_mptcp_pcp_host1" title="MPTCP stack using PCP">
        <artwork align="center"><![CDATA[
                    Host  
  +-----------------------------------------+
  |                                         |
  |                                         | 
  |   +-------------------------------+     |
  |   |           Application         |     |
  |   +-------------------------------+     |
  |         ^                               |
  |         |                               |
  |         v                               |
  |   +---------------+---------------+     |
  |   |   MPTCP       | PCP Client    |     |
  |   |   stack   <------>            |     |
  |   + - - - - - - - + - - - - - - - +     |
  |   | Subflow (TCP) | UDP           |     |
  |   +-------------------------------+     |
  |   |       IP      |      IP       |     |
  |   +-------------------------------+     |
  +-----------------------------------------+

]]></artwork>
      </figure>

      <t>The below steps briefly describe how a MPTCP stack uses the PCP
      FLOWDATA option:</t>

      <t><list style="numbers">
          <t>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.</t>

          <t>The application signals the required flow characteristics to the
          MPTCP stack via a API (such as the abstract API described in
          Appendix A of <xref target="RFC6897"/>). After getting the flow
          characteristics, the MPTCP stack uses the PCP client to send PCP MAP
          opcode with FILTER (section 11 of <xref target="RFC6887"/>) and
          FLOWDATA options (section 3 of <xref target="I-D.wing-pcp-flowdata">
          </xref>) to signal the flow characteristics like bandwidth, loss,
          delay, etc to multiple PCP servers.</t>

          <t>After receiving the PCP Flow extension responses from multiple
          PCP servers, the MPTCP stack sorts the source addresses according to
          the link characteristics.</t>

          <t>The MPTCP stack picks the source address from the above sorted
          list and uses the procedures explained in <xref target="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.</t>

          <t>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.</t>

          <t>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.</t>

          <t>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.</t>
        </list></t>

      <figure anchor="figure_mptcp_pcp_flow1" title="MPTCP stack using PCP">
        <artwork align="center"><![CDATA[

                         +--------+
+-----------+            |        +---------- { ISP-A }
| App       |-<network>--+ router |
+-----------+            |        +---------- { ISP-B }
                         +--------+
 
 

  App with MPTCP stack      PCP server      PCP Server 
       and PCP client         (ISP A)         (ISP B)      TCP server
 ------------------------       |              |               |
 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)-------------->|
   |              |             |              |               | 
     ]]></artwork>
      </figure>
    </section>

    <section anchor="mif" title="Multiple Interfaces">
      <t>An MPTCP session begins similarly to a regular TCP connection. If
      multiple paths are available, the MPTCP stack can use PCP flow
      extensions <xref target="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.</t>

      <section anchor="mif2" title="Interface Availability">
        <t>A MPTCP stack using the procedures described in <xref
        target="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.</t>

        <t>In such cases the MPTCP stack can use PCP to consolidate sublows or
        migrate an existing subflow, as described below.</t>

        <section anchor="mif3" title="consolidate subflows">
          <t>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.</t>
        </section>

        <section anchor="mif4" title="migrating an existing subflow">
          <t>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.</t>
        </section>
      </section>
    </section>

    <section anchor="mptcp2" title="Switch-over">
      <t>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).</t>
    </section>

    <section anchor="mptcp3"
             title="Using MP_PRIO mechanism of MPTCP along with PCP">
      <t>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 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.</t>
    </section>

    <section anchor="mptcp4" title="PCP Instance ID usage in MPTCP flows">
      <t>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.</t>
    </section>

    <section title="IANA Considerations">
      <t>None.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6887"/> are to
      be taken into account. </t>

      <t>Security considerations discussed in <xref target="RFC6824"/> are to
      be taken in to account when creating new TCP subflows.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.5245"?>

      <?rfc include="reference.RFC.6724"?>

      <?rfc include="reference.RFC.6824"?>

      <?rfc include='reference.I-D.ietf-pcp-proxy'
?>

      <?rfc include='reference.I-D.wing-pcp-flowdata'  ?>

      <?rfc include="reference.RFC.6897"?>

      <?rfc include='reference.RFC.6182'
?>

      <?rfc include='reference.RFC.6887'
?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.6296'?>

      <?rfc include='reference.RFC.6356'
?>

      <?rfc include='reference.I-D.deng-mif-api-session-continuity-guide'?>

      <!---->
    </references>
  </back>
</rfc>
