draft-ietf-aqm-recommendation-08.txt   draft-ietf-aqm-recommendation-09.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: February 14, 2015 August 13, 2014 Expires: July 17, 2015 January 13, 2015
IETF Recommendations Regarding Active Queue Management IETF Recommendations Regarding Active Queue Management
draft-ietf-aqm-recommendation-08 draft-ietf-aqm-recommendation-09
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 February 14, 2015. This Internet-Draft will expire on July 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2. The Need For Active Queue Management . . . . . . . . . . . . 6 2. The Need For Active Queue Management . . . . . . . . . . . . 6
2.1. AQM and Multiple Queues . . . . . . . . . . . . . . . . . 9 2.1. AQM and Multiple Queues . . . . . . . . . . . . . . . . . 9
2.2. AQM and Explicit Congestion Marking (ECN) . . . . . . . . 10 2.2. AQM and Explicit Congestion Marking (ECN) . . . . . . . . 10
2.3. AQM and Buffer Size . . . . . . . . . . . . . . . . . . . 10 2.3. AQM and Buffer Size . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . 15 4.2. Signaling to the transport endpoints . . . . . . . . . . 15
4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 16
4.3. AQM algorithms deployed SHOULD NOT require operational 4.3. AQM algorithms deployed SHOULD NOT require operational
tuning . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . 19 transport protocol behaviours . . . . . . . . . . . . . . 20
4.6. Interactions with congestion control algorithms . . . . . 20 4.6. Interactions with congestion control algorithms . . . . . 20
4.7. The need for further research . . . . . . . . . . . . . . 21 4.7. The need for further research . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 12, line 22 skipping to change at page 12, line 22
that does not throttle its sending rate when it experiences that does not throttle its sending rate when it experiences
congestion). Examples include some UDP streaming applications congestion). Examples include some UDP streaming applications
for packet voice and video, and some multicast bulk data for packet voice and video, and some multicast bulk data
transport. If no action is taken, such unresponsive flows could transport. If no action is taken, such unresponsive flows could
lead to a new congestion collapse. Some applications can even lead to a new congestion collapse. Some applications can even
increase their traffic volume in response to congestion (e.g. by increase their traffic volume in response to congestion (e.g. by
adding forward error correction when loss is experienced), with adding forward error correction when loss is experienced), with
the possibility that they contribute to congestion collapse. the possibility that they contribute to congestion collapse.
In general, UDP-based applications need to incorporate effective In general, UDP-based applications need to incorporate effective
congestion avoidance mechanisms [RFC5405]. Further research and congestion avoidance mechanisms [RFC5405]. Research continues to
development of ways to accomplish congestion avoidance for be needed to identify and develop ways to accomplish congestion
presently unresponsive applications continue to be important. avoidance for presently unresponsive applications. Network
Network devices need to be able to protect themselves against devices need to be able to protect themselves against
unresponsive flows, and mechanisms to accomplish this must be unresponsive flows, and mechanisms to accomplish this must be
developed and deployed. Deployment of such mechanisms would developed and deployed. Deployment of such mechanisms would
provide an incentive for all applications to become responsive by provide an incentive for all applications to become responsive by
either using a congestion-controlled transport (e.g. TCP, SCTP either using a congestion-controlled transport (e.g. TCP, SCTP
[RFC4960] and DCCP [RFC4340].) or by incorporating their own [RFC4960] and DCCP [RFC4340].) or by incorporating their own
congestion control in the application [RFC5405], [RFC6679]. congestion control in the application [RFC5405], [RFC6679].
Lastly, some applications (e.g. current web browsers) open a Lastly, some applications (e.g. current web browsers) open a
large numbers of short TCP flows for a single session. This can large numbers of short TCP flows for a single session. This can
lead to each individual flow spending the majority of time in the lead to each individual flow spending the majority of time in the
skipping to change at page 16, line 24 skipping to change at page 16, line 24
are under load has two effects: It protects the network, which is the are under load has two effects: It protects the network, which is the
primary reason that network devices drop packets. The detection of primary reason that network devices drop packets. The detection of
loss also provides a signal to a reliable transport (e.g. TCP, SCTP) loss also provides a signal to a reliable transport (e.g. TCP, SCTP)
that there is potential congestion using a pragmatic heuristic; "when that there is potential congestion using a pragmatic heuristic; "when
the network discards a message in flight, it may imply the presence 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 faulty equipment or media in a path, and it may imply the presence
of congestion. To be conservative, a transport must assume it may be of congestion. To be conservative, a transport must assume it may be
the latter." Unreliable transports (e.g. using UDP) need to the latter." Unreliable transports (e.g. using UDP) need to
similarly react to loss [RFC5405] similarly react to loss [RFC5405]
Network devices SHOULD use an AQM algorithm to determine the packets Network devices SHOULD use an AQM algorithm to measure local local
that are marked or discarded due to congestion. Procedures for congestion and to determine the packets to mark or drop so that the
dropping or marking packets within the network need to avoid congestion is managed.
increasing synchronization events, and hence randomness SHOULD be
introduced in the algorithms that generate these congestion signals
to the endpoints.
Loss also has an effect on the efficiency of a flow and can In general, dropping multiple packets from the same sessions in the
significantly impact some classes of application. In reliable same RTT is ineffective, and can reduce throughput. Also, dropping
transports the dropped data must be subsequently retransmitted. or marking packets from multiple sessions simultaneously can have the
While other applications/transports may adapt to the absence of lost effect of synchronizing them, resulting in increasing peaks and
data, this still implies inefficient use of available capacity and troughs in the subsequent traffic load. Hence, AQM algorithms SHOULD
the dropped traffic can affect other flows. Hence, congestion randomize dropping in time, to reduce the probability that congestion
signalling by loss is not entirely positive; it is a necessary evil. indications are only experienced by a small proportion of the active
flows.
Loss due to dropping also has an effect on the efficiency of a flow
and can significantly impact some classes of application. In
reliable transports the dropped data must be subsequently
retransmitted. While other applications/transports may adapt to the
absence of lost data, this still implies inefficient use of available
capacity and the dropped traffic can affect other flows. Hence,
congestion signalling by loss is not entirely positive; it is a
necessary evil.
4.2.1. AQM and ECN 4.2.1. AQM and ECN
Explicit Congestion Notification (ECN) [RFC4301] [RFC4774] [RFC6040] Explicit Congestion Notification (ECN) [RFC4301] [RFC4774] [RFC6040]
[RFC6679] is a network-layer function that allows a transport to [RFC6679] is a network-layer function that allows a transport to
receive network congestion information from a network device without receive network congestion information from a network device without
incurring the unintended consequences of loss. ECN includes both incurring the unintended consequences of loss. ECN includes both
transport mechanisms and functions implemented in network devices, transport mechanisms and functions implemented in network devices,
the latter rely upon using AQM to decider when and whether to ECN- the latter rely upon using AQM to decider when and whether to ECN-
mark. mark.
skipping to change at page 21, line 34 skipping to change at page 21, line 41
into the interaction between network queues and host applications, into the interaction between network queues and host applications,
and the means of signaling between them. This research has occurred, and the means of signaling between them. This research has occurred,
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.
In 2013, an obvious example of further research is the need to Traffic patterns can depend on the network deployment scenario, and
consider the use of Map/Reduce applications in data centers; do we Internet research therefore needs to consider the implications of a
need to extend our taxonomy of TCP/SCTP sessions to include not only diverse range of application interactions. At the time of writing
"mice" and "elephants", but "lemmings"? "Lemmings" are flash crowds (in 2015), an obvious example of further research is the need to
of "mice" that the network inadvertently try to signal to as if they consider the many-to-one communication patterns found in data
were elephant flows, resulting in head of line blocking in data centers, known as incast [Ren12], (e.g., produced by Map/Reduce
center applications. applications).
Research also needs to consider the need to extend our taxonomy of
transport sessions to include not only "mice" and "elephants", but
"lemmings"? Where "Lemmings" are flash crowds of "mice" that the
network inadvertently tries to signal to as if they were elephant
flows, resulting in head of line blocking in a data center deployment
scenario.
Examples of other required research include: Examples of other required research include:
o Research into new AQM and scheduling algorithms. o Research into new AQM and scheduling algorithms.
o Appropriate use of delay-based methods and the implications of o Appropriate use of delay-based methods and the implications of
AQM. AQM.
o Research into the use of and deployment of ECN alongside AQM. o Research into suitable algorithms for marking ECN-capable packets
that do not require operational configuration or tuning for common
use.
o Experience in the deployment of ECN alongside AQM.
o Tools for enabling AQM (and ECN) deployment and measuring the o Tools for enabling AQM (and ECN) deployment and measuring the
performance. performance.
o Methods for mitigating the impact of non-conformant and malicious o Methods for mitigating the impact of non-conformant and malicious
flows. flows.
o Research to understand the implications of using new network and o Research to understand the implications of using new network and
transport methods on applications. transport methods on applications.
skipping to change at page 26, line 42 skipping to change at page 27, line 9
System", RFC 6057, December 2010. System", RFC 6057, December 2010.
[RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion
Exposure (ConEx) Concepts and Use Cases", RFC 6789, Exposure (ConEx) Concepts and Use Cases", RFC 6789,
December 2012. December 2012.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
December 2012. December 2012.
[Ren12] Ren, Y., Zhao, Y., and P. Liu, "A survey on TCP Incast in
data center networks, International Journal of
Communication Systems, Volume 27, Issue 8, pages
1160-117", 1990.
[Shr96] Shreedhar, M. and G. Varghese, "Efficient Fair Queueing [Shr96] Shreedhar, M. and G. Varghese, "Efficient Fair Queueing
Using Deficit Round Robin", IEEE/ACM Transactions on Using Deficit Round Robin", IEEE/ACM Transactions on
Networking Vol 4, No. 3 , July 1996. Networking Vol 4, No. 3 , July 1996.
[Sto97] Stoica, I. and H. Zhang, "A Hierarchical Fair Service [Sto97] Stoica, I. and H. Zhang, "A Hierarchical Fair Service
Curve algorithm for Link sharing, real-time and priority Curve algorithm for Link sharing, real-time and priority
services", ACM SIGCOMM , 1997. services", ACM SIGCOMM , 1997.
[Sut99] Suter, B., "Buffer Management Schemes for Supporting TCP [Sut99] Suter, B., "Buffer Management Schemes for Supporting TCP
in Gigabit Routers with Per-flow Queueing", IEEE Journal in Gigabit Routers with Per-flow Queueing", IEEE Journal
skipping to change at page 28, line 31 skipping to change at page 28, line 48
-08 WG Draft - Minor edits August 2014 - Review comments from John -08 WG Draft - Minor edits August 2014 - Review comments from John
Leslie and Bob Briscoe. Text corrections including; updated Leslie and Bob Briscoe. Text corrections including; updated
Acknowledgments (RFC2309 ref) s/congestive/congestion/g; changed Acknowledgments (RFC2309 ref) s/congestive/congestion/g; changed
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.
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
Godred Fairhurst (editor) Godred Fairhurst (editor)
 End of changes. 15 change blocks. 
34 lines changed or deleted 59 lines changed or added

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