draft-ietf-aqm-recommendation-09.txt   draft-ietf-aqm-recommendation-10.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: July 17, 2015 January 13, 2015 Expires: August 27, 2015 February 23, 2015
IETF Recommendations Regarding Active Queue Management IETF Recommendations Regarding Active Queue Management
draft-ietf-aqm-recommendation-09 draft-ietf-aqm-recommendation-10
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
are not sufficiently responsive to congestion notification. are not sufficiently responsive to congestion notification.
The note largely repeats the recommendations of RFC 2309, and The note replaces the recommendations of RFC 2309 based on fifteen
replaces these after fifteen years of experience and new research. years of experience and new research.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 17, 2015. This Internet-Draft will expire on August 27, 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Congestion Collapse . . . . . . . . . . . . . . . . . . . 3 1.1. Congestion Collapse . . . . . . . . . . . . . . . . . . . 3
1.2. Active Queue Management to Manage Latency . . . . . . . . 3 1.2. Active Queue Management to Manage Latency . . . . . . . . 4
1.3. Document Overview . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Overview . . . . . . . . . . . . . . . . . . . . 5
1.4. Changes to the recommendations of RFC2309 . . . . . . . . 5 1.4. Changes to the recommendations of RFC2309 . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . 15 4.2. Signaling to the transport endpoints . . . . . . . . . . 16
4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 17
4.3. AQM algorithms deployed SHOULD NOT require operational 4.3. AQM algorithms deployed 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 . . . . . 20 4.6. Interactions with congestion control algorithms . . . . . 21
4.7. The need for further research . . . . . . . . . . . . . . 21 4.7. The need for further research . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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
service degradation or "Internet meltdown". This phenomenon was service degradation or "Internet meltdown". This phenomenon was
first observed during the early growth phase of the Internet in the first observed during the early growth phase of the Internet in the
mid 1980s [RFC0896][RFC0970], and is technically called "congestion mid 1980s [RFC0896][RFC0970], and is technically called "congestion
collapse" and was a key focus of RFC2309. collapse" and was a key focus of RFC2309.
Although wide-scale congestion collapse is not common in the
Internet, the presence of localised congestion collapse is by no
means rare. It is therefore important to continue to avoid
congestion collapse.
Since 1998, when RFC2309 was written, the Internet has become used Since 1998, when RFC2309 was written, the Internet has become used
for a variety of traffic. In the current Internet low latency is for a variety of traffic. In the current Internet, low latency is
extremely important for many interactive and transaction-based extremely important for many interactive and transaction-based
applications. The same type of technology that RFC2309 advocated for applications. The same type of technology that RFC2309 advocated for
combating congestion collapse is also effective at limiting delays to combating congestion collapse is also effective at limiting delays to
reduce the interaction delay experienced by applications. While reduce the interaction delay (latency) experienced by applications
there is still a need to avoid congestion collapse, there is now also [Bri15]. High or unpredictable latency can impact the performance of
a focus on reducing network latency using the same technology. the control loops used by ene-to-end protocols (including congestion
control algorithms using TCP). There is now also a focus on reducing
network latency using the same technology.
The mechanisms decsribed in this document may be implemented in
network devices on the path between end-points that include routers,
switches, and other network middleboxes. The methods may also be
implemented in the networking stacks within endpoint devices that
connect to the network.
1.1. Congestion Collapse 1.1. Congestion Collapse
The original fix for Internet meltdown was provided by Van Jacobsen. The original fix for Internet meltdown was provided by Van Jacobsen.
Beginning in 1986, Jacobsen developed the congestion avoidance Beginning in 1986, Jacobsen developed the congestion avoidance
mechanisms [Jacobson88] that are now required for implementations of mechanisms [Jacobson88] that are now required for implementations of
the Transport Control Protocol (TCP) [RFC0768] [RFC1122]. These the Transport Control Protocol (TCP) [RFC0793] [RFC1122]. ([RFC7414]
provides a roadmap to help identify TCP-related documents.) These
mechanisms operate in Internet hosts to cause TCP connections to mechanisms operate in Internet hosts to cause TCP connections to
"back off" during congestion. We say that TCP flows are "responsive" "back off" during congestion. We say that TCP flows are "responsive"
to congestion signals (i.e., packets that are dropped or marked with to congestion signals (i.e., packets that are dropped or marked with
explicit congestion notification [RFC3168]). It is primarily these explicit congestion notification [RFC3168]). It is primarily these
TCP congestion avoidance algorithms that prevent the congestion TCP congestion avoidance algorithms that prevent the congestion
collapse of today's Internet. Similar algorithms are specified for collapse of today's Internet. Similar algorithms are specified for
other non-TCP transports. other non-TCP transports.
However, that is not the end of the story. Considerable research has However, that is not the end of the story. Considerable research has
been done on Internet dynamics since 1988, and the Internet has been done on Internet dynamics since 1988, and the Internet has
grown. It has become clear that the congestion avoidance mechanisms grown. It has become clear that the congestion avoidance mechanisms
[RFC5681], while necessary and powerful, are not sufficient to [RFC5681], while necessary and powerful, are not sufficient to
provide good service in all circumstances. Basically, there is a provide good service in all circumstances. Basically, there is a
limit to how much control can be accomplished from the edges of the limit to how much control can be accomplished from the edges of the
network. Some mechanisms are needed in the network devices to network. Some mechanisms are needed in network devices to complement
complement the endpoint congestion avoidance mechanisms. These the endpoint congestion avoidance mechanisms. These mechanisms may
mechanisms may be implemented in network devices that include be implemented in network devices.
routers, switches, and other network middleboxes.
1.2. Active Queue Management to Manage Latency 1.2. Active Queue Management to Manage Latency
Internet latency has become a focus of attention to increase the Internet latency has become a focus of attention to increase the
responsiveness of Internet applications and protocols. One major responsiveness of Internet applications and protocols. One major
source of delay is the build-up of queues in network devices. source of delay is the build-up of queues in network devices.
Queueing occurs whenever the arrival rate of data at the ingress to a Queueing occurs whenever the arrival rate of data at the ingress to a
device exceeds the current egress rate. Such queueing is normal in a device exceeds the current egress rate. Such queueing is normal in a
packet-switched network and often necessary to absorb bursts in packet-switched network and is often necessary to absorb bursts in
transmission and perform statistical multiplexing of traffic, but transmission and perform statistical multiplexing of traffic, but
excessive queueing can lead to unwanted delay, reducing the excessive queueing can lead to unwanted delay, reducing the
performance of some Internet applications. performance of some Internet applications.
RFC 2309 introduced the concept of "Active Queue Management" (AQM), a RFC 2309 introduced the concept of "Active Queue Management" (AQM), a
> class of technologies that, by signaling to common congestion- class of technologies that, by signaling to common congestion-
controlled transports such as TCP, manages the size of queues that controlled transports such as TCP, manages the size of queues that
build in network buffers. RFC 2309 also describes a specific AQM build in network buffers. RFC 2309 also describes a specific AQM
algorithm, Random Early Detection (RED), and recommends that this be algorithm, Random Early Detection (RED), and recommends that this be
widely implemented and used by default in routers. widely implemented and used by default in routers.
With an appropriate set of parameters, RED is an effective algorithm. With an appropriate set of parameters, RED is an effective algorithm.
However, dynamically predicting this set of parameters was found to However, dynamically predicting this set of parameters was found to
be difficult. As a result, RED has not been enabled by default, and be difficult. As a result, RED has not been enabled by default, and
its present use in the Internet is limited. Other AQM algorithms its present use in the Internet is limited. Other AQM algorithms
have been developed since RC2309 was published, some of which are have been developed since RC2309 was published, some of which are
self-tuning within a range of applicability. Hence, while this memo self-tuning within a range of applicability. Hence, while this memo
continues to recommend the deployment of AQM, it no longer recommends continues to recommend the deployment of AQM, it no longer recommends
that RED or any other specific algorithm is used as a default; that RED or any other specific algorithm is used as a default;
instead it provides recommendations on how to select appropriate instead it provides recommendations on how to select appropriate
algorithms and recommends that algorithms should be used that a algorithms and that a recommended algorithm is able to automate any
recommended algorithm is able to automate any required tuning for required tuning for common deployment scenarios.
common deployment scenarios.
Deploying AQM in the network can significantly reduce the latency Deploying AQM in the network can significantly reduce the latency
across an Internet path and since writing RFC2309, this has become a across an Internet path and since writing RFC2309, this has become a
key motivation for using AQM in the Internet. In the context of AQM, key motivation for using AQM in the Internet. In the context of AQM,
it is useful to distinguish between two related classes of it is useful to distinguish between two related classes of
algorithms: "queue management" versus "scheduling" algorithms. To a algorithms: "queue management" versus "scheduling" algorithms. To a
rough approximation, queue management algorithms manage the length of rough approximation, queue management algorithms manage the length of
packet queues by marking or dropping packets when necessary or packet queues by marking or dropping packets when necessary or
appropriate, while scheduling algorithms determine which packet to appropriate, while scheduling algorithms determine which packet to
send next and are used primarily to manage the allocation of send next and are used primarily to manage the allocation of
skipping to change at page 7, line 28 skipping to change at page 8, line 4
data. Normally small queues are preferred in network devices, data. Normally small queues are preferred in network devices,
with sufficient queue capacity to absorb the bursts. The with sufficient queue capacity to absorb the bursts. The
counter-intuitive result is that maintaining normally-small counter-intuitive result is that maintaining normally-small
queues can result in higher throughput as well as lower end-to- queues can result in higher throughput as well as lower end-to-
end delay. In summary, queue limits should not reflect the end delay. In summary, queue limits should not reflect the
steady state queues we want to be maintained in the network; steady state queues we want to be maintained in the network;
instead, they should reflect the size of bursts that a network instead, they should reflect the size of bursts that a network
device needs to absorb. device needs to absorb.
2. Lock-Out 2. 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 the queue space starving other connection flows to monopolize the queue space starving other connections,
preventing them from getting room in the queue [Flo92]. preventing them from getting room in the queue [Flo92].
3. Mitigating the Impact of Packet Bursts 3. Mitigating the Impact of Packet Bursts
Large burst of packets can delay other packets, disrupting the Large burst of packets can delay other packets, disrupting the
control loop (e.g. the pacing of flows by the TCP ACK-Clock), and control loop (e.g. the pacing of flows by the TCP ACK-Clock), and
reducing the performance of flows that share a common bottleneck. reducing the performance of flows that share a common bottleneck.
4. Control loop synchronization 4. Control loop synchronization
skipping to change at page 12, line 4 skipping to change at page 12, line 28
1. TCP-Friendly flows 1. TCP-Friendly flows
A TCP-friendly flow responds to congestion notification within a A TCP-friendly flow responds to congestion notification within a
small number of path Round Trip Times (RTT), and in steady-state small number of path Round Trip Times (RTT), and in steady-state
it uses no more capacity than a conformant TCP running under it uses no more capacity than a conformant TCP running under
comparable conditions (drop rate, RTT, packet size, etc.). This comparable conditions (drop rate, RTT, packet size, etc.). This
is described in the remainder of the document. is described in the remainder of the document.
2. Non-Responsive Flows 2. Non-Responsive Flows
A flow that does not adjust its rate in response to congestion
notification within a small number of path RTTs, can also use
more capacity than a conformant TCP running under comparable
conditions. There is a growing set of applications whose
congestion avoidance algorithms are inadequate or nonexistent
(i.e., a flow that does not throttle its sending rate when it
experiences congestion).
The User Datagram Protocol (UDP) [RFC0768] provides a minimal, The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
best-effort transport to applications and upper-layer protocols best-effort transport to applications and upper-layer protocols
(both simply called "applications" in the remainder of this (both simply called "applications" in the remainder of this
document) and does not itself provide mechanisms to prevent document) and does not itself provide mechanisms to prevent
congestion collapse and establish a degree of fairness [RFC5405]. congestion collapse and establish a degree of fairness [RFC5405].
Examples that use UDP include some streaming applications for
packet voice and video, and some multicast bulk data transport.
Other traffic, when aggregated may also become unresponsive to
congestion notification. If no action is taken, such
unresponsive flows could lead to a new congestion collapse
[RFC2914]. Some applications can even increase their traffic
volume in response to congestion (e.g. by adding forward error
correction when loss is experienced), with the possibility that
they contribute to congestion collapse.
There is a growing set of UDP-based applications whose congestion In general, applications need to incorporate effective congestion
avoidance algorithms are inadequate or nonexistent (i.e, a flow avoidance mechanisms [RFC5405]. Research continues to be needed
that does not throttle its sending rate when it experiences to identify and develop ways to accomplish congestion avoidance
congestion). Examples include some UDP streaming applications for presently unresponsive applications. Network devices need to
for packet voice and video, and some multicast bulk data be able to protect themselves against unresponsive flows, and
transport. If no action is taken, such unresponsive flows could mechanisms to accomplish this must be developed and deployed.
lead to a new congestion collapse. Some applications can even Deployment of such mechanisms would provide an incentive for all
increase their traffic volume in response to congestion (e.g. by applications to become responsive by either using a congestion-
adding forward error correction when loss is experienced), with controlled transport (e.g. TCP, SCTP [RFC4960] and DCCP
the possibility that they contribute to congestion collapse. [RFC4340].) or by incorporating their own congestion control in
the application [RFC5405], [RFC6679].
In general, UDP-based applications need to incorporate effective
congestion avoidance mechanisms [RFC5405]. Research continues to
be needed to identify and develop ways to accomplish congestion
avoidance for presently unresponsive applications. Network
devices need to be able to protect themselves against
unresponsive flows, and mechanisms to accomplish this must be
developed and deployed. Deployment of such mechanisms would
provide an incentive for all applications to become responsive by
either using a congestion-controlled transport (e.g. TCP, SCTP
[RFC4960] and DCCP [RFC4340].) or by incorporating their own
congestion control in the application [RFC5405], [RFC6679].
Lastly, some applications (e.g. current web browsers) open a
large numbers of short TCP flows for a single session. This can
lead to each individual flow spending the majority of time in the
exponential TCP slow start phase, rather than in TCP congestion
avoidance. The resulting traffic aggregate can therefore be much
less responsive than a single standard TCP flow.
3. Transport Flows that are less responsive than TCP 3. Transport Flows that are less responsive than TCP
A second threat is posed by transport protocol implementations A second threat is posed by transport protocol implementations
that are responsive to congestion, but, either deliberately or that are responsive to congestion, but, either deliberately or
through faulty implementation, reduce less than a TCP flow would through faulty implementation, reduce less than a TCP flow would
have done in response to congestion. This covers a spectrum of have done in response to congestion. This covers a spectrum of
behaviours between (1) and (2). If applications are not behaviours between (1) and (2). If applications are not
sufficiently responsive to congestion signals, they may gain an sufficiently responsive to congestion signals, they may gain an
unfair share of the available network capacity. unfair share of the available network capacity.
skipping to change at page 13, line 25 skipping to change at page 13, line 50
adaptive codec, but responds incompletely to indications of adaptive codec, but responds incompletely to indications of
congestion or responds over an excessively long time period. congestion or responds over an excessively long time period.
Such flows are unlikely to be responsive to congestion signals in Such flows are unlikely to be responsive to congestion signals in
a timeframe comparable to a small number of end-to-end a timeframe comparable to a small number of end-to-end
transmission delays. However, over a longer timescale, perhaps transmission delays. However, over a longer timescale, perhaps
seconds in duration, they could moderate their speed, or increase seconds in duration, they could moderate their speed, or increase
their speed if they determine capacity to be available. their speed if they determine capacity to be available.
Tunneled traffic aggregates carrying multiple (short) TCP flows Tunneled traffic aggregates carrying multiple (short) TCP flows
can be more aggressive than standard bulk TCP. Applications can be more aggressive than standard bulk TCP. Applications
(e.g. web browsers and peer-to-peer file-sharing) have exploited (e.g., web browsers primarily supporting HTTP 1.1 and peer-to-
this by opening multiple connections to the same endpoint. peer file-sharing) have exploited this by opening multiple
connections to the same endpoint.
Lastly, some applications (e.g., web browsers primarily
supporting HTTP 1.1) open a large numbers of succesive short TCP
flows for a single session. This can lead to each individual
flow spending the majority of time in the exponential TCP slow
start phase, rather than in TCP congestion avoidance. The
resulting traffic aggregate can therefore be much less responsive
than a single standard TCP flow.
The projected increase in the fraction of total Internet traffic for The projected increase in the fraction of total Internet traffic for
more aggressive flows in classes 2 and 3 could pose a threat to the more aggressive flows in classes 2 and 3 could pose a threat to the
performance of the future Internet. There is therefore an urgent performance of the future Internet. There is therefore an urgent
need for measurements of current conditions and for further research need for measurements of current conditions and for further research
into the ways of managing such flows. This raises many difficult into the ways of managing such flows. This raises many difficult
issues in finding methods with an acceptable overhead cost that can issues in finding methods with an acceptable overhead cost that can
identify and isolate unresponsive flows or flows that are less identify and isolate unresponsive flows or flows that are less
responsive than TCP. Finally, there is as yet little measurement or responsive than TCP. Finally, there is as yet little measurement or
simulation evidence available about the rate at which these threats simulation evidence available about the rate at which these threats
are likely to be realized, or about the expected benefit of are likely to be realized, or about the expected benefit of
algorithms for managing such flows. algorithms for managing such flows.
Another topic requiring consideration is the appropriate granularity Another topic requiring consideration is the appropriate granularity
of a "flow" when considering a queue management method. There are a of a "flow" when considering a queue management method. There are a
few "natural" answers: 1) a transport (e.g. TCP or UDP) flow (source few "natural" answers: 1) a transport (e.g.,TCP or UDP) flow (source
address/port, destination address/port, protocol); 2) Differentiated address/port, destination address/port, protocol); 2) Differentiated
Services Code Point, DSCP; 3) a source/destination host pair (IP Services Code Point, DSCP; 3) a source/destination host pair (IP
address); 4) a given source host or a given destination host, or address); 4) a given source host or a given destination host, or
various combinations of the above; 5) a subscriber or site receiving various combinations of the above; 5) a subscriber or site receiving
the Internet service (enterprise or residential). the Internet service (enterprise or residential).
The source/destination host pair gives an appropriate granularity in The source/destination host pair gives an appropriate granularity in
many circumstances, However, different vendors/providers use many circumstances, However, different vendors/providers use
different granularities for defining a flow (as a way of different granularities for defining a flow (as a way of
"distinguishing" themselves from one another), and different "distinguishing" themselves from one another), and different
skipping to change at page 14, line 27 skipping to change at page 15, line 13
recommendations provided by this document are summarised as: recommendations provided by this document are summarised as:
1. Network devices SHOULD implement some AQM mechanism to manage 1. Network devices SHOULD implement some AQM mechanism to manage
queue lengths, reduce end-to-end latency, and avoid lock-out queue lengths, reduce end-to-end latency, and avoid lock-out
phenomena within the Internet. phenomena within the Internet.
2. Deployed AQM algorithms SHOULD support Explicit Congestion 2. Deployed AQM algorithms SHOULD support Explicit Congestion
Notification (ECN) as well as loss to signal congestion to Notification (ECN) as well as loss to signal congestion to
endpoints. endpoints.
3. The algorithms that the IETF recommends SHOULD NOT require 3. AQM algorithms SHOULD NOT require tuning of initial or
operational (especially manual) configuration or tuning. configuration parameters in common use cases.
4. AQM algorithms SHOULD respond to measured congestion, not 4. AQM algorithms SHOULD respond to measured congestion, not
application profiles. application profiles.
5. AQM algorithms SHOULD NOT interpret specific transport protocol 5. AQM algorithms SHOULD NOT interpret specific transport protocol
behaviours. behaviours.
6. Transport protocol congestion control algorithms SHOULD maximize 6. Transport protocol congestion control algorithms SHOULD maximize
their use of available capacity (when there is data to send) their use of available capacity (when there is data to send)
without incurring undue loss or undue round trip delay. without incurring undue loss or undue round trip delay.
skipping to change at page 16, line 16 skipping to change at page 16, line 49
reported RTT and increased latency can trigger a sender to adjust its reported RTT and increased latency can trigger a sender to adjust its
rate. Methods such as Low Extra Delay Background Transport (LEDBAT) rate. Methods such as Low Extra Delay Background Transport (LEDBAT)
[RFC6817] assume increased latency as a primary signal of congestion. [RFC6817] assume increased latency as a primary signal of congestion.
Appropriate use of delay-based methods and the implications of AQM Appropriate use of delay-based methods and the implications of AQM
presently remains an area for further research. presently remains an area for further research.
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, 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." Applications using unreliable transports (e.g.,using
similarly react to loss [RFC5405] UDP) need to similarly react to loss [RFC5405]
Network devices SHOULD use an AQM algorithm to measure local local Network devices SHOULD use an AQM algorithm to measure local
congestion and to determine the packets to mark or drop so that the congestion and to determine the packets to mark or drop so that the
congestion is managed. congestion is managed.
In general, dropping multiple packets from the same sessions in the In general, dropping multiple packets from the same sessions in the
same RTT is ineffective, and can reduce throughput. Also, dropping same RTT is ineffective, and can reduce throughput. Also, dropping
or marking packets from multiple sessions simultaneously can have the or marking packets from multiple sessions simultaneously can have the
effect of synchronizing them, resulting in increasing peaks and effect of synchronizing them, resulting in increasing peaks and
troughs in the subsequent traffic load. Hence, AQM algorithms SHOULD troughs in the subsequent traffic load. Hence, AQM algorithms SHOULD
randomize dropping in time, to reduce the probability that congestion randomize dropping in time, to reduce the probability that congestion
indications are only experienced by a small proportion of the active indications are only experienced by a small proportion of the active
skipping to change at page 17, line 38 skipping to change at page 18, line 24
2. A non-conformant, broken or malicious sender could ignore a 2. A non-conformant, broken or malicious sender could ignore a
reported ECN mark, as it could ignore a loss without using ECN; reported ECN mark, as it could ignore a loss without using ECN;
3. A malfunctioning or non-conforming network device may "hide" an 3. A malfunctioning or non-conforming network device may "hide" an
ECN mark (or fail to correctly set the ECN codepoint at an egress ECN mark (or fail to correctly set the ECN codepoint at an egress
of a network tunnel). of a network tunnel).
In normal operation, such cases should be very uncommon, however In normal operation, such cases should be very uncommon, however
overload protection is desirable to protect traffic from overload protection is desirable to protect traffic from
misconfigured or malicious use of ECN (e.g. a denial-of-service misconfigured or malicious use of ECN (e.g., a denial-of-service
attack that generates ECN-capable traffic that is unresponsive to CE- attack that generates ECN-capable traffic that is unresponsive to CE-
marking). marking).
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 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.
AQM algorithms need to consider both "initial conditions" and AQM algorithms need to consider both "initial conditions" and
skipping to change at page 18, line 24 skipping to change at page 19, line 9
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 SHOULD NOT require tuning of initial or configuration parameters. o AQM algorithm deployment SHOULD NOT require tuning in common use
An algorithm needs to provide a default behaviour that auto-tunes cases. An algorithm needs to provide a default behaviour that
to a reasonable performance for typical network operational auto-tunes to a reasonable performance for typical network
conditions. This is expected to ease deployment and operation. operational conditions. This is expected to ease deployment and
Initial conditions, such as the interface rate and MTU size or operation. Initial conditions, such as the interface rate and MTU
other values derived from these, MAY be required by an AQM size or other values derived 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
skipping to change at page 19, line 16 skipping to change at page 19, line 49
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 characterized 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
SHOULD observe the actual or projected time that a packet is in a SHOULD observe the actual or projected time that a packet is in a
queue (bytes at a rate being an analog to time). When an AQM queue (bytes at a rate being an analog to time). When an AQM
algorithm decides whether to drop (or mark) a packet, it is algorithm decides whether to drop (or mark) a packet, it is
RECOMMENDED that the size of the particular packet should not be RECOMMENDED that the size of the particular packet should not be
taken into account [RFC7141]. taken into account [RFC7141].
Applications (or transports) generally know the packet size that they Applications (or transports) generally know the packet size that they
are using and can hence make their judgments about whether to use are using and can hence make their judgments about whether to use
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 [RFC7141]. to the size of the packet that was sent [RFC7141].
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 Differentiated Services Code Point (DSCP) [RFC5559], the packet Differentiated Services Code Point (DSCP) [RFC5559],
enabling use of the ECN field (i.e. any of ECT(0), ECT(1) or enabling use of the ECN field (i.e., any of ECT(0), ECT(1) or
CE)[RFC3168] [RFC4774], a multi-field (MF) classifier that combines CE)[RFC3168] [RFC4774], a multi-field (MF) classifier that combines
the values of a set of protocol fields (e.g. IP address, transport, the values of a set of protocol fields (e.g., IP address, transport,
ports) or an equivalent codepoint at a lower layer. This ports) or an equivalent codepoint at a lower layer. This
recommendation goes beyond what is defined in RFC 3168, by allowing recommendation goes beyond what is defined in RFC 3168, by allowing
that an implementation MAY use more than one instance of an AQM that an implementation MAY use more than one instance of an AQM
algorithm to handle both ECN-capable and non-ECN-capable packets. 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
skipping to change at page 20, line 28 skipping to change at page 21, line 11
significant use of UDP [RFC0768] in voice and video services, and significant use of UDP [RFC0768] in voice and video services, and
some applications find utility in SCTP [RFC4960] and DCCP [RFC4340]. some applications find utility in SCTP [RFC4960] and DCCP [RFC4340].
Hence, AQM algorithms should also demonstrate operation with Hence, AQM algorithms should also demonstrate operation with
transports other than TCP and need to consider a variety of transports other than TCP and need to consider a variety of
applications. Selection of AQM algorithms also needs to consider use applications. Selection of AQM algorithms also needs to consider use
of tunnel encapsulations that may carry traffic aggregates. of tunnel encapsulations that may carry traffic aggregates.
AQM algorithms SHOULD NOT target or derive implicit assumptions about AQM algorithms SHOULD NOT target or derive implicit assumptions about
the characteristics desired by specific transports/applications. the characteristics desired by specific transports/applications.
Transports and applications need to respond to the congestion signals Transports and applications need to respond to the congestion signals
provided by AQM (i.e. dropping or ECN-marking) in a timely manner provided by AQM (i.e., dropping or ECN-marking) in a timely manner
(within a few RTT at the latest). (within a few RTT at the latest).
4.6. Interactions with congestion control algorithms 4.6. Interactions with congestion control algorithms
Applications and transports need to react to received implicit or Applications and transports need to react to received implicit or
explicit signals that indicate the presence of congestion. This explicit signals that indicate the presence of congestion. This
section identifies issues that can impact the design of transport section identifies issues that can impact the design of transport
protocols when using paths that use AQM. protocols when using paths that use AQM.
Transport protocols and applications need timely signals of Transport protocols and applications need timely signals of
congestion. The time taken to detect and respond to congestion is congestion. The time taken to detect and respond to congestion is
increased when network devices queue packets in buffers. It can be increased when network devices queue packets in buffers. It can be
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 of an elastic transport congestion control A common objective of an elastic transport congestion control
protocol is to allow an application to deliver the maximum rate of protocol is to allow an application to deliver the maximum rate of
data without inducing excessive delays when packets are queued in a data without inducing excessive delays when packets are queued in a
buffers within the network. To achieve this, a transport should try buffers within the network. To achieve this, a transport should try
to operate at rate below the inflexion point of the load/delay curve to operate at rate below the inflexion point of the load/delay curve
(the bend of what is sometimes called a "hockey-stick" curve) (the bend of what is sometimes called a "hockey-stick" curve)
[Jain94]. When the congestion window allows the load to approach [Jain94]. When the congestion window allows the load to approach
this bend, the end-to-end delay starts to rise - a result of this bend, the end-to-end delay starts to rise - a result of
congestion, as packets probabilistically arrive at non-overlapping congestion, as packets probabilistically arrive at non-overlapping
times. On the one hand, a transport that operates above this point times. On the one hand, a transport that operates above this point
can experience congestion loss and could also trigger operator can experience congestion loss and could also trigger operator
activities, such as those discussed in [RFC6057]. On the other hand, activities, such as those discussed in [RFC6057]. On the other hand,
a flow may achieve both near-maximum throughput and low latency when a flow may achieve both near-maximum throughput and low latency when
it operates close to this knee point, with minimal contribution to it operates close to this knee point, with minimal contribution to
router congestion. Choice of an appropriate rate/congestion window router congestion. Choice of an appropriate rate/congestion window
can therefore significantly impact the loss and delay experienced by can therefore significantly impact the loss and delay experienced by
skipping to change at page 21, line 20 skipping to change at page 21, line 51
activities, such as those discussed in [RFC6057]. On the other hand, activities, such as those discussed in [RFC6057]. On the other hand,
a flow may achieve both near-maximum throughput and low latency when a flow may achieve both near-maximum throughput and low latency when
it operates close to this knee point, with minimal contribution to it operates close to this knee point, with minimal contribution to
router congestion. Choice of an appropriate rate/congestion window router congestion. Choice of an appropriate rate/congestion window
can therefore significantly impact the loss and delay experienced by can therefore significantly impact the loss and delay experienced by
a flow and will impact other flows that share a common network queue. a flow and will impact other flows that share a common network 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, interactive
transaction-based protocols). Such applications may have different server-based gaming, transaction-based protocols). Such applications
objectives. They may not wish to maximize throughput, but may desire may have different objectives. They may not wish to maximize
a lower loss rate or bounded delay. throughput, but may desire 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,
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.
skipping to change at page 21, line 47 skipping to change at page 22, line 30
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. At the time of writing
(in 2015), an obvious example of further research is the need to (in 2015), an obvious example of further research is the need to
consider the many-to-one communication patterns found in data consider the many-to-one communication patterns found in data
centers, known as incast [Ren12], (e.g., produced by Map/Reduce centers, known as incast [Ren12], (e.g., produced by Map/Reduce
applications). 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 22, line 41 skipping to change at page 23, line 28
5. IANA Considerations 5. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
6. Security Considerations 6. Security Considerations
While security is a very important issue, it is largely orthogonal to While security is a very important issue, it is largely orthogonal to
the performance issues discussed in this memo. the performance issues discussed in this memo.
This recommendation requires algorithms to be independent of specific
transport or application behaviors. Therefore a network device does
not require visibility or access to upper layer protocol information
to implement an AQM algorithm. This ability to operate in an
application-agnostic fashion is therefore an example of a privacy-
enhancing feature.
Many deployed network devices use queueing methods that allow Many deployed network devices use queueing methods that allow
unresponsive traffic to capture network capacity, denying access to unresponsive traffic to capture network capacity, denying access to
other traffic flows. This could potentially be used as a denial-of- other traffic flows. This could potentially be used as a denial-of-
service attack. This threat could be reduced in network devices service attack. This threat could be reduced in network devices that
deploy AQM or some form of scheduling. We note, however, that a deploy AQM or some form of scheduling. We note, however, that a
denial-of-service attack that results in unresponsive traffic flows denial-of-service attack that results in unresponsive traffic flows
may be indistinguishable from other traffic flows (e.g. tunnels may be indistinguishable from other traffic flows (e.g., tunnels
carrying aggregates of short flows, high-rate isochronous carrying aggregates of short flows, high-rate isochronous
applications). New methods therefore may remain vulnerable, and this applications). New methods therefore may remain vulnerable, and this
document recommends that ongoing research should consider ways to document recommends that ongoing research should consider ways to
mitigate such attacks. mitigate such attacks.
7. Privacy Considerations 7. Privacy Considerations
This document, by itself, presents no new privacy issues. This document, by itself, presents no new privacy issues.
8. Acknowledgements 8. Acknowledgements
skipping to change at page 24, line 22 skipping to change at page 25, line 16
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012. for RTP over UDP", RFC 6679, August 2012.
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion [RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion
Notification", BCP 41, RFC 7141, February 2014. Notification", BCP 41, RFC 7141, February 2014.
9.2. Informative References 9.2. Informative References
[AQM-WG] "IETF AQM WG", . [AQM-WG] "IETF AQM WG", .
[Bri15] Briscoe, Bob., Brunstrom, Anna., Petlund, Andreas., Hayes,
David., Ros, David., Tsang, Ing-Jyh., Gjessing, Stein.,
Fairhurst, Gorry., Griwodz, Carsten., and Michael. Welzl,
"Reducing Internet Latency: A Survey of Techniques and
their Merit, IEEE Communications Surveys & Tutorials",
2015.
[CONEX] Mathis, M. and B. Briscoe, "The Benefits to Applications [CONEX] Mathis, M. and B. Briscoe, "The Benefits to Applications
of using Explicit Congestion Notification (ECN)", IETF of using Explicit Congestion Notification (ECN)", IETF
(Work-in-Progress) draft-ietf-conex-abstract-mech, March (Work-in-Progress) draft-ietf-conex-abstract-mech, March
2014. 2014.
[Choi04] Choi, Baek-Young., Moon, Sue., Zhang, Zhi-Li., [Choi04] Choi, Baek-Young., Moon, Sue., Zhang, Zhi-Li.,
Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point
Packet Delay In an Operational Network", March 2004. Packet Delay In an Operational Network", March 2004.
[Dem90] Demers, A., Keshav, S., and S. Shenker, "Analysis and [Dem90] Demers, A., Keshav, S., and S. Shenker, "Analysis and
skipping to change at page 26, line 31 skipping to change at page 27, line 31
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998. 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", RFC Friendly Rate Control (TFRC): Protocol Specification", RFC
5348, September 2008. 5348, September 2008.
skipping to change at page 27, line 9 skipping to change at page 28, line 13
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.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, February 2015.
[Ren12] Ren, Y., Zhao, Y., and P. Liu, "A survey on TCP Incast in [Ren12] Ren, Y., Zhao, Y., and P. Liu, "A survey on TCP Incast in
data center networks, International Journal of data center networks, International Journal of
Communication Systems, Volume 27, Issue 8, pages Communication Systems, Volume 27, Issue 8, pages
1160-117", 1990. 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
skipping to change at page 29, line 5 skipping to change at page 30, line 9
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. -09 WG Draft - Minor edits Jan 2015 - Edits following LC comments.
-10 WG Draft - Minor edits Feb 2015 - Update following IESG Review
o Gorry's Unresolved to-do list
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
Godred Fairhurst (editor) Godred Fairhurst (editor)
 End of changes. 51 change blocks. 
100 lines changed or deleted 211 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/