<?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="exp" docName="draft-boucadair-mptcp-probe-subflow-00"
     ipr="trust200902" updates="6824">
  <front>
    <title abbrev="MPTCP Probing">Probing MPTCP Subflows</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>This document specifies an extension to Multipath TCP (MPTCP) that is
      meant to assess whether a path used to establish a given subflow is
      MPTCP-friendly, i.e., intermediate nodes involved in that path do not
      alter nor strip MPTCP options, which would prevent the establishment of
      MPTCP communications along that path. A new flag bit, called Probe Flag
      (P-flag) is defined for this purpose.</t>

      <t>This document updates RFC6824.</t>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>This document specifies an extension to Multipath TCP (MPTCP, <xref
      target="RFC6824"></xref>) that is meant to assess whether a path used to
      establish a given subflow is MPTCP-friendly. That is, intermediate nodes
      involved in that path do not alter nor strip MPTCP options, which would
      prevent the establishment of MPTCP communications along that path.</t>

      <t>The problem is summarized briefly in <xref target="pb"></xref> while
      the probe flag is defined in <xref target="sol"></xref>.</t>

      <t>The solution proposed in this document allows to anticipate failures
      due to the presence of MPTCP-unfriendly devices in the communication
      paths.</t>
    </section>

    <section anchor="pb" title="The Problem">
      <t>MPTCP supports a backup mode that relies on a dedicated flag, called
      backup flag carried in the MP_JOIN option: when set, this flag informs
      the remote peer that this is a backup subflow. Several problems may be
      arise such as. For example:</t>

      <t><list style="symbols">
          <t>A peer decides to use a backup subflow but MPTCP cannot be used
          for that subflow because an intermediate function removes DSS
          options, for example. This failure will have a negative impact on
          the quality of experience.</t>

          <t>Several subflows can be candidate to be used as backup but the
          participating nodes do not know in advance whether associated
          forwarding paths are MPTCP-friendly, i.e., they can actually support
          MPTCP subflows. The participating nodes need some "hints" to decide
          which subflows are to be used as regular ones and those as backup.
          This lack of information may also affect the perceived quality of
          experience.</t>
        </list></t>
    </section>

    <section anchor="sol" title="Probe Flag (P-flag)">
      <t>As a solution to the problem described in <xref target="pb"></xref>,
      a meaning is associated with one of the reserved bits in MP_JOIN. This
      new flag bit is called: Probe Flag (P-flag). This flag bit is used to
      explicitly inform the remote peer that a probing procedure is associated
      with the corresponding subflow.</t>

      <t><xref target="fig1"></xref> and <xref target="fig2"></xref> show the
      required update to the MP_JOIN option format in SYN and SYN/ACK.</t>

      <t><figure anchor="fig1"
          title="Join Connection (MP_JOIN) Option (for Initial SYN)">
          <artwork><![CDATA[OLD: 

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+---------------+-------+-----+-+---------------+
      |     Kind      |  Length = 12  |Subtype|     |B|   Address ID  |
      +---------------+---------------+-------+-----+-+---------------+
      |                   Receiver's Token (32 bits)                  |
      +---------------------------------------------------------------+
      |                Sender's Random Number (32 bits)               |
      +---------------------------------------------------------------+

NEW:
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+---------------+-------+-+-+-+-+---------------+
      |     Kind      |  Length = 12  |Subtype|r|r|P|B|   Address ID  |
      +---------------+---------------+-------+-+-+-+-+---------------+
      |                   Receiver's Token (32 bits)                  |
      +---------------------------------------------------------------+
      |                Sender's Random Number (32 bits)               |
      +---------------------------------------------------------------+

      where "rr" are reserved bits for future assignment as
      additional flag bits. r bits MUST each be sent as zero and MUST be
      ignored on receipt.   

]]></artwork>
        </figure><figure anchor="fig2"
          title="Join Connection (MP_JOIN) Option (for Responding SYN/ACK)">
          <artwork><![CDATA[OLD:
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+---------------+-------+-----+-+---------------+
      |     Kind      |  Length = 16  |Subtype|     |B|   Address ID  |
      +---------------+---------------+-------+-----+-+---------------+
      |                                                               |
      |                Sender's Truncated HMAC (64 bits)              |
      |                                                               |
      +---------------------------------------------------------------+
      |                Sender's Random Number (32 bits)               |
      +---------------------------------------------------------------+

NEW:
                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+---------------+-------+-+-+-+-+---------------+
      |     Kind      |  Length = 16  |Subtype|r|r|P|B|   Address ID  |
      +---------------+---------------+-------+-+-+-+-+---------------+
      |                                                               |
      |                Sender's Truncated HMAC (64 bits)              |
      |                                                               |
      +---------------------------------------------------------------+
      |                Sender's Random Number (32 bits)               |
      +---------------------------------------------------------------+

      where "rr" are reserved bits for future assignment as
      additional flag bits. r bits MUST each be sent as zero and MUST be
      ignored on receipt. 

]]></artwork>
        </figure></t>

      <t>When set, the P-Flag bit indicates to the remote peer that a probing
      is associated with this subflow. The probing logic is to be further
      defined in future versions of this specification. Only probing data MUST
      be sent over a subflow that is tagged to be under probing. Probing MUST
      NOT interfere with data exchange over regular subflows, if any.</t>

      <t>An MPTCP endpoint that receives an MP_JOIN with a P-flag set, MUST
      echo the P-flag in the SYN/ACK if it supports the probing mechanism. If
      not, the P-flag MUST be ignored (i.e., the P-flag of the MP_JOIN
      included in the SYN/ACK must be set to 0).</t>

      <t>P-flag can be set independently of the backup flag.</t>

      <t>The handling of the B flag when P-flag is also set, is not altered by
      this specification.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>MPTCP-related security considerations are documented in <xref
      target="RFC6824"></xref> and <xref
      target="I-D.ietf-mptcp-attacks"></xref>.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBC</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.6824'?>

      <?rfc include='reference.RFC.2119'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-mptcp-attacks"?>

      <!---->
    </references>
  </back>
</rfc>
