Thanks again, Paul.
We have incorporated your feedback and replied in the original email
thread ("perfmetrdir review of draft-ietf-tcpm-prr-rfc6937bis-16").
Best regards,
neal
On Mon, Jun 9, 2025 at 5:31 AM Gorry (erg) <gorry@xxxxxxxxxxxxxx> wrote:
>
>
>
> On 9 Jun 2025, at 10:08, Paul Aitken via Datatracker <noreply@xxxxxxxx> wrote:
>
> Document: draft-ietf-tcpm-prr-rfc6937bis
> Title: Proportional Rate Reduction for TCP
> Reviewer: Paul Aitken
> Review result: Not Ready
>
> I've reviewed this draft for perfmetrdir.
>
> The draft does not define or modify any metrics. It may be useful to define
> metrics to allow operators to compare one algorithm with another, and to
> monitor an algorithm change to see whether throughput improved or not.
>
> Other issues:
>
> * The calculation in section 8 seems wrong.
> * Please properly xref each RFC: [RFCnnnn]
> * Quote terms to distinguish them from the prose.
> * Subjective claims should be justified.
>
>
> Thanks for taking the time to review this document. I expect the Editors will reply and address comments were possible.
>
> I’d expect CCWG would be a good home for any specifications relating to performance assessment of CC. Inputs like RFC 9743 from CCWG also might help in looking at these topics.
>
> Gorry
>
> Please see PA: inline.
>
> TCP Maintenance Working Group M. Mathis
> Internet-Draft
> Obsoletes: 6937 (if approved) N. Cardwell
> Intended status: Standards Track Y. Cheng
> Expires: 28 November 2025 N. Dukkipati
> Google, Inc.
> 27 May 2025
>
> Proportional Rate Reduction for TCP
> draft-ietf-tcpm-prr-rfc6937bis-16
>
> Abstract
>
> This document specifies a standards-track version of the Proportional
> Rate Reduction (PRR) algorithm that obsoletes the experimental
> version described in RFC 6937. PRR provides logic to regulate the
> amount of data sent by TCP or other transport protocols during fast
> recovery. PRR accurately regulates the actual flight size through
> recovery such that at the end of recovery it will be as close as
> possible to the slow start threshold (ssthresh), as determined by the
> congestion control algorithm.
>
> Status of This Memo
>
> This Internet-Draft is submitted in full conformance with the
> provisions of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF). Note that other groups may also distribute
> working documents as Internet-Drafts. The list of current Internet-
> Drafts is at https://datatracker.ietf.org/drafts/current/.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> This Internet-Draft will expire on 28 November 2025.
>
> Copyright Notice
>
> Copyright (c) 2025 IETF Trust and the persons identified as the
> document authors. All rights reserved.
>
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents (https://trustee.ietf.org/
> license-info) in effect on the date of publication of this document.
>
> Mathis, et al. Expires 28 November 2025 [Page 1]
> Internet-Draft Proportional Rate Reduction May 2025
>
> Please review these documents carefully, as they describe your rights
> and restrictions with respect to this document. Code Components
> extracted from this document must include Revised BSD License text as
> described in Section 4.e of the Trust Legal Provisions and are
> provided without warranty as described in the Revised BSD License.
>
> Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
> 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 3. Document and WG Information . . . . . . . . . . . . . . . . . 3
> 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
> 5. Changes From RFC 6937 . . . . . . . . . . . . . . . . . . . . 9
> 6. Relationships to other standards . . . . . . . . . . . . . . 11
> 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11
> 8. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 14
> 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
> 10. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 19
> 11. Adapting PRR to other transport protocols . . . . . . . . . . 21
> 12. Measurement Studies . . . . . . . . . . . . . . . . . . . . . 21
> 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
> 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
> 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
> 16. Normative References . . . . . . . . . . . . . . . . . . . . 22
> 17. Informative References . . . . . . . . . . . . . . . . . . . 23
> Appendix A. Strong Packet Conservation Bound . . . . . . . . . . 24
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
>
> 1. Introduction
>
> This document specifies a standards-track version of the Proportional
> Rate Reduction (PRR) algorithm that obsoletes the experimental
> version described in [RFC6937]. PRR smoothly regulates the amount of
> data sent during fast recovery, such that at the end of recovery the
> flight size will be as close as possible to the slow start threshold
> (ssthresh), as determined by the congestion control algorithm. PRR
> has been deployed in at least three major TCP implementations
> covering the vast majority of today's web traffic.
>
> PA: This sounds subjective. Cite references?
>
> Mathis, et al. Expires 28 November 2025 [Page 2]
> Internet-Draft Proportional Rate Reduction May 2025
>
> This document specifies several main changes from RFC 6937. First,
>
> PA: Please xref this properly: [RFC6937] - and also throughout the document.
>
> it introduces a new heuristic that replaces a manual configuration
> parameter that determined how conservative PRR was when the volume of
> in-flight data was less than ssthresh. Second, the algorithm
> specifies behavior for non-SACK connections. Third, the algorithm
> ensures a smooth sending process even when the sender has experienced
> high reordering and starts loss recovery after a large amount of
> sequence space has been SACKed. Finally, this document also includes
> additional discussion about the integration of PRR with congestion
> control and loss detection algorithms.
>
> 2. Conventions
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
> "OPTIONAL" in this document are to be interpreted as described in BCP
> 14 [RFC2119] [RFC8174] when, and only when, they appear in all
> capitals, as shown here.
>
> 3. Document and WG Information
>
> _RFC Editor: please remove this section before publication_
>
> Formatted: 2025-05-27 20:29:25+00:00
>
> Please send all comments, questions and feedback to tcpm@xxxxxxxx
>
> About revision 00:
>
> 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.
>
> About revision 01:
>
> * Recast the RFC 6937 introduction as background
>
> * Made "Changes From RFC 6937" an explicit section
>
> * 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)
>
> Mathis, et al. Expires 28 November 2025 [Page 3]
> Internet-Draft Proportional Rate Reduction May 2025
>
> About revision 02:
>
> * Companion RACK loss detection RECOMMENDED
>
> * Non-SACK accounting in the pseudo code
>
> * cwnd computation in the pseudo code
>
> * Force fast retransmit at the beginning of fast recovery
>
> * Remove deprecated Rate-Halving text
>
> * Fixed bugs in the example traces
>
> About revision 03 and 04:
>
> * Clarify when and how sndcnt becomes 0
>
> * Improve algorithm to smooth the sending rate under higher
> reordering cases
>
> About revision 05:
>
> * Revert the RecoverFS text and pseudocode to match the behavior in
> draft revision 03 and more closely match Linux TCP PRR
>
> About revision 06:
>
> * Update RecoverFS to be initialized as: RecoverFS = pipe.
>
> About revision 07:
>
> * Restored the revision 04 prose description for the rationale for
> initializing RecoverFS as: RecoverFS = pipe.
>
> * Added reference to [Hoe96Startup] in acknowledgements
>
> About revision 08:
>
> * Inserted missing reference to [RFC9293]
>
> * Recategorized "voluntary window reductions" as a phrase introduced
> by PRR
>
> About revision 09:
>
> Mathis, et al. Expires 28 November 2025 [Page 4]
> Internet-Draft Proportional Rate Reduction May 2025
>
> * Document the setting of cwnd = ssthresh when the sender completes
> a PRR episode, based on Linux TCP PRR experience and the mailing
> list discussion in the TCPM mailing list thread: "draft-ietf-tcpm-
> prr-rfc6937bis-03: set cwnd to ssthresh exiting fast recovery?".
> Mention the potential for bursts as a result of setting cwnd =
> ssthresh. Say that pacing is RECOMMENDED to deal with this.
>
> * Revised RecoverFS initialization to handle fast recoveries with
> mixes of real and spurious loss detection events (due to
> reordering), and incorporate consideration for a potentially large
> volume of data that is SACKed before fast recovery starts.
>
> * Fixed bugs in the definition of DeliveredData (reverted to
> definition from RFC 6937).
>
> * Clarified PRR triggers initialization based on start of congestion
> control reduction, not loss recovery, since congestion control may
> reduce ssthresh for each round trip with new losses in recovery.
>
> * Fixed bugs in PRR examples.
>
> About revision 10:
>
> * Minor typo fixes and wordsmithing.
>
> About revision 11:
>
> * Based on comments at the TCPM session at IETF 120, clarified the
> scope of congestion control algorithms for which PRR can be used,
> and clarified that it can be used for Reno or CUBIC.
>
> About revision 12:
>
> * Added "About revision 11" and "About revision 12" sections.
>
> * Added a clarification about the applicability to CUBIC in the
> algorithm section.
>
> About revision 13:
>
> * Switch from using the RFC 6675 "pipe" concept to an "inflight"
> concept that is independent of loss detection algorithm, and thus
> is usable with RACK-TLP loss detection [RFC8985]
>
> About revision 14:
>
> * Numerous editorial changes based on 2025-04-15 review from WIT
> area director Gorry Fairhurst.
>
> Mathis, et al. Expires 28 November 2025 [Page 5]
> Internet-Draft Proportional Rate Reduction May 2025
>
> * Added a note to the RFC Editor to remove this "Document and WG
> Information" section before publication.
>
> * Rephrased all sentences with "we" or "our" to remove those words.
>
> * Updated the RFC2119 MUST/SHOULD/MAY/... text to use the latest
> boilerplate text from RFC8174, and moved this text into a separate
> section.
>
> * Ensured that each term in the "Definitions" section is listed with
> (a) the term, (b) an actual in-line definition, and (c) the
> citation of the original source reference, where appropriate.
>
> * Added missing definitions for terms used in the document: cwnd,
> rwnd, ssthresh, SND.NXT, RMSS
>
> * In the "Relationships to other standards", after the paragraph
> about the congestion control algorithms with which PRR can be
> used, added a paragraph about PRR's independence from loss
> detection algorithm details and an explicit list of loss detection
> algorithms with which PRR can be used.
>
> * Where appropriate, changed "TCP" to a more generic phrase, like:
> "transport protocol", "connection", or "sender", depending on the
> context. Left "TCP" in place where that was the precise term that
> was appropriate in the context, given the protocol or packet
> header details. There are now no references to "TCP" in between
> the definition of SMSS and the "Adapting PRR to other transport
> protocols" section. The "Algorithm", "Examples", and "Properties"
> sections no longer mention "TCP".
>
> * Corrected the two occurrences of "MSS" in the pseudocode to use
> "SMSS", since "SMSS" has a definition and is consistent with the
> Reno (RFC5681) and CUBIC (RFC9438) documents.
>
> * Clarified the recommendation to use pacing to avoid bursts, and
> moved this into its own paragraph to make it easier for the reader
> to see.
>
> About revision 15:
>
> * Fixed the description of the initialization of RecoverFS to match
> the latest RecoverFS pseudocode
>
> * Add a note that in the first example both algorithms (RFC6675 and
> PRR) complete the fast recovery episode with a cwnd matching the
> ssthresh of 20.
>
> Mathis, et al. Expires 28 November 2025 [Page 6]
> Internet-Draft Proportional Rate Reduction May 2025
>
> * Revised order of 2nd and 4th co-author
>
> * Numerous editorial changes based on 2025-05-27 last call Genart
> review from Russ Housley, including the following changes.
>
> * Fixed abstract and intro sections that said that this document
> "updates" the experimental PRR algorithm to clarify that this
> document obsoletes the experimental PRR RFC
>
> * To address the feedback 'The 7th paragraph of Section 5 begins
> with "A final change"; yet the 8th paragraph talks about another
> adaptation to PRR', reworded the "A final change" phrase.
>
> * Moved the paragraph about measurement studies to a new
> "Measurement Studies" section, to address the feedback: 'The last
> paragraph of Section 5 is not really about changes since the
> publication of RFC 6937'
>
> * Fixed various minor editorial issues identified in the review
>
> About revision 16:
>
> * Revised the description and caption for the figures to try to
> improve clarity.
>
> 4. Background
>
> Congestion control algorithms like Reno [RFC5681] and CUBIC [RFC9438]
> require that transport protocol connections reduce their congestion
> window (cwnd) in response to losses. Fast recovery is the reference
>
> PA: Can an xref be added?
>
> algorithm for making this adjustment using feedback from
> acknowledgements. Its stated goal is to maintain a sender's self
> clock by relying on returning ACKs during recovery to clock more data
> into the network. Without PRR, fast recovery typically adjusts the
> window by waiting for a large fraction of a round-trip time (one half
> round-trip time of ACKs for Reno [RFC5681], or 30% of a round-trip
> time for CUBIC [RFC9438]) to pass before sending any data.
>
> Mathis, et al. Expires 28 November 2025 [Page 7]
> Internet-Draft Proportional Rate Reduction May 2025
>
> [RFC6675] makes fast recovery with Selective Acknowledgement (SACK)
> [RFC2018] more accurate by computing "pipe", a sender side estimate
> of the number of bytes still outstanding in the network. With
> [RFC6675], fast recovery is implemented by sending data as necessary
> on each ACK to allow pipe to rise to match ssthresh, the window size
>
> PA: Consider quoting parameters throughout the draft to distinguish them from
> the prose:
>
> to allow "pipe" to rise to match "ssthresh",
>
> as determined by the congestion control algorithm. This protects
> fast recovery from timeouts in many 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 carrying a SACK option that
> implies a large quantity of missing data can cause a step
> discontinuity in the pipe estimator, which can cause Fast Retransmit
> to send a burst of data.
>
> PRR avoids these excess window adjustments such that at the end of
> recovery the actual window size will be as close as possible to
> ssthresh, the window size as determined by the congestion control
> algorithm. It uses the fraction that is appropriate for the target
> window chosen by the congestion control algorithm. During PRR, one
> of two additional Reduction Bound algorithms limits the total window
> reduction due to all mechanisms, including transient application
> stalls and the losses themselves.
>
> This document describes two slightly different Reduction Bound
> algorithms: Conservative Reduction Bound (PRR-CRB), which is strictly
> packet conserving; and a Slow Start Reduction Bound (PRR-SSRB), which
> is more aggressive than PRR-CRB by at most 1 segment per ACK. PRR-
> CRB meets the Strong Packet Conservation Bound described in
> Appendix A; however, in real networks it does not perform as well as
> the algorithms described in [RFC6675], which prove to be more
> aggressive in a significant number of cases. PRR-SSRB offers a
> compromise by allowing a connection to send one additional segment
> per ACK, relative to PRR-CRB, in some situations. Although PRR-SSRB
> is less aggressive than [RFC6675] (transmitting fewer segments or
> taking more time to transmit them), it outperforms due to the lower
> probability of additional losses during recovery.
>
> PA: If PRR-CRB < RFC6675 < PRR-SSRB, why would PRR-CRB be used?
>
> The Strong Packet Conservation Bound on which PRR and both Reduction
> Bounds are based is patterned after Van Jacobson's packet
> conservation principle: segments delivered to the receiver are used
> as the clock to trigger sending the same number of segments back into
> the network. As much as possible, PRR and the Reduction Bound
> algorithms rely on this self clock process, and are only slightly
> affected by the accuracy of other estimators, such as the estimate of
> the volume of in-flight data. This is what gives the algorithms
> their precision in the presence of events that cause uncertainty in
> other estimators.
>
> Mathis, et al. Expires 28 November 2025 [Page 8]
> Internet-Draft Proportional Rate Reduction May 2025
>
> The original definition of the packet conservation principle
> [Jacobson88] treated packets that are presumed to be lost (e.g.,
> marked as candidates for retransmission) as having left the network.
> This idea is reflected in the estimator for in-flight data used by
> PRR, but it is distinct from the Strong Packet Conservation Bound as
> described in Appendix A, which is defined solely on the basis of data
> arriving at the receiver.
>
> 5. Changes From RFC 6937
>
> The largest change since [RFC6937] is the introduction of a new
> heuristic that uses good recovery progress (for TCP, when the latest
> ACK advances SND.UNA and does not indicate that a prior fast
> retransmit has been lost) to select the Reduction Bound. [RFC6937]
> left the choice of Reduction Bound to the discretion of the
> implementer but recommended to use PRR-SSRB by default. For all of
> the environments explored in earlier PRR research, the new heuristic
> is consistent with the old recommendation.
>
> The paper "An Internet-Wide Analysis of Traffic Policing"
> [Flach2016policing] uncovered a crucial situation not previously
> explored, where both Reduction Bounds perform very poorly, but for
> different reasons. Under many configurations, token bucket traffic
> policers can suddenly start discarding a large fraction of the
> traffic when tokens are depleted, 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 cause a data
> rate that is substantially larger than the token replenishment rate,
> causing 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 for
> multiple rounds. Both cases lead to prolonged recovery, decimating
> application latency and/or goodput.
>
> PA: It sounds like some metrics would be useful here, both to monitor the
> current situation and to evaluate the impact of any changes.
>
> Investigating these environments led to the development of a
> "safeACK" heuristic to dynamically switch between Reduction Bounds:
> by default conservatively use PRR-CRB and only switch to PRR-SSRB
> when ACKs indicate the recovery is making good progress (SND.UNA is
> advancing without detecting any new losses). The SafeACK heuristic
> was experimented with in Google's CDN [Flach2016policing] and
> implemented in Linux since 2015.
>
> This SafeACK heuristic is only invoked where losses, application-
> limited behavior, or other events cause the current estimate of in-
> flight data to fall below ssthresh. The high loss rates that make
> the heuristic essential are only common in the presence of heavy
>
> Mathis, et al. Expires 28 November 2025 [Page 9]
> Internet-Draft Proportional Rate Reduction May 2025
>
> losses such as traffic policers [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.
>
> PA: How should operators detect that policers are dropping packets, and measure
> whether throughput improved when policers are present?
>
> Another PRR algorithm change improves the sending process when the
> sender enters recovery after a large portion of sequence space has
> been SACKed. This scenario could happen when the sender has
> previously detected reordering, for example, by using [RFC8985]. In
> the previous version of PRR, RecoverFS did not properly account for
> sequence ranges SACKed before entering fast recovery, which caused
> PRR to send too slow initially. With the change, PRR properly
>
> PA: "which caused PRR to initially send too slowly."
>
> accounts for sequence ranges SACKed before entering fast recovery.
>
> Yet another change is to force a fast retransmit upon the first ACK
> that triggers the recovery. Previously, PRR may not allow a fast
> retransmit (i.e., sndcnt is 0) on the first ACK in fast recovery,
> depending on the loss situation. Forcing a fast retransmit is
> important to maintain the ACK clock and avoid potential
> retransmission timeout (RTO) events. The forced fast retransmit only
> happens once during the entire recovery and still follows the packet
> conservation principles in PRR. This heuristic has been implemented
> since the first widely deployed TCP PRR implementation in 2011.
>
> In another change, upon exiting recovery a data sender SHOULD set
> cwnd to ssthresh. This is important for robust performance. Without
> setting cwnd to ssthresh at the end of recovery, with application-
> limited sender behavior and some loss patterns cwnd could end fast
> recovery well below ssthresh, leading to bad performance. The
> performance could, in some cases, be worse than [RFC6675] recovery,
> which simply sets cwnd to ssthresh at the start of recovery. This
> behavior of setting cwnd to ssthresh at the end of recovery has been
> implemented since the first widely deployed TCP PRR implementation in
> 2011, and is similar to [RFC6675], which specifies setting cwnd to
> ssthresh at the start of recovery.
>
> Since [RFC6937] was written, PRR has also been adapted to perform
> multiplicative window reduction for non-loss based congestion control
> algorithms, such as for [RFC3168] style Explicit Congestion
> Notification (ECN). This can be done by using some parts of the loss
> recovery state machine (in particular the RecoveryPoint from
> [RFC6675]) to invoke the PRR ACK processing for exactly one round
> trip worth of ACKs. However, note that using PRR for for cwnd
>
> PA: NB "for for".
>
> reductions for [RFC3168] ECN has been observed, with some approaches
> to Active Queue Management (AQM), to cause an excess cwnd reduction
> during ECN-triggered congestion episodes, as noted in [VCC].
>
> Mathis, et al. Expires 28 November 2025 [Page 10]
> Internet-Draft Proportional Rate Reduction May 2025
>
> 6. Relationships to other standards
>
> PRR MAY be used in conjunction with any congestion control algorithm
> that intends to make a multiplicative decrease in its sending rate
> over approximately the time scale of one round trip time, as long as
> the current volume of in-flight data is limited by a congestion
> window (cwnd) and the target volume of in-flight data during that
> reduction is a fixed value given by ssthresh. In particular, PRR is
> applicable to both Reno [RFC5681] and CUBIC [RFC9438] congestion
> control. PRR is described as a modification to "A Conservative Loss
> Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP"
> [RFC6675]. It is most accurate with SACK [RFC2018] but does not
> require SACK.
>
> PRR MAY be used in conjunction with a wide array of loss detection
> algorithms. This is because PRR does not have any dependencies on
> the details of how a loss detection algorithm estimates which packets
> have been delivered and which packets have been lost. Upon the
> reception of each ACK, PRR simply needs the loss detection algorithm
> to communicate how many packets have been marked as lost and how many
> packets have been marked as delivered. Thus PRR MAY be used in
> conjunction with the loss detection algorithms specified or described
> in the following documents: Reno [RFC5681], NewReno [RFC6582], SACK
> [RFC6675], FACK [FACK], and RACK-TLP [RFC8985]. Because of the
> performance properties of RACK-TLP, including resilience to tail
> loss, reordering, and lost retransmissions, it is RECOMMENDED that
> PRR is implemented together with RACK-TLP loss recovery [RFC8985].
>
> The SafeACK heuristic came about as a result of robust Lost
> Retransmission Detection under development in an early precursor to
> [RFC8985]. Without Lost Retransmission Detection, policers that
> cause very high loss rates are at very high risk of causing
> retransmission timeouts because Reno [RFC5681], CUBIC [RFC9438], and
> [RFC6675] can send retransmissions significantly above the policed
> rate.
>
> 7. Definitions
>
> PA: It's a pity this section is so far into the document, as some of the terms
> have already been used without being defined first.
>
> PA: The terms use an eclectic mixture of capitalisation, camel-case, and single
> / multiple words. Is it possible to use a consistent naming scheme?
>
> The following terms, parameters, and state variables are used as they
> are defined in earlier documents:
>
> SND.UNA: The oldest unacknowledged sequence number. This is defined
> in [RFC9293].
>
> SND.NXT: The next sequence number to be sent. This is defined in
> [RFC9293].
>
> Mathis, et al. Expires 28 November 2025 [Page 11]
> Internet-Draft Proportional Rate Reduction May 2025
>
> duplicate ACK: An acknowledgment is considered a "duplicate ACK" when
> (a) the receiver of the ACK has outstanding data, (b) the incoming
> acknowledgment carries no data, (c) the SYN and FIN bits are both
> off, (d) the acknowledgment number is equal to the greatest
> acknowledgment received on the given connection (SND.UNA from
>
> PA: It would be good to use consistent definitions: "The oldest unacknowledged
> sequence number" versus "the greatest acknowledgment received on the given
> connection".
>
> [RFC9293]) and (e) the advertised window in the incoming
> acknowledgment equals the advertised window in the last incoming
> acknowledgment. This is defined in [RFC5681].
>
> FlightSize: The amount of data that has been sent but not yet
> cumulatively acknowledged. This is defined in [RFC5681].
>
> Receiver Maximum Segment Size (RMSS): The RMSS is the size of the
> largest segment the receiver is willing to accept. This is the value
> specified in the MSS option sent by the receiver during connection
> startup. Or, if the MSS option is not used, it is the default of 536
> bytes for IPv4 or 1220 bytes for IPv6 [RFC9293]. The size does not
> include the TCP/IP headers and options. This is defined in
> [RFC5681].
>
> Sender Maximum Segment Size (SMSS): The SMSS is the size of the
> largest segment that the sender can transmit. This value can be
> based on the maximum transmission unit of the network, the path MTU
> discovery [RFC1191][RFC4821] algorithm, RMSS, or other factors. The
> size does not include the TCP/IP headers and options. This is
> defined in [RFC5681].
>
> Receive Window (rwnd): The most recently received advertised receive
> window, in bytes. At any given time, a connection MUST NOT send data
> with a sequence number higher than the sum of SND.UNA and rwnd. This
> is defined in [RFC5681] and [RFC9293].
>
> Congestion Window (cwnd): A state variable that limits the amount of
> data a connection can send. At any given time, a connection MUST NOT
> send data if inflight matches or exceeds cwnd. This is defined in
>
> PA: "inflight" isn't defined until later. Consider adding "(see below)".
>
> [RFC5681].
>
> Slow Start Threshold (ssthresh): The slow start threshold (ssthresh)
> state variable is used to determine whether the slow start or
> congestion avoidance algorithm is used to control data transmission.
> This is defined in [RFC5681].
>
> PRR defines additional variables and terms:
>
> DeliveredData: The total number of bytes that the current ACK
>
> PA: For consistency, "Delivered Data".
>
> indicates have been delivered to the receiver. When there are no
> SACKed sequence ranges in the scoreboard before or after the ACK,
> DeliveredData is the change in SND.UNA. With SACK, DeliveredData can
>
> Mathis, et al. Expires 28 November 2025 [Page 12]
> Internet-Draft Proportional Rate Reduction May 2025
>
> be computed precisely as the change in SND.UNA, plus the (signed)
> change in SACKed. In recovery without SACK, DeliveredData is
> estimated to be 1 SMSS on receiving a duplicate acknowledgement, and
> on a subsequent partial or full ACK DeliveredData is the change in
> SND.UNA, minus 1 SMSS for each preceding duplicate ACK. Note that
> without SACK, a poorly-behaved receiver that returns extraneous
> duplicate ACKs (as described in [Savage99]) could attempt to
> artificially inflate DeliveredData. As a mitigation, if not using
> SACK then PRR disallows incrementing DeliveredData when the total
> bytes delivered in a PRR episode would exceed the estimated data
> outstanding upon entering recovery (RecoverFS).
>
> inflight: The data sender's best estimate of the number of bytes
> outstanding in the network. To calculate inflight, connections with
> SACK enabled and using [RFC6675] loss detection MAY use the "pipe"
> algorithm as specified in [RFC6675]. SACK-enabled connections using
> RACK-TLP loss detection [RFC8985] or other loss detection algorithms
> MUST calculate inflight by starting with SND.NXT - SND.UNA,
> subtracting out bytes SACKed in the scoreboard, subtracting out bytes
> marked lost in the scoreboard, and adding bytes in the scoreboard
> that have been retransmitted since they were last marked lost. For
> non-SACK-enabled connections, instead of subtracting out bytes SACKed
> in the SACK scoreboard, senders MUST subtract out: min(RecoverFS, 1
> SMSS for each preceding duplicate ACK in the fast recovery episode);
> the min() with RecoverFS is to protect against misbehaving receivers
> [Savage99].
>
> RecoverFS: The "recovery flight size", the number of bytes the sender
>
> PA: For consistency, this should be "Recovery Flight Size (recoverFS)".
>
> estimates are in flight in the network upon entering fast recovery.
> PRR uses RecoverFS to compute a smooth sending rate. Upon entering
> fast recovery, PRR initializes RecoverFS to "inflight". RecoverFS
> remains constant during a given fast recovery episode.
>
> safeACK: A local boolean variable indicating that the current ACK
> reported good progress. SafeACK is true only when the ACK has
> cumulatively acknowledged new data and the ACK does not indicate
> further losses. For example, an ACK triggering RFC6675 "last resort"
> retransmission (Section 4, NextSeg() condition 4) may indicate
> further losses. Both conditions indicate the recovery is making good
> progress and can send more aggressively.
>
> 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.
>
> Mathis, et al. Expires 28 November 2025 [Page 13]
> Internet-Draft Proportional Rate Reduction May 2025
>
> Voluntary window reductions: choosing not to send data in response to
> some ACKs, for the purpose of reducing the sending window size and
> data rate.
>
> 8. Algorithm
>
> At the beginning of a congestion control response episode initiated
> by the congestion control algorithm, a data sender using PRR MUST
> initialize the PRR state.
>
> The timing of the start of a congestion control response episode is
> entirely up to the congestion control algorithm, and (for example)
> could correspond to the start of a fast recovery episode, or a once-
> per-round-trip reduction when lost retransmits or lost original
> transmissions are detected after fast recovery is already in
> progress.
>
> The PRR initialization allows a modern congestion control algorithm,
> CongCtrlAlg(), that might set ssthresh to something other than
> FlightSize/2 (including, e.g., CUBIC [RFC9438]):
>
> ssthresh = CongCtrlAlg() // Target flight size in recovery
> prr_delivered = 0 // Total bytes delivered in recovery
> prr_out = 0 // Total bytes sent in recovery
> RecoverFS = SND.NXT - SND.UNA
> // Bytes SACKed before entering recovery will not be
> // marked as delivered during recovery:
> RecoverFS -= (bytes SACKed in scoreboard) - (bytes newly SACKed)
>
> PA: I can't reconcile this with the definitions in section 7. It subtracts the
> delta between these values whereas I'm expecting both values to be subtracted.
>
> Per section 7:
>
> 1. PRR initializes RecoverFS to "inflight".
>
> 2. calculate inflight by starting with SND.NXT - SND.UNA, subtracting out bytes
> SACKed in the scoreboard, subtracting out bytes marked lost in the scoreboard,
> and adding bytes in the scoreboard that have been retransmitted since they were
> last marked lost.
>
> Per the definitions, this line should be an addition so that the cumulative
> value is subtracted:
>
> RecoverFS -= (bytes SACKed in scoreboard) + (bytes newly SACKed)
>
> It may be clearer to parenthesise the RHS, or split it into two subtractions.
>
> // Include the (rare) case of cumulatively ACKed bytes:
> RecoverFS += (bytes newly cumulatively acknowledged)
>
> Mathis, et al. Expires 28 November 2025 [Page 14]
> Internet-Draft Proportional Rate Reduction May 2025
>
> On every ACK starting or during fast recovery,
> excluding the ACK that concludes a PRR episode:
>
> if (DeliveredData is 0)
> Return
>
> prr_delivered += DeliveredData
> inflight = (estimated volume of in-flight data)
> safeACK = (SND.UNA advances and no further loss indicated)
> if (inflight > ssthresh) {
> // Proportional Rate Reduction
> sndcnt = CEIL(prr_delivered * ssthresh / RecoverFS) - prr_out
>
> PA: Is floating point division required?
>
> } else {
> // PRR-CRB by default
> sndcnt = MAX(prr_delivered - prr_out, DeliveredData)
> if (safeACK) {
> // PRR-SSRB when recovery is in good progress
> sndcnt += SMSS
> }
> // Attempt to catch up, as permitted
> sndcnt = MIN(ssthresh - inflight, sndcnt)
> }
>
> if (prr_out is 0 AND sndcnt is 0) {
> // Force a fast retransmit upon entering recovery
> sndcnt = SMSS
> }
> cwnd = inflight + sndcnt
>
> On any data transmission or retransmission:
> prr_out += (data sent)
>
> A PRR episode ends upon either completing fast recovery, or before
> initiating a new PRR episode due to a new congestion control response
> episode.
>
> On the completion of a PRR episode:
> cwnd = ssthresh
>
> Note that this step that sets cwnd to ssthresh can potentially, in
> some scenarios, allow a burst of back-to-back segments into the
> network.
>
> Mathis, et al. Expires 28 November 2025 [Page 15]
> Internet-Draft Proportional Rate Reduction May 2025
>
> It is RECOMMENDED that implementations use pacing to reduce the
> burstiness of traffic. This recommendation is consistent with
> current practice to mitigate bursts, e.g. pacing transmission bursts
>
> PA: can a reference be added for this?
>
> after restarting from idle.
>
> 9. Examples
>
> This section illustrate these algorithms by showing their different
> behaviors for two example scenarios: a connection experiencing either
> a single loss or a burst of 15 consecutive losses. All cases use
> bulk data transfers (no application pauses), Reno congestion control
> [RFC5681], and cwnd = FlightSize = inflight = 20 segments, so
> ssthresh will be set to 10 at the beginning of recovery. The
> scenarios use standard Fast Retransmit [RFC5681] and Limited Transmit
> [RFC3042], so the sender will send two new segments followed by one
> retransmit in response to the first three duplicate ACKs following
> the losses.
>
> Each of the diagrams below shows the per ACK response to the first
> round trip for the various recovery algorithms when the zeroth
> segment is lost. The top line ("ack#") indicates the transmitted
> segment number triggering the ACKs, with an X for the lost segment.
> The "cwnd" and "inflight" lines indicate the values of cwnd and
> inflight, respectively, for these algorithms after processing each
> returning ACK but before further (re)transmission. The "sent" line
> indicates how much 'N'ew or 'R'etransmitted data would be sent. Note
> that the algorithms for deciding which data to send are out of scope
> of this document.
>
> Mathis, et al. Expires 28 November 2025 [Page 16]
> Internet-Draft Proportional Rate Reduction May 2025
>
> RFC 6675
> a X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
> c 20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> i 19 19 18 18 17 16 15 14 13 12 11 10 9 9 9 9 9 9 9 9 9 9
> s N N R N N N N N N N N N N
>
> PRR
> a X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
> c 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
> i 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 9 9
> s N N R N N N N N N N N N N
>
> a: ack#; c: cwnd; i: inflight; s: sent
>
> Figure 1
>
> In this first example, ACK#1 through ACK#19 contain SACKs for the
> original flight of data, ACK#20 and ACK#21 carry SACKs for the
> limited transmits triggered by the first and second SACKed segments,
> and ACK#22 carries the full cumulative ACK covering all data up
> through the limited transmits. ACK#22 completes the fast recovery
> episode, and thus completes the PRR episode.
>
> Note that both algorithms send the same total amount of data, and
> both algorithms complete the fast recovery episode with a cwnd
> matching the ssthresh of 20. RFC 6675 experiences a "half window of
> silence" while PRR spreads the voluntary window reduction across an
> entire RTT.
>
> Next, consider an example scenario with the same initial conditions,
> except that the first 15 packets (0-14) are lost. During the
> remainder of the lossy round trip, only 5 ACKs are returned to the
> sender. The following examines each of these algorithms in
> succession.
>
> Mathis, et al. Expires 28 November 2025 [Page 17]
> Internet-Draft Proportional Rate Reduction May 2025
>
> RFC 6675
> a X X X X X X X X X X X X X X X 15 16 17 18 19
> c 20 20 10 10 10
> i 19 19 4 9 9
> s N N 6R R R
>
> PRR
> a X X X X X X X X X X X X X X X 15 16 17 18 19
> c 20 20 5 5 5
> i 19 19 4 4 4
> s N N R R R
>
> a: ack#; c: cwnd; i: inflight; s: sent
>
> Figure 2
>
> In this specific situation, RFC 6675 is more aggressive because once
> Fast Retransmit is triggered (on the ACK for segment 17), the sender
> immediately retransmits sufficient data to bring inflight up to cwnd.
> Earlier measurements [RFC 6937 section 6]
>
> PA: Consider "section 6 of [RFC6937]" so the xref works correctly.
>
> indicate that RFC 6675
> significantly outperforms [RFC6937] PRR using only PRR-CRB, and some
> other similarly conservative algorithms that were tested, showing
> that it is significantly common for the actual losses to exceed the
> cwnd reduction determined by the congestion control algorithm.
>
> Under such heavy losses, during the first round trip of fast recovery
> PRR uses the PRR-CRB to follow the packet conservation principle.
> Since the total losses bring inflight below ssthresh, data is sent
> such that the total data transmitted, prr_out, follows the total data
> delivered to the receiver as reported by returning ACKs.
> Transmission is controlled by the sending limit, which is set to
> prr_delivered - prr_out.
>
> While not shown in the figure above, once the fast retransmits sent
> starting at ACK#17 are delivered and elicit ACKs that increment the
> SND.UNA, PRR enters PRR-SSRB and increases the window by exactly 1
> segment per ACK until inflight rises to ssthresh during recovery. On
> heavy losses when cwnd is large, PRR-SSRB recovers the losses
> exponentially faster than PRR-CRB. Although increasing the window
> during recovery seems to be ill advised, it is important to remember
> that this is actually less aggressive than permitted by [RFC6675],
> which sends the same quantity of additional data as a single burst in
> response to the ACK that triggered Fast Retransmit.
>
> Mathis, et al. Expires 28 November 2025 [Page 18]
> Internet-Draft Proportional Rate Reduction May 2025
>
> For less severe loss events, where the total losses are smaller than
> the difference between FlightSize and ssthresh, PRR-CRB and PRR-SSRB
> are not invoked since PRR stays in the proportional rate reduction
> mode.
>
> 10. Properties
>
> The following properties are common to both PRR-CRB and PRR-SSRB,
> except as noted:
>
> PRR maintains the sender's ACK clocking across most recovery events,
>
> PA: Vague. Explicitly say which are in or which are out?
>
> including burst losses. RFC 6675 can send large unclocked bursts
>
> PA: xref: [RFC6675]
>
> following burst losses.
>
> Normally, PRR will spread voluntary window reductions out evenly
> across a full RTT. This has the potential to generally reduce the
> burstiness of Internet traffic, and could be considered to be a type
> of soft pacing. Hypothetically, any pacing increases the probability
> that different flows are interleaved, reducing the opportunity for
> ACK compression and other phenomena that increase traffic burstiness.
> However, these effects have not been quantified.
>
> If there are minimal losses, PRR will converge to exactly the target
> window chosen by the congestion control algorithm. Note that as the
> sender approaches the end of recovery, prr_delivered will approach
> RecoverFS and sndcnt will be computed such that prr_out approaches
> ssthresh.
>
> Implicit window reductions, due to multiple isolated losses during
> recovery, cause later voluntary reductions to be skipped. For small
> numbers of losses, the window size ends at exactly the window chosen
> by the congestion control algorithm.
>
> For burst losses, earlier voluntary window reductions can be undone
> by sending extra segments in response to ACKs arriving later during
> recovery. Note that as long as some voluntary window reductions are
> not undone, and there is no application stall, the final value for
> inflight will be the same as ssthresh, the target cwnd value chosen
> by the congestion control algorithm.
>
> PA: Consider quoting the terms, both here and elsewhere in the document:
>
> the final value for
> "inflight" will be the same as "ssthresh", the target "cwnd" value chosen
> by the congestion control algorithm.
>
> PRR with either Reduction Bound improves the situation when there are
> application stalls, e.g., when the sending application does not queue
> data for transmission quickly enough or the receiver stops advancing
> the receive window. When there is an application stall early during
> recovery, prr_out will fall behind the sum of transmissions allowed
> by sndcnt. The missed opportunities to send due to stalls are
> treated like banked voluntary window reductions; specifically, they
> cause prr_delivered - prr_out to be significantly positive. If the
>
> Mathis, et al. Expires 28 November 2025 [Page 19]
> Internet-Draft Proportional Rate Reduction May 2025
>
> application catches up while the sender is still in recovery, the
> sender will send a partial window burst to grow inflight to catch up
> to exactly where it would have been had the application never
> stalled. Although such a burst could negatively impact the given
> flow or other sharing flows, this is exactly what happens every time
> there is a partial-RTT application stall while not in recovery. PRR
> makes partial-RTT stall behavior uniform in all states. Changing
> this behavior is out of scope for this document.
>
> PRR with Reduction Bound is less sensitive to errors in the inflight
> estimator. While in recovery, inflight is intrinsically an
> estimator, using incomplete information to estimate if un-SACKed
> segments are actually lost or merely out of order in the network.
> Under some conditions, inflight can have significant errors; for
> example, inflight is underestimated when a burst of reordered data is
> prematurely assumed to be lost and marked for retransmission. If the
> transmissions are regulated directly by inflight as they are with RFC
> 6675, a step discontinuity in the inflight estimator causes a burst
>
> PA: xref: [RFC6675] - here and elsewhere throughout the document.
>
> of data, which cannot be retracted once the inflight estimator is
> corrected a few ACKs later. For PRR dynamics, inflight merely
> determines which algorithm, PRR or the Reduction Bound, is used to
> compute sndcnt from DeliveredData. While inflight is underestimated,
> the algorithms are different by at most 1 segment per ACK. Once
> inflight is updated, they converge to the same final window at the
> end of recovery.
>
> Under all conditions and sequences of events during recovery, PRR-CRB
> strictly bounds the data transmitted to be equal to or less than the
> amount of data delivered to the receiver. This Strong Packet
> Conservation Bound is the most aggressive algorithm that does not
> lead to additional forced losses in some environments. It has the
> property that if there is a standing queue at a bottleneck with no
> cross traffic, the queue will maintain exactly constant length for
> the duration of the recovery, except for +1/-1 fluctuation due to
> differences in packet arrival and exit times. See Appendix A for a
> detailed discussion of this property.
>
> Although the Strong Packet Conservation Bound is very appealing for a
> number of reasons, earlier measurements [RFC 6937 section 6]
>
> PA: Consider "section 6 of [RFC6937]" so this xref's properly.
>
> 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
> losses. PRR-SSRB is a compromise that permits a sender to send one
> extra segment per ACK as compared to the Packet Conserving Bound when
> the ACK indicates the recovery is in good progress without further
> losses. From the perspective of a strict Packet Conserving Bound,
> PRR-SSRB does indeed open the window during recovery; however, it is
> significantly less aggressive than [RFC6675] in the presence of burst
> losses. The [RFC6675] "half window of silence" may temporarily
>
> Mathis, et al. Expires 28 November 2025 [Page 20]
> Internet-Draft Proportional Rate Reduction May 2025
>
> reduce queue pressure when congestion control does not reduce the
> congestion window entering recovery to avoid further losses. The
> goal of PRR is to minimize the opportunities to lose the self clock
> by smoothly controlling inflight toward the target set by the
>
> PA: Again, consider quoting the terms so they're clearly not part of the prose.
>
> congestion control. It is the congestion control's responsibility to
> avoid a full queue, not PRR.
>
> 11. Adapting PRR to other transport protocols
>
> The main PRR algorithm and reductions bounds can be adapted to any
> transport that can support RFC 6675. In one major implementation
>
> PA: xref: [RFC6675]
>
> (Linux TCP), PRR has been the default fast recovery algorithm for its
> default and supported congestion control modules.
>
> PA: This is ambiguous. Was it the default algorithm only for a few moments? Is
> the meaning, "has been (and still is)" ? Or, "has been but no longer is because
> ..." ?
>
> The safeACK heuristic can be generalized as any ACK of a
> retransmission that does not cause some other segment to be marked
> for retransmission. That is, PRR-SSRB is safe on any ACK that
> reduces the total number of pending and outstanding retransmissions.
>
> 12. Measurement Studies
>
> For [RFC6937] a companion paper [IMC11] evaluated [RFC3517] and
> various experimental PRR versions in a large-scale measurement study.
> Today, the legacy algorithms used in that study have already faded
> from code bases, making such comparisons impossible without
>
> PA: This sounds subjective.
>
> recreating historical algorithms. Readers interested in the
> measurement study should review section 5 of [RFC6937] and the IMC
> paper [IMC11].
>
> 13. Acknowledgements
>
> This document is based in part on previous work by Janey C. Hoe (see
>
> PA: "Janey C. Hoe", without extra space.
>
> -- ends --
>
> section 3.2, "Recovery from Multiple Packet Losses", of
> [Hoe96Startup]) and Matt Mathis, Jeff Semke, and Jamshid Mahdavi
> [RHID], and influenced by several discussions with John Heffner.
>
> Monia Ghobadi and Sivasankar Radhakrishnan helped analyze the
> experiments. Ilpo Jarvinen reviewed the initial implementation.
> Mark Allman, Richard Scheffenegger, Markku Kojo, Mirja Kuehlewind,
> Gorry Fairhurst, and Russ Housley improved the document through their
> insightful reviews and suggestions.
>
> 14. IANA Considerations
>
> This memo includes no request to IANA.
>
> Mathis, et al. Expires 28 November 2025 [Page 21]
> Internet-Draft Proportional Rate Reduction May 2025
>
> 15. Security Considerations
>
> PRR does not change the risk profile for TCP.
>
> Implementers that change PRR from counting bytes to segments have to
> be cautious about the effects of ACK splitting attacks [Savage99],
> where the receiver acknowledges partial segments for the purpose of
> confusing the sender's congestion accounting.
>
> 16. Normative References
>
> [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
> DOI 10.17487/RFC1191, November 1990,
> <https://www.rfc-editor.org/info/rfc1191>.
>
> [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
> Selective Acknowledgment Options", RFC 2018,
> DOI 10.17487/RFC2018, October 1996,
> <https://www.rfc-editor.org/info/rfc2018>.
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119,
> DOI 10.17487/RFC2119, March 1997,
> <https://www.rfc-editor.org/info/rfc2119>.
>
> [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
> Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
> <https://www.rfc-editor.org/info/rfc4821>.
>
> [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
> Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
> <https://www.rfc-editor.org/info/rfc5681>.
>
> [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
> NewReno Modification to TCP's Fast Recovery Algorithm",
> RFC 6582, DOI 10.17487/RFC6582, April 2012,
> <https://www.rfc-editor.org/info/rfc6582>.
>
> [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
> and Y. Nishida, "A Conservative Loss Recovery Algorithm
> Based on Selective Acknowledgment (SACK) for TCP",
> RFC 6675, DOI 10.17487/RFC6675, August 2012,
> <https://www.rfc-editor.org/info/rfc6675>.
>
> [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
> 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
> May 2017, <https://www.rfc-editor.org/info/rfc8174>.
>
> Mathis, et al. Expires 28 November 2025 [Page 22]
> Internet-Draft Proportional Rate Reduction May 2025
>
> [RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
> RACK-TLP Loss Detection Algorithm for TCP", RFC 8985,
> DOI 10.17487/RFC8985, February 2021,
> <https://www.rfc-editor.org/info/rfc8985>.
>
> [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
> STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
> <https://www.rfc-editor.org/info/rfc9293>.
>
> [RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
> "CUBIC for Fast and Long-Distance Networks", RFC 9438,
> DOI 10.17487/RFC9438, August 2023,
> <https://www.rfc-editor.org/info/rfc9438>.
>
> 17. Informative References
>
> [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgment:
> Refining TCP Congestion Control", ACM SIGCOMM SIGCOMM1996,
> August 1996,
> <https://dl.acm.org/doi/pdf/10.1145/248157.248181>.
>
> [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.
>
> [Hoe96Startup]
> Hoe, J., "Improving the start-up behavior of a congestion
> control scheme for TCP", ACM SIGCOMM SIGCOMM1996, August
> 1996.
>
> [IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi,
> "Proportional Rate Reduction for TCP", Proceedings of the
> 11th ACM SIGCOMM Conference on Internet Measurement
> 2011, Berlin, Germany, November 2011.
>
> [Jacobson88]
> Jacobson, V., "Congestion Avoidance and Control", SIGCOMM
> Comput. Commun. Rev. 18(4), August 1988.
>
> [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
> TCP's Loss Recovery Using Limited Transmit", RFC 3042,
> DOI 10.17487/RFC3042, January 2001,
> <https://www.rfc-editor.org/info/rfc3042>.
>
> Mathis, et al. Expires 28 November 2025 [Page 23]
> Internet-Draft Proportional Rate Reduction May 2025
>
> [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
> of Explicit Congestion Notification (ECN) to IP",
> RFC 3168, DOI 10.17487/RFC3168, September 2001,
> <https://www.rfc-editor.org/info/rfc3168>.
>
> [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
> Conservative Selective Acknowledgment (SACK)-based Loss
> Recovery Algorithm for TCP", RFC 3517,
> DOI 10.17487/RFC3517, April 2003,
> <https://www.rfc-editor.org/info/rfc3517>.
>
> [RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional
> Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937,
> May 2013, <https://www.rfc-editor.org/info/rfc6937>.
>
> [RHID] Mathis, M., Semke, J., and J. Mahdavi, "The Rate-Halving
> Algorithm for TCP Congestion Control", Work in Progress,
> August 1999, <https://datatracker.ietf.org/doc/html/draft-
> mathis-tcp-ratehalving>.
>
> [Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
> "TCP congestion control with a misbehaving receiver",
> SIGCOMM Comput. Commun. Rev. 29(5), October 1999.
>
> [VCC] Cronkite-Ratcliff, B., Bergman, A., Vargaftik, S., Ravi,
> M., McKeown, N., Abraham, I., and I. Keslassy,
> "Virtualized Congestion Control (Extended Version)",
> August 2016, <http://www.ee.technion.ac.il/~isaac/p/
> sigcomm16_vcc_extended.pdf>.
>
> Appendix A. Strong Packet Conservation Bound
>
> PRR-CRB is based on a conservative, philosophically pure, and
> aesthetically appealing Strong Packet Conservation Bound, described
> here. Although inspired by the packet conservation principle
> [Jacobson88], it differs in how it treats segments that are missing
> and presumed lost. Under all conditions and sequences of events
> during recovery, PRR-CRB strictly bounds the data transmitted to be
> equal to or less than the amount of data delivered to the receiver.
> Note that the effects of presumed losses are included in the inflight
> calculation, but do not affect the outcome of PRR-CRB, once inflight
> has fallen below ssthresh.
>
> This Strong Packet Conservation Bound is the most aggressive
> algorithm that does not lead to additional forced losses in some
> environments. It has the property that if there is a standing queue
> at a bottleneck that is carrying no other traffic, the queue will
> maintain exactly constant length for the entire duration of the
>
> Mathis, et al. Expires 28 November 2025 [Page 24]
> Internet-Draft Proportional Rate Reduction May 2025
>
> recovery, except for +1/-1 fluctuation due to differences in packet
> arrival and exit times. Any less aggressive algorithm will result in
> a declining queue at the bottleneck. Any more aggressive algorithm
> will result in an increasing queue or additional losses if it is a
> full drop tail queue.
>
> This property is demonstrated with a thought experiment:
>
> Imagine a network path that has insignificant delays in both
> directions, except for the processing time and queue at a single
> bottleneck in the forward path. In particular, when a packet is
> "served" at the head of the bottleneck queue, the following events
> happen in much less than one bottleneck packet time: the packet
> arrives at the receiver; the receiver sends an ACK that arrives at
> the sender; the sender processes the ACK and sends some data; the
> data is queued at the bottleneck.
>
> If sndcnt is set to DeliveredData and nothing else is inhibiting
> sending data, then clearly the data arriving at the bottleneck queue
> will exactly replace the data that was served at the head of the
> queue, so the queue will have a constant length. If queue is drop
> tail and full, then the queue will stay exactly full. Losses or
> reordering on the ACK path only cause wider fluctuations in the queue
> size, but do not raise its peak size, independent of whether the data
> is in order or out of order (including loss recovery from an earlier
> RTT). Any more aggressive algorithm that sends additional data will
> overflow the drop tail queue and cause loss. Any less aggressive
> algorithm will under-fill the queue. Therefore, setting sndcnt to
> DeliveredData is the most aggressive algorithm that does not cause
> forced losses in this simple network. Relaxing the assumptions
> (e.g., making delays more authentic and adding more flows, delayed
> ACKs, etc.) is likely to increase the fine grained fluctuations in
> queue size but does not change its basic behavior.
>
> Note that the congestion control algorithm implements a broader
> notion of optimal that includes appropriately sharing the network.
> Typical congestion control algorithms are likely to reduce the data
> sent relative to the Packet Conserving Bound implemented by PRR,
> bringing TCP's actual window down to ssthresh.
>
> Authors' Addresses
>
> Matt Mathis
> Email: ietf@xxxxxxxxxxxxxx
>
> Neal Cardwell
> Google, Inc.
>
> Mathis, et al. Expires 28 November 2025 [Page 25]
> Internet-Draft Proportional Rate Reduction May 2025
>
> Email: ncardwell@xxxxxxxxxx
>
> Yuchung Cheng
> Google, Inc.
> Email: ycheng@xxxxxxxxxx
>
> Nandita Dukkipati
> Google, Inc.
> Email: nanditad@xxxxxxxxxx
>
> Mathis, et al. Expires 28 November 2025 [Page 26]
>
>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
