--- 1/draft-ietf-tsvwg-byte-pkt-congest-07.txt 2012-08-13 16:14:27.057341946 +0200 +++ 2/draft-ietf-tsvwg-byte-pkt-congest-08.txt 2012-08-13 16:14:27.141341846 +0200 @@ -1,48 +1,50 @@ Transport Area Working Group B. Briscoe Internet-Draft BT Updates: 2309 (if approved) J. Manner Intended status: BCP Aalto University -Expires: August 23, 2012 February 20, 2012 +Expires: February 14, 2013 August 13, 2012 Byte and Packet Congestion Notification - draft-ietf-tsvwg-byte-pkt-congest-07 + draft-ietf-tsvwg-byte-pkt-congest-08 Abstract - This memo concerns dropping or marking packets using active queue - management (AQM) such as random early detection (RED) or pre- - congestion notification (PCN). 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) the byte-mode packet drop - variant of the RED AQM algorithm that drops fewer small packets - should not be used. + This document provides recommendations of best current practice for + dropping or marking packets using active queue management (AQM) such + as random early detection (RED) or pre-congestion notification (PCN). + 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) the byte-mode packet drop variant of the RED AQM + algorithm 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 August 23, 2012. + This Internet-Draft will expire on February 14, 2013. Copyright Notice Copyright (c) 2012 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 @@ -77,31 +79,31 @@ 4.2.1. Network Bias when Encoding . . . . . . . . . . . . . . 19 4.2.2. Transport Bias when Decoding . . . . . . . . . . . . . 21 4.2.3. Making Transports Robust against Control Packet Losses . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.4. Congestion Notification: Summary of Conflicting Advice . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Outstanding Issues and Next Steps . . . . . . . . . . . . . . 24 5.1. Bit-congestible Network . . . . . . . . . . . . . . . . . 24 5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 - 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 + 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 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 C. Byte-mode Drop Complicates Policing Congestion Response . . . . . . . . . . . . . . . . . . . . . . 37 Appendix D. Changes from Previous Versions . . . . . . . . . . . 38 1. Introduction This memo concerns how we should correctly scale congestion control functions with 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. @@ -179,21 +181,21 @@ This memo continues as follows. First it discusses terminology and scoping. Section 2 gives the concrete formal recommendations, followed by motivating arguments in Section 3. We then critically survey the advice given previously in the RFC series and the research literature (Section 4), referring to an assessment of whether or not this advice has been followed in production networks (Appendix A). To wrap up, outstanding issues are discussed that will need resolution both to inform future protocol designs and to handle legacy (Section 5). Then security issues are collected together in - Section 6 before conclusions are drawn in Section 7. The interested + Section 6 before conclusions are drawn in Section 8. The interested reader can find discussion of more detailed issues on the theme of byte vs. packet in the appendices. This memo intentionally includes a non-negligible amount of material on the subject. For the busy reader Section 2 summarises the recommendations for the Internet community. 1.1. Terminology and Scoping The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -206,22 +208,22 @@ offered (or that there is an impending risk that they will not be able to). The `impending risk' qualifier is added, because AQM systems (e.g. RED, PCN [RFC5670]) set a virtual limit smaller than the actual limit to the resource, then notify when this virtual limit is exceeded in order to avoid uncontrolled congestion of the actual capacity. Congestion notification communicates a real number bounded by the - range [0,1]. This ties in with the most well-understood measure - of congestion notification: drop probability. + range [ 0 , 1 ]. This ties in with the most well-understood + measure of congestion notification: drop probability. Explicit and Implicit Notification: The byte vs. packet dilemma concerns congestion notification irrespective of whether it is signalled implicitly by drop or using explicit congestion notification (ECN [RFC3168] or PCN [RFC5670]). Throughout this document, unless clear from the context, the term marking will be used to mean notifying congestion explicitly, while congestion notification will be used to mean notifying congestion either implicitly by drop or explicitly by marking. @@ -1117,21 +1119,25 @@ Appendix C explains why the ability of networks to police the response of _any_ transport to congestion depends on bit-congestible network resources only doing packet-mode not byte-mode drop. In summary, it says that making drop probability depend on the size of the packets that bits happen to be divided into simply encourages the bits to be divided into smaller packets. Byte-mode drop would therefore irreversibly complicate any attempt to fix the Internet's incentive structures. -7. Conclusions +7. IANA Considerations + + 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. @@ -1168,73 +1174,59 @@ incremental deployment complications. The recommendations have been developed on the well-founded basis that most Internet resources are bit-congestible not packet- 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]. -8. Acknowledgements +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. 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. -9. Comments Solicited +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. -10. References +11. References -10.1. Normative References +11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [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. - [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. - [RFC3426] Floyd, S., "General Architectural and - Policy Considerations", RFC 3426, - November 2002. - -10.2. Informative References +11.2. Informative References [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 @@ -1270,31 +1262,30 @@ congestion control", Automatica 35(12)1969--1985, December 1999, . [I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", - draft-ietf-avtcore-ecn-for-rtp-06 - (work in progress), February 2012. + draft-ietf-avtcore-ecn-for-rtp-08 + (work in progress), May 2012. [I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A. Cooper, "ConEx Concepts and Use Cases", - draft-ietf-conex-concepts-uses-03 - (work in progress), October 2011. + draft-ietf-conex-concepts-uses-04 + (work in progress), March 2012. [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. [PktSizeEquCC] Vasallo, P., "Variable Packet Size Equation-Based Congestion Control", ICSI Technical Report tr-00-008, 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. + [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. + [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. [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004. @@ -1833,21 +1838,21 @@ the network layer" (to side-step controversy over whether functions like AQM are in the transport layer but in network equipment). * Minor improvements to clarity throughout From -01 to -02: * Restructured the whole document for (hopefully) easier reading and clarity. The concrete recommendation, in RFC2119 language, - is now in Section 7. + is now in Section 8. From -00 to -01: * Minor clarifications throughout and updated references From briscoe-byte-pkt-mark-02 to ietf-byte-pkt-congest-00: * Added note on relationship to existing RFCs * Posed the question of whether packet-congestion could become common and deferred it to the IRTF ICCRG. Added ref to the