draft-ietf-tsvwg-byte-pkt-congest-09.txt   draft-ietf-tsvwg-byte-pkt-congest-10.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: May 11, 2013 November 7, 2012 Expires: November 24, 2013 May 23, 2013
Byte and Packet Congestion Notification Byte and Packet Congestion Notification
draft-ietf-tsvwg-byte-pkt-congest-09 draft-ietf-tsvwg-byte-pkt-congest-10
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 active queue management (AQM) such dropping or marking packets using any active queue management (AQM)
as random early detection (RED) or pre-congestion notification (PCN). algorithm, such as random early detection (RED), BLUE, pre-congestion
We give three strong recommendations: (1) packet size should be taken notification (PCN), etc. We give three strong recommendations: (1)
into account when transports read and respond to congestion packet size should be taken into account when transports read and
indications, (2) packet size should not be taken into account when respond to congestion indications, (2) packet size should not be
network equipment creates congestion signals (marking, dropping), and taken into account when network equipment creates congestion signals
therefore (3) the byte-mode packet drop variant of the RED AQM (marking, dropping), and therefore (3) in the specific case of RED,
algorithm that drops fewer small packets should not be used. This the byte-mode packet drop variant that drops fewer small packets
memo updates RFC 2309 to deprecate deliberate preferential treatment should not be used. This memo updates RFC 2309 to deprecate
of small packets in AQM algorithms. 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 May 11, 2013. This Internet-Draft will expire on November 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Scoping . . . . . . . . . . . . . . . . . 6 1.1. Terminology and Scoping . . . . . . . . . . . . . . . . . 6
1.2. Example Comparing Packet-Mode Drop and Byte-Mode Drop . . 7 1.2. Example Comparing Packet-Mode Drop and Byte-Mode Drop . . 7
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Recommendation on Queue Measurement . . . . . . . . . . . 9 2.1. Recommendation on Queue Measurement . . . . . . . . . . . 9
2.2. Recommendation on Encoding Congestion Notification . . . . 9 2.2. Recommendation on Encoding Congestion Notification . . . . 10
2.3. Recommendation on Responding to Congestion . . . . . . . . 10 2.3. Recommendation on Responding to Congestion . . . . . . . . 11
2.4. Recommendation on Handling Congestion Indications when 2.4. Recommendation on Handling Congestion Indications when
Splitting or Merging Packets . . . . . . . . . . . . . . . 11 Splitting or Merging Packets . . . . . . . . . . . . . . . 12
3. Motivating Arguments . . . . . . . . . . . . . . . . . . . . . 12 3. Motivating Arguments . . . . . . . . . . . . . . . . . . . . . 12
3.1. Avoiding Perverse Incentives to (Ab)use Smaller Packets . 12 3.1. Avoiding Perverse Incentives to (Ab)use Smaller Packets . 12
3.2. Small != Control . . . . . . . . . . . . . . . . . . . . . 13 3.2. Small != Control . . . . . . . . . . . . . . . . . . . . . 14
3.3. Transport-Independent Network . . . . . . . . . . . . . . 13 3.3. Transport-Independent Network . . . . . . . . . . . . . . 14
3.4. Partial Deployment of AQM . . . . . . . . . . . . . . . . 15 3.4. Partial Deployment of AQM . . . . . . . . . . . . . . . . 15
3.5. Implementation Efficiency . . . . . . . . . . . . . . . . 16 3.5. Implementation Efficiency . . . . . . . . . . . . . . . . 17
4. A Survey and Critique of Past Advice . . . . . . . . . . . . . 16 4. A Survey and Critique of Past Advice . . . . . . . . . . . . . 17
4.1. Congestion Measurement Advice . . . . . . . . . . . . . . 17 4.1. Congestion Measurement Advice . . . . . . . . . . . . . . 17
4.1.1. Fixed Size Packet Buffers . . . . . . . . . . . . . . 17 4.1.1. Fixed Size Packet Buffers . . . . . . . . . . . . . . 18
4.1.2. Congestion Measurement without a Queue . . . . . . . . 18 4.1.2. Congestion Measurement without a Queue . . . . . . . . 19
4.2. Congestion Notification Advice . . . . . . . . . . . . . . 19 4.2. Congestion Notification Advice . . . . . . . . . . . . . . 20
4.2.1. Network Bias when Encoding . . . . . . . . . . . . . . 19 4.2.1. Network Bias when Encoding . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 24 5.2. Bit- & Packet-congestible Network . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . . 38 Response . . . . . . . . . . . . . . . . . . . . . . 37
Appendix D. Changes from Previous Versions . . . . . . . . . . . 39 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 respect to packet size for the long term. It also
that expediency may be necessary to deal with existing widely recognises that expediency may be necessary to deal with existing
deployed protocols that don't live up to the long term goal. widely deployed protocols that don't live up to the long term goal.
When notifying 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.
The question of whether to take into account packet size arises at The question of whether to take into account packet size arises at
three stages in the congestion notification process: three stages in the congestion notification process:
Measuring congestion: When a congested resource measures locally how Measuring congestion: When a congested resource measures locally how
congested it is, should it measure its queue length in bytes or congested it is, should it measure its queue length in time, bytes
packets? or packets?
Encoding congestion notification into the wire protocol: When a Encoding congestion notification into the wire protocol: When a
congested network resource notifies its level of congestion, congested network resource signals its level of congestion, should
should it drop / mark each packet dependent on the byte-size of it drop / mark each packet dependent on the size of the particular
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 byte- to respond to congestion, should it take into account the size of
size of each missing or marked packet? each missing or marked packet?
Consensus has emerged over the years concerning the first stage: Consensus has emerged over the years concerning the first stage: if
whether queues are measured in bytes or packets, termed byte-mode queues cannot be measured in time, whether they should be measured in
queue measurement or packet-mode queue measurement. Section 2.1 of bytes or packets. Section 2.1 of this memo records this consensus in
this memo records this consensus in the RFC Series. In summary the the RFC Series. In summary the choice solely depends on whether the
choice solely depends on whether the resource is congested by bytes resource is congested by bytes or packets.
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 small packets in AQM algorithms. It recommends that (1)
packet size should be taken into account when transports read packet size should be taken into account when transports read
skipping to change at page 5, line 16 skipping to change at page 5, line 16
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 small packets in AQM algorithms. It recommends that (1)
packet size should be taken into account when transports read packet size should be taken into account when transports read
congestion indications, (2) not when network equipment writes them. congestion indications, (2) not when network equipment writes them.
This memo also adds to the congestion control principles enumerated
in BCP 41 [RFC2914].
In particular this means that the byte-mode packet drop variant of In the particular case of Random early Detection (RED), this means
Random early Detection (RED) should not be used to drop fewer small that the byte-mode packet drop variant should not be used to drop
packets, because that creates a perverse incentive for transports to fewer small packets, because that creates a perverse incentive for
use tiny segments, consequently also opening up a DoS vulnerability. transports to use tiny segments, consequently also opening up a DoS
Fortunately all the RED implementers who responded to our admittedly vulnerability. Fortunately all the RED implementers who responded to
limited survey (Section 4.2.4) have not followed the earlier advice our admittedly limited survey (Section 4.2.4) have not followed the
to use byte-mode drop, so the position this memo argues for seems to earlier advice to use byte-mode drop, so the position this memo
already exist in implementations. argues for seems to already exist in implementations.
However, at the transport layer, TCP congestion control is a widely However, at the transport layer, TCP congestion control is a widely
deployed protocol that doesn't scale with packet size. To date this deployed protocol that doesn't scale with packet size. To date this
hasn't been a significant problem because most TCP implementations hasn't been a significant problem because most TCP implementations
have been used with similar packet sizes. But, as we design new have been used with similar packet sizes. But, as we design new
congestion control mechanisms, the current recommendation is that we congestion control mechanisms, this memo recommends that we should
should build in scaling with packet size rather than assuming we build in scaling with packet size rather than assuming we should
should follow TCP's example. follow TCP's example.
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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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",
"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,
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.
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 (e.g. The `impending risk' qualifier is added, because AQM systems set a
RED, PCN [RFC5670]) set a virtual limit smaller than the actual virtual limit smaller than the actual limit to the resource, then
limit to the resource, then notify when this virtual limit is notify when this virtual limit is exceeded in order to avoid
exceeded in order to avoid uncontrolled congestion of the actual 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 range [ 0 , 1 ]. This ties in with the most well-understood
measure 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
skipping to change at page 6, line 50 skipping to change at page 7, line 9
Examples of packet-congestible resources are route look-up engines Examples of packet-congestible resources are route look-up engines
and firewalls, because load depends on how many packet headers and firewalls, because load depends on how many packet headers
they have to process. Examples of bit-congestible resources are they have to process. Examples of bit-congestible resources are
transmission links, radio power and most buffer memory, because transmission links, radio power and most buffer memory, because
the load depends on how many bits they have to transmit or store. the load depends on how many bits they have to transmit or store.
Some machine architectures use fixed size packet buffers, so Some machine architectures use fixed size packet buffers, so
buffer memory in these cases is packet-congestible (see buffer memory in these cases is packet-congestible (see
Section 4.1.1). Section 4.1.1).
Currently a design goal of network processing equipment such as The path through a machine will typically encounter both packet-
routers and firewalls is to keep packet processing uncongested congestible and bit-congestible resources. However, currently, a
even under worst case packet rates with runs of minimum size design goal of network processing equipment such as routers and
packets. Therefore, packet-congestion is currently rare [RFC6077; firewalls is to size the packet-processing engine(s) relative to
S.3.3], but there is no guarantee that it will not become more the lines in order to keep packet processing uncongested even
common in future. under worst case packet rates with runs of minimum size packets.
Therefore, packet-congestion is currently rare [RFC6077; S.3.3],
but there is no guarantee that it will not become more common in
future.
Note that information is generally processed or transmitted with a Note that information is generally processed or transmitted with a
minimum granularity greater than a bit (e.g. octets). The minimum granularity greater than a bit (e.g. octets). The
appropriate granularity for the resource in question should be appropriate granularity for the resource in question should be
used, but for the sake of brevity we will talk in terms of bytes used, but for the sake of brevity we will talk in terms of bytes
in this memo. in this memo.
Coarser Granularity: Resources may be congestible at higher levels Coarser Granularity: Resources may be congestible at higher levels
of granularity than bits or packets, for instance stateful of granularity than bits or packets, for instance stateful
firewalls are flow-congestible and call-servers are session- firewalls are flow-congestible and call-servers are session-
congestible. This memo focuses on congestion of connectionless congestible. This memo focuses on congestion of connectionless
resources, but the same principles may be applicable for resources, but the same principles may be applicable for
congestion notification protocols controlling per-flow and per- congestion notification protocols controlling per-flow and per-
session processing or state. session processing or state.
RED Terminology: In RED whether to use packets or bytes when RED Terminology: In RED whether to use packets or bytes when
measuring queues is called respectively "packet-mode queue measuring queues is called respectively "packet-mode queue
measurement" or "byte-mode queue measurement". And whether the measurement" or "byte-mode queue measurement". And whether the
probability of dropping a particular packet is independent or probability of dropping a particular packet is independent or
dependent on its byte-size is called respectively "packet-mode dependent on its size is called respectively "packet-mode drop" or
drop" or "byte-mode drop". The terms byte-mode and packet-mode "byte-mode drop". The terms byte-mode and packet-mode should not
should not be used without specifying whether they apply to queue be used without specifying whether they apply to queue measurement
measurement or to drop. or to drop.
1.2. Example Comparing Packet-Mode Drop and Byte-Mode Drop 1.2. Example Comparing Packet-Mode Drop and Byte-Mode Drop
A central question addressed by this document is whether to recommend Taking RED as a well-known example algorithm, a central question
that AQM uses RED's packet-mode drop and to deprecate byte-mode drop. addressed by this document is whether to recommend RED's packet-mode
Table 1 compares how packet-mode and byte-mode drop affect two flows drop variant and to deprecate byte-mode drop. Table 1 compares how
of different size packets. For each it gives the expected number of packet-mode and byte-mode drop affect two flows of different size
packets and of bits dropped in one second. Each example flow runs at packets. For each it gives the expected number of packets and of
the same bit-rate of 48Mb/s, but one is broken up into small 60 byte bits dropped in one second. Each example flow runs at the same bit-
packets and the other into large 1500 byte packets. rate of 48Mb/s, but one is broken up into small 60 byte packets and
the other into large 1500 byte packets.
To keep up the same bit-rate, in one second there are about 25 times To keep up the same bit-rate, in one second there are about 25 times
more small packets because they are 25 times smaller. As can be seen more small packets because they are 25 times smaller. As can be seen
from the table, the packet rate is 100,000 small packets versus 4,000 from the table, the packet rate is 100,000 small packets versus 4,000
large packets per second (pps). large packets per second (pps).
Parameter Formula Small packets Large packets Parameter Formula Small packets Large packets
-------------------- -------------- ------------- ------------- -------------------- -------------- ------------- -------------
Packet size s/8 60B 1,500B Packet size s/8 60B 1,500B
Packet size s 480b 12,000b Packet size s 480b 12,000b
skipping to change at page 9, line 7 skipping to change at page 9, line 13
proportionate to the size of the packet it is in. proportionate to the size of the packet it is in.
2. Recommendations 2. Recommendations
This section gives recommendations related to network equipment in This section gives recommendations related to network equipment in
Sections 2.1 and 2.2, and in Sections 2.3 and 2.4 we discuss the Sections 2.1 and 2.2, and in Sections 2.3 and 2.4 we discuss the
implications on the transport protocols. implications on the transport protocols.
2.1. Recommendation on Queue Measurement 2.1. Recommendation on Queue Measurement
Queue length is usually the most correct and simplest way to measure Ideally, an AQM would measure the service time of the queue to
congestion of a resource. To avoid the pathological effects of drop measure congestion of a resource. However service time can only be
tail, an AQM function can then be used to transform queue length into measured as packets leave the queue, where it is not always feasible
the probability of dropping or marking a packet (e.g. RED's to implement a full AQM algorithm. To predict the service time as
piecewise linear function between thresholds). packets join the queue, an AQM algorithm needs to measure the length
of the queue.
If the resource is bit-congestible, the implementation SHOULD measure In this case, if the resource is bit-congestible, the AQM
the length of the queue in bytes. If the resource is packet- implementation SHOULD measure the length of the queue in bytes and,
congestible, the implementation SHOULD measure the length of the if the resource is packet-congestible, the implementation SHOULD
queue in packets. No other choice makes sense, because the number of measure the length of the queue in packets. No other choice makes
packets waiting in the queue isn't relevant if the resource gets sense, because the number of packets waiting in the queue isn't
congested by bytes and vice versa. relevant if the resource gets congested by bytes and vice versa. For
example, the length of the queue into a transmission line would be
measured in bytes, while the length of the queue into a firewall
would be measured in packets.
What this advice means for the case of RED: To avoid the pathological effects of drop tail, the AQM can then
transform this service time or queue length into the probability of
dropping or marking a packet (e.g. RED's piecewise linear function
between thresholds).
What this advice means for RED as a specific example:
1. A RED implementation SHOULD use byte mode queue measurement for 1. A RED implementation SHOULD use byte mode queue measurement for
measuring the congestion of bit-congestible resources and packet measuring the congestion of bit-congestible resources and packet
mode queue measurement for packet-congestible resources. mode queue measurement for packet-congestible resources.
2. An implementation SHOULD NOT make it possible to configure the 2. An implementation SHOULD NOT make it possible to configure the
way a queue measures itself, because whether a queue is bit- way a queue measures itself, because whether a queue is bit-
congestible or packet-congestible is an inherent property of the congestible or packet-congestible is an inherent property of the
queue. queue.
Exceptions to these recommendations MAY be necessary, for instance
where a packet-congestible resource has to be configured as a proxy
bottleneck for a bit-congestible resource in an adjacent box that
does not support AQM.
The recommended approach in less straightforward scenarios, such as The recommended approach in less straightforward scenarios, such as
fixed size buffers, and resources without a queue, is discussed in fixed size packet buffers, resources without a queue and buffers
Section 4.1. comprising a mix of packet and bit-congestible resources, is
discussed in Section 4.1. For instance, Section 4.1.1 explains that
the queue into a line should be measured in bytes even if the queue
consists of fixed-size packet-buffers, because the root-cause of any
congestion is bytes arriving too fast for the line--packets filling
buffers are merely a symptom of the underlying congestion of the
line.
2.2. Recommendation on Encoding Congestion Notification 2.2. Recommendation on Encoding Congestion Notification
When encoding congestion notification (e.g. by drop, ECN & PCN), a When encoding congestion notification (e.g. by drop, ECN or PCN), the
network device SHOULD treat all packets equally, regardless of their probability that network equipment drops or marks a particular packet
size. In other words, the probability that network equipment drops to notify congestion SHOULD NOT depend on the size of the packet in
or marks a particular packet to notify congestion SHOULD NOT depend question. As the example in Section 1.2 illustrates, to drop any bit
on the size of the packet in question. As the example in Section 1.2 with probability 0.1% it is only necessary to drop every packet with
illustrates, to drop any bit with probability 0.1% it is only probability 0.1% without regard to the size of each packet.
necessary to drop every packet with probability 0.1% without regard
to the size of each packet.
This approach ensures the network layer offers sufficient congestion This approach ensures the network layer offers sufficient congestion
information for all known and future transport protocols and also information for all known and future transport protocols and also
ensures no perverse incentives are created that would encourage ensures no perverse incentives are created that would encourage
transports to use inappropriately small packet sizes. transports to use inappropriately small packet sizes.
What this advice means for the case of RED: What this advice means for RED as a specific example:
1. AQM algorithms such as RED SHOULD use packet-mode drop, ie they 1. The RED AQM algorithm SHOULD NOT use byte-mode drop, i.e. it
SHOULD NOT use byte-mode drop. The latter is more complex, it ought to use packet-mode drop. Byte-mode drop is more complex,
creates the perverse incentive to fragment segments into tiny it creates the perverse incentive to fragment segments into tiny
pieces and it is vulnerable to floods of small packets. pieces and it is vulnerable to floods of small packets.
2. If a vendor has implemented byte-mode drop, and an operator has 2. If a vendor has implemented byte-mode drop, and an operator has
turned it on, it is RECOMMENDED to turn it off, after turned it on, it is RECOMMENDED to switch it to packet-mode drop,
establishing if there are any implications on the relative after establishing if there are any implications on the relative
performance of applications using different packet sizes. performance of applications using different packet sizes. The
RED as a whole SHOULD NOT be turned off. Without RED, a drop unlikely possibility of some application-specific legacy use of
byte-mode drop is the only reason that all the above
recommendations on encoding congestion notification are not
phrased more strongly.
RED as a whole SHOULD NOT be switched off. Without RED, a drop
tail queue biases against large packets and is vulnerable to tail queue biases against large packets and is vulnerable to
floods of small packets. floods of small packets.
Note well that RED's byte-mode queue drop is completely orthogonal to Note well that RED's byte-mode queue drop is completely orthogonal to
byte-mode queue measurement and should not be confused with it. If a byte-mode queue measurement and should not be confused with it. If a
RED implementation has a byte-mode but does not specify what sort of RED implementation has a byte-mode but does not specify what sort of
byte-mode, it is most probably byte-mode queue measurement, which is byte-mode, it is most probably byte-mode queue measurement, which is
fine. However, if in doubt, the vendor should be consulted. fine. However, if in doubt, the vendor should be consulted.
A survey (Appendix A) showed that there appears to be little, if any, A survey (Appendix A) showed that there appears to be little, if any,
skipping to change at page 10, line 48 skipping to change at page 11, line 29
indication on every octet of the packet, not just one indication per indication on every octet of the packet, not just one indication per
packet. packet.
To be clear, the above recommendation solely describes how a To be clear, the above recommendation solely describes how a
transport should interpret the meaning of a congestion indication. transport should interpret the meaning of a congestion indication.
It makes no recommendation on whether a transport should act It makes no recommendation on whether a transport should act
differently based on this interpretation. It merely aids differently based on this interpretation. It merely aids
interoperablity between transports, if they choose to make their interoperablity between transports, if they choose to make their
actions depend on the strength of congestion indications. actions depend on the strength of congestion indications.
This definition will be useful as the the IETF transport area This definition will be useful as the IETF transport area continues
continues its programme of; its programme of;
o updating host-based congestion control protocols to take account o updating host-based congestion control protocols to take account
of packet size of packet size
o making transports less sensitive to losing control packets like o making transports less sensitive to losing control packets like
SYNs and pure ACKs. SYNs and pure ACKs.
What this advice means for the case of TCP: What this advice means for the case of TCP:
1. If two TCP flows with different packet sizes are required to run 1. If two TCP flows with different packet sizes are required to run
at equal bit rates under the same path conditions, this should be at equal bit rates under the same path conditions, this SHOULD be
done by altering TCP (Section 4.2.2), not network equipment (the done by altering TCP (Section 4.2.2), not network equipment (the
latter affects other transports besides TCP). latter affects other transports besides TCP).
2. If it is desired to improve TCP performance by reducing the 2. If it is desired to improve TCP performance by reducing the
chance that a SYN or a pure ACK will be dropped, this should be chance that a SYN or a pure ACK will be dropped, this SHOULD be
done by modifying TCP (Section 4.2.3), not network equipment. done by modifying TCP (Section 4.2.3), not network equipment.
To be clear, we are not recommending at all that TCPs under To be clear, we are not recommending at all that TCPs under
equivalent conditions should aim for equal bit-rates. We are merely equivalent conditions should aim for equal bit-rates. We are merely
saying that anyone trying to do such a thing should modify their TCP saying that anyone trying to do such a thing should modify their TCP
algorithm, not the network. algorithm, not the network.
These recommendations are phrased as 'SHOULD' rather than 'MUST',
because there may be cases where compatibility with pre-existing
versions of a transport protocol make the recommendations
impractical.
2.4. Recommendation on Handling Congestion Indications when Splitting 2.4. Recommendation on Handling Congestion Indications when Splitting
or Merging Packets or Merging Packets
Packets carrying congestion indications may be split or merged in Packets carrying congestion indications may be split or merged in
some circumstances (e.g. at a RTCP transcoder or during IP fragment some circumstances (e.g. at a RTP/RTCP transcoder or during IP
reassembly). Splitting and merging only make sense in the context of fragment reassembly). Splitting and merging only make sense in the
ECN, not loss. context of ECN, not loss.
The general rule to follow is that the number of octets in packets The general rule to follow is that the number of octets in packets
with congestion indications SHOULD be equivalent before and after with congestion indications SHOULD be equivalent before and after
merging or splitting. This is based on the principle used above; merging or splitting. This is based on the principle used above;
that an indication of congestion on a packet can be considered as an that an indication of congestion on a packet can be considered as an
indication of congestion on each octet of the packet. indication of congestion on each octet of the packet.
The above rule is not phrased with the word "MUST" to allow the The above rule is not phrased with the word "MUST" to allow the
following exception. There are cases where pre-existing protocols following exception. There are cases where pre-existing protocols
were not designed to conserve congestion marked octets (e.g. IP were not designed to conserve congestion marked octets (e.g. IP
fragment reassembly [RFC3168] or loss statistics in RTCP receiver fragment reassembly [RFC3168] or loss statistics in RTCP receiver
reports [RFC3550] before ECN was added reports [RFC3550] before ECN was added [RFC6679]). When any such
[I-D.ietf-avtcore-ecn-for-rtp]). When any such protocol is updated, protocol is updated, it SHOULD comply with the above rule to conserve
it SHOULD comply with the above rule to conserve marked octets. marked octets. However, the rule may be relaxed if it would
However, the rule may be relaxed if it would otherwise become too otherwise become too complex to interoperate with pre-existing
complex to interoperate with pre-existing implementations of the implementations of the protocol.
protocol.
One can think of a splitting or merging process as if all the One can think of a splitting or merging process as if all the
incoming congestion-marked octets increment a counter and all the incoming congestion-marked octets increment a counter and all the
outgoing marked octets decrement the same counter. In order to outgoing marked octets decrement the same counter. In order to
ensure that congestion indications remain timely, even the smallest ensure that congestion indications remain timely, even the smallest
positive remainder in the conceptual counter should trigger the next positive remainder in the conceptual counter should trigger the next
outgoing packet to be marked (causing the counter to go negative). outgoing packet to be marked (causing the counter to go negative).
3. Motivating Arguments 3. Motivating Arguments
skipping to change at page 12, line 36 skipping to change at page 13, line 21
than smaller ones would be dangerous in both the following cases: than smaller ones would be dangerous in both the following cases:
Malicious transports: A queue that gives an advantage to small Malicious transports: A queue that gives an advantage to small
packets can be used to amplify the force of a flooding attack. By packets can be used to amplify the force of a flooding attack. By
sending a flood of small packets, the attacker can get the queue sending a flood of small packets, the attacker can get the queue
to discard more traffic in large packets, allowing more attack to discard more traffic in large packets, allowing more attack
traffic to get through to cause further damage. Such a queue traffic to get through to cause further damage. Such a queue
allows attack traffic to have a disproportionately large effect on allows attack traffic to have a disproportionately large effect on
regular traffic without the attacker having to do much work. regular traffic without the attacker having to do much work.
Non-malicious transports: Even if a transport designer is not Non-malicious transports: Even if an application designer is not
actually malicious, if over time it is noticed that small packets actually malicious, if over time it is noticed that small packets
tend to go faster, designers will act in their own interest and tend to go faster, designers will act in their own interest and
use smaller packets. Queues that give advantage to small packets use smaller packets. Queues that give advantage to small packets
create an evolutionary pressure for transports to send at the same create an evolutionary pressure for applications or transports to
bit-rate but break their data stream down into tiny segments to send at the same bit-rate but break their data stream down into
reduce their drop rate. Encouraging a high volume of tiny packets tiny segments to reduce their drop rate. Encouraging a high
might in turn unnecessarily overload a completely unrelated part volume of tiny packets might in turn unnecessarily overload a
of the system, perhaps more limited by header-processing than completely unrelated part of the system, perhaps more limited by
bandwidth. header-processing than bandwidth.
Imagine two unresponsive flows arrive at a bit-congestible Imagine two unresponsive flows arrive at a bit-congestible
transmission link each with the same bit rate, say 1Mbps, but one transmission link each with the same bit rate, say 1Mbps, but one
consists of 1500B and the other 60B packets, which are 25x smaller. consists of 1500B and the other 60B packets, which are 25x smaller.
Consider a scenario where gentle RED [gentle_RED] is used, along with Consider a scenario where gentle RED [gentle_RED] is used, along with
the variant of RED we advise against, i.e. where the RED algorithm is the variant of RED we advise against, i.e. where the RED algorithm is
configured to adjust the drop probability of packets in proportion to configured to adjust the drop probability of packets in proportion to
each packet's size (byte mode packet drop). In this case, RED aims each packet's size (byte mode packet drop). In this case, RED aims
to drop 25x more of the larger packets than the smaller ones. Thus, to drop 25x more of the larger packets than the smaller ones. Thus,
for example if RED drops 25% of the larger packets, it will aim to for example if RED drops 25% of the larger packets, it will aim to
skipping to change at page 13, line 24 skipping to change at page 14, line 9
Note that, although the byte-mode drop variant of RED amplifies small Note that, although the byte-mode drop variant of RED amplifies small
packet attacks, drop-tail queues amplify small packet attacks even packet attacks, drop-tail queues amplify small packet attacks even
more (see Security Considerations in Section 6). Wherever possible more (see Security Considerations in Section 6). Wherever possible
neither should be used. neither should be used.
3.2. Small != Control 3.2. Small != Control
Dropping fewer control packets considerably improves performance. It Dropping fewer control packets considerably improves performance. It
is tempting to drop small packets with lower probability in order to is tempting to drop small packets with lower probability in order to
improve performance, because many control packets are small (TCP SYNs improve performance, because many control packets tend to be smaller
& ACKs, DNS queries & responses, SIP messages, HTTP GETs, etc). (TCP SYNs & ACKs, DNS queries & responses, SIP messages, HTTP GETs,
However, we must not give control packets preference purely by virtue etc). However, we must not give control packets preference purely by
of their smallness, otherwise it is too easy for any data source to virtue of their smallness, otherwise it is too easy for any data
get the same preferential treatment simply by sending data in smaller source to get the same preferential treatment simply by sending data
packets. Again we should not create perverse incentives to favour in smaller packets. Again we should not create perverse incentives
small packets rather than to favour control packets, which is what we to favour small packets rather than to favour control packets, which
intend. is what we intend.
Just because many control packets are small does not mean all small Just because many control packets are small does not mean all small
packets are control packets. packets are control packets.
So, rather than fix these problems in the network, we argue that the So, rather than fix these problems in the network, we argue that the
transport should be made more robust against losses of control transport should be made more robust against losses of control
packets (see 'Making Transports Robust against Control Packet Losses' packets (see 'Making Transports Robust against Control Packet Losses'
in Section 4.2.3). in Section 4.2.3).
3.3. Transport-Independent Network 3.3. Transport-Independent Network
skipping to change at page 15, line 38 skipping to change at page 16, line 20
argument applies solely to drop, not to ECN marking. argument applies solely to drop, not to ECN marking.
A queue drops packets for either of two reasons: a) to signal to host A queue drops packets for either of two reasons: a) to signal to host
congestion controls that they should reduce the load and b) because congestion controls that they should reduce the load and b) because
there is no buffer left to store the packets. Active queue there is no buffer left to store the packets. Active queue
management tries to use drops as a signal for hosts to slow down management tries to use drops as a signal for hosts to slow down
(case a) so that drop due to buffer exhaustion (case b) should not be (case a) so that drop due to buffer exhaustion (case b) should not be
necessary. necessary.
AQM is not universally deployed in every queue in the Internet; many AQM is not universally deployed in every queue in the Internet; many
cheap ethernet bridges, software firewalls, NATs on consumer devices, cheap Ethernet bridges, software firewalls, NATs on consumer devices,
etc implement simple tail-drop buffers. Even if AQM were universal, etc implement simple tail-drop buffers. Even if AQM were universal,
it has to be able to cope with buffer exhaustion (by switching to a it has to be able to cope with buffer exhaustion (by switching to a
behaviour like tail-drop), in order to cope with unresponsive or behaviour like tail-drop), in order to cope with unresponsive or
excessive transports. For these reasons networks will sometimes be excessive transports. For these reasons networks will sometimes be
dropping packets as a last resort (case b) rather than under AQM dropping packets as a last resort (case b) rather than under AQM
control (case a). control (case a).
When buffers are exhausted (case b), they don't naturally drop When buffers are exhausted (case b), they don't naturally drop
packets in proportion to their size. The network can only reduce the packets in proportion to their size. The network can only reduce the
probability of dropping smaller packets if it has enough space to probability of dropping smaller packets if it has enough space to
skipping to change at page 17, line 20 skipping to change at page 18, line 4
on its own size (Section 4.2). on its own size (Section 4.2).
The rest of this section is structured accordingly. The rest of this section is structured accordingly.
4.1. Congestion Measurement Advice 4.1. Congestion Measurement Advice
The choice of which metric to use to measure queue length was left The choice of which metric to use to measure queue length was left
open in RFC2309. It is now well understood that queues for bit- open in RFC2309. It is now well understood that queues for bit-
congestible resources should be measured in bytes, and queues for congestible resources should be measured in bytes, and queues for
packet-congestible resources should be measured in packets packet-congestible resources should be measured in packets
[pktByteEmail]. [pktByteEmail].
Congestion in some legacy bit-congestible buffers is only measured in Congestion in some legacy bit-congestible buffers is only measured in
packets not bytes. In such cases, the operator has to set the packets not bytes. In such cases, the operator has to set the
thresholds mindful of a typical mix of packets sizes. Any AQM thresholds mindful of a typical mix of packets sizes. Any AQM
algorithm on such a buffer will be oversensitive to high proportions algorithm on such a buffer will be oversensitive to high proportions
of small packets, e.g. a DoS attack, and undersensitive to high of small packets, e.g. a DoS attack, and under-sensitive to high
proportions of large packets. However, there is no need to make proportions of large packets. However, there is no need to make
allowances for the possibility of such legacy in future protocol allowances for the possibility of such legacy in future protocol
design. This is safe because any undersensitivity during unusual design. This is safe because any under-sensitivity during unusual
traffic mixes cannot lead to congestion collapse given the buffer traffic mixes cannot lead to congestion collapse given the buffer
will eventually revert to tail drop, discarding proportionately more will eventually revert to tail drop, discarding proportionately more
large packets. large packets.
4.1.1. Fixed Size Packet Buffers 4.1.1. Fixed Size Packet Buffers
The question of whether to measure queues in bytes or packets seems The question of whether to measure queues in bytes or packets seems
to be well understood. However, measuring congestion is not to be well understood. However, measuring congestion is confusing
straightforward when the resource is bit congestible but the queue is when the resource is bit congestible but the queue into the resource
packet congestible or vice versa. This section outlines the approach is packet congestible. This section outlines the approach to take.
to take. There is no controversy over what should be done, you just
need to be expert in probability to work it out. And, even if you
know what should be done, it's not always easy to find a practical
algorithm to implement it.
Some, mostly older, queuing hardware sets aside fixed sized buffers Some, mostly older, queuing hardware allocates fixed sized buffers in
in which to store each packet in the queue. Also, with some which to store each packet in the queue. This hardware forwards to
hardware, any fixed sized buffers not completely filled by a packet the line in one of two ways:
are padded when transmitted to the wire. If we imagine a theoretical
forwarding system with both queuing and transmission in fixed, MTU-
sized units, it should clearly be treated as packet-congestible,
because the queue length in packets would be a good model of
congestion of the lower layer link.
If we now imagine a hybrid forwarding system with transmission delay o With some hardware, any fixed sized buffers not completely filled
largely dependent on the byte-size of packets but buffers of one MTU by a packet are padded when transmitted to the wire. This case,
per packet, it should strictly require a more complex algorithm to should clearly be treated as packet-congestible, because both
determine the probability of congestion. It should be treated as two queuing and transmission are in fixed MTU-sized units. Therefore
resources in sequence, where the sum of the byte-sizes of the packets the queue length in packets is a good model of congestion of the
within each packet buffer models congestion of the line while the link.
length of the queue in packets models congestion of the queue. Then
the probability of congesting the forwarding buffer would be a
conditional probability--conditional on the previously calculated
probability of congesting the line.
In systems that use fixed size buffers, it is unusual for all the o More commonly, hardware with fixed size packet buffers transmits
buffers used by an interface to be the same size. Typically pools of packets to line without padding. This implies a hybrid forwarding
system with transmission congestion dependent on the size of
packets but queue congestion dependent on the number of packets,
irrespective of their size.
Nonetheless, there would be no queue at all unless the line had
become congested--the root-cause of any congestion is too many
bytes arriving for the line. Therefore, the AQM should measure
the queue length as the sum of all the packet sizes in bytes that
are queued up waiting to be serviced by the line, irrespective of
whether each packet is held in a fixed size buffer.
In the (unlikely) first case where use of padding means the queue
should be measured in packets, further confusion is likely because
the fixed buffers are rarely all one size. Typically pools of
different sized buffers are provided (Cisco uses the term 'buffer different sized buffers are provided (Cisco uses the term 'buffer
carving' for the process of dividing up memory into these pools carving' for the process of dividing up memory into these pools
[IOSArch]). Usually, if the pool of small buffers is exhausted, [IOSArch]). Usually, if the pool of small buffers is exhausted,
arriving small packets can borrow space in the pool of large buffers, arriving small packets can borrow space in the pool of large buffers,
but not vice versa. However, it is easier to work out what should be but not vice versa. However, there is no need to consider all this
done if we temporarily set aside the possibility of such borrowing. complexity, because the root-cause of any congestion is still line
Then, with fixed pools of buffers for different sized packets and no overload--buffer consumption is only the symptom. Therefore, the
borrowing, the size of each pool and the current queue length in each length of the queue should be measured as the sum of the bytes in the
pool would both be measured in packets. So an AQM algorithm would queue that will be transmitted to line, including any padding. In
have to maintain the queue length for each pool, and judge whether to the (unusual) case of transmission with padding this means the sum of
drop/mark a packet of a particular size by looking at the pool for the sizes of the small buffers queued plus the sum of the sizes of
packets of that size and using the length (in packets) of its queue. the large buffers queued.
We now return to the issue we temporarily set aside: small packets
borrowing space in larger buffers. In this case, the only difference
is that the pools for smaller packets have a maximum queue size that
includes all the pools for larger packets. And every time a packet
takes a larger buffer, the current queue size has to be incremented
for all queues in the pools of buffers less than or equal to the
buffer size used.
We will return to borrowing of fixed sized buffers when we discuss We will return to borrowing of fixed sized buffers when we discuss
biasing the drop/marking probability of a specific packet because of biasing the drop/marking probability of a specific packet because of
its size in Section 4.2.1. But here we can give a at least one its size in Section 4.2.1. But here we can repeat the simple rule
simple rule for how to measure the length of queues of fixed buffers: for how to measure the length of queues of fixed buffers: no matter
no matter how complicated the scheme is, ultimately any fixed buffer how complicated the buffering scheme is, ultimately a transmission
system will need to measure its queue length in packets not bytes. 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 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,
wireless spectrum is usually regarded as bit-congestible (for a given wireless spectrum is usually regarded as bit-congestible (for a given
coding scheme). But wireless link protocols do not always maintain a coding scheme). But wireless link protocols do not always maintain a
queue that depends on spectrum interference. Similarly, power queue that depends on spectrum interference. Similarly, power
limited resources are also usually bit-congestible if energy is limited resources are also usually bit-congestible if energy is
primarily required for transmission rather than header processing, primarily required for transmission rather than header processing,
but it is rare for a link protocol to build a queue as it approaches but it is rare for a link protocol to build a queue as it approaches
maximum power. 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.
skipping to change at page 20, line 4 skipping to change at page 20, line 34
by making the policing mechanism count the volume of bytes randomly by making the policing mechanism count the volume of bytes randomly
dropped, not the number of packets. dropped, not the number of packets.
A few months before RFC2309 was published, an addendum was added to A few months before RFC2309 was published, an addendum was added to
the above archived email referenced from the RFC, in which the final the above archived email referenced from the RFC, in which the final
paragraph seemed to partially retract what had previously been said. paragraph seemed to partially retract what had previously been said.
It clarified that the question of whether the probability of It clarified that the question of whether the probability of
dropping/marking a packet should depend on its size was not related dropping/marking a packet should depend on its size was not related
to whether the resource itself was bit congestible, but a completely to whether the resource itself was bit congestible, but a completely
orthogonal question. However the only example given had the queue orthogonal question. However the only example given had the queue
measured in packets but packet drop depended on the byte-size of the measured in packets but packet drop depended on the size of the
packet in question. No example was given the other way round. packet in question. No example was given the other way round.
In 2000, Cnodder et al [REDbyte] pointed out that there was an error In 2000, Cnodder et al [REDbyte] pointed out that there was an error
in the part of the original 1993 RED algorithm that aimed to in the part of the original 1993 RED algorithm that aimed to
distribute drops uniformly, because it didn't correctly take into distribute drops uniformly, because it didn't correctly take into
account the adjustment for packet size. They recommended an account the adjustment for packet size. They recommended an
algorithm called RED_4 to fix this. But they also recommended a algorithm called RED_4 to fix this. But they also recommended a
further change, RED_5, to adjust drop rate dependent on the square of further change, RED_5, to adjust drop rate dependent on the square of
relative packet size. This was indeed consistent with one implied relative packet size. This was indeed consistent with one implied
motivation behind RED's byte mode drop--that we should reverse motivation behind RED's byte mode drop--that we should reverse
skipping to change at page 20, line 38 skipping to change at page 21, line 19
probabilities of greater than 1 (which gives a hint that there is probabilities of greater than 1 (which gives a hint that there is
probably a mistake in the theory somewhere). probably a mistake in the theory somewhere).
On 10-Nov-2004, this variant of byte-mode packet drop was made the On 10-Nov-2004, this variant of byte-mode packet drop was made the
default in the ns2 simulator. It seems unlikely that byte-mode drop default in the ns2 simulator. It seems unlikely that byte-mode drop
has ever been implemented in production networks (Appendix A), has ever been implemented in production networks (Appendix A),
therefore any conclusions based on ns2 simulations that use RED therefore any conclusions based on ns2 simulations that use RED
without disabling byte-mode drop are likely to behave very without disabling byte-mode drop are likely to behave very
differently from RED in production networks. differently from RED in production networks.
4.2.1.2. Packet Size Bias Regardless of RED 4.2.1.2. Packet Size Bias Regardless of AQM
The byte-mode drop variant of RED is, of course, not the only The byte-mode drop variant of RED (or a similar variant of other AQM
possible bias towards small packets in queueing systems. We have algorithms) is not the only possible bias towards small packets in
already mentioned that tail-drop queues naturally tend to lock-out queueing systems. We have already mentioned that tail-drop queues
large packets once they are full. But also queues with fixed sized naturally tend to lock-out large packets once they are full.
buffers reduce the probability that small packets will be dropped if
(and only if) they allow small packets to borrow buffers from the
pools for larger packets. As was explained in Section 4.1.1 on fixed
size buffer carving, borrowing effectively makes the maximum queue
size for small packets greater than that for large packets, because
more buffers can be used by small packets while less will fit large
packets.
In itself, the bias towards small packets caused by buffer borrowing But also queues with fixed sized buffers reduce the probability that
is perfectly correct. Lower drop probability for small packets is small packets will be dropped if (and only if) they allow small
legitimate in buffer borrowing schemes, because small packets packets to borrow buffers from the pools for larger packets (see
genuinely congest the machine's buffer memory less than large Section 4.1.1). Borrowing effectively makes the maximum queue size
packets, given they can fit in more spaces. The bias towards small for small packets greater than that for large packets, because more
packets is not artificially added (as it is in RED's byte-mode drop buffers can be used by small packets while less will fit large
algorithm), it merely reflects the reality of the way fixed buffer packets. Incidentally, the bias towards small packets from buffer
memory gets congested. Incidentally, the bias towards small packets borrowing is nothing like as large as that of RED's byte-mode drop.
from buffer borrowing is nothing like as large as that of RED's byte-
mode drop.
Nonetheless, fixed-buffer memory with tail drop is still prone to Nonetheless, fixed-buffer memory with tail drop is still prone to
lock-out large packets, purely because of the tail-drop aspect. So a lock-out large packets, purely because of the tail-drop aspect. So,
good AQM algorithm like RED with packet-mode drop should be used with fixed size packet-buffers should be augmented with a good AQM
fixed buffer memories where possible. If RED is too complicated to algorithm and packet-mode drop. If an AQM is too complicated to
implement with multiple fixed buffer pools, the minimum necessary to implement with multiple fixed buffer pools, the minimum necessary to
prevent large packet lock-out is to ensure smaller packets never use prevent large packet lock-out is to ensure smaller packets never use
the last available buffer in any of the pools for larger packets. the last available buffer in any of the pools for larger packets.
4.2.2. Transport Bias when Decoding 4.2.2. Transport Bias when Decoding
The above proposals to alter the network equipment to bias towards The above proposals to alter the network equipment to bias towards
smaller packets have largely carried on outside the IETF process. smaller packets have largely carried on outside the IETF process.
Whereas, within the IETF, there are many different proposals to alter Whereas, within the IETF, there are many different proposals to alter
transport protocols to achieve the same goals, i.e. either to make transport protocols to achieve the same goals, i.e. either to make
skipping to change at page 27, line 36 skipping to change at page 27, line 51
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 [RFC2119] Bradner, S., "Key words for use in RFCs to
RFCs to Indicate Requirement Levels", Indicate Requirement Levels", BCP 14, RFC 2119,
BCP 14, RFC 2119, March 1997. March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Black, "The Addition of Explicit Addition of Explicit Congestion Notification
Congestion Notification (ECN) to IP", (ECN) to IP", RFC 3168, September 2001.
RFC 3168, September 2001.
11.2. Informative References 11.2. Informative References
[CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. [BLUE02] Feng, W-c., Shin, K., Kandlur, D., and D. Saha,
Le Boudec, "Congestion Control for "The BLUE active queue management algorithms",
Flows with Variable Packet Size", ACM IEEE/ACM Transactions on Networking 10(4) 513--
CCR 34(2) 137--151, 2004, <http:// 528, August 2002,
doi.acm.org/10.1145/997150.997162>. <http://dx.doi.org/10.1109/TNET.2002.801399>.
[CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. [CCvarPktSize] Widmer, J., Boutremans, C., and J-Y. Le Boudec,
Prabhaker, "Approximate Fair Dropping "Congestion Control for Flows with Variable
for Variable Length Packets", IEEE Packet Size", ACM CCR 34(2) 137--151, 2004,
Micro 21(1):48--56, January- <http://doi.acm.org/10.1145/997150.997162>.
February 2001, <http://
www.stanford.edu/~balaji/papers/
01approximatefair.pdf}>.
[DRQ] Shin, M., Chong, S., and I. Rhee, [CHOKe_Var_Pkt] Psounis, K., Pan, R., and B. Prabhaker,
"Dual-Resource TCP/AQM for "Approximate Fair Dropping for Variable Length
Processing-Constrained Networks", Packets", IEEE Micro 21(1):48--56, January-
IEEE/ACM Transactions on February 2001, <http://www.stanford.edu/~balaji/
Networking Vol 16, issue 2, papers/01approximatefair.pdf}>.
April 2008, <http://dx.doi.org/
10.1109/TNET.2007.900415>.
[DupTCP] Wischik, D., "Short messages", Royal [CoDel12] Nichols, K. and V. Jacobson, "Controlling Queue
Society workshop on networks: Delay", ACM Queue 10(5), May 2012,
modelling and control , <http://queue.acm.org/detail.cfm?id=2209336>.
September 2007, <http://
www.cs.ucl.ac.uk/staff/ucacdjw/
Research/shortmsg.html>.
[ECNFixedWireless] Siris, V., "Resource Control for [DRQ] Shin, M., Chong, S., and I. Rhee, "Dual-Resource
Elastic Traffic in CDMA Networks", TCP/AQM for Processing-Constrained Networks",
Proc. ACM MOBICOM'02 , IEEE/ACM Transactions on Networking Vol 16,
September 2002, <http:// issue 2, April 2008,
www.ics.forth.gr/netlab/publications/ <http://dx.doi.org/10.1109/TNET.2007.900415>.
resource_control_elastic_cdma.html>.
[Evol_cc] Gibbens, R. and F. Kelly, "Resource [DupTCP] Wischik, D., "Short messages", Royal Society
pricing and the evolution of workshop on networks: modelling and control ,
congestion control", September 2007, <http://www.cs.ucl.ac.uk/staff/
Automatica 35(12)1969--1985, ucacdjw/Research/shortmsg.html>.
December 1999, <http://
www.statslab.cam.ac.uk/~frank/
evol.html>.
[I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I., [ECNFixedWireless] Siris, V., "Resource Control for Elastic Traffic
Perkins, C., O'Hanlon, P., and K. in CDMA Networks", Proc. ACM MOBICOM'02 ,
Carlberg, "Explicit Congestion September 2002, <http://www.ics.forth.gr/netlab/
Notification (ECN) for RTP over UDP", publications/
draft-ietf-avtcore-ecn-for-rtp-08 resource_control_elastic_cdma.html>.
(work in progress), May 2012.
[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A. [Evol_cc] Gibbens, R. and F. Kelly, "Resource pricing and
Cooper, "ConEx Concepts and Use the evolution of congestion control",
Cases", Automatica 35(12)1969--1985, December 1999,
(work in progress), March 2012. <http://www.statslab.cam.ac.uk/~frank/
evol.html>.
[IOSArch] Bollapragada, V., White, R., and C. [I-D.pan-tsvwg-pie] Pan, R., Natarajan, P., Piglione, C., and M.
Murphy, "Inside Cisco IOS Software Prabhu, "PIE: A Lightweight Control Scheme To
Architecture", Cisco Press: CCIE Address the Bufferbloat Problem",
Professional Development ISBN13: 978- draft-pan-tsvwg-pie-00 (work in progress),
1-57870-181-0, July 2000. December 2012.
[PktSizeEquCC] Vasallo, P., "Variable Packet Size [IOSArch] Bollapragada, V., White, R., and C. Murphy,
Equation-Based Congestion Control", "Inside Cisco IOS Software Architecture", Cisco
ICSI Technical Report tr-00-008, Press: CCIE Professional Development ISBN13:
2000, <http://http.icsi.berkeley.edu/ 978-1-57870-181-0, July 2000.
ftp/global/pub/techreports/2000/
tr-00-008.pdf>.
[RED93] Floyd, S. and V. Jacobson, "Random [PktSizeEquCC] Vasallo, P., "Variable Packet Size Equation-
Early Detection (RED) gateways for Based Congestion Control", ICSI Technical
Congestion Avoidance", IEEE/ACM Report tr-00-008, 2000, <http://
Transactions on Networking 1(4) 397-- http.icsi.berkeley.edu/ftp/global/pub/
413, August 1993, <http:// techreports/2000/tr-00-008.pdf>.
www.icir.org/floyd/papers/red/
red.html>.
[REDbias] Eddy, W. and M. Allman, "A Comparison [RED93] Floyd, S. and V. Jacobson, "Random Early
of RED's Byte and Packet Modes", Detection (RED) gateways for Congestion
Computer Networks 42(3) 261--280, Avoidance", IEEE/ACM Transactions on
June 2003, <http://www.ir.bbn.com/ Networking 1(4) 397--413, August 1993,
documents/articles/redbias.ps>. <http://www.icir.org/floyd/papers/red/red.html>.
[REDbyte] De Cnodder, S., Elloumi, O., and K. [REDbias] Eddy, W. and M. Allman, "A Comparison of RED's
Pauwels, "RED behavior with different Byte and Packet Modes", Computer Networks 42(3)
packet sizes", Proc. 5th IEEE 261--280, June 2003, <http://www.ir.bbn.com/
Symposium on Computers and documents/articles/redbias.ps>.
Communications (ISCC) 793--799,
July 2000, <http://www.icir.org/
floyd/red/Elloumi99.pdf>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., [REDbyte] De Cnodder, S., Elloumi, O., and K. Pauwels,
Davie, B., Deering, S., Estrin, D., "RED behavior with different packet sizes",
Floyd, S., Jacobson, V., Minshall, Proc. 5th IEEE Symposium on Computers and
G., Partridge, C., Peterson, L., Communications (ISCC) 793--799, July 2000,
Ramakrishnan, K., Shenker, S., <http://www.icir.org/floyd/red/Elloumi99.pdf>.
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., [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
and D. Black, "Definition of the Deering, S., Estrin, D., Floyd, S., Jacobson,
Differentiated Services Field (DS V., Minshall, G., Partridge, C., Peterson, L.,
Field) in the IPv4 and IPv6 Headers", Ramakrishnan, K., Shenker, S., Wroclawski, J.,
RFC 2474, December 1998. and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC3426] Floyd, S., "General Architectural and [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Policy Considerations", RFC 3426, "Definition of the Differentiated Services Field
November 2002. (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC3550] Schulzrinne, H., Casner, S., [RFC2914] Floyd, S., "Congestion Control Principles",
Frederick, R., and V. Jacobson, "RTP: BCP 41, RFC 2914, September 2000.
A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550,
July 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns [RFC3426] Floyd, S., "General Architectural and Policy
Regarding Congestion Control for Considerations", RFC 3426, November 2002.
Voice Traffic in the Internet",
RFC 3714, March 2004.
[RFC4828] Floyd, S. and E. Kohler, "TCP [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and
Friendly Rate Control (TFRC): The V. Jacobson, "RTP: A Transport Protocol for
Small-Packet (SP) Variant", RFC 4828, Real-Time Applications", STD 64, RFC 3550,
April 2007. July 2003.
[RFC5348] Floyd, S., Handley, M., Padhye, J., [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding
and J. Widmer, "TCP Friendly Rate Congestion Control for Voice Traffic in the
Control (TFRC): Protocol Internet", RFC 3714, March 2004.
Specification", RFC 5348,
September 2008.
[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate
S., and K. Ramakrishnan, "Adding Control (TFRC): The Small-Packet (SP) Variant",
Explicit Congestion Notification RFC 4828, April 2007.
(ECN) Capability to TCP's SYN/ACK
Packets", RFC 5562, June 2009.
[RFC5670] Eardley, P., "Metering and Marking [RFC5348] Floyd, S., Handley, M., Padhye, J., and J.
Behaviour of PCN-Nodes", RFC 5670, Widmer, "TCP Friendly Rate Control (TFRC):
November 2009. Protocol Specification", RFC 5348,
September 2008.
[RFC5681] Allman, M., Paxson, V., and E. [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K.
Blanton, "TCP Congestion Control", Ramakrishnan, "Adding Explicit Congestion
RFC 5681, September 2009. Notification (ECN) Capability to TCP's SYN/ACK
Packets", RFC 5562, June 2009.
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. [RFC5670] Eardley, P., "Metering and Marking Behaviour of
Iyengar, "Adding Acknowledgement PCN-Nodes", RFC 5670, November 2009.
Congestion Control to TCP", RFC 5690,
February 2010.
[RFC6077] Papadimitriou, D., Welzl, M., Scharf, [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP
M., and B. Briscoe, "Open Research Congestion Control", RFC 5681, September 2009.
Issues in Internet Congestion
Control", RFC 6077, February 2011.
[Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness: [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar,
Dismantling a Religion", ACM "Adding Acknowledgement Congestion Control to
CCR 37(2)63--74, April 2007, <http:// TCP", RFC 5690, February 2010.
portal.acm.org/
citation.cfm?id=1232926>.
[gentle_RED] Floyd, S., "Recommendation on using [RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., and B.
the "gentle_" variant of RED", Web Briscoe, "Open Research Issues in Internet
page , March 2000, <http:// Congestion Control", RFC 6077, February 2011.
www.icir.org/floyd/red/gentle.html>.
[pBox] Floyd, S. and K. Fall, "Promoting the [RFC6679] Westerlund, M., Johansson, I., Perkins, C.,
Use of End-to-End Congestion Control O'Hanlon, P., and K. Carlberg, "Explicit
in the Internet", IEEE/ACM Congestion Notification (ECN) for RTP over UDP",
Transactions on Networking 7(4) 458-- RFC 6679, August 2012.
472, August 1999, <http://
www.aciri.org/floyd/
end2end-paper.html>.
[pktByteEmail] Floyd, S., "RED: Discussions of Byte [RFC6789] Briscoe, B., Woundy, R., and A. Cooper,
and Packet Modes", Web page Red Queue "Congestion Exposure (ConEx) Concepts and Use
Management, March 1997, <Available Cases", RFC 6789, December 2012.
at: http://ee.lbl.gov/floyd/
REDaveraging.txt>. [Rate_fair_Dis] Briscoe, B., "Flow Rate Fairness: Dismantling a
Religion", ACM CCR 37(2)63--74, April 2007,
<http://portal.acm.org/citation.cfm?id=1232926>.
[gentle_RED] Floyd, S., "Recommendation on using the
"gentle_" variant of RED", Web page ,
March 2000,
<http://www.icir.org/floyd/red/gentle.html>.
[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,
<http://www.aciri.org/floyd/end2end-paper.html>.
[pktByteEmail] Floyd, S., "RED: Discussions of Byte and Packet
Modes", email , March 1997, <http://
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 38, line 34 skipping to change at page 38, line 29
cannot, at least not without a lot of complexity. cannot, at least not without a lot of complexity.
The early research proposals for type (i) policing at a bottleneck The early research proposals for type (i) policing at a bottleneck
link [pBox] used byte-mode drop, then detected flows that contributed link [pBox] used byte-mode drop, then detected flows that contributed
disproportionately to the number of packets dropped. However, with disproportionately to the number of packets dropped. However, with
no extra complexity, later proposals used packet mode drop and looked no extra complexity, later proposals used packet mode drop and looked
for flows that contributed a disproportionate amount of dropped bytes for flows that contributed a disproportionate amount of dropped bytes
[CHOKe_Var_Pkt]. [CHOKe_Var_Pkt].
Work is progressing on the congestion exposure protocol (ConEx Work is progressing on the congestion exposure protocol (ConEx
[I-D.ietf-conex-concepts-uses]), which enables a type (ii) edge [RFC6789]), which enables a type (ii) edge policer located at a
policer located at a user's attachment point. The idea is to be able user's attachment point. The idea is to be able to take an
to take an integrated view of the effect of all a user's traffic on integrated view of the effect of all a user's traffic on any link in
any link in the internetwork. However, byte-mode drop would the internetwork. However, byte-mode drop would effectively preclude
effectively preclude such edge policing because of the MTU issue such edge policing because of the MTU issue above.
above.
Indeed, making drop probability depend on the size of the packets Indeed, making drop probability depend on the size of the packets
that bits happen to be divided into would simply encourage the bits that bits happen to be divided into would simply encourage the bits
to be divided into smaller packets in order to confuse policing. In to be divided into smaller packets in order to confuse policing. In
contrast, as long as a dropped/marked packet is taken to mean that contrast, as long as a dropped/marked packet is taken to mean that
all the bytes in the packet are dropped/marked, a policer can remain all the bytes in the packet are dropped/marked, a policer can remain
robust against bits being re-divided into different size packets or robust against bits being re-divided into different size packets or
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 -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
AQMs and explained that we always use RED for examples, but
this doesn't mean it's not applicable to other AQMs. [A number
of reviewers have described the draft as "about RED"]
* S.1 & S.2.1 Queue measurement: Explained that the choice
between measuring the queue in packets or bytes is only
relevant if measuring it in time units is infeasible [So as not
to imply that we haven't noticed the advances made by PDPC &
CoDel]
* S.1.1. Terminology: Better explained why hybrid systems
congested by both packets and bytes are often designed to be
treated as bit-congestible [Richard Barnes].
* S.2.1. Queue measurement advice: Added examples. Added a
counter-example to justify SHOULDs rather than MUSTs. Pointed
to S.4.1 for a list of more complicated scenarios. [Benson
Schliesser, OpsDir]
* S2.2. Recommendation on Encoding Congestion Notification:
Removed SHOULD treat packets equally, leaving only SHOULD NOT
drop dependent on packet size, to avoid it sounding like we're
saying QoS is not allowed. Pointed to possible app-specific
legacy use of byte-mode as a counter-example that prevents us
saying MUST NOT. [Pete Resnick]
* S.2.3. Recommendation on Responding to Congestion: capitalised
the two SHOULDs in recommendations for TCP, and gave possible
counter-examples. [noticed while dealing with Pete Resnick's
point]
* S2.4. Splitting & Merging: RTCP -> RTP/RTCP [Pete McCann, Gen-
ART]
* S.3.2 Small != Control: many control packets are small ->
...tend to be small [Stephen Farrell]
* S.3.1 Perverse incentives: Changed transport designers to app
developers [Stephen Farrell]
* S.4.1.1. Fixed Size Packet Buffers: Nearly completely re-
written to simplify and to reverse the advice when the
underlying resource is bit-congestible, irrespective of whether
the buffer consists of fixed-size packet buffers. [Richard
Barnes & Benson Schliesser]
* S.4.2.1.2. Packet Size Bias Regardless of AQM: Largely re-
written to reflect the earlier change in advice about fixed-
size packet buffers, and to primarily focus on getting rid of
tail-drop, not various nuances of tail-drop. [Richard Barnes &
Benson Schliesser]
* Editorial corrections [Tim Bray, AppsDir, Pete McCann, Gen-ART
and others]
* Updated refs (two I-Ds have become RFCs). [Pete McCann]
From -08 to -09: Following WG last call:
* S.2.1: Made RED-related queue measurement recommendations
clearer
* S.2.3: Added to "Recommendation on Responding to Congestion" to
make it clear that we are definitely not saying transports have
to equalise bit-rates, just how to do it and not do it, if you
want to.
* S.3: Clarified motivation sections S.3.3 "Transport-Independent
Network" and S.3.5 "Implementation Efficiency"
* S.3.4: Completely changed motivating argument from "Scaling
Congestion Control with Packet Size" to "Partial Deployment of
AQM".
From -07 to -08:
* Altered abstract to say it provides best current practice and
highlight that it updates RFC2309
* Added null IANA section
* Updated refs
From -06 to -07: From -06 to -07:
* A mix-up with the corollaries and their naming in 2.1 to 2.3 * A mix-up with the corollaries and their naming in 2.1 to 2.3
fixed. fixed.
From -05 to -06: From -05 to -06:
* Primarily editorial fixes. * Primarily editorial fixes.
From -04 to -05: From -04 to -05:
 End of changes. 98 change blocks. 
383 lines changed or deleted 481 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/