--- 1/draft-ietf-tsvwg-byte-pkt-congest-10.txt 2013-08-01 23:14:22.329909286 -0700 +++ 2/draft-ietf-tsvwg-byte-pkt-congest-11.txt 2013-08-01 23:14:22.429911880 -0700 @@ -1,50 +1,51 @@ Transport Area Working Group B. Briscoe Internet-Draft BT Updates: 2309 (if approved) J. Manner Intended status: BCP Aalto University -Expires: November 24, 2013 May 23, 2013 +Expires: February 2, 2014 August 1, 2013 Byte and Packet Congestion Notification - draft-ietf-tsvwg-byte-pkt-congest-10 + draft-ietf-tsvwg-byte-pkt-congest-11 Abstract This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) - algorithm, such as random early detection (RED), BLUE, pre-congestion - notification (PCN), etc. We give three strong recommendations: (1) - packet size should be taken into account when transports read and - respond to congestion indications, (2) packet size should not be - taken into account when network equipment creates congestion signals - (marking, dropping), and therefore (3) in the specific case of RED, - the byte-mode packet drop variant that drops fewer small packets - should not be used. This memo updates RFC 2309 to deprecate - deliberate preferential treatment of small packets in AQM algorithms. + algorithm, including random early detection (RED), BLUE, pre- + congestion notification (PCN) and newer schemes such as CoDel and + PIE. We give three strong recommendations: (1) packet size should be + taken into account when transports detect and respond to congestion + indications, (2) packet size should not be taken into account when + network equipment creates congestion signals (marking, dropping), and + therefore (3) in the specific case of RED, the byte-mode packet drop + variant that drops fewer small packets should not be used. This memo + updates RFC 2309 to deprecate deliberate preferential treatment of + small packets in AQM algorithms. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -82,38 +83,39 @@ Losses . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.4. Congestion Notification: Summary of Conflicting Advice . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Outstanding Issues and Next Steps . . . . . . . . . . . . . . 24 5.1. Bit-congestible Network . . . . . . . . . . . . . . . . . 24 5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 - 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 - Appendix A. Survey of RED Implementation Status . . . . . . . . . 31 - Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 32 - B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 33 - B.2. Bit-Congestible and Packet-Congestible Indications . . . . 36 + Appendix A. Survey of RED Implementation Status . . . . . . . . . 32 + Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 33 + B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 34 + B.2. Bit-Congestible and Packet-Congestible Indications . . . . 37 Appendix C. Byte-mode Drop Complicates Policing Congestion - Response . . . . . . . . . . . . . . . . . . . . . . 37 - Appendix D. Changes from Previous Versions . . . . . . . . . . . 38 + Response . . . . . . . . . . . . . . . . . . . . . . 38 + Appendix D. Changes from Previous Versions . . . . . . . . . . . 39 1. Introduction - This memo concerns how we should correctly scale congestion control - functions with respect to packet size for the long term. It also - recognises that expediency may be necessary to deal with existing - widely deployed protocols that don't live up to the long term goal. + This document provides recommendations of best current practice for + how we should correctly scale congestion control functions with + respect to packet size for the long term. It also recognises that + 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 packet sizes into account has exercised the minds of researchers and practitioners for as long as active queue management (AQM) has been discussed. Indeed, one reason AQM was originally introduced was to reduce the lock-out effects that small packets can have on large packets in drop-tail queues. This memo aims to state the principles we should be using and to outline how these principles will affect future protocol design, taking into account the existing deployments we have already. @@ -128,24 +130,24 @@ Encoding congestion notification into the wire protocol: When a congested network resource signals its level of congestion, should it drop / mark each packet dependent on the size of the particular packet in question? Decoding congestion notification from the wire protocol: When a transport interprets the notification in order to decide how much to respond to congestion, should it take into account the size of each missing or marked packet? - Consensus has emerged over the years concerning the first stage: if - queues cannot be measured in time, whether they should be measured in - bytes or packets. Section 2.1 of this memo records this consensus in - the RFC Series. In summary the choice solely depends on whether the + Consensus has emerged over the years concerning the first stage, + which Section 2.1 records in the RFC Series. In summary: If possible + it is best to measure congestion by time in the queue, but otherwise + the choice between bytes and packets solely depends on whether the resource is congested by bytes or packets. The controversy is mainly around the last two stages: whether to allow for the size of the specific packet notifying congestion i) when the network encodes or ii) when the transport decodes the congestion notification. Currently, the RFC series is silent on this matter other than a paper trail of advice referenced from [RFC2309], which conditionally recommends byte-mode (packet-size dependent) drop [pktByteEmail]. @@ -142,34 +144,33 @@ resource is congested by bytes or packets. The controversy is mainly around the last two stages: whether to allow for the size of the specific packet notifying congestion i) when the network encodes or ii) when the transport decodes the congestion notification. Currently, the RFC series is silent on this matter other than a paper trail of advice referenced from [RFC2309], which conditionally recommends byte-mode (packet-size dependent) drop [pktByteEmail]. - Reducing drop of small packets certainly has some tempting 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. However, there are ways of addressing these issues at the transport layer, rather than reverse engineering network forwarding to fix the problems. This memo updates [RFC2309] to deprecate deliberate preferential - treatment of small packets in AQM algorithms. It recommends that (1) - packet size should be taken into account when transports read - congestion indications, (2) not when network equipment writes them. - This memo also adds to the congestion control principles enumerated - in BCP 41 [RFC2914]. + treatment of packets in AQM algorithms solely because of their size. + It recommends that (1) packet size should be taken into account when + transports detect and respond to congestion indications, (2) not when + network equipment creates them. This memo also adds to the + congestion control principles enumerated in BCP 41 [RFC2914]. In the particular case of Random early Detection (RED), this means that the byte-mode packet drop variant should not be used to drop fewer small packets, because that creates a perverse incentive for transports to use tiny segments, consequently also opening up a DoS vulnerability. Fortunately all the RED implementers who responded to our admittedly limited survey (Section 4.2.4) have not followed the earlier advice to use byte-mode drop, so the position this memo argues for seems to already exist in implementations. @@ -199,26 +200,26 @@ recommendations for the Internet community. 1.1. Terminology and Scoping The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This memo applies to the design of all AQM algorithms, for example, Random Early Detection (RED) [RFC2309], BLUE [BLUE02], Pre-Congestion - Notification (PCN) [RFC5670], Controlled Delay (CoDel) [CoDel12] and - the Proportional Integral controller Enhanced (PIE) - [I-D.pan-tsvwg-pie]. Throughout, RED is used as a concrete example - because it is a widely known and deployed AQM algorithm. There is no - intention to imply that the advice is any less applicable to the - other algorithms, nor that RED is preferred. + Notification (PCN) [RFC5670], Controlled Delay (CoDel) + [I-D.nichols-tsvwg-codel] and the Proportional Integral controller + Enhanced (PIE) [I-D.pan-tsvwg-pie]. Throughout, RED is used as a + concrete example because it is a widely known and deployed AQM + algorithm. There is no intention to imply that the advice is any + less applicable to the other algorithms, nor that RED is preferred. Congestion Notification: Congestion notification is a changing signal that aims to communicate the probability that the network 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 able to). The `impending risk' qualifier is added, because AQM systems set a virtual limit smaller than the actual limit to the resource, then notify when this virtual limit is exceeded in order to avoid @@ -845,39 +846,45 @@ how complicated the buffering scheme is, ultimately a transmission 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 rarely important to measure how congested the buffering system is. 4.1.2. Congestion Measurement without 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 to determine the probability that it will drop or mark each packet. - But not all congested resources lead to queues. For instance, - wireless spectrum is usually regarded as bit-congestible (for a given - coding scheme). But wireless link protocols do not always maintain a - queue that depends on spectrum interference. Similarly, power - limited resources are also usually bit-congestible if energy is - 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. + But not all congested resources lead to queues. For instance, power + limited resources are usually bit-congestible if energy is 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. For instance spectrum congestion can be modelled by signal quality using target bit-energy-to-noise-density ratio. And, to model radio power exhaustion, transmission power levels can be measured and compared to the maximum power available. [ECNFixedWireless] proposes a practical and theoretically sound way to combine congestion notification for different bit-congestible resources at different layers along an end to end path, whether wireless or wired, and 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.1. Network Bias when Encoding 4.2.1.1. Advice on Packet Size Bias in RED The previously mentioned email [pktByteEmail] referred to by [RFC2309] advised that most scarce resources in the Internet were 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 @@ -1132,27 +1138,34 @@ The IRTF Internet congestion control research group (ICCRG) has set itself the task of reaching consensus on generic forwarding mechanisms that are necessary and sufficient to support the Internet's future congestion control requirements (the first challenge in [RFC6077]). The research question of whether packet 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 [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 - This memo recommends that queues do not bias drop probability towards - small packets as this creates a perverse incentive for transports to - break down their flows into tiny segments. One of the benefits of - implementing AQM was meant to be to remove this perverse incentive - that drop-tail queues gave to small packets. + This memo recommends that queues do not bias drop probability due to + packets size. For instance dropping small packets less often than + large creates a perverse incentive for transports to break down their + flows into tiny segments. One of the benefits of implementing AQM + 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 congestion. So another reason for recommending that queues do not bias drop probability towards small packets is to avoid the vulnerability to small packet DDoS attacks that would otherwise result. One of the benefits of implementing AQM was meant to be to remove drop-tail's DoS vulnerability to small packets, so we shouldn't add it back again. If most queues implemented AQM with byte-mode drop, the resulting @@ -1177,23 +1190,24 @@ This document has no actions for IANA. 8. Conclusions This memo identifies the three distinct stages of the congestion notification process where implementations need to decide whether to take packet size into account. The recommendations provided in Section 2 of this memo are different in each case: - o When network equipment measures the length of a queue, whether it - counts in bytes or packets depends on whether the network resource - is congested respectively by bytes or by packets. + o When network equipment measures the length of a queue, if it is + not feasible to use time it is recommended to count in bytes if + 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, it is recommended that the size of the particular packet should not be taken into account o However, when a transport algorithm responds to a dropped or marked packet, the size of the rate reduction should be proportionate to the size of the packet. In summary, the answers are 'it depends', 'no' and 'yes' respectively @@ -1225,216 +1238,240 @@ congestible. We need to know the likelihood that this assumption 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 Congestion Control Research Group (ICCRG) is currently working on these problems [RFC6077]. 9. Acknowledgements Thank you to Sally Floyd, who gave extensive and useful review comments. Also thanks for the reviews from Philip Eardley, David - Black, Fred Baker, Toby Moncaster, Arnaud Jacquet and Mirja - Kuehlewind as well as helpful explanations of different hardware - approaches from Larry Dunn and Fred Baker. We are grateful to Bruce - Davie and his colleagues for providing a timely and efficient survey - of RED implementation in Cisco's product range. Also grateful thanks - to Toby Moncaster, Will Dormann, John Regnault, Simon Carter and - Stefaan De Cnodder who further helped survey the current status of - RED implementation and deployment and, finally, thanks to the - anonymous individuals who responded. + Black, Fred Baker, David Taht, Toby Moncaster, Arnaud Jacquet and + Mirja Kuehlewind as well as helpful explanations of different + hardware approaches from Larry Dunn and Fred Baker. We are grateful + to Bruce Davie and his colleagues for providing a timely and + efficient survey of RED implementation in Cisco's product range. + Also grateful thanks to Toby Moncaster, Will Dormann, John Regnault, + Simon Carter and Stefaan De Cnodder who further helped survey the + current status of RED implementation and deployment and, finally, + thanks to the anonymous individuals who responded. Bob Briscoe and Jukka Manner were partly funded by Trilogy, a research project (ICT- 216372) supported by the European Community under its Seventh Framework Programme. The views expressed here are those of the authors only. 10. Comments Solicited Comments and questions are encouraged and very welcome. They can be addressed to the IETF Transport Area working group mailing list , and/or to the authors. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to - Indicate Requirement Levels", BCP 14, RFC 2119, - March 1997. + Indicate Requirement Levels", BCP 14, + RFC 2119, March 1997. - [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The - Addition of Explicit Congestion Notification - (ECN) to IP", RFC 3168, September 2001. + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, + "The Addition of Explicit Congestion + Notification (ECN) to IP", RFC 3168, + September 2001. 11.2. Informative References - [BLUE02] Feng, W-c., Shin, K., Kandlur, D., and D. Saha, - "The BLUE active queue management algorithms", - IEEE/ACM Transactions on Networking 10(4) 513-- - 528, August 2002, - . + [BLUE02] Feng, W-c., Shin, K., Kandlur, D., and D. + Saha, "The BLUE active queue management + algorithms", IEEE/ACM Transactions on + Networking 10(4) 513--528, August 2002, . - [CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. Le Boudec, - "Congestion Control for Flows with Variable - Packet Size", ACM CCR 34(2) 137--151, 2004, - . + [CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. Le + Boudec, "Congestion Control for Flows with + Variable Packet Size", ACM CCR 34(2) 137-- + 151, 2004, + . [CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. Prabhaker, - "Approximate Fair Dropping for Variable Length - Packets", IEEE Micro 21(1):48--56, January- - February 2001, . - - [CoDel12] Nichols, K. and V. Jacobson, "Controlling Queue - Delay", ACM Queue 10(5), May 2012, - . + "Approximate Fair Dropping for Variable + Length Packets", IEEE Micro 21(1):48--56, + January-February 2001, . - [DRQ] Shin, M., Chong, S., and I. Rhee, "Dual-Resource - TCP/AQM for Processing-Constrained Networks", - IEEE/ACM Transactions on Networking Vol 16, - issue 2, April 2008, - . + [DRQ] Shin, M., Chong, S., and I. Rhee, "Dual- + Resource TCP/AQM for Processing- + Constrained Networks", IEEE/ACM + Transactions on Networking Vol 16, issue + 2, April 2008, . - [DupTCP] Wischik, D., "Short messages", Royal Society - workshop on networks: modelling and control , - September 2007, . + [DupTCP] Wischik, D., "Short messages", Royal + Society workshop on networks: modelling + and control , September 2007, . - [ECNFixedWireless] Siris, V., "Resource Control for Elastic Traffic - in CDMA Networks", Proc. ACM MOBICOM'02 , - September 2002, . - [Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and - the evolution of congestion control", - Automatica 35(12)1969--1985, December 1999, - . + [Evol_cc] Gibbens, R. and F. Kelly, "Resource + pricing and the evolution of congestion + control", Automatica 35(12)1969--1985, + December 1999, . - [I-D.pan-tsvwg-pie] Pan, R., Natarajan, P., Piglione, C., and M. - Prabhu, "PIE: A Lightweight Control Scheme To - Address the Bufferbloat Problem", - draft-pan-tsvwg-pie-00 (work in progress), - December 2012. + [I-D.nichols-tsvwg-codel] Nichols, K. and V. Jacobson, "Controlled + Delay Active Queue Management", + draft-nichols-tsvwg-codel-01 (work in + progress), February 2013. - [IOSArch] Bollapragada, V., White, R., and C. Murphy, - "Inside Cisco IOS Software Architecture", Cisco - Press: CCIE Professional Development ISBN13: - 978-1-57870-181-0, July 2000. + [I-D.pan-tsvwg-pie] Pan, R., Natarajan, P., Piglione, C., and + M. Prabhu, "PIE: A Lightweight Control + Scheme To Address the Bufferbloat + Problem", draft-pan-tsvwg-pie-00 (work in + progress), December 2012. - [PktSizeEquCC] Vasallo, P., "Variable Packet Size Equation- - Based Congestion Control", ICSI Technical - Report tr-00-008, 2000, . [RED93] Floyd, S. and V. Jacobson, "Random Early Detection (RED) gateways for Congestion Avoidance", IEEE/ACM Transactions on - Networking 1(4) 397--413, August 1993, - . + Networking 1(4) 397--413, August 1993, . - [REDbias] Eddy, W. and M. Allman, "A Comparison of RED's - Byte and Packet Modes", Computer Networks 42(3) - 261--280, June 2003, . + [REDbias] Eddy, W. and M. Allman, "A Comparison of + RED's Byte and Packet Modes", Computer + Networks 42(3) 261--280, June 2003, . - [REDbyte] De Cnodder, S., Elloumi, O., and K. Pauwels, - "RED behavior with different packet sizes", - Proc. 5th IEEE Symposium on Computers and - Communications (ISCC) 793--799, July 2000, - . + [REDbyte] De Cnodder, S., Elloumi, O., and K. + Pauwels, "RED behavior with different + packet sizes", Proc. 5th IEEE Symposium on + Computers and Communications (ISCC) 793-- + 799, July 2000, . - [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., - Deering, S., Estrin, D., Floyd, S., Jacobson, - V., Minshall, G., Partridge, C., Peterson, L., - Ramakrishnan, K., Shenker, S., Wroclawski, J., - and L. Zhang, "Recommendations on Queue - Management and Congestion Avoidance in the - Internet", RFC 2309, April 1998. + [RFC2309] Braden, B., Clark, D., Crowcroft, J., + Davie, B., Deering, S., Estrin, D., Floyd, + S., Jacobson, V., Minshall, G., Partridge, + C., Peterson, L., Ramakrishnan, K., + Shenker, S., Wroclawski, J., and L. Zhang, + "Recommendations on Queue Management and + Congestion Avoidance in the Internet", + RFC 2309, April 1998. - [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, - "Definition of the Differentiated Services Field - (DS Field) in the IPv4 and IPv6 Headers", - RFC 2474, December 1998. + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. + Black, "Definition of the Differentiated + Services Field (DS Field) in the IPv4 and + IPv6 Headers", RFC 2474, December 1998. - [RFC2914] Floyd, S., "Congestion Control Principles", - BCP 41, RFC 2914, September 2000. + [RFC2914] Floyd, S., "Congestion Control + Principles", BCP 41, RFC 2914, + September 2000. - [RFC3426] Floyd, S., "General Architectural and Policy - Considerations", RFC 3426, November 2002. + [RFC3426] Floyd, S., "General Architectural and + Policy Considerations", RFC 3426, + November 2002. - [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and - V. Jacobson, "RTP: A Transport Protocol for - Real-Time Applications", STD 64, RFC 3550, - July 2003. + [RFC3550] Schulzrinne, H., Casner, S., Frederick, + R., and V. Jacobson, "RTP: A Transport + Protocol for Real-Time Applications", + STD 64, RFC 3550, July 2003. - [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding - Congestion Control for Voice Traffic in the - Internet", RFC 3714, March 2004. + [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns + Regarding Congestion Control for Voice + Traffic in the Internet", RFC 3714, + March 2004. - [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate - Control (TFRC): The Small-Packet (SP) Variant", - RFC 4828, April 2007. + [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly + Rate Control (TFRC): The Small-Packet (SP) + Variant", RFC 4828, April 2007. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. - [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. - Ramakrishnan, "Adding Explicit Congestion - Notification (ECN) Capability to TCP's SYN/ACK - Packets", RFC 5562, June 2009. + [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and + K. Ramakrishnan, "Adding Explicit + Congestion Notification (ECN) Capability + to TCP's SYN/ACK Packets", RFC 5562, + June 2009. - [RFC5670] Eardley, P., "Metering and Marking Behaviour of - PCN-Nodes", RFC 5670, November 2009. + [RFC5670] Eardley, P., "Metering and Marking + Behaviour of PCN-Nodes", RFC 5670, + November 2009. - [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP - Congestion Control", RFC 5681, September 2009. + [RFC5681] Allman, M., Paxson, V., and E. Blanton, + "TCP Congestion Control", RFC 5681, + September 2009. - [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, - "Adding Acknowledgement Congestion Control to - TCP", RFC 5690, February 2010. + [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. + Iyengar, "Adding Acknowledgement + Congestion Control to TCP", RFC 5690, + February 2010. - [RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., and B. - Briscoe, "Open Research Issues in Internet - Congestion Control", RFC 6077, February 2011. + [RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., + and B. Briscoe, "Open Research Issues in + Internet Congestion Control", RFC 6077, + February 2011. - [RFC6679] Westerlund, M., Johansson, I., Perkins, C., - O'Hanlon, P., and K. Carlberg, "Explicit - Congestion Notification (ECN) for RTP over UDP", - RFC 6679, August 2012. + [RFC6679] Westerlund, M., Johansson, I., Perkins, + C., O'Hanlon, P., and K. Carlberg, + "Explicit Congestion Notification (ECN) + for RTP over UDP", RFC 6679, August 2012. [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, - "Congestion Exposure (ConEx) Concepts and Use - Cases", RFC 6789, December 2012. + "Congestion Exposure (ConEx) Concepts and + Use Cases", RFC 6789, December 2012. - [Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness: Dismantling a - Religion", ACM CCR 37(2)63--74, April 2007, - . + [Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness: + Dismantling a Religion", ACM + CCR 37(2)63--74, April 2007, . [gentle_RED] Floyd, S., "Recommendation on using the "gentle_" variant of RED", Web page , - March 2000, - . + March 2000, . - [pBox] Floyd, S. and K. Fall, "Promoting the Use of - End-to-End Congestion Control in the Internet", - IEEE/ACM Transactions on Networking 7(4) 458-- - 472, August 1999, - . + [pBox] Floyd, S. and K. Fall, "Promoting the Use + of End-to-End Congestion Control in the + Internet", IEEE/ACM Transactions on + Networking 7(4) 458--472, August 1999, . - [pktByteEmail] Floyd, S., "RED: Discussions of Byte and Packet - Modes", email , March 1997, . + [pktByteEmail] Floyd, S., "RED: Discussions of Byte and + Packet Modes", email , March 1997, . Appendix A. Survey of RED Implementation Status This Appendix is informative, not normative. 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 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 the respondents, we can say that those that have responded include @@ -1777,20 +1814,49 @@ across different size flows [Rate_fair_Dis]. Appendix D. Changes from Previous Versions To be removed by the RFC Editor on publication. Full incremental diffs between each version are available at (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: * Updates 2309: Left header unchanged reflecting eventual IESG consensus [Sean Turner, Pete Resnick]. * S.1 Intro: This memo adds to the congestion control principles enumerated in BCP 41 [Pete Resnick] * Abstract, S.1, S.1.1, s.1.2 Intro, Scoping and Example: Made applicability to all AQMs clearer listing some more example