draft-ietf-aqm-recommendation-10.txt   draft-ietf-aqm-recommendation-11.txt 
Network Working Group F. Baker, Ed. Network Working Group F. Baker, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 2309 (if approved) G. Fairhurst, Ed. Obsoletes: 2309 (if approved) G. Fairhurst, Ed.
Intended status: Best Current Practice University of Aberdeen Intended status: Best Current Practice University of Aberdeen
Expires: August 27, 2015 February 23, 2015 Expires: August 29, 2015 February 25, 2015
IETF Recommendations Regarding Active Queue Management IETF Recommendations Regarding Active Queue Management
draft-ietf-aqm-recommendation-10 draft-ietf-aqm-recommendation-11
Abstract Abstract
This memo presents recommendations to the Internet community This memo presents recommendations to the Internet community
concerning measures to improve and preserve Internet performance. It concerning measures to improve and preserve Internet performance. It
presents a strong recommendation for testing, standardization, and presents a strong recommendation for testing, standardization, and
widespread deployment of active queue management (AQM) in network widespread deployment of active queue management (AQM) in network
devices, to improve the performance of today's Internet. It also devices, to improve the performance of today's Internet. It also
urges a concerted effort of research, measurement, and ultimate urges a concerted effort of research, measurement, and ultimate
deployment of AQM mechanisms to protect the Internet from flows that deployment of AQM mechanisms to protect the Internet from flows that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2015. This Internet-Draft will expire on August 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. The Need For Active Queue Management . . . . . . . . . . . . 6 2. The Need For Active Queue Management . . . . . . . . . . . . 6
2.1. AQM and Multiple Queues . . . . . . . . . . . . . . . . . 10 2.1. AQM and Multiple Queues . . . . . . . . . . . . . . . . . 10
2.2. AQM and Explicit Congestion Marking (ECN) . . . . . . . . 10 2.2. AQM and Explicit Congestion Marking (ECN) . . . . . . . . 10
2.3. AQM and Buffer Size . . . . . . . . . . . . . . . . . . . 11 2.3. AQM and Buffer Size . . . . . . . . . . . . . . . . . . . 11
3. Managing Aggressive Flows . . . . . . . . . . . . . . . . . . 11 3. Managing Aggressive Flows . . . . . . . . . . . . . . . . . . 11
4. Conclusions and Recommendations . . . . . . . . . . . . . . . 14 4. Conclusions and Recommendations . . . . . . . . . . . . . . . 14
4.1. Operational deployments SHOULD use AQM procedures . . . . 15 4.1. Operational deployments SHOULD use AQM procedures . . . . 15
4.2. Signaling to the transport endpoints . . . . . . . . . . 16 4.2. Signaling to the transport endpoints . . . . . . . . . . 16
4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 17
4.3. AQM algorithms deployed SHOULD NOT require operational 4.3. AQM algorithm deployment SHOULD NOT require operational
tuning . . . . . . . . . . . . . . . . . . . . . . . . . 18 tuning . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. AQM algorithms SHOULD respond to measured congestion, not 4.4. AQM algorithms SHOULD respond to measured congestion, not
application profiles. . . . . . . . . . . . . . . . . . . 19 application profiles. . . . . . . . . . . . . . . . . . . 19
4.5. AQM algorithms SHOULD NOT be dependent on specific 4.5. AQM algorithms SHOULD NOT be dependent on specific
transport protocol behaviours . . . . . . . . . . . . . . 20 transport protocol behaviours . . . . . . . . . . . . . . 20
4.6. Interactions with congestion control algorithms . . . . . 21 4.6. Interactions with congestion control algorithms . . . . . 21
4.7. The need for further research . . . . . . . . . . . . . . 22 4.7. The need for further research . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Internet protocol architecture is based on a connectionless end- The Internet protocol architecture is based on a connectionless end-
to-end packet service using the Internet Protocol, whether IPv4 to-end packet service using the Internet Protocol, whether IPv4
[RFC0791] or IPv6 [RFC2460]. The advantages of its connectionless [RFC0791] or IPv6 [RFC2460]. The advantages of its connectionless
design: flexibility and robustness, have been amply demonstrated. design: flexibility and robustness, have been amply demonstrated.
However, these advantages are not without cost: careful design is However, these advantages are not without cost: careful design is
required to provide good service under heavy load. In fact, lack of required to provide good service under heavy load. In fact, lack of
attention to the dynamics of packet forwarding can result in severe attention to the dynamics of packet forwarding can result in severe
skipping to change at page 18, line 37 skipping to change at page 18, line 37
An AQM algorithm that supports ECN needs to define the threshold and An AQM algorithm that supports ECN needs to define the threshold and
algorithm for ECN-marking. This threshold MAY differ from that used algorithm for ECN-marking. This threshold MAY differ from that used
for dropping packets that are not marked as ECN-capable, and SHOULD for dropping packets that are not marked as ECN-capable, and SHOULD
be configurable. be configurable.
Network devices SHOULD use an algorithm to drop excessive traffic Network devices SHOULD use an algorithm to drop excessive traffic
(e.g., at some level above the threshold for CE-marking), even when (e.g., at some level above the threshold for CE-marking), even when
the packets are marked as originating from an ECN-capable transport. the packets are marked as originating from an ECN-capable transport.
4.3. AQM algorithms deployed SHOULD NOT require operational tuning 4.3. AQM algorithm deployment SHOULD NOT require operational tuning
A number of AQM algorithms have been proposed. Many require some A number of AQM algorithms have been proposed. Many require some
form of tuning or setting of parameters for initial network form of tuning or setting of parameters for initial network
conditions. This can make these algorithms difficult to use in conditions. This can make these algorithms difficult to use in
operational networks. operational networks.
AQM algorithms need to consider both "initial conditions" and AQM algorithms need to consider both "initial conditions" and
"operational conditions". The former includes values that exist "operational conditions". The former includes values that exist
before any experience is gathered about the use of the algorithm, before any experience is gathered about the use of the algorithm,
such as the configured speed of interface, support for full duplex such as the configured speed of interface, support for full duplex
communication, interface MTU and other properties of the link. The communication, interface MTU and other properties of the link. The
latter includes information observed from monitoring the size of the latter includes information observed from monitoring the size of the
queue, experienced queueing delay, rate of packet discard, etc. queue, experienced queueing delay, rate of packet discard, etc.
This document therefore specifies that AQM algorithms that are This document therefore specifies that AQM algorithms that are
proposed for deployment in the Internet have the following proposed for deployment in the Internet have the following
properties: properties:
o AQM algorithm deployment SHOULD NOT require tuning in common use o AQM algorithm deployment SHOULD NOT require tuning. An algorithm
cases. An algorithm needs to provide a default behaviour that MUST provide a default behaviour that auto-tunes to a reasonable
auto-tunes to a reasonable performance for typical network performance for typical network operational conditions. This is
operational conditions. This is expected to ease deployment and expected to ease deployment and operation. Initial conditions,
operation. Initial conditions, such as the interface rate and MTU such as the interface rate and MTU size or other values derived
size or other values derived from these, MAY be required by an AQM from these, MAY be required by an AQM algorithm.
algorithm.
o MAY support further manual tuning that could improve performance o MAY support further manual tuning that could improve performance
in a specific deployed network. Algorithms that lack such in a specific deployed network. Algorithms that lack such
variables are acceptable, but if such variables exist, they SHOULD variables are acceptable, but if such variables exist, they SHOULD
be externalized (made visible to the operator). Guidance needs to be externalized (made visible to the operator). Guidance needs to
be provided on the cases where auto-tuning is unlikely to achieve be provided on the cases where auto-tuning is unlikely to achieve
acceptable performance and to identify the set of parameters that acceptable performance and to identify the set of parameters that
can be tuned. For example, the expected response of an algorithm can be tuned. For example, the expected response of an algorithm
may need to be configured to accommodate the largest expected Path may need to be configured to accommodate the largest expected Path
RTT, since this value can not be known at initialization. This RTT, since this value can not be known at initialization. This
skipping to change at page 22, line 26 skipping to change at page 22, line 23
and we as a community have learned a lot. However, we are not done. and we as a community have learned a lot. However, we are not done.
We have learned that the problems of congestion, latency and buffer- We have learned that the problems of congestion, latency and buffer-
sizing have not gone away, and are becoming more important to many sizing have not gone away, and are becoming more important to many
users. A number of self-tuning AQM algorithms have been found that users. A number of self-tuning AQM algorithms have been found that
offer significant advantages for deployed networks. There is also offer significant advantages for deployed networks. There is also
renewed interest in deploying AQM and the potential of ECN. renewed interest in deploying AQM and the potential of ECN.
Traffic patterns can depend on the network deployment scenario, and Traffic patterns can depend on the network deployment scenario, and
Internet research therefore needs to consider the implications of a Internet research therefore needs to consider the implications of a
diverse range of application interactions. At the time of writing diverse range of application interactions. This includes ensuring
(in 2015), an obvious example of further research is the need to that combinations of mechanisms, as well as combinations of traffic
consider the many-to-one communication patterns found in data patterns, do not interact and result in either significantly reduced
centers, known as incast [Ren12], (e.g., produced by Map/Reduce flow throughput or significantly increased latency.
applications). Such anlaysis needs to study not only each
application traffic type, but should also include combinations of At the time of writing (in 2015), an obvious example of further
types of traffic. research is the need to consider the many-to-one communication
patterns found in data centers, known as incast [Ren12], (e.g.,
produced by Map/Reduce applications). Such anlaysis needs to study
not only each application traffic type, but should also include
combinations of types of traffic.
Research also needs to consider the need to extend our taxonomy of Research also needs to consider the need to extend our taxonomy of
transport sessions to include not only "mice" and "elephants", but transport sessions to include not only "mice" and "elephants", but
"lemmings"? Where "Lemmings" are flash crowds of "mice" that the "lemmings"? Where "Lemmings" are flash crowds of "mice" that the
network inadvertently tries to signal to as if they were elephant network inadvertently tries to signal to as if they were elephant
flows, resulting in head of line blocking in a data center deployment flows, resulting in head of line blocking in a data center deployment
scenario. scenario.
Examples of other required research include: Examples of other required research include:
skipping to change at page 30, line 11 skipping to change at page 30, line 11
the more bold language from RFC2309 to reflect a more considered the more bold language from RFC2309 to reflect a more considered
perceived threat to Internet Performance; modified the category perceived threat to Internet Performance; modified the category
that is not-TCP-like to be "less responsive to congestion than that is not-TCP-like to be "less responsive to congestion than
TCP" and more clearkly noted that represents a range of TCP" and more clearkly noted that represents a range of
behaviours. behaviours.
-09 WG Draft - Minor edits Jan 2015 - Edits following LC comments. -09 WG Draft - Minor edits Jan 2015 - Edits following LC comments.
-10 WG Draft - Minor edits Feb 2015 - Update following IESG Review -10 WG Draft - Minor edits Feb 2015 - Update following IESG Review
o Gorry's Unresolved to-do list -11 WG Draft - Minor edits Feb 2015 - Resolution of last issues.
o ----------------
o DISCUSS: This sentence above could be understood in different
ways. For example, that any configuration is wrong. The ability
to activate AQM is a good thing IMO. The section 4.3 title is
closer to what you intend to say: "AQM algorithms deployed SHOULD
NOT require operational tuning" The issue is that you only define
what you mean by "operational configuration" in section 4.3
o ----------------
o DISCUSS1: OLD: 3. The algorithms that the IETF recommends SHOULD
NOT require operational (especially manual) configuration or
tuning. NEW: AQM algorithm deployment SHOULD NOT require tuning
of initial or configuration parameters. Gorry proposes: AQM
algorithms specified by the IETF SHOULD NOT require tuning of
initial or configuration parameters.
o -------------------------
o DISCUSS2: OLD: 4.3 AQM algorithms deployed SHOULD NOT require
operational tuning NEW: 4.3 AQM algorithm deployment SHOULD NOT
require tuning
o ---------------------------------
o COMMENT: I see relatively little, and that includes here mention
that time scales for queue management and the time scale for
application responsiveness to congestion signals are wildly
different. e.g. one is measured in usecs the other is bounded by
RTT. queue sizing and policing around abberant events, for example
micro-as loops driven by a prefix withdraw isn't really dealt with
at all.
o - GF: This is true, although we hint at the same issue with paths
with satellite delay (when RTT >> AQM loop response time) --- have
we ideas of what to write?
o ---------------------------------
o GEN-ART COMMENT: "Ensuring that mechanisms do not interact badly:
Given that a number of different mechanisms are being developed
and potentially may all be deployed in various quantities in
routers, etc., along the path that a packet takes, ensuring that
this does not lead to instability or other interactions should
also be a target of research. A number of applications now have
flow control mechanisms that may be deployed as an adjunct to TCP
so that a single path may have multiple nested end-to-end feedback
loops (notably, just about to be standardized, HHTP2!) and it
would be very wise to ensure that adding AQM into the loop does
not lead to problems. "-GF:what is this comment about???? - I know
the problems of flow control interaction in HTTP2 with TCP; but I
don't understand how that applies and what new text this needs:
Ideas?
Authors' Addresses Authors' Addresses
Fred Baker (editor) Fred Baker (editor)
Cisco Systems Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: fred@cisco.com Email: fred@cisco.com
 End of changes. 9 change blocks. 
75 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/