Internet DRAFT - draft-baker-tsvwg-aqm-recommendation
draft-baker-tsvwg-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]
