One document matched: draft-boucadair-mptcp-max-subflow-02.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-02"
     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 option mainly targets 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 in other deployment scenarios. It is out of scope of this
      document to identify what are 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 optimize 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>The MP_MAXSUBFLOW option (<xref target="fig"></xref>) follows the
      shared experimental format defined in <xref
      target="I-D.ietf-mptcp-rfc6824bis"></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 |
      +---------------+---------------+-------+-------+---------------+
      |                        Maximum Subflows                       |
      +---------------+-----------------------------------------------+
]]></artwork>
        </figure>The meaning of "Kind", "Length", "Subtype", and "Flags"
      (especially 'S' and 'U' flags) are exactly the same as defined in
      Section 3.7 of <xref target="I-D.ietf-mptcp-rfc6824bis"></xref>.</t>

      <t>Experiment ID MUST be set to 0xAA (see <xref
      target="iana"></xref>).</t>

      <t>The "Maximum Subflows" field indicates the maximum number of
      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 MP_MAXSUBFLOW option 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>How an MPTCP endpoint determines the maximum number of concurrent
      subflows it supports (i.e., the value it indicates in an MP_MAXSUBFLOW
      option) is implementation-specific. For example, an implementation may
      support a configuration parameter and/or use a default value.</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>

      <t>Establishing a large number of subflows may exhaust the resources of
      an MPTCP implementation (especially, MPTCP servers). MPTCP
      implementations SHOULD rate-limit the number of concurrent subflows per
      MPTCP connection. This policy is meant to prevent DoS attacks that would
      result in creating additional subflows to exhaust the remote peer
      resources (typically, an MPTCP server).</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document uses the experiment Id (0xAA). This Id is not
      registered yet given that no registry is maintained by IANA for this
      purpose.</t>
    </section>
  </middle>

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

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

      <?rfc include='reference.I-D.ietf-mptcp-rfc6824bis'?>
    </references>

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

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

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