7. Properties
The following properties are common to both PRR-CRB and PRR-SSRB, except as noted:
1. Maintaining the ACK Clock
PRR attempts to maintain the sender's ACK clock across recovery events, including burst losses. In contrast, [RFC6675] can send large, unclocked bursts following burst losses.
Benefit: Avoids introducing additional bursty traffic into the network, helping to stabilize congestion control.
2. Smooth Window Reduction
Normally, PRR spreads voluntary window reductions evenly across a full RTT. This has the potential to generally reduce the burstiness of Internet traffic and can be thought of as a form 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.
3. Precise Convergence to Target Window
If there are minimal losses, PRR will converge precisely to 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.
Mathematical Guarantee: Under ideal conditions, inflight = ssthresh at the end of recovery.
4. Automatic Adaptation to Implicit Window Reductions
Implicit window reductions, due to multiple isolated losses during recovery, cause subsequent voluntary reductions to be skipped. For small numbers of losses, the window size ends up at precisely the window chosen by the congestion control algorithm.
Mechanism: PRR automatically adjusts so that the sum of actual losses and voluntary reductions reaches the target reduction.
5. Handling Burst Losses
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 of inflight will be the same as ssthresh.
Flexibility: Allows being more conservative when severe congestion is detected, and more aggressive when conditions improve.
6. Application Stall Handling
PRR with either Reduction Bound improves the situation when there is an application stall, for example, when the sending application does not queue data for transmission quickly enough or the receiver stops advancing its receive window.
Stall Scenario Handling
When an application stall occurs early during recovery:
- prr_out will fall behind the sum of the transmissions permitted by SndCnt
- The missed transmission opportunities due to stalls are treated like banked voluntary window reductions
- Specifically, they cause prr_delivered - prr_out to be significantly positive
Catch-Up Mechanism
If the application catches up while the sender is still in recovery:
- The sender will send a partial window burst to increase inflight
- This causes inflight to approach the exact position it would have been at if the application had never stalled
- While such a burst might be detrimental to the given flow or other flows sharing the path, this is exactly what happens for partial-RTT application stalls whenever not in recovery
Unified Behavior: PRR makes partial-RTT-stall behavior uniform in all states. Changing this behavior is out of scope for this document.
7. Robustness to Inflight Estimator Errors
PRR with Reduction Bounds is less sensitive to errors in the inflight estimator.
During recovery, inflight is fundamentally an estimator that uses incomplete information to estimate whether unSACKed segments are actually lost or merely out of order in the network. Under some conditions, inflight can have significant errors; for example, when a burst of reordered data is prematurely assumed to be lost and marked for retransmission, inflight is underestimated.
Error Tolerance Mechanism
If transmissions are regulated directly by inflight (as they are in [RFC6675]):
- A step discontinuity in the inflight estimator causes a burst of data
- The burst cannot be retracted once the inflight estimator is corrected a few ACKs later
With PRR dynamics:
- inflight only determines which algorithm (PRR or Reduction Bound) is used to compute SndCnt from DeliveredData
- When inflight is underestimated, the algorithms differ by at most 1 segment per ACK
- Once inflight is updated, they converge to the same final window at the end of recovery
8. Strong Packet Conservation Bound (PRR-CRB)
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.
Queue Length Property
It has the property that if there is a standing queue at a bottleneck with no cross traffic, the queue will maintain a completely constant length during recovery, except for +1/-1 fluctuations due to differences in packet arrival and departure times.
See Appendix A for a detailed discussion of this property.
9. PRR-SSRB Trade-Off
While the Strong Packet Conservation Bound is very appealing for a number of reasons, earlier measurements (discussed in Section 6 of [RFC6675]) suggest that it is not aggressive enough and does not perform as well as the algorithm described in [RFC6675], which permits data bursts in the presence of burst losses.
PRR-SSRB is a compromise that allows a connection to send 1 additional segment per ACK relative to the packet conservation bound when the ACK indicates that recovery is proceeding well without further losses.
Performance Balance
From the perspective of the strict packet conservation bound:
- PRR-SSRB does open the window during recovery
- But it is much less aggressive than [RFC6675] in the presence of burst losses
- It outperforms the latter due to the lower probability of additional losses during recovery
Practical Effect: PRR-SSRB provides better stability than [RFC6675] while maintaining good performance.