draft-ietf-aqm-recommendation-07.txt   draft-ietf-aqm-recommendation-08.txt 
Network Working Group F. Baker, Ed. Network Working Group F. Baker, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 2309 (if approved) G. Fairhurst, Ed. Obsoletes: 2309 (if approved) G. Fairhurst, Ed.
Intended status: Best Current Practice University of Aberdeen Intended status: Best Current Practice University of Aberdeen
Expires: February 6, 2015 August 05, 2014 Expires: February 14, 2015 August 13, 2014
IETF Recommendations Regarding Active Queue Management IETF Recommendations Regarding Active Queue Management
draft-ietf-aqm-recommendation-07 draft-ietf-aqm-recommendation-08
Abstract Abstract
This memo presents recommendations to the Internet community This memo presents recommendations to the Internet community
concerning measures to improve and preserve Internet performance. It concerning measures to improve and preserve Internet performance. It
presents a strong recommendation for testing, standardization, and presents a strong recommendation for testing, standardization, and
widespread deployment of active queue management (AQM) in network widespread deployment of active queue management (AQM) in network
devices, to improve the performance of today's Internet. It also devices, to improve the performance of today's Internet. It also
urges a concerted effort of research, measurement, and ultimate urges a concerted effort of research, measurement, and ultimate
deployment of AQM mechanisms to protect the Internet from flows that deployment of AQM mechanisms to protect the Internet from flows that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2015. This Internet-Draft will expire on February 14, 2015.
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 32 skipping to change at page 2, line 32
2.2. AQM and Explicit Congestion Marking (ECN) . . . . . . . . 10 2.2. AQM and Explicit Congestion Marking (ECN) . . . . . . . . 10
2.3. AQM and Buffer Size . . . . . . . . . . . . . . . . . . . 10 2.3. AQM and Buffer Size . . . . . . . . . . . . . . . . . . . 10
3. Managing Aggressive Flows . . . . . . . . . . . . . . . . . . 11 3. Managing Aggressive Flows . . . . . . . . . . . . . . . . . . 11
4. Conclusions and Recommendations . . . . . . . . . . . . . . . 14 4. Conclusions and Recommendations . . . . . . . . . . . . . . . 14
4.1. Operational deployments SHOULD use AQM procedures . . . . 15 4.1. Operational deployments SHOULD use AQM procedures . . . . 15
4.2. Signaling to the transport endpoints . . . . . . . . . . 15 4.2. Signaling to the transport endpoints . . . . . . . . . . 15
4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. AQM and ECN . . . . . . . . . . . . . . . . . . . . . 16
4.3. AQM algorithms deployed SHOULD NOT require operational 4.3. AQM algorithms deployed SHOULD NOT require operational
tuning . . . . . . . . . . . . . . . . . . . . . . . . . 17 tuning . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. AQM algorithms SHOULD respond to measured congestion, not 4.4. AQM algorithms SHOULD respond to measured congestion, not
application profiles. . . . . . . . . . . . . . . . . . . 18 application profiles. . . . . . . . . . . . . . . . . . . 19
4.5. AQM algorithms SHOULD NOT be dependent on specific 4.5. AQM algorithms SHOULD NOT be dependent on specific
transport protocol behaviours . . . . . . . . . . . . . . 19 transport protocol behaviours . . . . . . . . . . . . . . 19
4.6. Interactions with congestion control algorithms . . . . . 20 4.6. Interactions with congestion control algorithms . . . . . 20
4.7. The need for further research . . . . . . . . . . . . . . 21 4.7. The need for further research . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 "congestive 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.
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 experienced by applications. While
there is still a need to avoid congestion collapse, there is now also there is still a need to avoid congestion collapse, there is now also
a focus on reducing network latency using the same technology. a focus on reducing network latency using the same technology.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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) [RFC0768] [RFC1122]. 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 congestive 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 the network devices to
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 recommends that algorithms should be used that a
recommened algorithm is able to automate any required tuning for recommended algorithm is able to automate any 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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
The first issue is the need for an advanced form of queue management The first issue is the need for an advanced form of queue management
that we call "Active Queue Management", AQM. Section 2 summarizes that we call "Active Queue Management", AQM. Section 2 summarizes
the benefits that active queue management can bring. A number of AQM the benefits that active queue management can bring. A number of AQM
procedures are described in the literature, with different procedures are described in the literature, with different
characteristics. This document does not recommend any of them in characteristics. This document does not recommend any of them in
particular, but does make recommendations that ideally would affect particular, but does make recommendations that ideally would affect
the choice of procedure used in a given implementation. the choice of procedure used in a given implementation.
The second issue, discussed in Section 4 of this memo, is the The second issue, discussed in Section 4 of this memo, is the
potential for future congestive collapse of the Internet due to flows potential for future congestion collapse of the Internet due to flows
that are unresponsive, or not sufficiently responsive, to congestion that are unresponsive, or not sufficiently responsive, to congestion
indications. Unfortunately, while scheduling can mitigate some of indications. Unfortunately, while scheduling can mitigate some of
the side-effects of sharing a network queue with an unresponsive the side-effects of sharing a network queue with an unresponsive
flow, there is currently no consensus solution to controlling the flow, there is currently no consensus solution to controlling the
congestion caused by such aggressive flows. Methods such as congestion caused by such aggressive flows. Methods such as
congestion exposure (ConEx) [RFC6789] offer a framework [CONEX] that congestion exposure (ConEx) [RFC6789] offer a framework [CONEX] that
can update network devices to alleviate these effects. Significant can update network devices to alleviate these effects. Significant
research and engineering will be required before any solution will be research and engineering will be required before any solution will be
available. It is imperative that work to mitigate the impact of available. It is imperative that work to mitigate the impact of
unresponsive flows is energetically pursued, to ensure the future unresponsive flows is energetically pursued, to ensure acceptable
stability of the Internet. performance and the future stability of the 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 on the use of AQM and recommendations for defining Internet community on the use of AQM and recommendations for defining
AQM algorithms. AQM algorithms.
1.4. Changes to the recommendations of RFC2309 1.4. Changes to the recommendations of RFC2309
This memo replaces the recommendations in [RFC2309], which resulted This memo replaces the recommendations in [RFC2309], which resulted
from past discussions of end-to-end performance, Internet congestion, from past discussions of end-to-end performance, Internet congestion,
and RED in the End-to-End Research Group of the Internet Research and RED in the End-to-End Research Group of the Internet Research
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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 connection
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 synchronisation 4. Control loop synchronization
Congestion control, like other end-to-end mechanisms, introduces Congestion control, like other end-to-end mechanisms, introduces
a control loop between hosts. Sessions that share a common a control loop between hosts. Sessions that share a common
network bottleneck can therefore become synchronised, introducing network bottleneck can therefore become synchronised, introducing
periodic disruption (e.g. jitter/loss). "lock-out" is often also periodic disruption (e.g. jitter/loss). "lock-out" is often also
the result of synchronization or other timing effects the result of synchronization or other timing effects
Besides tail drop, two alternative queue management disciplines that Besides tail drop, two alternative queue management disciplines that
can be applied when a queue becomes full are "random drop on full" or can be applied when a queue becomes full are "random drop on full" or
"head drop on full". When a new packet arrives at a full queue using "head drop on full". When a new packet arrives at a full queue using
skipping to change at page 9, line 28 skipping to change at page 9, line 28
benefit "increased fairness", because general fairness among benefit "increased fairness", because general fairness among
flows requires per-flow state, which is not provided by queue flows requires per-flow state, which is not provided by queue
management. For example, in a network device using AQM with only management. For example, in a network device using AQM with only
FIFO scheduling, two TCP flows may receive very different share FIFO scheduling, two TCP flows may receive very different share
of the network capacity simply because they have different round- of the network capacity simply because they have different round-
trip times [Floyd91], and a flow that does not use congestion trip times [Floyd91], and a flow that does not use congestion
control may receive more capacity than a flow that does. AQM can control may receive more capacity than a flow that does. AQM can
therefore be combined with a scheduling mechanism that divides therefore be combined with a scheduling mechanism that divides
network traffic between multiple queues (section 2.1). network traffic between multiple queues (section 2.1).
4. Reduce the probability of control loop synchronisation 4. Reduce the probability of control loop synchronization
The probability of network control loop synchronisation can be The probability of network control loop synchronization can be
reduced if network devices introduce randomness in the AQM reduced if network devices introduce randomness in the AQM
functions that trigger congestion avoidance at the sending host. functions that trigger congestion avoidance at the sending host.
2.1. AQM and Multiple Queues 2.1. AQM and Multiple Queues
A network device may use per-flow or per-class queuing with a A network device may use per-flow or per-class queuing with a
scheduling algorithm to either prioritise certain applications or scheduling algorithm to either prioritize certain applications or
classes of traffic, limit the rate of transmission, or to provide classes of traffic, limit the rate of transmission, or to provide
isolation between different traffic flows within a common class. For isolation between different traffic flows within a common class. For
example, a router may maintain per-flow state to achieve general example, a router may maintain per-flow state to achieve general
fairness by a per-flow scheduling algorithm such as various forms of fairness by a per-flow scheduling algorithm such as various forms of
Fair Queueing (FQ) [Dem90] [Sut99], including Weighted Fair Queuing Fair Queueing (FQ) [Dem90] [Sut99], including Weighted Fair Queuing
(WFQ), Stochastic Fairness Queueing (SFQ) [McK90] Deficit Round Robin (WFQ), Stochastic Fairness Queueing (SFQ) [McK90] Deficit Round Robin
(DRR) [Shr96], [Nic12], and/or a Class-Based Queue scheduling (DRR) [Shr96], [Nic12], and/or a Class-Based Queue scheduling
algorithm such as CBQ [Floyd95]. Hierarchical queues may also be algorithm such as CBQ [Floyd95]. Hierarchical queues may also be
used e.g., as a part of a Hierarchical Token Bucket (HTB), or used e.g., as a part of a Hierarchical Token Bucket (HTB), or
Hierarchical Fair Service Curve (HFSC) [Sto97]. These methods are Hierarchical Fair Service Curve (HFSC) [Sto97]. These methods are
also used to realise a range of Quality of Service (QoS) behaviours also used to realize a range of Quality of Service (QoS) behaviours
designed to meet the need of traffic classes (e.g. using the designed to meet the need of traffic classes (e.g. using the
integrated or differentiated service models). integrated or differentiated service models).
AQM is needed even for network devices that use per-flow or per-class AQM is needed even for network devices that use per-flow or per-class
queuing, because scheduling algorithms by themselves do not control queuing, because scheduling algorithms by themselves do not control
the overall queue size or the size of individual queues. AQM the overall queue size or the size of individual queues. AQM
mechanisms might need to control the overall queue sizes, to ensure mechanisms might need to control the overall queue sizes, to ensure
that arriving bursts can be accommodated without dropping packets. that arriving bursts can be accommodated without dropping packets.
AQM should also be used to control the queue size for each individual AQM should also be used to control the queue size for each individual
flow or class, so that they do not experience unnecessarily high flow or class, so that they do not experience unnecessarily high
skipping to change at page 11, line 38 skipping to change at page 11, line 38
In this document a flow is known as "TCP-friendly" when it has a In this document a flow is known as "TCP-friendly" when it has a
congestion response that approximates the average response expected congestion response that approximates the average response expected
of a TCP flow. One example method of a TCP-friendly scheme is the of a TCP flow. One example method of a TCP-friendly scheme is the
TCP-Friendly Rate Control algorithm [RFC5348]. In this document, the TCP-Friendly Rate Control algorithm [RFC5348]. In this document, the
term is used more generally to describe this and other algorithms term is used more generally to describe this and other algorithms
that meet these goals. that meet these goals.
There are a variety of types of network flow. Some convenient There are a variety of types of network flow. Some convenient
classes that describe flows are: (1) TCP Friendly flows, (2) classes that describe flows are: (1) TCP Friendly flows, (2)
unresponsive flows, i.e., flows that do not slow down when congestion unresponsive flows, i.e., flows that do not slow down when congestion
occurs, and (3) flows that are responsive but are not TCP-friendly. occurs, and (3) flows that are responsive but are less responsive to
The last two classes contain more aggressive flows that pose congestion than TCP. The last two classes contain more aggressive
significant threats to Internet performance, which we will now flows that can pose significant threats to Internet performance.
discuss.
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
skipping to change at page 12, line 16 skipping to change at page 12, line 16
(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].
There is a growing set of UDP-based applications whose congestion There is a growing set of UDP-based applications whose congestion
avoidance algorithms are inadequate or nonexistent (i.e, a flow avoidance algorithms are inadequate or nonexistent (i.e, a flow
that does not throttle its sending rate when it experiences that does not throttle its sending rate when it experiences
congestion). Examples include some UDP streaming applications congestion). Examples include some UDP streaming applications
for packet voice and video, and some multicast bulk data for packet voice and video, and some multicast bulk data
transport. If no action is taken, such unresponsive flows could transport. If no action is taken, such unresponsive flows could
lead to a new congestive collapse. lead to a new congestion collapse. 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.
In general, UDP-based applications need to incorporate effective In general, UDP-based applications need to incorporate effective
congestion avoidance mechanisms [RFC5405]. Further research and congestion avoidance mechanisms [RFC5405]. Further research and
development of ways to accomplish congestion avoidance for development of ways to accomplish congestion avoidance for
presently unresponsive applications continue to be important. presently unresponsive applications continue to be important.
Network devices need to be able to protect themselves against Network devices need to be able to protect themselves against
unresponsive flows, and mechanisms to accomplish this must be unresponsive flows, and mechanisms to accomplish this must be
developed and deployed. Deployment of such mechanisms would developed and deployed. Deployment of such mechanisms would
provide an incentive for all applications to become responsive by provide an incentive for all applications to become responsive by
either using a congestion-controlled transport (e.g. TCP, SCTP either using a congestion-controlled transport (e.g. TCP, SCTP
[RFC4960] and DCCP [RFC4340].) or by incorporating their own [RFC4960] and DCCP [RFC4340].) or by incorporating their own
congestion control in the application [RFC5405], [RFC6679]. congestion control in the application [RFC5405], [RFC6679].
Lastly, some applications (e.g. current web browsers) open a Lastly, some applications (e.g. current web browsers) open a
large numbers of short TCP flows for a single session. This can large numbers of short TCP flows for a single session. This can
lead to each individual flow spending the majority of time in the lead to each individual flow spending the majority of time in the
exponential TCP slow start phase, rather than in TCP congestion exponential TCP slow start phase, rather than in TCP congestion
avoidance. The resulting traffic aggregate can therefore be much avoidance. The resulting traffic aggregate can therefore be much
less responsive than a single standard TCP flow. less responsive than a single standard TCP flow.
3. Non-TCP-friendly Transport Protocols 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, are not TCP-friendly. Such through faulty implementation, reduce less than a TCP flow would
applications may gain an unfair share of the available network have done in response to congestion. This covers a spectrum of
capacity. behaviours between (1) and (2). If applications are not
sufficiently responsive to congestion signals, they may gain an
unfair share of the available network capacity.
For example, the popularity of the Internet has caused a For example, the popularity of the Internet has caused a
proliferation in the number of TCP implementations. Some of proliferation in the number of TCP implementations. Some of
these may fail to implement the TCP congestion avoidance these may fail to implement the TCP congestion avoidance
mechanisms correctly because of poor implementation. Others may mechanisms correctly because of poor implementation. Others may
deliberately be implemented with congestion avoidance algorithms deliberately be implemented with congestion avoidance algorithms
that are more aggressive in their use of capacity than other TCP that are more aggressive in their use of capacity than other TCP
implementations; this would allow a vendor to claim to have a implementations; this would allow a vendor to claim to have a
"faster TCP". The logical consequence of such implementations "faster TCP". The logical consequence of such implementations
would be a spiral of increasingly aggressive TCP implementations, would be a spiral of increasingly aggressive TCP implementations,
skipping to change at page 13, line 24 skipping to change at page 13, line 29
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 and peer-to-peer file-sharing) have exploited
this by opening multiple connections to the same endpoint. this by opening multiple connections to the same endpoint.
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 clearly poses a threat to more aggressive flows in classes 2 and 3 could pose a threat to the
future Internet stability. There is an urgent need for measurements performance of the future Internet. There is therefore an urgent
of current conditions and for further research into the ways of need for measurements of current conditions and for further research
managing such flows. This raises many difficult issues in into the ways of managing such flows. This raises many difficult
identifying and isolating unresponsive or non-TCP-friendly flows at issues in finding methods with an acceptable overhead cost that can
an acceptable overhead cost. Finally, there is as yet little identify and isolate unresponsive flows or flows that are less
measurement or simulation evidence available about the rate at which responsive than TCP. Finally, there is as yet little measurement or
these threats are likely to be realized, or about the expected simulation evidence available about the rate at which these threats
benefit of algorithms for managing such flows. are likely to be realized, or about the expected benefit of
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).
skipping to change at page 16, line 24 skipping to change at page 16, line 27
that there is potential congestion using a pragmatic heuristic; "when that there is potential congestion using a pragmatic heuristic; "when
the network discards a message in flight, it may imply the presence the network discards a message in flight, it may imply the presence
of faulty equipment or media in a path, and it may imply the presence of faulty equipment or media in a path, and it may imply the presence
of congestion. To be conservative, a transport must assume it may be of congestion. To be conservative, a transport must assume it may be
the latter." Unreliable transports (e.g. using UDP) need to the latter." Unreliable transports (e.g. using UDP) need to
similarly react to loss [RFC5405] similarly react to loss [RFC5405]
Network devices SHOULD use an AQM algorithm to determine the packets Network devices SHOULD use an AQM algorithm to determine the packets
that are marked or discarded due to congestion. Procedures for that are marked or discarded due to congestion. Procedures for
dropping or marking packets within the network need to avoid dropping or marking packets within the network need to avoid
increasing synchronisation events, and hence randomness SHOULD be increasing synchronization events, and hence randomness SHOULD be
introduced in the algorithms that generate these congestion signals introduced in the algorithms that generate these congestion signals
to the endpoints. to the endpoints.
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, congestion the dropped traffic can affect other flows. Hence, congestion
signalling by loss is not entirely positive; it is a necessary evil. signalling by loss is not entirely positive; it is a necessary evil.
skipping to change at page 18, line 25 skipping to change at page 18, line 30
conditions. This is expected to ease deployment and operation. conditions. This is expected to ease deployment and operation.
Initial conditions, such as the interface rate and MTU size or Initial conditions, such as the interface rate and MTU size or
other values derived from these, MAY be required by an AQM 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
satisfactory performance and to identify the set of parameters acceptable performance and to identify the set of parameters that
that can be tuned. For example, the expected response of an can be tuned. For example, the expected response of an algorithm
algorithm may need to be configured to accommodate the largest may need to be configured to accommodate the largest expected Path
expected Path RTT, since this value can not be known at RTT, since this value can not be known at initialization. This
initialisation. This guidance is expected to enable the algorithm guidance is expected to enable the algorithm to be deployed in
to be deployed in networks that have specific characteristics networks that have specific characteristics (paths with variable/
(paths with variable/larger delay; networks where capacity is larger delay; networks where capacity is impacted by interactions
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
skipping to change at page 22, line 38 skipping to change at page 22, line 44
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
The original recommendation in [RFC2309] was written by the End-to- The original version of this document describing best current
End Research Group, which is to say Bob Braden, Dave Clark, Jon practice was based on the informational text of [RFC2309]. This was
Crowcroft, Bruce Davie, Steve Deering, Deborah Estrin, Sally Floyd, written by the End-to-End Research Group, which is to say Bob Braden,
Van Jacobson, Greg Minshall, Craig Partridge, Larry Peterson, KK Dave Clark, Jon Crowcroft, Bruce Davie, Steve Deering, Deborah
Ramakrishnan, Scott Shenker, John Wroclawski, and Lixia Zhang. This Estrin, Sally Floyd, Van Jacobson, Greg Minshall, Craig Partridge,
is an edited version of that document, with much of its text and Larry Peterson, KK Ramakrishnan, Scott Shenker, John Wroclawski, and
arguments unchanged. Lixia Zhang. Although there are important differences, many of the
key arguments in the present document remain unchanged from those in
RFC 2309.
The need for an updated document was agreed to in the tsvarea meeting The need for an updated document was agreed to in the tsvarea meeting
at IETF 86. This document was reviewed on the aqm@ietf.org list. at IETF 86. This document was reviewed on the aqm@ietf.org list.
Comments were received from Colin Perkins, Richard Scheffenegger, Comments were received from Colin Perkins, Richard Scheffenegger,
Dave Taht, John Leslie, David Collier-Brown and many others. Dave Taht, John Leslie, David Collier-Brown and many others.
Gorry Fairhurst was in part supported by the European Community under Gorry Fairhurst was in part supported by the European Community under
its Seventh Framework Programme through the Reducing Internet its Seventh Framework Programme through the Reducing Internet
Transport Latency (RITE) project (ICT-317700). Transport Latency (RITE) project (ICT-317700).
skipping to change at page 27, line 12 skipping to change at page 27, line 24
Level", SIGCOMM Symposium proceedings on Communications Level", SIGCOMM Symposium proceedings on Communications
architectures and protocols , August 1995. architectures and protocols , August 1995.
[Zha90] Zhang, L. and D. Clark, "Oscillating Behavior of Network [Zha90] Zhang, L. and D. Clark, "Oscillating Behavior of Network
Traffic: A Case Study Simulation, Traffic: A Case Study Simulation,
http://groups.csail.mit.edu/ana/Publications/Zhang-DDC- http://groups.csail.mit.edu/ana/Publications/Zhang-DDC-
Oscillating-Behavior-of-Network-Traffic-1990.pdf", 1990. Oscillating-Behavior-of-Network-Traffic-1990.pdf", 1990.
Appendix A. Change Log Appendix A. Change Log
RFC-Editor please remove this appendix before publication.
Initial Version: March 2013 Initial Version: March 2013
Minor update of the algorithms that the IETF recommends SHOULD NOT Minor update of the algorithms that the IETF recommends SHOULD NOT
require operational (especially manual) configuration or tuningdate: require operational (especially manual) configuration or tuning
April 2013 April 2013
Major surgery. This draft is for discussion at IETF-87 and expected Major surgery. This draft is for discussion at IETF-87 and expected
to be further updated. to be further updated.
July 2013 July 2013
-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
skipping to change at page 27, line 45 skipping to change at page 28, line 10
-04 WG Draft - Minor edits May 2014 - Comments during WGLC: Provided -04 WG Draft - Minor edits May 2014 - Comments during WGLC: Provided
some introductory subsections to help people (with subsections and some introductory subsections to help people (with subsections and
better text). - Written more on the role scheduling. - Clarified better text). - Written more on the role scheduling. - Clarified
that ECN mark threshold needs to be configurable. - Reworked your that ECN mark threshold needs to be configurable. - Reworked your
"knee" para. Various updates in response to feedback. "knee" para. Various updates in response to feedback.
-05 WG Draft - Minor edits June 2014 - New text added to address -05 WG Draft - Minor edits June 2014 - New text added to address
further comments, and improve introduction - adding context, further comments, and improve introduction - adding context,
reference to Conex, linking between sections, added text on reference to Conex, linking between sections, added text on
synchronisation. synchronization.
-06 WG Draft - Minor edits July 2014 - Reorganised the introduction -06 WG Draft - Minor edits July 2014 - Reorganised the introduction
following WG feedback to better explain how this relates to the following WG feedback to better explain how this relates to the
original goals of RFC2309. Added item on packet bursts. Various original goals of RFC2309. Added item on packet bursts. Various
minor corrections incorporated - no change to main minor corrections incorporated - no change to main
recommendations. recommendations.
-07 WG Draft - Minor edits July 2014 - Replaced ID REF by RFC 7141. -07 WG Draft - Minor edits July 2014 - Replaced ID REF by RFC 7141.
Changes made to introduction following inputs from Wes Eddy and Changes made to introduction following inputs from Wes Eddy and
John Leslie. Corrections and additions proposed by Bob Briscoe. John Leslie. Corrections and additions proposed by Bob Briscoe.
-08 WG Draft - Minor edits August 2014 - Review comments from John
Leslie and Bob Briscoe. Text corrections including; updated
Acknowledgments (RFC2309 ref) s/congestive/congestion/g; changed
the more bold language from RFC2309 to reflect a more considered
perceived threat to Internet Performance; modified the category
that is not-TCP-like to be "less responsive to congestion than
TCP" and more clearkly noted that represents a range of
behaviours.
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. 27 change blocks. 
53 lines changed or deleted 70 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/