One document matched: draft-boucadair-mptcp-max-subflow-01.xml

<?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-max-subflow-01"
     ipr="trust200902">
  <front>
    <title abbrev="MPTCP Maximum Subflows">Negotiating the Maximum Number of
    Multipath TCP (MPTCP) Subflows</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</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>Orange</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 experimental Multipath TCP (MPTCP) option
      that is meant to negotiate the maximum number of subflows that can be
      established and maintained for a given MPTCP connection. The purpose is
      to minimize any possible performance degradation that can be induced by
      a possibly large number of establishment requests for additional
      subflows if the remote endpoint is not appropriately dimensioned to
      handle such requests.</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 a Multipath TCP (MPTCP, <xref
      target="RFC6824"></xref>) option that is meant to indicate to a remote
      peer the maximum number of subflows that can be established within a
      single MPTCP connection. If the remote peer honors the indication
      provided in this option, any performance degradation induced by a
      possibly abusive setup of additional subflows that exceed the said
      maximum becomes unlikely.</t>

      <t>This document adheres to <xref
      target="I-D.bonaventure-mptcp-exp-option"></xref>.</t>

      <t>This option targets mainly MPTCP deployments within a single
      administrative domain such as those MPTCP designs meant to achieve
      load-balancing, for example. The use of this option contributes to the
      harmonization of node configuration within an administrative domain, so
      that an optimal number of subflows is maintained by involved nodes
      independently of their actual performance capabilities. This option can
      be used for other deployment scenarios. It is out of scope of this
      document to identify an exhaustive list of such scenarios.</t>

      <t>Section 3.4 of <xref target="I-D.ietf-mptcp-experience"></xref>
      includes a discussion on the MPTCP session manager issues</t>

      <section title="Experiment Goals">
        <t>Experiments based upon the MPTCP option described in this document
        are meant to help operators refine their MPTCP design and operational
        procedures, by tweaking some MPTCP parameters such as the number of
        subflows to be associated with a given MPTCP connection. Experimenting
        with this MPTCP option should also help assess whether this option can
        be used to propagate MPTCP-related optimization parameters (derived
        from the number of concurrent subflows associated to each MPTCP
        connection) that can be configured in a node that is responsible for
        aggregating MPTCP connections established with upstream nodes.</t>
      </section>
    </section>

    <section anchor="option"
             title="Maximum Subflows MPTCP Option (MP_MAXSUBFLOW)">
      <t>This option follows the shared experimental format defined in <xref
      target="I-D.bonaventure-mptcp-exp-option"></xref> (see <xref
      target="fig"></xref>).</t>

      <t><figure align="center" anchor="fig" title="Option Format">
          <artwork><![CDATA[                           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     |Subtype| Flags |  Experiment   |
      +---------------+---------------+-------+-------+---------------+
      | Id. (16 bits) |              Maximum Sub-Flows                |
      +---------------+-----------------------------------------------+
]]></artwork>
        </figure>The meaning of "Kind", "Length", "Subtype", and "Flags"
      (especially 'S' and 'U' flags) are exactly the same as defined in <xref
      target="I-D.bonaventure-mptcp-exp-option"></xref>.</t>

      <t>Experiment ID (to be assigned, see <xref target="iana"></xref>).</t>

      <t>The "Maximum Sub-Flows" field indicates the number of maximum
      concurrent subflows that can be maintained by a given MPTCP endpoint for
      each MPTCP connection established by or with this endpoint. The value of
      this field MUST be strictly greater than zero.</t>
    </section>

    <section title="Behavior">
      <t>The option defined in <xref target="option"></xref> MAY be used by a
      TCP endpoint to indicate to its corresponding peer the maximum number of
      subflows that it can maintain per MPTCP connection.</t>

      <t>If two peers (T1 and T2) indicate the maximum number of concurrent
      subflows per connection they can maintain, then they MUST NOT maintain
      more than "MIN(MAX_SUBFLOW(T1), MAX_SUBFLOW(T2))" concurrent
      subflows.</t>

      <t>The absence of the MP_MAXSUBFLOW option in an MPTCP control message
      issued by a MPTCP endpoint is an indication that this endpoint can
      instantiate any number of subflows per MPTCP connection.</t>
    </section>

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

    <section anchor="iana" title="IANA Considerations">
      <t>This document requests IANA to assign an experiment ID for
      MP_MAXSUBFLOW as per <xref
      target="I-D.bonaventure-mptcp-exp-option"></xref>.</t>
    </section>
  </middle>

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

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

      <?rfc include='reference.I-D.bonaventure-mptcp-exp-option'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.7430"?>

      <?rfc include='reference.I-D.ietf-mptcp-experience'?>

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