draft-ietf-tsvwg-byte-pkt-congest-10.txt   draft-ietf-tsvwg-byte-pkt-congest-11.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT Internet-Draft BT
Updates: 2309 (if approved) J. Manner Updates: 2309 (if approved) J. Manner
Intended status: BCP Aalto University Intended status: BCP Aalto University
Expires: November 24, 2013 May 23, 2013 Expires: February 2, 2014 August 1, 2013
Byte and Packet Congestion Notification Byte and Packet Congestion Notification
draft-ietf-tsvwg-byte-pkt-congest-10 draft-ietf-tsvwg-byte-pkt-congest-11
Abstract Abstract
This document provides recommendations of best current practice for This document provides recommendations of best current practice for
dropping or marking packets using any active queue management (AQM) dropping or marking packets using any active queue management (AQM)
algorithm, such as random early detection (RED), BLUE, pre-congestion algorithm, including random early detection (RED), BLUE, pre-
notification (PCN), etc. We give three strong recommendations: (1) congestion notification (PCN) and newer schemes such as CoDel and
packet size should be taken into account when transports read and PIE. We give three strong recommendations: (1) packet size should be
respond to congestion indications, (2) packet size should not be taken into account when transports detect and respond to congestion
taken into account when network equipment creates congestion signals indications, (2) packet size should not be taken into account when
(marking, dropping), and therefore (3) in the specific case of RED, network equipment creates congestion signals (marking, dropping), and
the byte-mode packet drop variant that drops fewer small packets therefore (3) in the specific case of RED, the byte-mode packet drop
should not be used. This memo updates RFC 2309 to deprecate variant that drops fewer small packets should not be used. This memo
deliberate preferential treatment of small packets in AQM algorithms. updates RFC 2309 to deprecate deliberate preferential treatment of
small packets in AQM algorithms.
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 November 24, 2013. This Internet-Draft will expire on February 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 3, line 40 skipping to change at page 3, line 40
Losses . . . . . . . . . . . . . . . . . . . . . . . . 23 Losses . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.4. Congestion Notification: Summary of Conflicting 4.2.4. Congestion Notification: Summary of Conflicting
Advice . . . . . . . . . . . . . . . . . . . . . . . . 23 Advice . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Outstanding Issues and Next Steps . . . . . . . . . . . . . . 24 5. Outstanding Issues and Next Steps . . . . . . . . . . . . . . 24
5.1. Bit-congestible Network . . . . . . . . . . . . . . . . . 24 5.1. Bit-congestible Network . . . . . . . . . . . . . . . . . 24
5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 25 5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Survey of RED Implementation Status . . . . . . . . . 31 Appendix A. Survey of RED Implementation Status . . . . . . . . . 32
Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 32 Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 33
B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 33 B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 34
B.2. Bit-Congestible and Packet-Congestible Indications . . . . 36 B.2. Bit-Congestible and Packet-Congestible Indications . . . . 37
Appendix C. Byte-mode Drop Complicates Policing Congestion Appendix C. Byte-mode Drop Complicates Policing Congestion
Response . . . . . . . . . . . . . . . . . . . . . . 37 Response . . . . . . . . . . . . . . . . . . . . . . 38
Appendix D. Changes from Previous Versions . . . . . . . . . . . 38 Appendix D. Changes from Previous Versions . . . . . . . . . . . 39
1. Introduction 1. Introduction
This memo concerns how we should correctly scale congestion control This document provides recommendations of best current practice for
functions with respect to packet size for the long term. It also how we should correctly scale congestion control functions with
recognises that expediency may be necessary to deal with existing respect to packet size for the long term. It also recognises that
widely deployed protocols that don't live up to the long term goal. expediency may be necessary to deal with existing widely deployed
protocols that don't live up to the long term goal.
When signalling congestion, the problem of how (and whether) to take When signalling congestion, the problem of how (and whether) to take
packet sizes into account has exercised the minds of researchers and packet sizes into account has exercised the minds of researchers and
practitioners for as long as active queue management (AQM) has been practitioners for as long as active queue management (AQM) has been
discussed. Indeed, one reason AQM was originally introduced was to discussed. Indeed, one reason AQM was originally introduced was to
reduce the lock-out effects that small packets can have on large reduce the lock-out effects that small packets can have on large
packets in drop-tail queues. This memo aims to state the principles packets in drop-tail queues. This memo aims to state the principles
we should be using and to outline how these principles will affect we should be using and to outline how these principles will affect
future protocol design, taking into account the existing deployments future protocol design, taking into account the existing deployments
we have already. we have already.
skipping to change at page 4, line 39 skipping to change at page 4, line 40
Encoding congestion notification into the wire protocol: When a Encoding congestion notification into the wire protocol: When a
congested network resource signals its level of congestion, should congested network resource signals its level of congestion, should
it drop / mark each packet dependent on the size of the particular it drop / mark each packet dependent on the size of the particular
packet in question? packet in question?
Decoding congestion notification from the wire protocol: When a Decoding congestion notification from the wire protocol: When a
transport interprets the notification in order to decide how much transport interprets the notification in order to decide how much
to respond to congestion, should it take into account the size of to respond to congestion, should it take into account the size of
each missing or marked packet? each missing or marked packet?
Consensus has emerged over the years concerning the first stage: if Consensus has emerged over the years concerning the first stage,
queues cannot be measured in time, whether they should be measured in which Section 2.1 records in the RFC Series. In summary: If possible
bytes or packets. Section 2.1 of this memo records this consensus in it is best to measure congestion by time in the queue, but otherwise
the RFC Series. In summary the choice solely depends on whether the the choice between bytes and packets solely depends on whether the
resource is congested by bytes or packets. resource is congested by bytes or packets.
The controversy is mainly around the last two stages: whether to The controversy is mainly around the last two stages: whether to
allow for the size of the specific packet notifying congestion i) allow for the size of the specific packet notifying congestion i)
when the network encodes or ii) when the transport decodes the when the network encodes or ii) when the transport decodes the
congestion notification. congestion notification.
Currently, the RFC series is silent on this matter other than a paper Currently, the RFC series is silent on this matter other than a paper
trail of advice referenced from [RFC2309], which conditionally trail of advice referenced from [RFC2309], which conditionally
recommends byte-mode (packet-size dependent) drop [pktByteEmail]. recommends byte-mode (packet-size dependent) drop [pktByteEmail].
skipping to change at page 5, line 4 skipping to change at page 5, line 5
resource is congested by bytes or packets. resource is congested by bytes or packets.
The controversy is mainly around the last two stages: whether to The controversy is mainly around the last two stages: whether to
allow for the size of the specific packet notifying congestion i) allow for the size of the specific packet notifying congestion i)
when the network encodes or ii) when the transport decodes the when the network encodes or ii) when the transport decodes the
congestion notification. congestion notification.
Currently, the RFC series is silent on this matter other than a paper Currently, the RFC series is silent on this matter other than a paper
trail of advice referenced from [RFC2309], which conditionally trail of advice referenced from [RFC2309], which conditionally
recommends byte-mode (packet-size dependent) drop [pktByteEmail]. recommends byte-mode (packet-size dependent) drop [pktByteEmail].
Reducing drop of small packets certainly has some tempting Reducing drop of small packets certainly has some tempting
advantages: i) it drops less control packets, which tend to be small advantages: i) it drops less control packets, which tend to be small
and ii) it makes TCP's bit-rate less dependent on packet size. and ii) it makes TCP's bit-rate less dependent on packet size.
However, there are ways of addressing these issues at the transport However, there are ways of addressing these issues at the transport
layer, rather than reverse engineering network forwarding to fix the layer, rather than reverse engineering network forwarding to fix the
problems. problems.
This memo updates [RFC2309] to deprecate deliberate preferential This memo updates [RFC2309] to deprecate deliberate preferential
treatment of small packets in AQM algorithms. It recommends that (1) treatment of packets in AQM algorithms solely because of their size.
packet size should be taken into account when transports read It recommends that (1) packet size should be taken into account when
congestion indications, (2) not when network equipment writes them. transports detect and respond to congestion indications, (2) not when
This memo also adds to the congestion control principles enumerated network equipment creates them. This memo also adds to the
in BCP 41 [RFC2914]. congestion control principles enumerated in BCP 41 [RFC2914].
In the particular case of Random early Detection (RED), this means In the particular case of Random early Detection (RED), this means
that the byte-mode packet drop variant should not be used to drop that the byte-mode packet drop variant should not be used to drop
fewer small packets, because that creates a perverse incentive for fewer small packets, because that creates a perverse incentive for
transports to use tiny segments, consequently also opening up a DoS transports to use tiny segments, consequently also opening up a DoS
vulnerability. Fortunately all the RED implementers who responded to vulnerability. Fortunately all the RED implementers who responded to
our admittedly limited survey (Section 4.2.4) have not followed the our admittedly limited survey (Section 4.2.4) have not followed the
earlier advice to use byte-mode drop, so the position this memo earlier advice to use byte-mode drop, so the position this memo
argues for seems to already exist in implementations. argues for seems to already exist in implementations.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
recommendations for the Internet community. recommendations for the Internet community.
1.1. Terminology and Scoping 1.1. Terminology and Scoping
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This memo applies to the design of all AQM algorithms, for example, This memo applies to the design of all AQM algorithms, for example,
Random Early Detection (RED) [RFC2309], BLUE [BLUE02], Pre-Congestion Random Early Detection (RED) [RFC2309], BLUE [BLUE02], Pre-Congestion
Notification (PCN) [RFC5670], Controlled Delay (CoDel) [CoDel12] and Notification (PCN) [RFC5670], Controlled Delay (CoDel)
the Proportional Integral controller Enhanced (PIE) [I-D.nichols-tsvwg-codel] and the Proportional Integral controller
[I-D.pan-tsvwg-pie]. Throughout, RED is used as a concrete example Enhanced (PIE) [I-D.pan-tsvwg-pie]. Throughout, RED is used as a
because it is a widely known and deployed AQM algorithm. There is no concrete example because it is a widely known and deployed AQM
intention to imply that the advice is any less applicable to the algorithm. There is no intention to imply that the advice is any
other algorithms, nor that RED is preferred. less applicable to the other algorithms, nor that RED is preferred.
Congestion Notification: Congestion notification is a changing Congestion Notification: Congestion notification is a changing
signal that aims to communicate the probability that the network signal that aims to communicate the probability that the network
resource(s) will not be able to forward the level of traffic load resource(s) will not be able to forward the level of traffic load
offered (or that there is an impending risk that they will not be offered (or that there is an impending risk that they will not be
able to). able to).
The `impending risk' qualifier is added, because AQM systems set a The `impending risk' qualifier is added, because AQM systems set a
virtual limit smaller than the actual limit to the resource, then virtual limit smaller than the actual limit to the resource, then
notify when this virtual limit is exceeded in order to avoid notify when this virtual limit is exceeded in order to avoid
skipping to change at page 19, line 31 skipping to change at page 19, line 31
how complicated the buffering scheme is, ultimately a transmission how complicated the buffering scheme is, ultimately a transmission
line is nearly always bit-congestible so the number of bytes queued line is nearly always bit-congestible so the number of bytes queued
up waiting for the line measures how congested the line is, and it is up waiting for the line measures how congested the line is, and it is
rarely important to measure how congested the buffering system is. rarely important to measure how congested the buffering system is.
4.1.2. Congestion Measurement without a Queue 4.1.2. Congestion Measurement without a Queue
AQM algorithms are nearly always described assuming there is a queue AQM algorithms are nearly always described assuming there is a queue
for a congested resource and the algorithm can use the queue length for a congested resource and the algorithm can use the queue length
to determine the probability that it will drop or mark each packet. to determine the probability that it will drop or mark each packet.
But not all congested resources lead to queues. For instance, But not all congested resources lead to queues. For instance, power
wireless spectrum is usually regarded as bit-congestible (for a given limited resources are usually bit-congestible if energy is primarily
coding scheme). But wireless link protocols do not always maintain a required for transmission rather than header processing, but it is
queue that depends on spectrum interference. Similarly, power rare for a link protocol to build a queue as it approaches maximum
limited resources are also usually bit-congestible if energy is power.
primarily required for transmission rather than header processing,
but it is rare for a link protocol to build a queue as it approaches
maximum power.
Nonetheless, AQM algorithms do not require a queue in order to work. Nonetheless, AQM algorithms do not require a queue in order to work.
For instance spectrum congestion can be modelled by signal quality For instance spectrum congestion can be modelled by signal quality
using target bit-energy-to-noise-density ratio. And, to model radio using target bit-energy-to-noise-density ratio. And, to model radio
power exhaustion, transmission power levels can be measured and power exhaustion, transmission power levels can be measured and
compared to the maximum power available. [ECNFixedWireless] proposes compared to the maximum power available. [ECNFixedWireless] proposes
a practical and theoretically sound way to combine congestion a practical and theoretically sound way to combine congestion
notification for different bit-congestible resources at different notification for different bit-congestible resources at different
layers along an end to end path, whether wireless or wired, and layers along an end to end path, whether wireless or wired, and
whether with or without queues. whether with or without queues.
In wireless protocols that use request to send / clear to send (RTS /
CTS) control, such as some variants of IEEE802.11, it is reasonable
to base an AQM on the time spent waiting for transmission
opportunities (TXOPs) even though wireless spectrum is usually
regarded as congested by bits (for a given coding scheme). This is
because requests for TXOPs queue up as the spectrum gets congested by
all the bits being transferred. So the time that TXOPs are queued
directly reflects bit congestion of the spectrum.
4.2. Congestion Notification Advice 4.2. Congestion Notification Advice
4.2.1. Network Bias when Encoding 4.2.1. Network Bias when Encoding
4.2.1.1. Advice on Packet Size Bias in RED 4.2.1.1. Advice on Packet Size Bias in RED
The previously mentioned email [pktByteEmail] referred to by The previously mentioned email [pktByteEmail] referred to by
[RFC2309] advised that most scarce resources in the Internet were [RFC2309] advised that most scarce resources in the Internet were
bit-congestible, which is still believed to be true (Section 1.1). bit-congestible, which is still believed to be true (Section 1.1).
But it went on to offer advice that is updated by this memo. It said But it went on to offer advice that is updated by this memo. It said
skipping to change at page 25, line 29 skipping to change at page 25, line 34
The IRTF Internet congestion control research group (ICCRG) has set The IRTF Internet congestion control research group (ICCRG) has set
itself the task of reaching consensus on generic forwarding itself the task of reaching consensus on generic forwarding
mechanisms that are necessary and sufficient to support the mechanisms that are necessary and sufficient to support the
Internet's future congestion control requirements (the first Internet's future congestion control requirements (the first
challenge in [RFC6077]). The research question of whether packet challenge in [RFC6077]). The research question of whether packet
congestion might become common and what to do if it does may in the congestion might become common and what to do if it does may in the
future be explored in the IRTF (the "Challenge 3: Packet Size" in future be explored in the IRTF (the "Challenge 3: Packet Size" in
[RFC6077]). [RFC6077]).
Note that sometimes it seems that resources might be congested by
neither bits nor packets, e.g. where the queue for access to a
wireless medium is in units of transmission opportunities. However,
the root cause of congestion of the underlying spectrum is overload
of bits (see Section 4.1.2).
6. Security Considerations 6. Security Considerations
This memo recommends that queues do not bias drop probability towards This memo recommends that queues do not bias drop probability due to
small packets as this creates a perverse incentive for transports to packets size. For instance dropping small packets less often than
break down their flows into tiny segments. One of the benefits of large creates a perverse incentive for transports to break down their
implementing AQM was meant to be to remove this perverse incentive flows into tiny segments. One of the benefits of implementing AQM
that drop-tail queues gave to small packets. was meant to be to remove this perverse incentive that drop-tail
queues gave to small packets.
In practice, transports cannot all be trusted to respond to In practice, transports cannot all be trusted to respond to
congestion. So another reason for recommending that queues do not congestion. So another reason for recommending that queues do not
bias drop probability towards small packets is to avoid the bias drop probability towards small packets is to avoid the
vulnerability to small packet DDoS attacks that would otherwise vulnerability to small packet DDoS attacks that would otherwise
result. One of the benefits of implementing AQM was meant to be to result. One of the benefits of implementing AQM was meant to be to
remove drop-tail's DoS vulnerability to small packets, so we remove drop-tail's DoS vulnerability to small packets, so we
shouldn't add it back again. shouldn't add it back again.
If most queues implemented AQM with byte-mode drop, the resulting If most queues implemented AQM with byte-mode drop, the resulting
skipping to change at page 26, line 26 skipping to change at page 26, line 37
This document has no actions for IANA. This document has no actions for IANA.
8. Conclusions 8. Conclusions
This memo identifies the three distinct stages of the congestion This memo identifies the three distinct stages of the congestion
notification process where implementations need to decide whether to notification process where implementations need to decide whether to
take packet size into account. The recommendations provided in take packet size into account. The recommendations provided in
Section 2 of this memo are different in each case: Section 2 of this memo are different in each case:
o When network equipment measures the length of a queue, whether it o When network equipment measures the length of a queue, if it is
counts in bytes or packets depends on whether the network resource not feasible to use time it is recommended to count in bytes if
is congested respectively by bytes or by packets. the network resource is congested by bytes, or to count in packets
if is congested by packets.
o When network equipment decides whether to drop (or mark) a packet, o When network equipment decides whether to drop (or mark) a packet,
it is recommended that the size of the particular packet should it is recommended that the size of the particular packet should
not be taken into account not be taken into account
o However, when a transport algorithm responds to a dropped or o However, when a transport algorithm responds to a dropped or
marked packet, the size of the rate reduction should be marked packet, the size of the rate reduction should be
proportionate to the size of the packet. proportionate to the size of the packet.
In summary, the answers are 'it depends', 'no' and 'yes' respectively In summary, the answers are 'it depends', 'no' and 'yes' respectively
skipping to change at page 27, line 26 skipping to change at page 27, line 38
congestible. We need to know the likelihood that this assumption congestible. We need to know the likelihood that this assumption
will prevail longer term and, if it might not, what protocol changes will prevail longer term and, if it might not, what protocol changes
will be needed to cater for a mix of the two. The IRTF Internet will be needed to cater for a mix of the two. The IRTF Internet
Congestion Control Research Group (ICCRG) is currently working on Congestion Control Research Group (ICCRG) is currently working on
these problems [RFC6077]. these problems [RFC6077].
9. Acknowledgements 9. Acknowledgements
Thank you to Sally Floyd, who gave extensive and useful review Thank you to Sally Floyd, who gave extensive and useful review
comments. Also thanks for the reviews from Philip Eardley, David comments. Also thanks for the reviews from Philip Eardley, David
Black, Fred Baker, Toby Moncaster, Arnaud Jacquet and Mirja Black, Fred Baker, David Taht, Toby Moncaster, Arnaud Jacquet and
Kuehlewind as well as helpful explanations of different hardware Mirja Kuehlewind as well as helpful explanations of different
approaches from Larry Dunn and Fred Baker. We are grateful to Bruce hardware approaches from Larry Dunn and Fred Baker. We are grateful
Davie and his colleagues for providing a timely and efficient survey to Bruce Davie and his colleagues for providing a timely and
of RED implementation in Cisco's product range. Also grateful thanks efficient survey of RED implementation in Cisco's product range.
to Toby Moncaster, Will Dormann, John Regnault, Simon Carter and Also grateful thanks to Toby Moncaster, Will Dormann, John Regnault,
Stefaan De Cnodder who further helped survey the current status of Simon Carter and Stefaan De Cnodder who further helped survey the
RED implementation and deployment and, finally, thanks to the current status of RED implementation and deployment and, finally,
anonymous individuals who responded. thanks to the anonymous individuals who responded.
Bob Briscoe and Jukka Manner were partly funded by Trilogy, a Bob Briscoe and Jukka Manner were partly funded by Trilogy, a
research project (ICT- 216372) supported by the European Community research project (ICT- 216372) supported by the European Community
under its Seventh Framework Programme. The views expressed here are under its Seventh Framework Programme. The views expressed here are
those of the authors only. those of the authors only.
10. Comments Solicited 10. Comments Solicited
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors. <tsvwg@ietf.org>, and/or to the authors.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, Indicate Requirement Levels", BCP 14,
March 1997. RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black,
Addition of Explicit Congestion Notification "The Addition of Explicit Congestion
(ECN) to IP", RFC 3168, September 2001. Notification (ECN) to IP", RFC 3168,
September 2001.
11.2. Informative References 11.2. Informative References
[BLUE02] Feng, W-c., Shin, K., Kandlur, D., and D. Saha, [BLUE02] Feng, W-c., Shin, K., Kandlur, D., and D.
"The BLUE active queue management algorithms", Saha, "The BLUE active queue management
IEEE/ACM Transactions on Networking 10(4) 513-- algorithms", IEEE/ACM Transactions on
528, August 2002, Networking 10(4) 513--528, August 2002, <h
<http://dx.doi.org/10.1109/TNET.2002.801399>. ttp://dx.doi.org/10.1109/
TNET.2002.801399>.
[CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. Le Boudec, [CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. Le
"Congestion Control for Flows with Variable Boudec, "Congestion Control for Flows with
Packet Size", ACM CCR 34(2) 137--151, 2004, Variable Packet Size", ACM CCR 34(2) 137--
<http://doi.acm.org/10.1145/997150.997162>. 151, 2004,
<http://doi.acm.org/10.1145/
997150.997162>.
[CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. Prabhaker, [CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. Prabhaker,
"Approximate Fair Dropping for Variable Length "Approximate Fair Dropping for Variable
Packets", IEEE Micro 21(1):48--56, January- Length Packets", IEEE Micro 21(1):48--56,
February 2001, <http://www.stanford.edu/~balaji/ January-February 2001, <http://
papers/01approximatefair.pdf}>. www.stanford.edu/~balaji/papers/
01approximatefair.pdf}>.
[CoDel12] Nichols, K. and V. Jacobson, "Controlling Queue [DRQ] Shin, M., Chong, S., and I. Rhee, "Dual-
Delay", ACM Queue 10(5), May 2012, Resource TCP/AQM for Processing-
<http://queue.acm.org/detail.cfm?id=2209336>. Constrained Networks", IEEE/ACM
Transactions on Networking Vol 16, issue
2, April 2008, <http://dx.doi.org/10.1109/
TNET.2007.900415>.
[DRQ] Shin, M., Chong, S., and I. Rhee, "Dual-Resource [DupTCP] Wischik, D., "Short messages", Royal
TCP/AQM for Processing-Constrained Networks", Society workshop on networks: modelling
IEEE/ACM Transactions on Networking Vol 16, and control , September 2007, <http://
issue 2, April 2008, www.cs.ucl.ac.uk/staff/ucacdjw/Research/
<http://dx.doi.org/10.1109/TNET.2007.900415>. shortmsg.html>.
[DupTCP] Wischik, D., "Short messages", Royal Society [ECNFixedWireless] Siris, V., "Resource Control for Elastic
workshop on networks: modelling and control , Traffic in CDMA Networks", Proc. ACM
September 2007, <http://www.cs.ucl.ac.uk/staff/ MOBICOM'02 , September 2002, <http://
ucacdjw/Research/shortmsg.html>. www.ics.forth.gr/netlab/publications/
resource_control_elastic_cdma.html>.
[ECNFixedWireless] Siris, V., "Resource Control for Elastic Traffic [Evol_cc] Gibbens, R. and F. Kelly, "Resource
in CDMA Networks", Proc. ACM MOBICOM'02 , pricing and the evolution of congestion
September 2002, <http://www.ics.forth.gr/netlab/ control", Automatica 35(12)1969--1985,
publications/ December 1999, <http://
resource_control_elastic_cdma.html>. www.statslab.cam.ac.uk/~frank/evol.html>.
[Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and [I-D.nichols-tsvwg-codel] Nichols, K. and V. Jacobson, "Controlled
the evolution of congestion control", Delay Active Queue Management",
Automatica 35(12)1969--1985, December 1999, draft-nichols-tsvwg-codel-01 (work in
<http://www.statslab.cam.ac.uk/~frank/ progress), February 2013.
evol.html>.
[I-D.pan-tsvwg-pie] Pan, R., Natarajan, P., Piglione, C., and M. [I-D.pan-tsvwg-pie] Pan, R., Natarajan, P., Piglione, C., and
Prabhu, "PIE: A Lightweight Control Scheme To M. Prabhu, "PIE: A Lightweight Control
Address the Bufferbloat Problem", Scheme To Address the Bufferbloat
draft-pan-tsvwg-pie-00 (work in progress), Problem", draft-pan-tsvwg-pie-00 (work in
December 2012. progress), December 2012.
[IOSArch] Bollapragada, V., White, R., and C. Murphy, [IOSArch] Bollapragada, V., White, R., and C.
"Inside Cisco IOS Software Architecture", Cisco Murphy, "Inside Cisco IOS Software
Press: CCIE Professional Development ISBN13: Architecture", Cisco Press: CCIE
978-1-57870-181-0, July 2000. Professional Development ISBN13: 978-1-
57870-181-0, July 2000.
[PktSizeEquCC] Vasallo, P., "Variable Packet Size Equation- [PktSizeEquCC] Vasallo, P., "Variable Packet Size
Based Congestion Control", ICSI Technical Equation-Based Congestion Control", ICSI
Report tr-00-008, 2000, <http:// Technical Report tr-00-008, 2000, <http://
http.icsi.berkeley.edu/ftp/global/pub/ http.icsi.berkeley.edu/ftp/global/pub/
techreports/2000/tr-00-008.pdf>. techreports/2000/tr-00-008.pdf>.
[RED93] Floyd, S. and V. Jacobson, "Random Early [RED93] Floyd, S. and V. Jacobson, "Random Early
Detection (RED) gateways for Congestion Detection (RED) gateways for Congestion
Avoidance", IEEE/ACM Transactions on Avoidance", IEEE/ACM Transactions on
Networking 1(4) 397--413, August 1993, Networking 1(4) 397--413, August 1993, <ht
<http://www.icir.org/floyd/papers/red/red.html>. tp://www.icir.org/floyd/papers/red/
red.html>.
[REDbias] Eddy, W. and M. Allman, "A Comparison of RED's [REDbias] Eddy, W. and M. Allman, "A Comparison of
Byte and Packet Modes", Computer Networks 42(3) RED's Byte and Packet Modes", Computer
261--280, June 2003, <http://www.ir.bbn.com/ Networks 42(3) 261--280, June 2003, <http:
documents/articles/redbias.ps>. //www.ir.bbn.com/documents/articles/
redbias.ps>.
[REDbyte] De Cnodder, S., Elloumi, O., and K. Pauwels, [REDbyte] De Cnodder, S., Elloumi, O., and K.
"RED behavior with different packet sizes", Pauwels, "RED behavior with different
Proc. 5th IEEE Symposium on Computers and packet sizes", Proc. 5th IEEE Symposium on
Communications (ISCC) 793--799, July 2000, Computers and Communications (ISCC) 793--
<http://www.icir.org/floyd/red/Elloumi99.pdf>. 799, July 2000, <http://www.icir.org/
floyd/red/Elloumi99.pdf>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., [RFC2309] Braden, B., Clark, D., Crowcroft, J.,
Deering, S., Estrin, D., Floyd, S., Jacobson, Davie, B., Deering, S., Estrin, D., Floyd,
V., Minshall, G., Partridge, C., Peterson, L., S., Jacobson, V., Minshall, G., Partridge,
Ramakrishnan, K., Shenker, S., Wroclawski, J., C., Peterson, L., Ramakrishnan, K.,
and L. Zhang, "Recommendations on Queue Shenker, S., Wroclawski, J., and L. Zhang,
Management and Congestion Avoidance in the "Recommendations on Queue Management and
Internet", RFC 2309, April 1998. Congestion Avoidance in the Internet",
RFC 2309, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D.
"Definition of the Differentiated Services Field Black, "Definition of the Differentiated
(DS Field) in the IPv4 and IPv6 Headers", Services Field (DS Field) in the IPv4 and
RFC 2474, December 1998. IPv6 Headers", RFC 2474, December 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", [RFC2914] Floyd, S., "Congestion Control
BCP 41, RFC 2914, September 2000. Principles", BCP 41, RFC 2914,
September 2000.
[RFC3426] Floyd, S., "General Architectural and Policy [RFC3426] Floyd, S., "General Architectural and
Considerations", RFC 3426, November 2002. Policy Considerations", RFC 3426,
November 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and [RFC3550] Schulzrinne, H., Casner, S., Frederick,
V. Jacobson, "RTP: A Transport Protocol for R., and V. Jacobson, "RTP: A Transport
Real-Time Applications", STD 64, RFC 3550, Protocol for Real-Time Applications",
July 2003. STD 64, RFC 3550, July 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns
Congestion Control for Voice Traffic in the Regarding Congestion Control for Voice
Internet", RFC 3714, March 2004. Traffic in the Internet", RFC 3714,
March 2004.
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly
Control (TFRC): The Small-Packet (SP) Variant", Rate Control (TFRC): The Small-Packet (SP)
RFC 4828, April 2007. Variant", RFC 4828, April 2007.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J.
Widmer, "TCP Friendly Rate Control (TFRC): Widmer, "TCP Friendly Rate Control (TFRC):
Protocol Specification", RFC 5348, Protocol Specification", RFC 5348,
September 2008. September 2008.
[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and
Ramakrishnan, "Adding Explicit Congestion K. Ramakrishnan, "Adding Explicit
Notification (ECN) Capability to TCP's SYN/ACK Congestion Notification (ECN) Capability
Packets", RFC 5562, June 2009. to TCP's SYN/ACK Packets", RFC 5562,
June 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of [RFC5670] Eardley, P., "Metering and Marking
PCN-Nodes", RFC 5670, November 2009. Behaviour of PCN-Nodes", RFC 5670,
November 2009.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP [RFC5681] Allman, M., Paxson, V., and E. Blanton,
Congestion Control", RFC 5681, September 2009. "TCP Congestion Control", RFC 5681,
September 2009.
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, [RFC5690] Floyd, S., Arcia, A., Ros, D., and J.
"Adding Acknowledgement Congestion Control to Iyengar, "Adding Acknowledgement
TCP", RFC 5690, February 2010. Congestion Control to TCP", RFC 5690,
February 2010.
[RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., and B. [RFC6077] Papadimitriou, D., Welzl, M., Scharf, M.,
Briscoe, "Open Research Issues in Internet and B. Briscoe, "Open Research Issues in
Congestion Control", RFC 6077, February 2011. Internet Congestion Control", RFC 6077,
February 2011.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., [RFC6679] Westerlund, M., Johansson, I., Perkins,
O'Hanlon, P., and K. Carlberg, "Explicit C., O'Hanlon, P., and K. Carlberg,
Congestion Notification (ECN) for RTP over UDP", "Explicit Congestion Notification (ECN)
RFC 6679, August 2012. for RTP over UDP", RFC 6679, August 2012.
[RFC6789] Briscoe, B., Woundy, R., and A. Cooper, [RFC6789] Briscoe, B., Woundy, R., and A. Cooper,
"Congestion Exposure (ConEx) Concepts and Use "Congestion Exposure (ConEx) Concepts and
Cases", RFC 6789, December 2012. Use Cases", RFC 6789, December 2012.
[Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness: Dismantling a [Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness:
Religion", ACM CCR 37(2)63--74, April 2007, Dismantling a Religion", ACM
<http://portal.acm.org/citation.cfm?id=1232926>. CCR 37(2)63--74, April 2007, <http://
portal.acm.org/citation.cfm?id=1232926>.
[gentle_RED] Floyd, S., "Recommendation on using the [gentle_RED] Floyd, S., "Recommendation on using the
"gentle_" variant of RED", Web page , "gentle_" variant of RED", Web page ,
March 2000, March 2000, <http://www.icir.org/floyd/
<http://www.icir.org/floyd/red/gentle.html>. red/gentle.html>.
[pBox] Floyd, S. and K. Fall, "Promoting the Use of [pBox] Floyd, S. and K. Fall, "Promoting the Use
End-to-End Congestion Control in the Internet", of End-to-End Congestion Control in the
IEEE/ACM Transactions on Networking 7(4) 458-- Internet", IEEE/ACM Transactions on
472, August 1999, Networking 7(4) 458--472, August 1999, <ht
<http://www.aciri.org/floyd/end2end-paper.html>. tp://www.aciri.org/floyd/
end2end-paper.html>.
[pktByteEmail] Floyd, S., "RED: Discussions of Byte and Packet [pktByteEmail] Floyd, S., "RED: Discussions of Byte and
Modes", email , March 1997, <http:// Packet Modes", email , March 1997, <http:/
www-nrg.ee.lbl.gov/floyd/REDaveraging.txt>. /www-nrg.ee.lbl.gov/floyd/
REDaveraging.txt>.
Appendix A. Survey of RED Implementation Status Appendix A. Survey of RED Implementation Status
This Appendix is informative, not normative. This Appendix is informative, not normative.
In May 2007 a survey was conducted of 84 vendors to assess how widely In May 2007 a survey was conducted of 84 vendors to assess how widely
drop probability based on packet size has been implemented in RED drop probability based on packet size has been implemented in RED
Table 3. About 19% of those surveyed replied, giving a sample size Table 3. About 19% of those surveyed replied, giving a sample size
of 16. Although in most cases we do not have permission to identify of 16. Although in most cases we do not have permission to identify
the respondents, we can say that those that have responded include the respondents, we can say that those that have responded include
skipping to change at page 39, line 5 skipping to change at page 40, line 5
across different size flows [Rate_fair_Dis]. across different size flows [Rate_fair_Dis].
Appendix D. Changes from Previous Versions Appendix D. Changes from Previous Versions
To be removed by the RFC Editor on publication. To be removed by the RFC Editor on publication.
Full incremental diffs between each version are available at Full incremental diffs between each version are available at
<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-byte-pkt-congest/> <http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-byte-pkt-congest/>
(courtesy of the rfcdiff tool): (courtesy of the rfcdiff tool):
From -10 to -11: Following a further WGLC:
* Abstract: clarified that advice applies to all AQMs including
newer ones
* Abstract & Intro: changed 'read' to 'detect', because you don't
read losses, you detect them.
* S.1. Introduction: Disambiguated summary of advice on queue
measurement.
* Clarified that the doc deprecates any preference based solely
on packet size, it's not only against preferring smaller
packets.
* S.4.1.2. Congestion Measurement without a Queue: Explained
that a queue of TXOPs represents a queue into spectrum
congested by too many bits.
* S.5.2: Bit- & Packet-congestible Network: Referred to
explanation in S.4.1.2 to make the point that TXOPs are not a
primary unit of workload like bits and packets are, even though
you get queues of TXOPs.
* 6. Security: Disambiguated 'bias towards'.
* 8. Conclusions: Made consistent with recommendation to use
time if possible for queue measurement.
From -09 to -10: Following IESG review: From -09 to -10: Following IESG review:
* Updates 2309: Left header unchanged reflecting eventual IESG * Updates 2309: Left header unchanged reflecting eventual IESG
consensus [Sean Turner, Pete Resnick]. consensus [Sean Turner, Pete Resnick].
* S.1 Intro: This memo adds to the congestion control principles * S.1 Intro: This memo adds to the congestion control principles
enumerated in BCP 41 [Pete Resnick] enumerated in BCP 41 [Pete Resnick]
* Abstract, S.1, S.1.1, s.1.2 Intro, Scoping and Example: Made * Abstract, S.1, S.1.1, s.1.2 Intro, Scoping and Example: Made
applicability to all AQMs clearer listing some more example applicability to all AQMs clearer listing some more example
 End of changes. 54 change blocks. 
201 lines changed or deleted 269 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/