5. Relationships to Other Standards
PRR can be used with any congestion control algorithm that intends to apply a multiplicative reduction to its sending rate over a timescale of roughly one round-trip time, where the current amount of inflight data is limited by the congestion window (cwnd), and where the target amount of inflight data during that reduction is a fixed value given by ssthresh.
In particular, PRR is suitable for use with Reno [RFC5681] and CUBIC [RFC9438] congestion control.
Relationship with Loss Recovery Algorithms
PRR is described as a modification to "The Conservative Loss Recovery Algorithm for SACK-based TCP" [RFC6675]. It is most accurate when used with SACK [RFC2018], but SACK is not required.
PRR can be combined with a wide range of loss detection algorithms. This is because PRR does not depend on the details of how the loss detection algorithm estimates which packets have been delivered and which packets have been lost. Upon each ACK received, PRR only needs the loss detection algorithm to communicate how many packets have been marked as lost and how many packets have been marked as delivered.
Therefore, PRR can be combined with loss detection algorithms specified or described in the following documents:
- Reno [RFC5681]
- NewReno [RFC6582]
- SACK [RFC6675]
- Forward Acknowledgment (FACK) [FACK]
- Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985]
Due to RACK-TLP's performance characteristics, including resilience to tail loss, reordering, and lost retransmissions, it is RECOMMENDED that PRR be implemented with RACK-TLP loss recovery [RFC8985].
Origin of the SafeACK Heuristic
The SafeACK heuristic was a consequence of developing robust lost retransmission detection in an early precursor to [RFC8985].
Without lost retransmission detection, policers causing very high packet loss rates faced extremely high risk of causing retransmission timeouts, because Reno [RFC5681], CUBIC [RFC9438], and [RFC6675] could send retransmissions well above the policing rate.
Compatibility with Congestion Control Algorithms
PRR is designed to work well with various congestion control algorithms:
Reno Congestion Control
- PRR smooths Reno's fast recovery process
- Avoids Reno's sharp window reduction at the start of recovery
- Provides more stable sending rate
CUBIC Congestion Control
- PRR is compatible with CUBIC's window reduction mechanism
- Provides precise rate control during fast recovery
- Maintains CUBIC's growth characteristics after recovery
ECN Compatibility
PRR can be adapted for use with Explicit Congestion Notification (ECN) [RFC3168] by using portions of the loss recovery state machine to invoke PRR processing in response to ECN marking rather than actual packet loss.
Compatibility with Transport Protocols
While PRR was originally designed for TCP, its core principles can be applied to other transport protocols, provided they:
- Use window-based congestion control
- Have a mechanism similar to fast recovery
- Can estimate the amount of inflight data
- Receive acknowledgments for sent data
Chapter 9 discusses in detail the considerations for adapting PRR to other transport protocols.