One document matched: draft-boucadair-mptcp-extensions-00.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-extensions-00"
     ipr="trust200902">
  <front>
    <title abbrev="MPTCP Maximum Subflows">Negotiating the Maximum Number of
    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 experimental 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 appropriateley 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 MPTCP 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>

      <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">
      <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> is 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 this 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>

      <t>If no maximum number of subflows is configured locally to an MPTCP
      endpoint, it may rely on the results of procedures such as <xref
      target="I-D.boucadair-mptcp-connectivity-checks"></xref> as a hint to
      determine the value to include in the "Maximum Sub-Flows" MPTCP
      option.</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 requests IANA to assign an experiment ID as per <xref
      target="I-D.bonaventure-mptcp-exp-option"></xref>.</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'?>

      <reference anchor="I-D.bonaventure-mptcp-exp-option">
        <front>
          <title>Experimental Multipath TCP option</title>

          <author fullname="Olivier Bonaventure " initials="O."
                  surname="Bonaventure ">
            <organization></organization>
          </author>

          <author fullname="Benjamin Hesmans" initials="B." surname="Hesmans">
            <organization></organization>

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

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

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date year="1992" />
        </front>
      </reference>
    </references>

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

      <?rfc include='reference.I-D.boucadair-mptcp-connectivity-checks'?>

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