[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-baker-aqm-recommendation

Network Working Group                                         F.J. Baker
Internet-Draft                                             Cisco Systems
Updates: 2309 (if approved)                               March 13, 2013
Intended status: Best Current Practice
Expires: September 14, 2013


         IETF Recommendations Regarding Active Queue Management
                draft-baker-tsvwg-aqm-recommendation-00

Abstract

   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.

Note to IESG

   RFC Editor: this note should be removed on publication.

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Baker                  Expires September 14, 2013               [Page 1]


Internet-Draft            AQM Recommendations                 March 2013


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Specific Recommendations  . . . . . . . . . . . . . . . . . .   3
     2.1.  Operational deployments SHOULD use AQM procedures . . . .   4
     2.2.  Signaling to the endpoints of a session . . . . . . . . .   4
     2.3.  AQM algorithms deployed SHOULD NOT require operational
           tuning  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  AQM algorithms deployed SHOULD be effective on all common
           Internet traffic  . . . . . . . . . . . . . . . . . . . .   5
     2.5.  TCP and SCTP congestion control algorithms SHOULD
           maximize their use of available bandwidth without
           incurring loss or undue round trip delay  . . . . . . . .   5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     4.1.  Privacy Considerations  . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction
















Baker                  Expires September 14, 2013               [Page 2]


Internet-Draft            AQM Recommendations                 March 2013


   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 TCP [RFC0793] 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.

   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.

   The question is how best, and where best, to use them.

1.1.  Requirements Language

   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 [RFC2119].

2.  Specific Recommendations

   The IETF, in discussion, has developed a set of specific
   recommendations regarding the implementation and operational use of
   AQM procedures.  These include:

   1.  Operational deployments SHOULD use AQM procedures.

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

   3.  AQM algorithms deployed SHOULD NOT require operational
       (especially manual) tuning.

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



Baker                  Expires September 14, 2013               [Page 3]


Internet-Draft            AQM Recommendations                 March 2013


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

2.1.  Operational deployments SHOULD use AQM procedures

   This is the recommendation of [RFC2309], 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.

2.2.  Signaling to the endpoints of a session

   Means of signaling to an endpoint regarding its effect on the network
   and how it might consider adapting include, at least:

   o  Delaying data segments in flight, such as in a queue, which
      affects Ack Clocking and as a result the transmission of new data.

   o  Marking traffic, such as using Explicit Congestion
      Control[RFC3168] [RFC4301] [RFC4774] [RFC6040]

   o  Dropping traffic in transit.

   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
   [RFC2474] and [RFC2475].  They are used operationally when an
   operator considers it important to do so.

   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.






Baker                  Expires September 14, 2013               [Page 4]


Internet-Draft            AQM Recommendations                 March 2013


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

   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.

2.3.  AQM algorithms deployed SHOULD NOT require operational tuning

   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.

2.4.  AQM algorithms deployed SHOULD be effective on all common Internet
      traffic

   AQM algorithms often target TCP [RFC0793], as it is by far the
   predominant transport in the Internet today.  However, we have
   significant use of UDP [RFC0768] in voice and video services, and
   find utility in SCTP [RFC4960] and DCCP [RFC4340].  Hence, AQM
   algorithms that are effective with all of those transports and the
   applications that use them are to be preferred.

2.5.  TCP and SCTP congestion control algorithms SHOULD maximize their
      use of available bandwidth without incurring loss or undue round
      trip delay

   The terms "knee" and "cliff" area defined by [JAIN].  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 [RFC6057].

   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.

3.  IANA Considerations




Baker                  Expires September 14, 2013               [Page 5]


Internet-Draft            AQM Recommendations                 March 2013


   This memo asks the IANA for no new parameters.

4.  Security Considerations

   This document, by itself, presents no new security issues.

4.1.  Privacy Considerations

   This document, by itself, presents no new privacy issues.

5.  Acknowledgements

6.  Change Log

   Initial Version:  March 2013

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2309]  Braden, B., Clark, D.D., Crowcroft, J., Davie, B.,
              Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
              Minshall, G., Partridge, C., Peterson, L., Ramakrishnan,
              K.K., Shenker, S., Wroclawski, J., and L. Zhang,
              "Recommendations on Queue Management and Congestion
              Avoidance in the Internet", RFC 2309, April 1998.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP", RFC
              3168, September 2001.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4774]  Floyd, S., "Specifying Alternate Semantics for the
              Explicit Congestion Notification (ECN) Field", BCP 124,
              RFC 4774, November 2006.

   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
              Notification", RFC 6040, November 2010.

7.2.  Informative References






Baker                  Expires September 14, 2013               [Page 6]


Internet-Draft            AQM Recommendations                 March 2013


   [JAIN]     Jain, Raj., Ramakrishnan, KK., and Chiu. Dah-Ming,
              "Congestion avoidance scheme for computer networks", US
              Patent Office 5377327, December 1994.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D.L. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
              1998.

   [RFC2475]  Blake, S., Black, D.L., Carlson, M.A., Davies, E., Wang,
              Z., and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC6057]  Bastian, C., Klieber, T., Livingood, J., Mills, J., and R.
              Woundy, "Comcast's Protocol-Agnostic Congestion Management
              System", RFC 6057, December 2010.

Author's Address

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com













Baker                  Expires September 14, 2013               [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/