Summary

  • RFC 9937 standardizes Proportional Rate Reduction for fast recovery. It uses a sender's estimates and the congestion-control algorithm's ssthresh target to decide how much that sender may send after an ACK.
  • That allowance is not evidence that the path is clear, that a shared bottleneck has spare capacity, that the receiving application completed work or that a service has recovered.

The incident channel offered a familiar shortcut: losses had occurred, the receiver was acknowledging again, the sender was transmitting again, and the flight estimate was converging. Someone called the route “back.”

That word hides the useful boundary in RFC 9937, Proportional Rate Reduction (PRR). The December 2025 Standards Track document replaces Experimental RFC 6937. Its job is narrow: regulate data sent by TCP or another transport protocol during fast recovery so that the actual flight size ends as close as possible to the ssthresh selected by the congestion-control algorithm.

The algorithm does not discover an objective recovery truth. It works with a sender's best estimates. DeliveredData estimates what the current ACK indicates was delivered since the previous ACK. inflight estimates outstanding data. RecoverFS estimates what might be delivered over this recovery episode. The chosen congestion controller supplies ssthresh; PRR does not choose the business meaning of that target, reserve it from competing traffic or certify it as safe.

An ACK is an input to local arithmetic

For each relevant ACK, PRR updates recovery counters, computes SafeACK, and derives SndCnt: the number of bytes the sender should send in response. Above the target, it proportions sending to delivered data and ssthresh. Below it, PRR uses a conservative reduction bound, or—when the ACK indicates good progress—a bound that may permit up to one extra segment. At completion it sets cwnd to ssthresh; RFC 9937 separately recommends pacing because that step can in some circumstances create a burst.

Those are excellent reasons to retain the inputs and decision. They are not grounds to collapse them into “the network recovered.” SACK makes the accounting more accurate, but the document does not require SACK. Different loss detectors can supply the delivered/lost information. A non-SACK case even needs a guard against a receiver inflating the sender's delivered-data estimate through extraneous duplicate ACKs. A local calculation can be careful and still be bounded by the evidence it received.

RFC 9937 is also explicit about scope. Incremental deployment changes the sender's transport implementation; it requires no change to receivers or networks. PRR may work with Reno or CUBIC, but fairness remains determined by the congestion-control algorithm. The recovery scheduler has not acquired authority over a receiver's application, another operator's queue, a traffic policer or a customer consequence.

Keep a recovery receipt

Operations should preserve a small receipt instead of a large green assertion: the selected congestion controller and version, the target ssthresh, ACK/SACK and loss-detector observations, DeliveredData, inflight, RecoverFS, SafeACK, SndCnt, retransmission and pacing choices, receiver-window and application limits, then an independent observation after the recovery episode. That record lets a later reviewer distinguish a permitted transmission from a measured reduction in loss, queueing or user harm.

Heng Lu's Running-Code Primacy is useful precisely here. Running code can establish the state it actually computes and enforces. It cannot, by naming an estimate “recovery,” create the path-wide fact or service authority that would require evidence outside one endpoint. Later decisions—admission, alert closure, capacity planning and customer communication—remain local decisions for the parties carrying their consequences.

Sources