Skip to main content

9. Adapting PRR to Other Transport Protocols

The main PRR algorithm and reduction bounds can be adapted to any transport protocol that can support [RFC6675]. In one major implementation (Linux TCP), PRR has been the fast recovery algorithm for its default and supported congestion control modules since its introduction in 2011 [First_TCP_PRR].

The SafeACK heuristic can be generalized to any ACK for a retransmission that does not cause some other segment to be marked for retransmission.

10. Measurement Studies

For [RFC6937], a companion paper [IMC11] evaluated [RFC3517] and various experimental versions of PRR in large-scale measurement studies. At the time of publication, the legacy algorithms used in the study no longer exist in the codebases used for the study, making such comparisons difficult without recreating historical algorithms.

Readers interested in measurement studies should consult Section 5 of [RFC6937] and the IMC paper [IMC11].

11. Operational Considerations

11.1. Incremental Deployment​

PRR is incrementally deployable because it only leverages existing transport protocol mechanisms to acknowledge data delivery and detect lost data.

Deployment Requirements:

  • PRR only requires changes to the data sender's transport protocol implementation
  • No changes are needed to the data receiver
  • No changes are needed to the network

This allows data senders using PRR to work correctly with any existing data receiver or network. PRR requires no changes or assistance from routers, switches, or other devices in the network.

11.2. Fairness​

PRR aims to maintain the fairness properties of the congestion control algorithm with which it is deployed.

How It Works:

  • PRR only runs during a congestion control response phase (such as fast recovery or a cwnd step reduction from a TCP ECN reaction defined in [RFC3168])
  • Only makes short-term, per-acknowledgment decisions to smoothly regulate the amount of inflight data during the regulation phase
  • So that at the end of the phase it approaches as closely as possible to the slow start threshold (ssthresh) determined by the congestion control algorithm

Mechanisms Not Modified:

  • PRR does not modify congestion control cwnd increase or decrease mechanisms outside of congestion control response phases

11.3. Protecting the Network Against Excessive Queuing and Packet Loss​

Long-term Impact​

On long timescales, PRR aims to maintain the queueing and packet loss properties of the congestion control algorithm with which it is deployed.

As described above, PRR only runs during a congestion control response phase (such as fast recovery or response to ECN), and only makes short-term, per-acknowledgment decisions to smoothly regulate the amount of inflight data during the regulation phase, so that at the end of the phase it approaches as closely as possible to the slow start threshold (ssthresh) determined by the congestion control algorithm.

Short-term Impact​

On short timescales, PRR aims to result in lower packet loss rates than preceding approaches like [RFC6675].

Principle of Advantage:

  • PRR is inspired by the principle of packet conservation
  • Relies on self-clocked processes wherever possible
  • With [RFC6675], a single ACK carrying SACK options and implying a large amount of missing data can cause a step discontinuity in the pipe estimator
  • This can result in fast retransmit sending a large burst of data far exceeding the amount of delivered data
  • PRR avoids such bursts by making transmission decisions based on the amount of delivered data rather than the amount of lost data

Performance Improvement:

  • As described above, PRR-SSRB is less aggressive than [RFC6675] (transmitting fewer segments or taking more time to transmit them)
  • Due to a lower probability of additional packet loss during recovery, it outperforms the latter

12. IANA Considerations

This document has no IANA actions.

13. Security Considerations

PRR does not change the risk profile of the transport protocol.

ACK Division Attack Protection:

Implementers adapting PRR from counting bytes to counting segments must be careful about the impact of ACK division attacks [Savage99], where receivers acknowledge partial segments with the intent of confusing the sender's congestion accounting.

Recommendation: Using byte counting rather than segment counting better defends against such attacks.

Last updated on