draft-ietf-tcpm-prr-rfc6937bis-00.txt   draft-ietf-tcpm-prr-rfc6937bis-01.txt 
TCP Maintenance Working Group M. Mathis TCP Maintenance Working Group M. Mathis
Internet-Draft N. Dukkipati Internet-Draft N. Dukkipati
Obsoletes: 6937 (if approved) Y. Cheng Obsoletes: 6937 (if approved) Y. Cheng
Intended status: Standards Track Google, Inc. Intended status: Standards Track Google, Inc.
Expires: 16 July 2021 12 January 2021 Expires: 26 August 2021 22 February 2021
Proportional Rate Reduction for TCP Proportional Rate Reduction for TCP
draft-ietf-tcpm-prr-rfc6937bis-00 draft-ietf-tcpm-prr-rfc6937bis-01
Abstract Abstract
This document updates the Proportional Rate Reduction (PRR) algorithm This document updates the experimental Proportional Rate Reduction
described as experimental in RFC 6937 to standards track. PRR (PRR) algorithm, described RFC 6937, to standards track. PRR
potentially replaces the Fast Recovery and Rate-Halving algorithms. potentially replaces the Fast Recovery and Rate-Halving algorithms.
All of these algorithms regulate the amount of data sent by TCP or All of these algorithms regulate the amount of data sent by TCP or
other transport protocol during loss recovery. PRR more accurately other transport protocol during loss recovery. PRR accurately
regulates the actual flight size through recovery such that at the regulates the actual flight size through recovery such that at the
end of recovery it will be as close as possible to the ssthresh, as end of recovery it will be as close as possible to the ssthresh, as
determined by the congestion control algorithm. determined by the congestion control algorithm.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 16 July 2021. This Internet-Draft will expire on 26 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction to bis . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document and WG Information . . . . . . . . . . . . . . . 3 1.1. Document and WG Information . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Changes From RFC 6937 . . . . . . . . . . . . . . . . . . . . 5
4. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Relationships to other standards . . . . . . . . . . . . . . 6
4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Conclusion and Recommendations . . . . . . . . . . . . . . . 14 8. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Adapting PRR to other transport protocols . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 16 12. Normative References . . . . . . . . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . 15
Appendix A. Strong Packet Conservation Bound . . . . . . . . . . 17 Appendix A. Strong Packet Conservation Bound . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction to bis 1. Introduction
This document updates the Proportional Rate Reduction (PRR) algorithm This document updates the Proportional Rate Reduction (PRR) algorithm
described in [RFC6937]from experimental to standards track. PRR described in [RFC6937] from experimental to standards track. PRR
accuracy regulates the amount of data sent during loss recovery, such accuracy regulates the amount of data sent during loss recovery, such
that at the end of recovery the flight size will be as close as that at the end of recovery the flight size will be as close as
possible to the ssthresh, as determined by the congestion control possible to the ssthresh, as determined by the congestion control
algorithm. PRR has been deployed in at least 3 major operating algorithm. PRR has been deployed in at least 3 major operating
systems covering the vast majority of today's web traffic. There systems covering the vast majority of today's web traffic.
have been no changes to PRR as documented in the experimental RFC.
The descriptions here have been [will be] updated to normative
standards language. For a tutorial description of the algorithms and
the rationale behind them please see the original RFC.
The experimental RFC describes two different reduction bound
algorithms to limit the total window reduction due to all mechanisms,
including transient application stalls and the losses themselves:
Conservative Reduction Bound (CRB), which is strictly packet
conserving; and a Slow Start Reduction Bound (SSRB), which is more
aggressive than CRB by at most 1 segment per ACK. [RFC6937] left the
choice of Reduction Bound to the discretion of the implementer.
The paper "An Internet-Wide Analysis of Traffic Policing" [Flatch et
al] uncovered a crucial situation where the Reduction Bound mattered.
Under certain configurations, token bucket traffic policers
[token_bucket] can suddenly start discarding a large fraction of the
traffic. This happens without warning to the end systems when
policers run out of tokens. The transport congestion control has no
opportunity to measure the token rate, and sets ssthresh based on the
recently observed path performance. This value for ssthresh may be
substantially larger than can be sustained by the token rate,
potentially causing persistent high loss. Under these conditions,
both reduction bounds perform very poorly. PRR-CRB is too timid,
sometimes causing very long recovery times at smaller than necessary
windows, and PRR-SSRB is too aggressive, often causing many
retransmissions to be lost multiple times.
Investigating these environments led to the development of a
heuristic to dynamically switch between Reduction Bounds: use PRR-
SSRB only while snd.una is advancing without evidence of ongoing
congestion and use PRR-CRB otherwise.
This heuristic is only invoked for what should be a rare corner case:
when losses or other events cause the flight size to fall below
ssthresh. The extreme loss rates that make the heuristic important
are only common in the presence of poorly configured token bucket
policers, which are pathologically wasteful and inefficient. In
these environments the heuristics serves to salvage a bad situation
and any reasonable implementation of the heuristic performs far
better than either bound by itself.
The algorithm below is identical to the algorithm presented in The only change from RFC 6937 is the introduction of a new heuristic
[RFC6937]. The "conservative" parameter MAY be replaced by the that replaces a manual configuration parameter. There have been no
heuristic also described below. changes to the behaviors of the algorithms or the previously
published results. The new heuristic only changes behaviors in
corner cases that were not relevant prior to the Lost Retransmission
Detection (LRD) algorithm which was not implemented until after RFC
6937 was published. This document also includes additional
discussion about integration into other congestion control and
recovery algorithms.
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]
1.1. Document and WG Information 1.1. Document and WG Information
Formatted: 2021-02-22 14:22:57-08:00
Please send all comments, questions and feedback to tcpm@ietf.org Please send all comments, questions and feedback to tcpm@ietf.org
Formatted: 2021-01-13 15:31:40-08:00 About revision 00:
About this revision: The introduction above was drawn from draft-mathis-tcpm-rfc6937bis-
00. All of the text below was copied verbatim from RFC 6937, to
facilitate comparison between RFC 6937 and this document as it
evolves.
Text above (the "Introduction to bis") is drawn from draft-mathis- About revision 01:
tcpm-rfc6937bis-00. In this -00, all of the text below is copied
verbatim from RFC 6937, to facilitate comparison between RFC 6937 and
this document as it evolves.
2. Introduction * Recast the RFC 6937 introduction as background
This document describes an experimental algorithm, PRR, to improve * Made "Changes From RFC 6937" an explicit section
the accuracy of the amount of data sent by TCP during loss recovery.
* Made Relationships to other standards more explicit
* Added a generalized safeACK heuristic
* Provided hints for non TCP implementations
* Added language about detecting ACK splitting, but have no advice
on actions (yet)
2. Background
This section is copied almost verbatim from the introduction to RFC
6937.
Standard congestion control [RFC5681] requires that TCP (and other Standard congestion control [RFC5681] requires that TCP (and other
protocols) reduce their congestion window (cwnd) in response to protocols) reduce their congestion window (cwnd) in response to
losses. Fast Recovery, described in the same document, is the losses. Fast Recovery, described in the same document, is the
reference algorithm for making this adjustment. Its stated goal is reference algorithm for making this adjustment. Its stated goal is
to recover TCP's self clock by relying on returning ACKs during to recover TCP's self clock by relying on returning ACKs during
recovery to clock more data into the network. Fast Recovery recovery to clock more data into the network. Fast Recovery
typically adjusts the window by waiting for one half round-trip time typically adjusts the window by waiting for one half round-trip time
(RTT) of ACKs to pass before sending any data. It is fragile because (RTT) of ACKs to pass before sending any data. It is fragile because
it cannot compensate for the implicit window reduction caused by the it cannot compensate for the implicit window reduction caused by the
skipping to change at page 4, line 36 skipping to change at page 4, line 17
threshold (ssthresh), the window size as determined by the congestion threshold (ssthresh), the window size as determined by the congestion
control algorithm. This protects Fast Recovery from timeouts in many control algorithm. This protects Fast Recovery from timeouts in many
cases where there are heavy losses, although not if the entire second cases where there are heavy losses, although not if the entire second
half of the window of data or ACKs are lost. However, a single ACK half of the window of data or ACKs are lost. However, a single ACK
carrying a SACK option that implies a large quantity of missing data carrying a SACK option that implies a large quantity of missing data
can cause a step discontinuity in the pipe estimator, which can cause can cause a step discontinuity in the pipe estimator, which can cause
Fast Retransmit to send a burst of data. Fast Retransmit to send a burst of data.
The Rate-Halving algorithm sends data on alternate ACKs during The Rate-Halving algorithm sends data on alternate ACKs during
recovery, such that after 1 RTT the window has been halved. Rate- recovery, such that after 1 RTT the window has been halved. Rate-
Halving is implemented in Linux after only being informally published Halving was implemented in Linux after only being informally
[RHweb], including an uncompleted document [RHID]. Rate-Halving also published [RHweb], including an uncompleted document [RHID]. Rate-
does not adequately compensate for the implicit window reduction Halving also does not adequately compensate for the implicit window
caused by the losses and assumes a net 50% window reduction, which reduction caused by the losses and assumes a net 50% window
was completely standard at the time it was written but not reduction, which was completely standard at the time it was written
appropriate for modern congestion control algorithms, such as CUBIC but not appropriate for modern congestion control algorithms, such as
[CUBIC], which reduce the window by less than 50%. As a consequence, CUBIC [CUBIC], which reduce the window by less than 50%. As a
Rate-Halving often allows the window to fall further than necessary, consequence, Rate-Halving often allows the window to fall further
reducing performance and increasing the risk of timeouts if there are than necessary, reducing performance and increasing the risk of
additional losses. timeouts if there are additional losses.
PRR avoids these excess window adjustments such that at the end of PRR avoids these excess window adjustments such that at the end of
recovery the actual window size will be as close as possible to recovery the actual window size will be as close as possible to
ssthresh, the window size as determined by the congestion control ssthresh, the window size as determined by the congestion control
algorithm. It is patterned after Rate-Halving, but using the algorithm. It is patterned after Rate-Halving, but using the
fraction that is appropriate for the target window chosen by the fraction that is appropriate for the target window chosen by the
congestion control algorithm. During PRR, one of two additional congestion control algorithm. During PRR, one of two additional
Reduction Bound algorithms limits the total window reduction due to Reduction Bound algorithms limits the total window reduction due to
all mechanisms, including transient application stalls and the losses all mechanisms, including transient application stalls and the losses
themselves. themselves.
skipping to change at page 5, line 40 skipping to change at page 5, line 23
presence of events that cause uncertainty in other estimators. presence of events that cause uncertainty in other estimators.
The original definition of the packet conservation principle The original definition of the packet conservation principle
[Jacobson88] treated packets that are presumed to be lost (e.g., [Jacobson88] treated packets that are presumed to be lost (e.g.,
marked as candidates for retransmission) as having left the network. marked as candidates for retransmission) as having left the network.
This idea is reflected in the pipe estimator defined in RFC 6675 and This idea is reflected in the pipe estimator defined in RFC 6675 and
used here, but it is distinct from the Strong Packet Conservation used here, but it is distinct from the Strong Packet Conservation
Bound as described in Appendix A, which is defined solely on the Bound as described in Appendix A, which is defined solely on the
basis of data arriving at the receiver. basis of data arriving at the receiver.
We evaluated these and other algorithms in a large scale measurement 3. Changes From RFC 6937
study presented in a companion paper [IMC11] and summarized in
Section 6. This measurement study was based on RFC 3517 [RFC3517],
which has since been superseded by RFC 6675. Since there are slight
differences between the two specifications, and we were meticulous
about our implementation of RFC 3517, we are not comfortable
unconditionally asserting that our measurement results apply to RFC
6675, although we believe this to be the case. We have instead
chosen to be pedantic about describing measurement results relative
to RFC 3517, on which they were actually based. General discussions
of algorithms and their properties have been updated to refer to RFC
6675.
We found that for authentic network traffic, PRR-SSRB outperforms The largest change since RFC 6937 [RFC6937] is the introduction of a
both RFC 3517 and Linux Rate-Halving even though it is less new heuristic that uses good recovery progress (For TCP, snd.una
aggressive than RFC 3517. We believe that these results apply to RFC advances and no additional segments are marked as lost) to select
6675 as well. which Reduction Bound. RFC 6937 left the choice of Reduction Bound
to the discretion of the implementer but recommended to use BBR-SSRB
by default. For all of the environments explored in earlier PRR
research, the new heuristic is consistent with the old
recommendation.
The algorithms are described as modifications to RFC 5681 [RFC5681], The paper "An Internet-Wide Analysis of Traffic Policing"
"TCP Congestion Control", using concepts drawn from the pipe [Flach2016policing] uncovered a crucial situation, not previously
algorithm [RFC6675]. They are most accurate and more easily explored, where both Reduction Bounds perform very poorly, but for
implemented with SACK [RFC2018], but do not require SACK. different reasons. Under many configurations, token bucket traffic
policers [token_bucket] can suddenly start discarding a large
fraction of the traffic, without any warning to the end systems. The
transport congestion control has no opportunity to measure the token
rate, and sets ssthresh based on the previously observed path
performance. This value for ssthresh may result in a data rate that
is substantially larger than the token rate, causing persistent high
loss. Under these conditions, both reduction bounds perform very
poorly. PRR-CRB is too timid, sometimes causing very long recovery
times at smaller than necessary windows, and PRR-SSRB is too
aggressive, often causing many retransmissions to be lost multiple
times.
3. Definitions Investigating these environments led to the development of a
"safeACK" heuristic to dynamically switch between Reduction Bounds:
use PRR-SSRB for ACKs reporting that the recovery is making good
progress (snd.una is advancing without any new losses) and PRR-CRB
otherwise
This heuristic is only invoked where application-limited behavior,
losses or other events cause the flight size to fall below ssthresh.
The extreme loss rates that make the heuristic important are only
common in the presence of token bucket policers, which are
pathologically wasteful and inefficient [Flach2016policing]. In
these environments the heuristic serves to salvage a bad situation
and any reasonable implementation of the heuristic performs far
better than either bound by itself. The heuristic has no effect
whatsoever in congestion events where there are no lost
retransmissions, including all of the examples described below and in
RFC 6937.
Since RFC 6937 was written, PRR has also been adapted to perform
multiplicative window reduction for non-loss based congestion control
algorithms, such as for RFC 3168 style ECN. This is typically done
by using some parts of the loss recovery state machine (in particular
the RecoveryPoint from RFC 6675) to invoke the PRR ACK processing for
exactly one round trip worth of ACKs.
For RFC 6937 we published a companion paper [IMC11] in which we
evaluated Fast Retransmit, Rate-Halving and various experimental PRR
versions in a large scale measurement study. Today, the legacy
algorithms used in that study have already faded from the code base,
making such comparisons impossible without recreating historical
algorithms. Readers interested in the measurement study should
review section 5 of RFC 6937 and the IMC paper [IMC11].
4. Relationships to other standards
PRR is described as modifications to "TCP Congestion Control"
[RFC5681], and "A Conservative Loss Recovery Algorithm Based on
Selective Acknowledgment (SACK) for TCP" [RFC6675]. It is most
accurate and more easily implemented with SACK [RFC2018], but does
not require SACK.
The SafeACK heuristic came about as a consequence of robust Lost
Retransmission Detection under development in an early precursor to
[RACK]. Without LRD, policers that cause very high loss rates are
guaranteed to also cause retransmission timeouts because both RFC
5681 and RFC 6675 will send retransmissions above the policed rate.
PRR and the SafeACK heuristic were already well in place before the
RACK algorithm was fully matured. Note that there is no experience
implementing or testing RACK without PRR.
For this reason it is recommended that PRR is implemented with RACK.
5. Definitions
The following terms, parameters, and state variables are used as they The following terms, parameters, and state variables are used as they
are defined in earlier documents: are defined in earlier documents:
RFC 793: snd.una (send unacknowledged) RFC 793: snd.una (send unacknowledged).
RFC 5681: duplicate ACK, FlightSize, Sender Maximum Segment Size RFC 5681: duplicate ACK, FlightSize, Sender Maximum Segment Size
(SMSS) (SMSS).
RFC 6675: covered (as in "covered sequence numbers") RFC 6675: covered (as in "covered sequence numbers").
Voluntary window reductions: choosing not to send data in response to Voluntary window reductions: choosing not to send data in response to
some ACKs, for the purpose of reducing the sending window size and some ACKs, for the purpose of reducing the sending window size and
data rate data rate.
We define some additional variables: We define some additional variables:
SACKd: The total number of bytes that the scoreboard indicates have SACKd: The total number of bytes that the scoreboard indicates have
been delivered to the receiver. This can be computed by scanning the been delivered to the receiver. This can be computed by scanning the
scoreboard and counting the total number of bytes covered by all sack scoreboard and counting the total number of bytes covered by all sack
blocks. If SACK is not in use, SACKd is not defined. blocks. If SACK is not in use, SACKd is not defined.
DeliveredData: The total number of bytes that the current ACK DeliveredData: The total number of bytes that the current ACK
indicates have been delivered to the receiver. When not in recovery, indicates have been delivered to the receiver. With SACK,
DeliveredData is the change in snd.una. With SACK, DeliveredData can DeliveredData can be computed precisely as the change in snd.una,
be computed precisely as the change in snd.una, plus the (signed) plus the (signed) change in SACKd. In recovery without SACK,
change in SACKd. In recovery without SACK, DeliveredData is DeliveredData is estimated to be 1 SMSS on duplicate
estimated to be 1 SMSS on duplicate acknowledgements, and on a acknowledgements, and on a subsequent partial or full ACK,
subsequent partial or full ACK, DeliveredData is estimated to be the DeliveredData is estimated to be the change in snd.una, minus 1 SMSS
change in snd.una, minus 1 SMSS for each preceding duplicate ACK. for each preceding duplicate ACK. If this calculation results in a
negative DeliveredData the data sender can infer that the receiver is
using a ACK splitting attack [and do what? @@@@]
Note that DeliveredData is robust; for TCP using SACK, DeliveredData Note that DeliveredData is robust; for TCP using SACK, DeliveredData
can be precisely computed anywhere in the network just by inspecting can be precisely computed anywhere along the return path by
the returning ACKs. The consequence of missing ACKs is that later inspecting the returning ACKs. The consequence of missing ACKs is
ACKs will show a larger DeliveredData. Furthermore, for any TCP that later ACKs will show a larger DeliveredData. Furthermore, for
(with or without SACK), the sum of DeliveredData must agree with the any TCP (with or without SACK), the sum of DeliveredData must agree
forward progress over the same time interval. with the forward progress over the same time interval.
We introduce a local variable "sndcnt", which indicates exactly how safeACK: A local variable indicating that the current ACK reported
many bytes should be sent in response to each ACK. Note that the good progress -- snd.una advanced with no additional segments newly
decision of which data to send (e.g., retransmit missing data or send marked lost.
more new data) is out of scope for this document.
4. Algorithms sndcnt: A local variable indicating exactly how many bytes should be
sent in response to each ACK. Note that the decision of which data
to send (e.g., retransmit missing data or send more new data) is out
of scope for this document.
6. Algorithms
At the beginning of recovery, initialize PRR state. This assumes a At the beginning of recovery, initialize PRR state. This assumes a
modern congestion control algorithm, CongCtrlAlg(), that might set modern congestion control algorithm, CongCtrlAlg(), that might set
ssthresh to something other than FlightSize/2: ssthresh to something other than FlightSize/2:
ssthresh = CongCtrlAlg() // Target cwnd after recovery ssthresh = CongCtrlAlg() // Target cwnd after recovery
prr_delivered = 0 // Total bytes delivered during recovery prr_delivered = 0 // Total bytes delivered during recovery
prr_out = 0 // Total bytes sent during recovery prr_out = 0 // Total bytes sent during recovery
RecoverFS = snd.nxt-snd.una // FlightSize at the start of recovery RecoverFS = snd.nxt-snd.una // FlightSize at the start of recovery
Figure 1 Figure 1
On every ACK during recovery compute: On every ACK during recovery compute:
DeliveredData = change_in(snd.una) + change_in(SACKd) DeliveredData = change_in(snd.una) + change_in(SACKd)
prr_delivered += DeliveredData prr_delivered += DeliveredData
pipe = (RFC 6675 pipe algorithm) pipe = (RFC 6675 pipe algorithm)
safeACK = (snd.una advances with no new losses)
if (pipe > ssthresh) { if (pipe > ssthresh) {
// Proportional Rate Reduction // Proportional Rate Reduction
sndcnt = CEIL(prr_delivered * ssthresh / RecoverFS) - prr_out sndcnt = CEIL(prr_delivered * ssthresh / RecoverFS) - prr_out
} else { } else {
// Two versions of the Reduction Bound // Two version of the reduction bound
if (conservative) { // PRR-CRB if (safeACK) { // PRR+SSRB
limit = prr_delivered - prr_out
} else { // PRR-SSRB
limit = MAX(prr_delivered - prr_out, DeliveredData) + MSS limit = MAX(prr_delivered - prr_out, DeliveredData) + MSS
} else { // PRR+CRB
limit = prr_delivered - prr_out
} }
// Attempt to catch up, as permitted by limit // Attempt to catch up, as permitted by limit
sndcnt = MIN(ssthresh - pipe, limit) sndcnt = MIN(ssthresh - pipe, limit)
} }
Figure 2 Figure 2
On any data transmission or retransmission: On any data transmission or retransmission:
prr_out += (data sent) // strictly less than or equal to sndcnt prr_out += (data sent) // strictly less than or equal to sndcnt
Figure 3 Figure 3
4.1. Examples 7. Examples
We illustrate these algorithms by showing their different behaviors We illustrate these algorithms by showing their different behaviors
for two scenarios: TCP experiencing either a single loss or a burst for two scenarios: TCP experiencing either a single loss or a burst
of 15 consecutive losses. In all cases we assume bulk data (no of 15 consecutive losses. In all cases we assume bulk data (no
application pauses), standard Additive Increase Multiplicative application pauses), standard Additive Increase Multiplicative
Decrease (AIMD) congestion control, and cwnd = FlightSize = pipe = 20 Decrease (AIMD) congestion control, and cwnd = FlightSize = pipe = 20
segments, so ssthresh will be set to 10 at the beginning of recovery. segments, so ssthresh will be set to 10 at the beginning of recovery.
We also assume standard Fast Retransmit and Limited Transmit We also assume standard Fast Retransmit and Limited Transmit
[RFC3042], so TCP will send 2 new segments followed by 1 retransmit [RFC3042], so TCP will send 2 new segments followed by 1 retransmit
in response to the first 3 duplicate ACKs following the losses. in response to the first 3 duplicate ACKs following the losses.
Each of the diagrams below shows the per ACK response to the first Each of the diagrams below shows the per ACK response to the first
round trip for the various recovery algorithms when the zeroth round trip for the various recovery algorithms when the zeroth
segment is lost. The top line indicates the transmitted segment segment is lost. The top line indicates the transmitted segment
number triggering the ACKs, with an X for the lost segment. "cwnd" number triggering the ACKs, with an X for the lost segment. "cwnd"
and "pipe" indicate the values of these algorithms after processing and "pipe" indicate the values of these algorithms after processing
each returning ACK. "Sent" indicates how much 'N'ew or each returning ACK. "Sent" indicates how much 'N'ew or
'R'etransmitted data would be sent. Note that the algorithms for 'R'etransmitted data would be sent. Note that the algorithms for
deciding which data to send are out of scope of this document. deciding which data to send are out of scope of this document.
We are including the Linux Rate_Halving implementation to illustrate
the state-of-the-art at the time, even though this algorithm is no
longer supported.
When there is a single loss, PRR with either of the Reduction Bound When there is a single loss, PRR with either of the Reduction Bound
algorithms has the same behavior. We show "RB", a flag indicating algorithms has the same behavior. We show "RB", a flag indicating
which Reduction Bound subexpression ultimately determined the value which Reduction Bound subexpression ultimately determined the value
of sndcnt. When there are minimal losses, "limit" (both algorithms) of sndcnt. When there are minimal losses, "limit" (both algorithms)
will always be larger than ssthresh - pipe, so the sndcnt will be will always be larger than ssthresh - pipe, so the sndcnt will be
ssthresh - pipe, indicated by "s" in the "RB" row. ssthresh - pipe, indicated by "s" in the "RB" row.
RFC 6675 RFC 6675
ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
cwnd: 20 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 cwnd: 20 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
pipe: 19 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10 pipe: 19 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10
sent: N N R N N N N N N N N sent: N N R N N N N N N N N
Rate-Halving (Linux) Rate-Halving (Historical Linux)
ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
cwnd: 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 cwnd: 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11
pipe: 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 pipe: 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10
sent: N N R N N N N N N N N sent: N N R N N N N N N N N
PRR PRR
ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
pipe: 19 19 18 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10 pipe: 19 19 18 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10
sent: N N R N N N N N N N N sent: N N R N N N N N N N N
RB: s s RB: s s
skipping to change at page 10, line 11 skipping to change at page 11, line 11
packets (0-14) are lost. During the remainder of the lossy RTT, only packets (0-14) are lost. During the remainder of the lossy RTT, only
5 ACKs are returned to the sender. We examine each of these 5 ACKs are returned to the sender. We examine each of these
algorithms in succession. algorithms in succession.
RFC 6675 RFC 6675
ack# X X X X X X X X X X X X X X X 15 16 17 18 19 ack# X X X X X X X X X X X X X X X 15 16 17 18 19
cwnd: 20 20 11 11 11 cwnd: 20 20 11 11 11
pipe: 19 19 4 10 10 pipe: 19 19 4 10 10
sent: N N 7R R R sent: N N 7R R R
Rate-Halving (Linux) Rate-Halving (Historical Linux)
ack# X X X X X X X X X X X X X X X 15 16 17 18 19 ack# X X X X X X X X X X X X X X X 15 16 17 18 19
cwnd: 20 20 5 5 5 cwnd: 20 20 5 5 5
pipe: 19 19 4 4 4 pipe: 19 19 4 4 4
sent: N N R R R sent: N N R R R
PRR-CRB PRR-CRB
ack# X X X X X X X X X X X X X X X 15 16 17 18 19 ack# X X X X X X X X X X X X X X X 15 16 17 18 19
pipe: 19 19 4 4 4 pipe: 19 19 4 4 4
sent: N N R R R sent: N N R R R
RB: b b b RB: b b b
skipping to change at page 10, line 34 skipping to change at page 11, line 34
ack# X X X X X X X X X X X X X X X 15 16 17 18 19 ack# X X X X X X X X X X X X X X X 15 16 17 18 19
pipe: 19 19 4 5 6 pipe: 19 19 4 5 6
sent: N N 2R 2R 2R sent: N N 2R 2R 2R
RB: bd d d RB: bd d d
Figure 5 Figure 5
In this specific situation, RFC 6675 is more aggressive because once In this specific situation, RFC 6675 is more aggressive because once
Fast Retransmit is triggered (on the ACK for segment 17), TCP Fast Retransmit is triggered (on the ACK for segment 17), TCP
immediately retransmits sufficient data to bring pipe up to cwnd. immediately retransmits sufficient data to bring pipe up to cwnd.
Our measurement data (see Section 6) indicates that RFC 6675 Our earlier measurements [RFC 6937 section 6] indicates that RFC 6675
significantly outperforms Rate-Halving, PRR-CRB, and some other significantly outperforms Rate-Halving, PRR-CRB, and some other
similarly conservative algorithms that we tested, showing that it is similarly conservative algorithms that we tested, showing that it is
significantly common for the actual losses to exceed the window significantly common for the actual losses to exceed the window
reduction determined by the congestion control algorithm. reduction determined by the congestion control algorithm.
The Linux implementation of Rate-Halving includes an early version of The Linux implementation of Rate-Halving included an early version of
the Conservative Reduction Bound [RHweb]. In this situation, the 5 the Conservative Reduction Bound [RHweb]. With this algorithm, the 5
ACKs trigger exactly 1 transmission each (2 new data, 3 old data), ACKs trigger exactly 1 transmission each (2 new data, 3 old data),
and cwnd is set to 5. At a window size of 5, it takes 3 round trips and cwnd is set to 5. At a window size of 5, it takes 3 round trips
to retransmit all 15 lost segments. Rate-Halving does not raise the to retransmit all 15 lost segments. Rate-Halving does not raise the
window at all during recovery, so when recovery finally completes, window at all during recovery, so when recovery finally completes,
TCP will slow start cwnd from 5 up to 10. In this example, TCP TCP will slow start cwnd from 5 up to 10. In this example, TCP
operates at half of the window chosen by the congestion control for operates at half of the window chosen by the congestion control for
more than 3 RTTs, increasing the elapsed time and exposing it to more than 3 RTTs, increasing the elapsed time and exposing it to
timeouts in the event that there are additional losses. timeouts in the event that there are additional losses.
PRR-CRB implements a Conservative Reduction Bound. Since the total PRR-CRB implements a Conservative Reduction Bound. Since the total
skipping to change at page 11, line 35 skipping to change at page 12, line 35
and indicated by RB:d tagging in the figure. Although increasing the and indicated by RB:d tagging in the figure. Although increasing the
window during recovery seems to be ill advised, it is important to window during recovery seems to be ill advised, it is important to
remember that this is actually less aggressive than permitted by RFC remember that this is actually less aggressive than permitted by RFC
5681, which sends the same quantity of additional data as a single 5681, which sends the same quantity of additional data as a single
burst in response to the ACK that triggered Fast Retransmit. burst in response to the ACK that triggered Fast Retransmit.
For less extreme events, where the total losses are smaller than the For less extreme events, where the total losses are smaller than the
difference between FlightSize and ssthresh, PRR-CRB and PRR-SSRB have difference between FlightSize and ssthresh, PRR-CRB and PRR-SSRB have
identical behaviors. identical behaviors.
5. Properties 8. Properties
The following properties are common to both PRR-CRB and PRR-SSRB, The following properties are common to both PRR-CRB and PRR-SSRB,
except as noted: except as noted:
PRR maintains TCP's ACK clocking across most recovery events, PRR maintains TCP's ACK clocking across most recovery events,
including burst losses. RFC 6675 can send large unclocked bursts including burst losses. RFC 6675 can send large unclocked bursts
following burst losses. following burst losses.
Normally, PRR will spread voluntary window reductions out evenly Normally, PRR will spread voluntary window reductions out evenly
across a full RTT. This has the potential to generally reduce the across a full RTT. This has the potential to generally reduce the
skipping to change at page 13, line 17 skipping to change at page 14, line 17
amount of data delivered to the receiver. We claim that this Strong amount of data delivered to the receiver. We claim that this Strong
Packet Conservation Bound is the most aggressive algorithm that does Packet Conservation Bound is the most aggressive algorithm that does
not lead to additional forced losses in some environments. It has not lead to additional forced losses in some environments. It has
the property that if there is a standing queue at a bottleneck with the property that if there is a standing queue at a bottleneck with
no cross traffic, the queue will maintain exactly constant length for no cross traffic, the queue will maintain exactly constant length for
the duration of the recovery, except for +1/-1 fluctuation due to the duration of the recovery, except for +1/-1 fluctuation due to
differences in packet arrival and exit times. See Appendix A for a differences in packet arrival and exit times. See Appendix A for a
detailed discussion of this property. detailed discussion of this property.
Although the Strong Packet Conservation Bound is very appealing for a Although the Strong Packet Conservation Bound is very appealing for a
number of reasons, our measurements summarized in Section 6 number of reasons, our earlier measurements [RFC 6937 section 6]
demonstrate that it is less aggressive and does not perform as well demonstrate that it is less aggressive and does not perform as well
as RFC 6675, which permits bursts of data when there are bursts of as RFC 6675, which permits bursts of data when there are bursts of
losses. PRR-SSRB is a compromise that permits TCP to send 1 extra losses. PRR-SSRB is a compromise that permits TCP to send 1 extra
segment per ACK as compared to the Packet Conserving Bound. From the segment per ACK as compared to the Packet Conserving Bound. From the
perspective of a strict Packet Conserving Bound, PRR-SSRB does indeed perspective of a strict Packet Conserving Bound, PRR-SSRB does indeed
open the window during recovery; however, it is significantly less open the window during recovery; however, it is significantly less
aggressive than RFC 6675 in the presence of burst losses. aggressive than RFC 6675 in the presence of burst losses.
6. Measurements 9. Adapting PRR to other transport protocols
In a companion IMC11 paper [IMC11], we describe some measurements
comparing the various strategies for reducing the window during
recovery. The experiments were performed on servers carrying Google
production traffic and are briefly summarized here.
The various window reduction algorithms and extensive instrumentation
were all implemented in Linux 2.6. We used the uniform set of
algorithms present in the base Linux implementation, including CUBIC
[CUBIC], Limited Transmit [RFC3042], threshold transmit (Section 3.1
in [FACK]) (this algorithm was not present in RFC 3517, but a similar
algorithm has been added to RFC 6675), and lost retransmission
detection algorithms. We confirmed that the behaviors of Rate-
Halving (the Linux default), RFC 3517, and PRR were authentic to
their respective specifications and that performance and features
were comparable to the kernels in production use. All of the
different window reduction algorithms were all present in a common
kernel and could be selected with a sysctl, such that we had an
absolutely uniform baseline for comparing them.
Our experiments included an additional algorithm, PRR with an
unlimited bound (PRR-UB), which sends ssthresh-pipe bursts when pipe
falls below ssthresh. This behavior parallels RFC 3517.
An important detail of this configuration is that CUBIC only reduces
the window by 30%, as opposed to the 50% reduction used by
traditional congestion control algorithms. This accentuates the
tendency for RFC 3517 and PRR-UB to send a burst at the point when
Fast Retransmit gets triggered because pipe is likely to already be
below ssthresh. Precisely this condition was observed for 32% of the
recovery events: pipe fell below ssthresh before Fast Retransmit was
triggered, thus the various PRR algorithms started in the Reduction
Bound phase, and RFC 3517 sent bursts of segments with the Fast
Retransmit.
In the companion paper, we observe that PRR-SSRB spends the least
time in recovery of all the algorithms tested, largely because it
experiences fewer timeouts once it is already in recovery.
RFC 3517 experiences 29% more detected lost retransmissions and 2.6%
more timeouts (presumably due to undetected lost retransmissions)
than PRR-SSRB. These results are representative of PRR-UB and other
algorithms that send bursts when pipe falls below ssthresh.
Rate-Halving experiences 5% more timeouts and significantly smaller
final cwnd values at the end of recovery. The smaller cwnd sometimes
causes the recovery itself to take extra round trips. These results
are representative of PRR-CRB and other algorithms that implement
strict packet conservation during recovery.
7. Conclusion and Recommendations
Although the Strong Packet Conservation Bound used in PRR-CRB is very
appealing for a number of reasons, our measurements show that it is
less aggressive and does not perform as well as RFC 3517 (and by
implication RFC 6675), which permits bursts of data when there are
bursts of losses. RFC 3517 and RFC 6675 are conservative in the
original sense of Van Jacobson's packet conservation principle, which
included the assumption that presumed lost segments have indeed left
the network. PRR-CRB makes no such assumption, following instead a
Strong Packet Conservation Bound in which only packets that have
actually arrived at the receiver are considered to have left the
network. PRR-SSRB is a compromise that permits TCP to send 1 extra
segment per ACK relative to the Strong Packet Conservation Bound, to
partially compensate for excess losses.
From the perspective of the Strong Packet Conservation Bound, PRR-
SSRB does indeed open the window during recovery; however, it is
significantly less aggressive than RFC 3517 (and RFC 6675) in the
presence of burst losses. Even so, it often outperforms RFC 3517
(and presumably RFC 6675) because it avoids some of the self-
inflicted losses caused by bursts.
At this time, we see no reason not to test and deploy PRR-SSRB on a The main PRR algorithm and reductions bounds can be adapted to any
large scale. Implementers worried about any potential impact of transport that can support RFC 6675.
raising the window during recovery may want to optionally support
PRR-CRB (which is actually simpler to implement) for comparison
studies. Furthermore, there is one minor detail of PRR that can be
improved by replacing pipe by total_pipe, as defined by Laminar TCP
[Laminar].
One final comment about terminology: we expect that common usage will The safeACK heuristic can be generalized as any ACK of a
drop "Slow Start Reduction Bound" from the algorithm name. This retransmission that does not cause some other segment to be marked
document needed to be pedantic about having distinct names for PRR for retransmission. That is, PRR_SSRB is safe on any ACK that
and every variant of the Reduction Bound. However, we do not reduces the total number of pending and outstanding retransmissions.
anticipate any future exploration of the alternative Reduction
Bounds.
8. Acknowledgements 10. Acknowledgements
This document is based in part on previous incomplete work by Matt This document is based in part on previous incomplete work by Matt
Mathis, Jeff Semke, and Jamshid Mahdavi [RHID] and influenced by Mathis, Jeff Semke, and Jamshid Mahdavi [RHID] and influenced by
several discussions with John Heffner. several discussions with John Heffner.
Monia Ghobadi and Sivasankar Radhakrishnan helped analyze the Monia Ghobadi and Sivasankar Radhakrishnan helped analyze the
experiments. experiments.
Ilpo Jarvinen reviewed the code. Ilpo Jarvinen reviewed the code.
Mark Allman improved the document through his insightful review. Mark Allman improved the document through his insightful review.
Neal Cardwell for reviewing and testing the patch. Neal Cardwell for reviewing and testing the patch.
9. Security Considerations 11. Security Considerations
PRR does not change the risk profile for TCP. PRR does not change the risk profile for TCP.
Implementers that change PRR from counting bytes to segments have to Implementers that change PRR from counting bytes to segments have to
be cautious about the effects of ACK splitting attacks [Savage99], be cautious about the effects of ACK splitting attacks [Savage99],
where the receiver acknowledges partial segments for the purpose of where the receiver acknowledges partial segments for the purpose of
confusing the sender's congestion accounting. confusing the sender's congestion accounting.
10. Normative References 12. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
skipping to change at page 16, line 25 skipping to change at page 15, line 40
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
and Y. Nishida, "A Conservative Loss Recovery Algorithm and Y. Nishida, "A Conservative Loss Recovery Algorithm
Based on Selective Acknowledgment (SACK) for TCP", Based on Selective Acknowledgment (SACK) for TCP",
RFC 6675, DOI 10.17487/RFC6675, August 2012, RFC 6675, DOI 10.17487/RFC6675, August 2012,
<https://www.rfc-editor.org/info/rfc6675>. <https://www.rfc-editor.org/info/rfc6675>.
11. Informative References 13. Informative References
[CUBIC] Rhee, I. and L. Xu, "CUBIC: A new TCP-friendly high-speed [CUBIC] Rhee, I. and L. Xu, "CUBIC: A new TCP-friendly high-speed
TCP variant", PFLDnet 2005, February 2005. TCP variant", PFLDnet 2005, February 2005.
[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment: [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment:
Refining TCP Congestion Control", ACM SIGCOMM SIGCOMM96, Refining TCP Congestion Control", ACM SIGCOMM SIGCOMM96,
August 1996. August 1996.
[Flach2016policing]
Flach, T., Papageorge, P., Terzis, A., Pedrosa, L., Cheng,
Y., Al Karim, T., Katz-Bassett, E., and R. Govindan, "An
Internet-Wide Analysis of Traffic Policing", ACM
SIGCOMM SIGCOMM2016, August 2016.
[IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi, [IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi,
"Proportional Rate Reduction for TCP", Proceedings of the "Proportional Rate Reduction for TCP", Proceedings of the
11th ACM SIGCOMM Conference on Internet Measurement 11th ACM SIGCOMM Conference on Internet Measurement
2011, Berlin, Germany, November 2011. 2011, Berlin, Germany, November 2011.
[Jacobson88] [Jacobson88]
Jacobson, V., "Congestion Avoidance and Control", SIGCOMM Jacobson, V., "Congestion Avoidance and Control", SIGCOMM
Comput. Commun. Rev. 18(4), August 1988. Comput. Commun. Rev. 18(4), August 1988.
[Laminar] Mathis, M., "Laminar TCP and the case for refactoring TCP [Laminar] Mathis, M., "Laminar TCP and the case for refactoring TCP
skipping to change at page 17, line 31 skipping to change at page 17, line 9
<http://www.psc.edu/networking/papers/FACKnotes/current/>. <http://www.psc.edu/networking/papers/FACKnotes/current/>.
[Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, [Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP congestion control with a misbehaving receiver", "TCP congestion control with a misbehaving receiver",
SIGCOMM Comput. Commun. Rev. 29(5), October 1999. SIGCOMM Comput. Commun. Rev. 29(5), October 1999.
Appendix A. Strong Packet Conservation Bound Appendix A. Strong Packet Conservation Bound
PRR-CRB is based on a conservative, philosophically pure, and PRR-CRB is based on a conservative, philosophically pure, and
aesthetically appealing Strong Packet Conservation Bound, described aesthetically appealing Strong Packet Conservation Bound, described
here. Although inspired by Van Jacobson's packet conservation here. Although inspired by the packet conservation principle
principle [Jacobson88], it differs in how it treats segments that are [Jacobson88], it differs in how it treats segments that are missing
missing and presumed lost. Under all conditions and sequences of and presumed lost. Under all conditions and sequences of events
events during recovery, PRR-CRB strictly bounds the data transmitted during recovery, PRR-CRB strictly bounds the data transmitted to be
to be equal to or less than the amount of data delivered to the equal to or less than the amount of data delivered to the receiver.
receiver. Note that the effects of presumed losses are included in Note that the effects of presumed losses are included in the pipe
the pipe calculation, but do not affect the outcome of PRR-CRB, once calculation, but do not affect the outcome of PRR-CRB, once pipe has
pipe has fallen below ssthresh. fallen below ssthresh.
We claim that this Strong Packet Conservation Bound is the most We claim that this Strong Packet Conservation Bound is the most
aggressive algorithm that does not lead to additional forced losses aggressive algorithm that does not lead to additional forced losses
in some environments. It has the property that if there is a in some environments. It has the property that if there is a
standing queue at a bottleneck that is carrying no other traffic, the standing queue at a bottleneck that is carrying no other traffic, the
queue will maintain exactly constant length for the entire duration queue will maintain exactly constant length for the entire duration
of the recovery, except for +1/-1 fluctuation due to differences in of the recovery, except for +1/-1 fluctuation due to differences in
packet arrival and exit times. Any less aggressive algorithm will packet arrival and exit times. Any less aggressive algorithm will
result in a declining queue at the bottleneck. Any more aggressive result in a declining queue at the bottleneck. Any more aggressive
algorithm will result in an increasing queue or additional losses if algorithm will result in an increasing queue or additional losses if
 End of changes. 50 change blocks. 
236 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/