One document matched: draft-baker-tsvwg-aqm-recommendation-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as <29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC 
         if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="bcp" docName="draft-baker-tsvwg-aqm-recommendation-00"
     ipr="trust200902" updates="2309">
  <front>
    <title abbrev="AQM Recommendations">IETF Recommendations Regarding Active
    Queue Management</title>

    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization>Cisco Systems</organization>

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

          <city>Santa Barbara</city>

          <code>93117</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <email>fred@cisco.com</email>
      </address>
    </author>

    <date year="2013" />

    <area>Internet Engineering Task Force</area>

    <workgroup></workgroup>

    <abstract>
      <t>Fifteen years after the IAB issued its recommendations regarding
      congestion control in RFC 2309, a major issue in the community is the
      issue that RFC addresses: Buffer bloat. It may be time to update the
      recommendation.</t>
    </abstract>

    <note title="Note to IESG">
      <t>RFC Editor: this note should be removed on publication.</t>

      <t>IESG: RFC 2309 is an IAB Recommendation, but is an Informational
      document rather than BCP. Since this document targets BCP status, idnits
      considers the normative reference to it as a down-reference. In the
      opinion of the author, both it and this document should be BCPs. Please
      adjust the status of RFC 2309.</t>
    </note>

    <!--
      <texttable anchor="table_example" title="A Very Simple Table">
      <preamble>Tables use ttcol to define column headers and widths.
      Every cell then has a "c" element for its content.</preamble>
          <ttcol align="center">ttcol #1</ttcol>
                                    <ttcol align="center">ttcol #2</ttcol>
                      <c>c #1</c>		<c>c #2</c>
                      <c>c #3</c>		<c>c #4</c>
                      <c>c #5</c>		<c>c #6</c>
      <postamble>which is a very simple example.</postamble>
      </texttable>
    -->
  </front>

  <middle>
    <!--		
      <t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
      <t>
	<list style="symbols">
	    <t>First bullet</t>
	    <t>Second bullet</t>
	</list>
     </t>
-->

    <!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
	ASCII artwork goes here... 
]]>
</artwork>
</figure>
-->

    <section title="Introduction">
      <t>Active Queue Management (AQM) procedures are a class of procedures
      that are used to manage queue depth. Every queue in a network is finite,
      if for no other reason because even virtual memory is finite. Tail-drop
      queue management procedures are widely implemented and well known for
      their issues; since common congestion control algorithms used in <xref
      target="RFC0793">TCP</xref> attempt to maximize the amount of data the
      keep outstanding (to maximize bandwidth usage), the effect of "fill the
      queue until it is full and then drop something" is to fill network
      queues, maximizing both end to end delay and variation in delay. AQM
      procedures have been developed as a means of signaling earlier, enabling
      the network to keep its buffers relatively empty and available to store
      large bursts of data momentarily in the normal case.</t>

      <t>There are a number of AQM procedures in the literature. The
      prototypical one is Random Early Detection (RED). Other alternatives
      include Blue, Adaptive Virtual Queue (AVQ), Controlling Queue Delay
      (Codel), Proportional Integral controller Enhanced (PIE), and no doubt a
      variety of others. This document makes no recommendation on those
      procedures per se; if an operator or implementor finds one useful, they
      should use it. This document does, however, attempt to give guidance on
      how such a choice might be made.</t>

      <t>The question is how best, and where best, to use them.</t>

      <section 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"></xref>.</t>
      </section>
    </section>

    <section anchor="recommendations" title="Specific Recommendations">
      <t>The IETF, in discussion, has developed a set of specific
      recommendations regarding the implementation and operational use of AQM
      procedures. These include:<list style="numbers">
          <t>Operational deployments SHOULD use AQM procedures.</t>

          <t>Deployed AQM SHOULD use ECN as well as loss, and set thresholds
          to mark traffic earlier than it is lost.</t>

          <t>AQM algorithms deployed SHOULD NOT require operational
          (especially manual) tuning.</t>

          <t>AQM algorithms deployed SHOULD be effective on all common
          Internet traffic, including traffic that uses TCP, SCTP, UDP, and
          DCCP as transports.</t>

          <t>TCP and SCTP congestion control algorithms SHOULD maximize their
          use of available bandwidth without incurring loss or undue round
          trip delay when possible.</t>
        </list></t>

      <section anchor="useAQM"
               title="Operational deployments SHOULD use AQM procedures">
        <t>This is the recommendation of <xref target="RFC2309"></xref>, which
        is recomended reading. In short, AQM procedures are designed to
        minimize delay induced in the network by queues which have filled due
        to the behavior of hosts trying to send data to other hosts. Marking
        and loss behaviors signal to the senders of data that network buffers
        are becoming unnecessarily full, and they would do well to moderate
        their behavior.</t>
      </section>

      <section anchor="signaling"
               title="Signaling to the endpoints of a session">
        <t>Means of signaling to an endpoint regarding its effect on the
        network and how it might consider adapting include, at least: <list
            style="symbols">
            <t>Delaying data segments in flight, such as in a queue, which
            affects Ack Clocking and as a result the transmission of new
            data.</t>

            <t>Marking traffic, such as using Explicit Congestion Control<xref
            target="RFC3168"></xref> <xref target="RFC4301"></xref> <xref
            target="RFC4774"></xref> <xref target="RFC6040"></xref></t>

            <t>Dropping traffic in transit.</t>
          </list></t>

        <t>The use of advanced scheduling mechanisms, such as priority
        queuing, classful queuing, and fair queuing, is often effective in
        networks to help a network to serve the needs of an application. It
        can be used to manage traffic passing a choke point. This is discussed
        in <xref target="RFC2474"></xref> and <xref target="RFC2475"></xref>.
        They are used operationally when an operator considers it important to
        do so.</t>

        <t>Loss has two effects. It protects the network, which is the primary
        reason the network imposes it. Its use as a signal to TCP or SCTP is a
        pragmatic heuristic; "when the network discards a message in flight,
        it may imply the presence of faulty equipment or media in a path, and
        it may imply the presence of congestion. Presume the latter." However,
        it also has an effect on the efficiency of the data flow. The data in
        question must be retransmitted, or its absence must otherwise be
        adapted to by the application in question, which implies at least
        inefficient use of available bandwidth and may affect other data
        flows. Hence, loss is not entirely positive; it is a necessary
        evil.</t>

        <t>Explicit Congestion Control, however, communicates information
        about network congestion that is assuredly about congestion, and
        avoids the unintended consequences of loss.</t>

        <t>Hence, network communication to the host regarding the moderation
        of its traffic flow SHOULD include both ECN and loss, with ECN being
        triggered earlier than loss. In this way, congestion control can be
        achieved in the general case without loss, and loss remains the backup
        when needed.</t>
      </section>

      <section anchor="autotuning"
               title="AQM algorithms deployed SHOULD NOT require operational tuning">
        <t>A number of algorithms have been proposed. Many require some form
        of tuning or initial condition, which makes them difficult to use
        operationally. Hence, self-tuning algorithms are to be preferred.</t>
      </section>

      <section anchor="alltraffic"
               title="AQM algorithms deployed SHOULD be effective on all common Internet traffic">
        <t>AQM algorithms often target <xref target="RFC0793">TCP</xref>, as
        it is by far the predominant transport in the Internet today. However,
        we have significant use of <xref target="RFC0768">UDP</xref> in voice
        and video services, and find utility in <xref
        target="RFC4960">SCTP</xref> and <xref target="RFC4340"> DCCP </xref>.
        Hence, AQM algorithms that are effective with all of those transports
        and the applications that use them are to be preferred.</t>
      </section>

      <section anchor="tcpcc"
               title="TCP and SCTP congestion control algorithms SHOULD maximize their use of available bandwidth without incurring loss or undue round trip delay">
        <t>The terms "knee" and "cliff" area defined by <xref
        target="JAIN"></xref>. They respectively refer to the minimum and
        maximum values of the effective window that have the effect of
        maximizing transmission rate in a congestion control algorithm such as
        is used by TCP or SCTP. For the sender of data, exceeding the cliff is
        ineffective, as it (by definition) induces loss; operating at a point
        close to the cliff has a negative impact on other traffic and
        applications, triggering operator activities such as discussed in
        <xref target="RFC6057"></xref>.</t>

        <t>Operating below the knee is also ineffective, as it fails to use
        available network capacity. If the objective is to deliver data from
        its source to its recipient in the least possible time, as a result,
        the behavior of any TCP/SCTP congestion control algorithm SHOULD be to
        seek and use effective window values at or above the knee and well
        below the cliff.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo asks the IANA for no new parameters.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document, by itself, presents no new security issues.</t>

      <section anchor="Privacy" title="Privacy Considerations">
        <t>This document, by itself, presents no new privacy issues.</t>
      </section>
    </section>

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

    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="Initial Version:">March 2013</t>
        </list></t>
    </section>
  </middle>

  <back>
    <!-- references split to informative and normative -->

    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2309"?>

      <?rfc include="reference.RFC.3168" ?>

      <?rfc include="reference.RFC.4301" ?>

      <?rfc include="reference.RFC.4774" ?>

      <?rfc include="reference.RFC.6040" ?>
    </references>

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

      <?rfc include="reference.RFC.0793" ?>

      <?rfc include="reference.RFC.2474" ?>

      <?rfc include="reference.RFC.2475" ?>

      <?rfc include="reference.RFC.4340" ?>

      <?rfc include="reference.RFC.4960" ?>

      <?rfc include="reference.RFC.6057" ?>

      <reference anchor="JAIN">
        <front>
          <title>Congestion avoidance scheme for computer networks</title>

          <author fullname="Rajendra K. Jain" initials="Raj" surname="Jain">
            <organization>Digital Equipment Corporation</organization>
          </author>

          <author fullname="KK Ramakrishnan" initials="KK"
                  surname="Ramakrishnan">
            <organization>Digital Equipment Corporation</organization>
          </author>

          <author fullname="Chiu Dah-Ming" initials="Chiu" surname="Dah-Ming">
            <organization>Digital Equipment Corporation</organization>
          </author>

          <date day="27" month="December" year="1994" />
        </front>

        <seriesInfo name="US Patent Office" value="5377327" />
      </reference>
    </references>
  </back>
</rfc>