Summary

  • Proportional Rate Reduction uses delivery progress reported by each ACK to calculate a bounded transmission allowance, moving actual in-flight data toward a target selected elsewhere instead of treating recovery as one abrupt window cut.
  • That ACK is a narrow operating receipt, not proof that the path has healed; a credible deployment must preserve who selected the target, which PRR branch ran, what was actually sent and whether pacing and outcomes matched the claim.

The endpoint concealed the journey

Consider a TCP sender with twenty segments in flight when loss forces the congestion-control algorithm to choose ten as the recovery target. An older recovery pattern can cut the window immediately, wait while the estimated flight drains, then release several segments together. The worked example in RFC 9937 calls the pause a “half window of silence.” Another estimator discontinuity can create the opposite problem: a sudden allowance and a burst.

Now consider a second sender. It reaches the same target of ten, but it reduces its outstanding data gradually as acknowledgments return. Each ACK permits a measured response. The final arithmetic can look identical while the traffic presented to the network is not.

This was the problem behind Proportional Rate Reduction, or PRR. The 2011 paper by Nandita Dukkipati, Matt Mathis, Yuchung Cheng and Monia Ghobadi examined short flows, application stalls, burst loss, ACK loss and reordering, and stretch ACKs. It reported that legacy mechanisms could over-reduce the window or send large bursts. In that study, PRR and the accompanying early-retransmit work reduced TCP latency for connections experiencing loss by 3–10%, depending on response size. That is a measured historical result, not a promise for every path.

Experimental RFC 6937 followed in 2013, authored by Mathis, Dukkipati and Cheng. In December 2025, Standards Track RFC 9937, by Mathis, Neal Cardwell, Cheng and Dukkipati, replaced it. The line of work matters here collectively. Dukkipati is neither assigned sole invention nor made responsible for every implementation. Her documented role connects the original measurement question to the experiment and then to a revised standard.

Three decisions that should not be collapsed

PRR becomes easier to understand when three decisions remain separate.

First, a congestion-control algorithm chooses ssthresh: the desired amount of data in flight at the end of this recovery episode. Reno, CUBIC or another compatible controller may make that choice. PRR does not decide how severe congestion is, and it does not author the target.

Second, the recovery machinery observes acknowledgments and estimates progress. RFC 9937 defines DeliveredData as the sender's best estimate of how many bytes the current ACK says have reached the receiver since the previous ACK. “Best estimate” is important. An ACK carries evidence from a particular observation surface; it is not a complete diagnosis of the path.

Third, PRR calculates SndCnt, the number of bytes the sender is allowed to transmit in response to that ACK. A separate selection function decides whether those bytes are retransmissions or new data. PRR regulates quantity and timing. It does not choose the content of the release.

This separation is a minimum specification in practice. The common calculation is precise, while future and local choices remain with the modules that possess the relevant state. No ACK is promoted into a universal instruction. No standards document becomes the running endpoint.

Delivered progress becomes a release clock

At the beginning of recovery, the sender records the flight size it believes could be delivered during the episode, called RecoverFS. It also starts two counters: prr_delivered, the accumulated delivery progress, and prr_out, the data transmitted during recovery.

When the estimated data in flight remains above ssthresh, the core proportional calculation asks how much output should have been released so far, given the fraction of the original flight now reported delivered and the smaller target. The sender rounds that allowance upward, subtracts what PRR has already sent, and obtains the next SndCnt.

The result is not a timer announcing that the network is healthy again. It is a receipt-triggered budget. If delivery progress arrives in small steps, releases follow in small steps. If acknowledgments are lost, a later ACK can report more accumulated delivery; the calculation catches up without handing an estimator discontinuity an unlimited burst.

That is the deeper achievement. PRR does not need to know a metaphysical truth about congestion before every send. It uses a narrow, locally verifiable signal for a narrow action. The target remains where the congestion controller put it.

Caution below the target

Losses can reduce the estimated in-flight data below ssthresh. At that point, a strictly conservative sender may recover too slowly, yet blind acceleration can manufacture another loss episode. RFC 9937 handles this with two reduction bounds.

The default Conservative Reduction Bound ties additional output closely to delivered data. The Slow Start Reduction Bound can be one sender maximum segment more aggressive for an ACK that satisfies SafeACK. That flag requires cumulative acknowledgment progress and no new loss indicated by the ACK.

The 2025 revision made this choice adaptive. Research on token-bucket traffic policers had exposed a case the earlier design had not handled well: once tokens are exhausted, a policer may begin dropping at a high rate without first revealing its replenishment rate to the sender. A target inferred from earlier performance may therefore be too optimistic. Conservatism is the default; the extra segment is earned by the specified evidence of progress.

Even here, the name must not outrun the evidence. SafeACK does not mean the path is safe. It means that, for this branch of this recovery calculation, the ACK contains the two facts required for the limited extra allowance.

Completion is not absolution

PRR updates prr_out on every transmission. When the recovery episode completes, the algorithm sets the congestion window to ssthresh. That makes the endpoint explicit, but RFC 9937 also records an uncomfortable boundary: the completion step can permit a back-to-back burst in some scenarios. It recommends pacing to reduce burstiness.

The specification therefore does not declare victory over every timing hazard. Nor does it claim that the softer pacing effects sometimes associated with PRR have all been quantified. It presents an algorithm, interfaces and known limits.

RFC 9937 records that PRR has served as Linux TCP's fast-recovery algorithm for its default and supported congestion-control modules since the first widely deployed implementation in 2011. That is significant implementation history. It still does not prove which branch a particular kernel executed yesterday, whether pacing was active, or whether a given service saw the paper's latency effect.

The receipt an operator should retain

A defensible PRR claim begins with an episode record, not a product label. It should identify the transport build and congestion-control module; the loss-detection trigger; starting cwnd, inflight and RecoverFS; and the component and configuration that selected ssthresh.

For each relevant ACK, the record should retain cumulative progress, newly reported loss, DeliveredData, the SafeACK result and reason, the selected proportional, CRB or SSRB branch, calculated SndCnt, bytes actually sent and resulting prr_out. It should also identify the separate choice between retransmission and new data.

At completion, the operator needs the final window and in-flight estimates, pacing state, any burst, timeout or repeated loss, and the latency and goodput distributions for a comparable control cohort. Tests should include reordering, application stalls, SACK and non-SACK cases where supported, and token-bucket policing. Negative evidence belongs in the record: ACK progress can continue while path or application outcomes remain poor.

That ledger preserves the hierarchy of claims. The ACK observed delivery. The congestion controller chose a target. PRR computed a release. Another function chose bytes. Running code sent them. Measurements, not the RFC title, establish the outcome.

Sources