draft-ietf-tsvwg-byte-pkt-congest-07.txt   draft-ietf-tsvwg-byte-pkt-congest-08.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: August 23, 2012 February 20, 2012 Expires: February 14, 2013 August 13, 2012
Byte and Packet Congestion Notification Byte and Packet Congestion Notification
draft-ietf-tsvwg-byte-pkt-congest-07 draft-ietf-tsvwg-byte-pkt-congest-08
Abstract Abstract
This memo concerns dropping or marking packets using active queue This document provides recommendations of best current practice for
management (AQM) such as random early detection (RED) or pre- dropping or marking packets using active queue management (AQM) such
congestion notification (PCN). We give three strong recommendations: as random early detection (RED) or pre-congestion notification (PCN).
(1) packet size should be taken into account when transports read and We give three strong recommendations: (1) packet size should be taken
respond to congestion indications, (2) packet size should not be into account when transports read 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) the byte-mode packet drop network equipment creates congestion signals (marking, dropping), and
variant of the RED AQM algorithm that drops fewer small packets therefore (3) the byte-mode packet drop variant of the RED AQM
should not be used. 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 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 August 23, 2012. This Internet-Draft will expire on February 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 42 skipping to change at page 3, line 37
4.2.1. Network Bias when Encoding . . . . . . . . . . . . . . 19 4.2.1. Network Bias when Encoding . . . . . . . . . . . . . . 19
4.2.2. Transport Bias when Decoding . . . . . . . . . . . . . 21 4.2.2. Transport Bias when Decoding . . . . . . . . . . . . . 21
4.2.3. Making Transports Robust against Control Packet 4.2.3. Making Transports Robust against Control Packet
Losses . . . . . . . . . . . . . . . . . . . . . . . . 22 Losses . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.4. Congestion Notification: Summary of Conflicting 4.2.4. Congestion Notification: Summary of Conflicting
Advice . . . . . . . . . . . . . . . . . . . . . . . . 22 Advice . . . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . 24 5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Survey of RED Implementation Status . . . . . . . . . 31 Appendix A. Survey of RED Implementation Status . . . . . . . . . 31
Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 32 Appendix B. Sufficiency of Packet-Mode Drop . . . . . . . . . . . 32
B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 33 B.1. Packet-Size (In)Dependence in Transports . . . . . . . . . 33
B.2. Bit-Congestible and Packet-Congestible Indications . . . . 36 B.2. Bit-Congestible and Packet-Congestible Indications . . . . 36
Appendix C. Byte-mode Drop Complicates Policing Congestion Appendix C. Byte-mode Drop Complicates Policing Congestion
Response . . . . . . . . . . . . . . . . . . . . . . 37 Response . . . . . . . . . . . . . . . . . . . . . . 37
Appendix D. Changes from Previous Versions . . . . . . . . . . . 38 Appendix D. Changes from Previous Versions . . . . . . . . . . . 38
1. Introduction 1. Introduction
This memo concerns how we should correctly scale congestion control This memo concerns how we should correctly scale congestion control
functions with packet size for the long term. It also recognises functions with packet size for the long term. It also recognises
that expediency may be necessary to deal with existing widely that expediency may be necessary to deal with existing widely
deployed protocols that don't live up to the long term goal. deployed protocols that don't live up to the long term goal.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
This memo continues as follows. First it discusses terminology and This memo continues as follows. First it discusses terminology and
scoping. Section 2 gives the concrete formal recommendations, scoping. Section 2 gives the concrete formal recommendations,
followed by motivating arguments in Section 3. We then critically followed by motivating arguments in Section 3. We then critically
survey the advice given previously in the RFC series and the research survey the advice given previously in the RFC series and the research
literature (Section 4), referring to an assessment of whether or not literature (Section 4), referring to an assessment of whether or not
this advice has been followed in production networks (Appendix A). this advice has been followed in production networks (Appendix A).
To wrap up, outstanding issues are discussed that will need To wrap up, outstanding issues are discussed that will need
resolution both to inform future protocol designs and to handle resolution both to inform future protocol designs and to handle
legacy (Section 5). Then security issues are collected together in 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 reader can find discussion of more detailed issues on the theme of
byte vs. packet in the appendices. byte vs. packet in the appendices.
This memo intentionally includes a non-negligible amount of material This memo intentionally includes a non-negligible amount of material
on the subject. For the busy reader Section 2 summarises the on the subject. For the busy reader Section 2 summarises the
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",
skipping to change at page 6, line 24 skipping to change at page 6, line 24
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 (e.g. The `impending risk' qualifier is added, because AQM systems (e.g.
RED, PCN [RFC5670]) set a virtual limit smaller than the actual RED, PCN [RFC5670]) set a virtual limit smaller than the actual
limit to the resource, then notify when this virtual limit is limit to the resource, then notify when this virtual limit is
exceeded in order to avoid uncontrolled congestion of the actual exceeded in order to avoid uncontrolled congestion of the actual
capacity. capacity.
Congestion notification communicates a real number bounded by the Congestion notification communicates a real number bounded by the
range [0,1]. This ties in with the most well-understood measure range [ 0 , 1 ]. This ties in with the most well-understood
of congestion notification: drop probability. measure of congestion notification: drop probability.
Explicit and Implicit Notification: The byte vs. packet dilemma Explicit and Implicit Notification: The byte vs. packet dilemma
concerns congestion notification irrespective of whether it is concerns congestion notification irrespective of whether it is
signalled implicitly by drop or using explicit congestion signalled implicitly by drop or using explicit congestion
notification (ECN [RFC3168] or PCN [RFC5670]). Throughout this notification (ECN [RFC3168] or PCN [RFC5670]). Throughout this
document, unless clear from the context, the term marking will be document, unless clear from the context, the term marking will be
used to mean notifying congestion explicitly, while congestion used to mean notifying congestion explicitly, while congestion
notification will be used to mean notifying congestion either notification will be used to mean notifying congestion either
implicitly by drop or explicitly by marking. implicitly by drop or explicitly by marking.
skipping to change at page 25, line 33 skipping to change at page 25, line 33
Appendix C explains why the ability of networks to police the Appendix C explains why the ability of networks to police the
response of _any_ transport to congestion depends on bit-congestible response of _any_ transport to congestion depends on bit-congestible
network resources only doing packet-mode not byte-mode drop. In network resources only doing packet-mode not byte-mode drop. In
summary, it says that making drop probability depend on the size of summary, it says that making drop probability depend on the size of
the packets that bits happen to be divided into simply encourages the the packets that bits happen to be divided into simply encourages the
bits to be divided into smaller packets. Byte-mode drop would bits to be divided into smaller packets. Byte-mode drop would
therefore irreversibly complicate any attempt to fix the Internet's therefore irreversibly complicate any attempt to fix the Internet's
incentive structures. 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 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, whether it
counts in bytes or packets depends on whether the network resource counts in bytes or packets depends on whether the network resource
is congested respectively by bytes or by packets. is congested respectively by bytes or by packets.
skipping to change at page 26, line 37 skipping to change at page 26, line 41
incremental deployment complications. incremental deployment complications.
The recommendations have been developed on the well-founded basis The recommendations have been developed on the well-founded basis
that most Internet resources are bit-congestible not packet- that most Internet resources are bit-congestible not packet-
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].
8. 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, Toby Moncaster, Arnaud Jacquet and Mirja
Kuehlewind as well as helpful explanations of different hardware Kuehlewind as well as helpful explanations of different hardware
approaches from Larry Dunn and Fred Baker. We are grateful to Bruce approaches from Larry Dunn and Fred Baker. We are grateful to Bruce
Davie and his colleagues for providing a timely and efficient survey Davie and his colleagues for providing a timely and efficient survey
of RED implementation in Cisco's product range. Also grateful thanks of RED implementation in Cisco's product range. Also grateful thanks
to Toby Moncaster, Will Dormann, John Regnault, Simon Carter and to Toby Moncaster, Will Dormann, John Regnault, Simon Carter and
Stefaan De Cnodder who further helped survey the current status of Stefaan De Cnodder who further helped survey the current status of
RED implementation and deployment and, finally, thanks to the RED implementation and deployment and, finally, thanks to the
anonymous individuals who responded. 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.
9. 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.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement Levels", RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997. 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. [RFC3168] Ramakrishnan, K., Floyd, S., and D.
Black, "The Addition of Explicit Black, "The Addition of Explicit
Congestion Notification (ECN) to IP", Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3426] Floyd, S., "General Architectural and 11.2. Informative References
Policy Considerations", RFC 3426,
November 2002.
10.2. Informative References
[CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. [CCvarPktSize] Widmer, J., Boutremans, C., and J-Y.
Le Boudec, "Congestion Control for Le Boudec, "Congestion Control for
Flows with Variable Packet Size", ACM Flows with Variable Packet Size", ACM
CCR 34(2) 137--151, 2004, <http:// CCR 34(2) 137--151, 2004, <http://
doi.acm.org/10.1145/997150.997162>. doi.acm.org/10.1145/997150.997162>.
[CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. [CHOKe_Var_Pkt] Psounis, K., Pan, R., and B.
Prabhaker, "Approximate Fair Dropping Prabhaker, "Approximate Fair Dropping
for Variable Length Packets", IEEE for Variable Length Packets", IEEE
skipping to change at page 28, line 42 skipping to change at page 28, line 32
congestion control", congestion control",
Automatica 35(12)1969--1985, Automatica 35(12)1969--1985,
December 1999, <http:// December 1999, <http://
www.statslab.cam.ac.uk/~frank/ www.statslab.cam.ac.uk/~frank/
evol.html>. evol.html>.
[I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I., [I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I.,
Perkins, C., O'Hanlon, P., and K. Perkins, C., O'Hanlon, P., and K.
Carlberg, "Explicit Congestion Carlberg, "Explicit Congestion
Notification (ECN) for RTP over UDP", Notification (ECN) for RTP over UDP",
draft-ietf-avtcore-ecn-for-rtp-06 draft-ietf-avtcore-ecn-for-rtp-08
(work in progress), February 2012. (work in progress), May 2012.
[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A. [I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A.
Cooper, "ConEx Concepts and Use Cooper, "ConEx Concepts and Use
Cases", Cases",
draft-ietf-conex-concepts-uses-03 draft-ietf-conex-concepts-uses-04
(work in progress), October 2011. (work in progress), March 2012.
[IOSArch] Bollapragada, V., White, R., and C. [IOSArch] Bollapragada, V., White, R., and C.
Murphy, "Inside Cisco IOS Software Murphy, "Inside Cisco IOS Software
Architecture", Cisco Press: CCIE Architecture", Cisco Press: CCIE
Professional Development ISBN13: 978- Professional Development ISBN13: 978-
1-57870-181-0, July 2000. 1-57870-181-0, July 2000.
[PktSizeEquCC] Vasallo, P., "Variable Packet Size [PktSizeEquCC] Vasallo, P., "Variable Packet Size
Equation-Based Congestion Control", Equation-Based Congestion Control",
ICSI Technical Report tr-00-008, ICSI Technical Report tr-00-008,
2000, <http://http.icsi.berkeley.edu/ 2000, <http://http.icsi.berkeley.edu/
ftp/global/pub/techreports/2000/ ftp/global/pub/techreports/2000/
skipping to change at page 29, line 39 skipping to change at page 29, line 28
documents/articles/redbias.ps>. documents/articles/redbias.ps>.
[REDbyte] De Cnodder, S., Elloumi, O., and K. [REDbyte] De Cnodder, S., Elloumi, O., and K.
Pauwels, "RED behavior with different Pauwels, "RED behavior with different
packet sizes", Proc. 5th IEEE packet sizes", Proc. 5th IEEE
Symposium on Computers and Symposium on Computers and
Communications (ISCC) 793--799, Communications (ISCC) 793--799,
July 2000, <http://www.icir.org/ July 2000, <http://www.icir.org/
floyd/red/Elloumi99.pdf>. floyd/red/Elloumi99.pdf>.
[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., [RFC2474] Nichols, K., Blake, S., Baker, F.,
and D. Black, "Definition of the and D. Black, "Definition of the
Differentiated Services Field (DS Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998. RFC 2474, December 1998.
[RFC3426] Floyd, S., "General Architectural and
Policy Considerations", RFC 3426,
November 2002.
[RFC3550] Schulzrinne, H., Casner, S., [RFC3550] Schulzrinne, H., Casner, S.,
Frederick, R., and V. Jacobson, "RTP: Frederick, R., and V. Jacobson, "RTP:
A Transport Protocol for Real-Time A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, Applications", STD 64, RFC 3550,
July 2003. July 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns
Regarding Congestion Control for Regarding Congestion Control for
Voice Traffic in the Internet", Voice Traffic in the Internet",
RFC 3714, March 2004. RFC 3714, March 2004.
skipping to change at page 40, line 41 skipping to change at page 40, line 41
the network layer" (to side-step controversy over whether the network layer" (to side-step controversy over whether
functions like AQM are in the transport layer but in network functions like AQM are in the transport layer but in network
equipment). equipment).
* Minor improvements to clarity throughout * Minor improvements to clarity throughout
From -01 to -02: From -01 to -02:
* Restructured the whole document for (hopefully) easier reading * Restructured the whole document for (hopefully) easier reading
and clarity. The concrete recommendation, in RFC2119 language, and clarity. The concrete recommendation, in RFC2119 language,
is now in Section 7. is now in Section 8.
From -00 to -01: From -00 to -01:
* Minor clarifications throughout and updated references * Minor clarifications throughout and updated references
From briscoe-byte-pkt-mark-02 to ietf-byte-pkt-congest-00: From briscoe-byte-pkt-mark-02 to ietf-byte-pkt-congest-00:
* Added note on relationship to existing RFCs * Added note on relationship to existing RFCs
* Posed the question of whether packet-congestion could become * Posed the question of whether packet-congestion could become
common and deferred it to the IRTF ICCRG. Added ref to the common and deferred it to the IRTF ICCRG. Added ref to the
 End of changes. 21 change blocks. 
48 lines changed or deleted 53 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/