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 October 13, 2013.

Copyright Notice

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

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

1. Introduction

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.
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:

• Delaying data segments in flight, such as in a queue, which affects Ack Clocking and as a result the transmission of new data.
• Marking traffic, such as using Explicit Congestion Control[RFC3168] [RFC4301] [RFC4774] [RFC6040]
• 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.

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

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

7.2. Informative References

Author's Address