draft-ietf-aqm-recommendation-02.txt   draft-ietf-aqm-recommendation-03.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 18, 2014 February 14, 2014 Expires: August 19, 2014 February 15, 2014
IETF Recommendations Regarding Active Queue Management IETF Recommendations Regarding Active Queue Management
draft-ietf-aqm-recommendation-02 draft-ietf-aqm-recommendation-03
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 18, 2014. This Internet-Draft will expire on August 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. The Need For Active Queue Management . . . . . . . . . . . . 4 2. The Need For Active Queue Management . . . . . . . . . . . . 4
3. Managing Aggressive Flows . . . . . . . . . . . . . . . . . . 8 3. Managing Aggressive Flows . . . . . . . . . . . . . . . . . . 8
4. Conclusions and Recommendations . . . . . . . . . . . . . . . 10 4. Conclusions and Recommendations . . . . . . . . . . . . . . . 10
4.1. Operational deployments SHOULD use AQM procedures . . . 11 4.1. Operational deployments SHOULD use AQM procedures . . . 11
4.2. Signaling to the transport endpoints . . . . . . . . . . 11 4.2. Signaling to the transport endpoints . . . . . . . . . . 12
4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 13
4.3. AQM algorithms deployed SHOULD NOT require operational 4.3. AQM algorithms deployed SHOULD NOT require operational
tuning . . . . . . . . . . . . . . . . . . . . . . . . . 13 tuning . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. AQM algorithms SHOULD respond to measured congestion, not 4.4. AQM algorithms SHOULD respond to measured congestion, not
application profiles. . . . . . . . . . . . . . . . . . . 14 application profiles. . . . . . . . . . . . . . . . . . . 15
4.5. AQM algorithms SHOULD NOT be dependent on specific 4.5. AQM algorithms SHOULD NOT be dependent on specific
transport protocol behaviours . . . . . . . . . . . . . . 15 transport protocol behaviours . . . . . . . . . . . . . . 15
4.6. Interactions with congestion control algorithms . . . . . 16 4.6. Interactions with congestion control algorithms . . . . . 16
4.7. The need for further research . . . . . . . . . . . . . . 17 4.7. The need for further research . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
Internet. Internet.
Section 4 concludes the memo with a set of recommendations to the Section 4 concludes the memo with a set of recommendations to the
Internet community concerning these topics. Internet community concerning these topics.
The discussion in this memo applies to "best-effort" traffic, which The discussion in this memo applies to "best-effort" traffic, which
is to say, traffic generated by applications that accept the is to say, traffic generated by applications that accept the
occasional loss, duplication, or reordering of traffic in flight. It occasional loss, duplication, or reordering of traffic in flight. It
also applies to other traffic, such as real-time traffic that can also applies to other traffic, such as real-time traffic that can
adapt its sending rate to reduce loss and/or delay. It is most adapt its sending rate to reduce loss and/or delay. It is most
effective, when the adaption occurs on time scales of a single Round effective when the adaption occurs on time scales of a single Round
Trip Time (RTT) or a small number of RTTs, for elastic traffic Trip Time (RTT) or a small number of RTTs, for elastic traffic
[RFC1633]. [RFC1633].
[RFC2309] resulted from past discussions of end-to-end performance, [RFC2309] resulted from past discussions of end-to-end performance,
Internet congestion, and Random Early Discard (RED) in the End-to-End Internet congestion, and Random Early Discard (RED) in the End-to-End
Research Group of the Internet Research Task Force (IRTF). This Research Group of the Internet Research Task Force (IRTF). This
update results from experience with this and other algorithms, and update results from experience with this and other algorithms, and
the AQM discussion within the IETF[AQM-WG]. the AQM discussion within the IETF[AQM-WG].
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 4, line 49 skipping to change at page 4, line 49
reached, then reject (drop) subsequent incoming packets until the reached, then reject (drop) subsequent incoming packets until the
queue decreases because a packet from the queue has been transmitted. queue decreases because a packet from the queue has been transmitted.
This technique is known as "tail drop", since the packet that arrived This technique is known as "tail drop", since the packet that arrived
most recently (i.e., the one on the tail of the queue) is dropped most recently (i.e., the one on the tail of the queue) is dropped
when the queue is full. This method has served the Internet well for when the queue is full. This method has served the Internet well for
years, but it has two important drawbacks: years, but it has two important drawbacks:
1. Lock-Out 1. Lock-Out
In some situations tail drop allows a single connection or a few In some situations tail drop allows a single connection or a few
flows to monopolize queue space, preventing other connections flows to monopolize the queue space starving other connection
from getting room in the queue. This "lock-out" phenomenon is preventing them from getting room in the queue. This "lock-out"
often the result of synchronization or other timing effects. phenomenon is often the result of synchronization or other timing
effects.
2. Full Queues 2. Full Queues
The tail drop discipline allows queues to maintain a full (or, The tail drop discipline allows queues to maintain a full (or,
almost full) status for long periods of time, since tail drop almost full) status for long periods of time, since tail drop
signals congestion (via a packet drop) only when the queue has signals congestion (via a packet drop) only when the queue has
become full. It is important to reduce the steady-state queue become full. It is important to reduce the steady-state queue
size, and this is perhaps the most important goal for queue size, and this is perhaps the most important goal for queue
management. management.
skipping to change at page 6, line 34 skipping to change at page 6, line 36
space is inadequate, then the network device will have no ability space is inadequate, then the network device will have no ability
to buffer bursts. By keeping the average queue size small, AQM to buffer bursts. By keeping the average queue size small, AQM
will provide greater capacity to absorb naturally-occurring will provide greater capacity to absorb naturally-occurring
bursts without dropping packets. bursts without dropping packets.
Furthermore, without AQM, more packets will be dropped when a Furthermore, without AQM, more packets will be dropped when a
queue does overflow. This is undesirable for several reasons. queue does overflow. This is undesirable for several reasons.
First, with a shared queue and the tail drop discipline, this can First, with a shared queue and the tail drop discipline, this can
result in unnecessary global synchronization of flows, resulting result in unnecessary global synchronization of flows, resulting
in lowered average link utilization, and hence lowered network in lowered average link utilization, and hence lowered network
throughput. Second, unnecessary packet drops represent a throughput. Second, unnecessary packet drops represent a waste
possible waste of network capacity on the path before the drop of network capacity on the path before the drop point.
point.
While AQM can manage queue lengths and reduce end-to-end latency While AQM can manage queue lengths and reduce end-to-end latency
even in the absence of end-to-end congestion control, it will be even in the absence of end-to-end congestion control, it will be
able to reduce packet drops only in an environment that continues able to reduce packet drops only in an environment that continues
to be dominated by end-to-end congestion control. to be dominated by end-to-end congestion control.
2. Provide a lower-delay interactive service 2. Provide a lower-delay interactive service
By keeping a small average queue size, AQM will reduce the delays By keeping a small average queue size, AQM will reduce the delays
experienced by flows. This is particularly important for experienced by flows. This is particularly important for
interactive applications such as short Web transfers, Telnet interactive applications such as short Web transfers, POP/IMAP,
traffic, or interactive audio-video sessions, whose subjective Telnet traffic, or interactive audio-video sessions, whose
(and objective) performance is better when the end-to-end delay subjective (and objective) performance is better when the end-to-
is low. end delay is low.
3. Avoid lock-out behavior 3. Avoid lock-out behavior
AQM can prevent lock-out behavior by ensuring that there will AQM can prevent lock-out behavior by ensuring that there will
almost always be a buffer available for an incoming packet. For almost always be a buffer available for an incoming packet. For
the same reason, AQM can prevent a bias against low capacity, but the same reason, AQM can prevent a bias against low capacity, but
highly bursty, flows. highly bursty, flows.
Lock-out is undesirable because it constitutes a gross unfairness Lock-out is undesirable because it constitutes a gross unfairness
among groups of flows. However, we stop short of calling this among groups of flows. However, we stop short of calling this
skipping to change at page 8, line 6 skipping to change at page 8, line 9
It is also important to differentiate the choice of buffer size for a It is also important to differentiate the choice of buffer size for a
queue in a switch/router or other network device, and the queue in a switch/router or other network device, and the
threshold(s) and other parameters that determine how and when an AQM threshold(s) and other parameters that determine how and when an AQM
algorithm operates. One the one hand, the optimum buffer size is a algorithm operates. One the one hand, the optimum buffer size is a
function of operational requirements and should generally be sized to function of operational requirements and should generally be sized to
be sufficient to buffer the largest normal traffic burst that is be sufficient to buffer the largest normal traffic burst that is
expected. This size depends on the number and burstiness of traffic expected. This size depends on the number and burstiness of traffic
arriving at the queue and the rate at which traffic leaves the queue. arriving at the queue and the rate at which traffic leaves the queue.
Different types of traffic and deployment scenarios will lead to Different types of traffic and deployment scenarios will lead to
different requirements. On the other hand, the choice of AQM different requirements. AQM frees a designer from having to the
limit buffer space to achieve acceptable performance, allowing
allocation of sufficient buffering to satisfy the needs of the
particular traffic pattern. On the other hand, the choice of AQM
algorithm and associated parameters is a function of the way in which algorithm and associated parameters is a function of the way in which
congestion is experienced and the required reaction to achieve congestion is experienced and the required reaction to achieve
acceptable performance. This latter topic is the primary topic of acceptable performance. This latter topic is the primary topic of
the following sections. the following sections.
3. Managing Aggressive Flows 3. Managing Aggressive Flows
One of the keys to the success of the Internet has been the One of the keys to the success of the Internet has been the
congestion avoidance mechanisms of TCP. Because TCP "backs off" congestion avoidance mechanisms of TCP. Because TCP "backs off"
during congestion, a large number of TCP connections can share a during congestion, a large number of TCP connections can share a
skipping to change at page 12, line 31 skipping to change at page 12, line 42
congestion. congestion.
It is essential that all Internet hosts respond to loss [RFC5681], It is essential that all Internet hosts respond to loss [RFC5681],
[RFC5405][RFC4960][RFC4340]. Packet dropping by network devices that [RFC5405][RFC4960][RFC4340]. Packet dropping by network devices that
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 transport must the latter." of congestion. To be conservative, a transport must assume it may be
Unreliable transports (e.g. using UDP) need to similarly react to the latter." Unreliable transports (e.g. using UDP) need 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 determine the packets
that are marked or discarded due to congestion. that are marked or discarded due to congestion.
Loss also has an effect on the efficiency of a flow and can Loss also has an effect on the efficiency of a flow and can
significantly impact some classes of application. In reliable significantly impact some classes of application. In reliable
transports the dropped data must be subsequently retransmitted. transports the dropped data must be subsequently retransmitted.
While other applications/transports may adapt to the absence of lost While other applications/transports may adapt to the absence of lost
data, this still implies inefficient use of available capacity and data, this still implies inefficient use of available capacity and
the dropped traffic can affect other flows. Hence, loss is not the dropped traffic can affect other flows. Hence, congestion
entirely positive; it is a necessary evil. 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 whether to ECN-mark. the latter rely upon using AQM to decider whether to ECN-mark.
skipping to change at page 13, line 29 skipping to change at page 13, line 39
traffic or by dropping non-ECN-capable traffic. traffic or by dropping non-ECN-capable traffic.
Safe deployment of ECN requires that network devices drop excessive Safe deployment of ECN requires that network devices drop excessive
traffic, even when marked as originating from an ECN-capable traffic, even when marked as originating from an ECN-capable
transport. This is a necessary safety precaution because (1) A non- transport. This is a necessary safety precaution because (1) A non-
conformant, broken or malicious receiver could conceal an ECN mark, conformant, broken or malicious receiver could conceal an ECN mark,
and not report this to the sender (2) A non-conformant, broken or and not report this to the sender (2) A non-conformant, broken or
malicious sender could ignore a reported ECN mark, as it could ignore malicious sender could ignore a reported ECN mark, as it could ignore
a loss without using ECN (3) A malfunctioning or non-conforming a loss without using ECN (3) A malfunctioning or non-conforming
network device may similarly "hide" an ECN mark. In normal operation network device may similarly "hide" an ECN mark. In normal operation
such cases should be very uncommon. such cases should be very uncommon, however overload protection is
desirable to protect traffic from misconfigured or malicous use of
ECN.
Network devices SHOULD use an algorithm to drop excessive traffic, Network devices SHOULD use an algorithm to drop excessive traffic,
even when marked as originating from an ECN-capable transport. even when marked as originating from an ECN-capable transport.
4.3. AQM algorithms deployed SHOULD NOT require operational tuning 4.3. AQM algorithms deployed 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.
skipping to change at page 14, line 21 skipping to change at page 14, line 33
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 autotuning is unlikely to achieve be provided on the cases where autotuning is unlikely to achieve
satisfactory performance and to identify the set of parameters satisfactory performance and to identify the set of parameters
that can be tuned. This is expected to enable the algorithm to be that can be tuned. This is expected to enable the algorithm to be
deployed in networks that have specific characteristics (variable/ deployed in networks that have specific characteristics (variable/
larger delay; networks were capacity is impacted by interactions larger delay; networks where capacity is impacted by interactions
with lower layer mechanisms, etc). with lower layer mechanisms, etc).
o MAY provide logging and alarm signals to assist in identifying if o MAY provide logging and alarm signals to assist in identifying if
an algorithm using manual or auto-tuning is functioning as an algorithm using manual or auto-tuning is functioning as
expected. (e.g., this could be based on an internal consistency expected. (e.g., this could be based on an internal consistency
check between input, output, and mark/drop rates over time). This check between input, output, and mark/drop rates over time). This
is expected to encourage deployment by default and allow operators is expected to encourage deployment by default and allow operators
to identify potential interactions with other network functions. to identify potential interactions with other network functions.
Hence, self-tuning algorithms are to be preferred. Algorithms Hence, self-tuning algorithms are to be preferred. Algorithms
recommended for general Internet deployment by the IETF need to be recommended for general Internet deployment by the IETF need to be
designed so that they do not require operational (especially manual) designed so that they do not require operational (especially manual)
configuration or tuning. configuration or tuning.
4.4. AQM algorithms SHOULD respond to measured congestion, not 4.4. AQM algorithms SHOULD respond to measured congestion, not
application profiles. application profiles.
Not all applications transmit packets of the same size. Although Not all applications transmit packets of the same size. Although
applications may be characterised by particular profiles of packet applications may be characterized by particular profiles of packet
size this should not be used as the basis for AQM (see next section). size this should not be used as the basis for AQM (see next section).
Other methods exist, e.g. Differentiated Services queueing, Pre- Other methods exist, e.g. Differentiated Services queueing, Pre-
Congestion Notification (PCN) [RFC5559], that can be used to Congestion Notification (PCN) [RFC5559], that can be used to
differentiate and police classes of application. Network devices may differentiate and police classes of application. Network devices may
combine AQM with these traffic classification mechanisms and perform combine AQM with these traffic classification mechanisms and perform
AQM only on specific queues within a network device. AQM only on specific queues within a network device.
An AQM algorithm should not deliberately try to prejudice the size of An AQM algorithm should not deliberately try to prejudice the size of
packet that performs best (i.e. Preferentially drop/mark based only packet that performs best (i.e. Preferentially drop/mark based only
on packet size). Procedures for selecting packets to mark/drop on packet size). Procedures for selecting packets to mark/drop
skipping to change at page 15, line 20 skipping to change at page 15, line 38
small or large packets based on the data they wish to send and the small or large packets based on the data they wish to send and the
expected impact on the delay or throughput, or other performance expected impact on the delay or throughput, or other performance
parameter. When a transport or application responds to a dropped or parameter. When a transport or application responds to a dropped or
marked packet, the size of the rate reduction should be proportionate marked packet, the size of the rate reduction should be proportionate
to the size of the packet that was sent [Byte-pkt]. to the size of the packet that was sent [Byte-pkt].
AQM-enabled system MAY instantiate different instances of an AQM AQM-enabled system MAY instantiate different instances of an AQM
algorithm to be applied within the same traffic class. Traffic algorithm to be applied within the same traffic class. Traffic
classes may be differentiated based on an Access Control List (ACL), classes may be differentiated based on an Access Control List (ACL),
the packet DiffServ Code Point (DSCP) [RFC5559], setting of the ECN the packet DiffServ Code Point (DSCP) [RFC5559], setting of the ECN
field[RFC3168] [RFC4774] or an equivalent codepoint at a lower layer. field[RFC3168] [RFC4774], a multi-field (MF) classifier that combines
This recommendation goes beyond what is defined in RFC 3168, by the values of a set of protocol fields (e.g. IP address, transport,
allowing that an implementation MAY use more than one instance of an ports) or an equivalent codepoint at a lower layer. This
AQM algorithm to handle both ECN-capable and non-ECN-capable packets. recommendation goes beyond what is defined in RFC 3168, by allowing
that an implementation MAY use more than one instance of an AQM
algorithm to handle both ECN-capable and non-ECN-capable packets.
4.5. AQM algorithms SHOULD NOT be dependent on specific transport 4.5. AQM algorithms SHOULD NOT be dependent on specific transport
protocol behaviours protocol behaviours
In deploying AQM, network devices need to support a range of Internet In deploying AQM, network devices need to support a range of Internet
traffic and SHOULD NOT make implicit assumptions about the traffic and SHOULD NOT make implicit assumptions about the
characteristics desired by the set transports/applications the characteristics desired by the set transports/applications the
network supports. That is, AQM methods should be opaque to the network supports. That is, AQM methods should be opaque to the
choice of transport and application. choice of transport and application.
skipping to change at page 16, line 25 skipping to change at page 16, line 42
difficult to detect tail losses at a higher layer and this may difficult to detect tail losses at a higher layer and this may
sometimes require transport timers or probe packets to detect and sometimes require transport timers or probe packets to detect and
respond to such loss. Loss patterns may also impact timely respond to such loss. Loss patterns may also impact timely
detection, e.g. the time may be reduced when network devices do not detection, e.g. the time may be reduced when network devices do not
drop long runs of packets from the same flow. drop long runs of packets from the same flow.
A common objective is to deliver data from its source end point to A common objective is to deliver data from its source end point to
its destination in the least possible time. When speaking of TCP its destination in the least possible time. When speaking of TCP
performance, the terms "knee" and "cliff" area defined by [Jain94]. performance, the terms "knee" and "cliff" area defined by [Jain94].
They respectively refer to the minimum congestion window that They respectively refer to the minimum congestion window that
maximises throughput and the maximum congestion window that avoids maximizes throughput and the maximum congestion window that avoids
loss. An application that transmits at the rate determined by this loss. An application that transmits at the rate determined by this
window has the effect of maximizing the rate or throughput. For the window has the effect of maximizing the rate or throughput. For the
sender, exceeding the cliff is ineffective, as it (by definition) sender, exceeding the cliff is ineffective, as it (by definition)
induces loss; operating at a point close to the cliff has a negative induces loss; operating at a point close to the cliff has a negative
impact on other traffic and applications, triggering operator impact on other traffic and applications, triggering operator
activities, such as those discussed in [RFC6057]. Operating below activities, such as those discussed in [RFC6057]. Operating below
the knee reduces the throughput, since the sender fails to use the knee reduces the throughput, since the sender fails to use
available network capacity. As a result, the behavior of any elastic available network capacity. As a result, the behavior of any elastic
transport congestion control algorithm designed to minimise delivery transport congestion control algorithm designed to minimize delivery
time should seek to use an effective window at or above the knee and time should seek to use an effective window at or above the knee and
well below the cliff. Choice of an appropriate rate can well below the cliff. Choice of an appropriate rate can
significantly impact the loss and delay experienced not only by a significantly impact the loss and delay experienced not only by a
flow, but by other flows that share the same queue. flow, but by other flows that share the same queue.
Some applications may send less than permitted by the congestion Some applications may send less than permitted by the congestion
control window (or rate). Examples include multimedia codecs that control window (or rate). Examples include multimedia codecs that
stream at some natural rate (or set of rates) or an application that stream at some natural rate (or set of rates) or an application that
is naturally interactive (e.g., some web applications, gaming, is naturally interactive (e.g., some web applications, gaming,
transaction-based protocols). Such applications may have different transaction-based protocols). Such applications may have different
objectives. They may not wish to maximise throughput, but may desire objectives. They may not wish to maximize throughput, but may desire
a lower loss rate or bounded delay. a lower loss rate or bounded delay.
The correct operation of an AQM-enabled network device MUST NOT rely The correct operation of an AQM-enabled network device MUST NOT rely
upon specific transport responses to congestion signals. upon specific transport responses to congestion signals.
4.7. The need for further research 4.7. The need for further research
The second recommendation of [RFC2309] called for further research The second recommendation of [RFC2309] called for further research
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,
skipping to change at page 17, line 21 skipping to change at page 17, line 35
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 In 2013, an obvious example of further research is the need to
consider the use of Map/Reduce applications in data centers; do we consider the use of Map/Reduce applications in data centers; do we
need to extend our taxonomy of TCP/SCTP sessions to include not only need to extend our taxonomy of TCP/SCTP sessions to include not only
"mice" and "elephants", but "lemmings". Where "Lemmings" are flash "mice" and "elephants", but "lemmings". "Lemmings" are flash crowds
crowds of "mice" that the network inadvertently try to signal to as of "mice" that the network inadvertently try to signal to as if they
if they were elephant flows, resulting in head of line blocking in were elephant flows, resulting in head of line blocking in data
data center applications. center applications.
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 Research into the use of and deployment of ECN alongside AQM. o Research into the use of and 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.
skipping to change at page 22, line 28 skipping to change at page 22, line 39
-00 WG Draft - Updated transport recommendations; revised deployment -00 WG Draft - Updated transport recommendations; revised deployment
configuration section; numerous minor edits. configuration section; numerous minor edits.
Oct 2013 Oct 2013
-01 WG Draft - Updated transport recommendations; revised deployment -01 WG Draft - Updated transport recommendations; revised deployment
configuration section; numerous minor edits. configuration section; numerous minor edits.
Jan 2014 - Feedback from WG. Jan 2014 - Feedback from WG.
-02 WG Draft - Minor edits Feb 2014 - Mainly language fixes. -02 WG Draft - Minor edits Feb 2014 - Mainly language fixes.
-03 WG Draft - Minor edits Feb 2013 - Comments from David Collier-
Brown and David Taht.
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)
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen, Scotland AB24 3UE Aberdeen, Scotland AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
 End of changes. 24 change blocks. 
42 lines changed or deleted 51 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/