TCP PRR RFC 6937: Loss Recovery, FlightSize Regulation & VPN Pacing

High-speed encrypted transit corridors and commercial virtual private networks rely on the Transmission Control Protocol (TCP) to move data reliably. When packets traverse multi-hop internet paths, cellular links, or lossy Wi-Fi networks, transient drops inevitably occur. How the transport layer handles these packet drops determines whether applications experience an imperceptible micro-pause or an abrupt throughput freeze accompanied by latency spikes.

For nearly two decades, standard congestion control relied on legacy Fast Recovery mechanisms defined in RFC 3517 and RFC 5681. These algorithms suffered from a structural flaw: upon detecting loss, they enforced transmission silence followed by packet bursts, creating disruptive pipeline stalls. Standardized in RFC 6937, Proportional Rate Reduction (PRR) re-engineers TCP loss recovery by pacing packet transmissions dynamically throughout the recovery episode, eliminating artificial pauses and stabilizing transport performance.

The Pipeline Bubble Dilemma: How Classic Fast Recovery Freezes High-Speed TCP

In classical TCP congestion control, detecting packet loss via three duplicate ACKs signals that the network pipe cannot support the current Congestion Window (CWND). The protocol reacts by cutting CWND in half to establish a new slow-start threshold (ssthresh). While reducing sending rate is essential to relieve congested buffers, the legacy implementation method introduced severe side effects.

Under RFC 3517 and RFC 5681, the sender calculates FlightSize—the volume of unacknowledged data in transit. When loss occurs, FlightSize often exceeds the newly reduced ssthresh target:

Loss Event Detected:
  Initial State: CWND = 40 packets, FlightSize = 40 packets
  Target State : ssthresh = 20 packets

Legacy Fast Recovery Response:
  Transmission halted completely until FlightSize drops from 40 to 20.
  Duration of silence: Half of one Round-Trip Time (0.5 * RTT).

This enforced silence produces a "pipeline bubble." For up to half an RTT, the sender emits zero packets. The bottleneck queue drains completely, starving intermediate routing nodes. When FlightSize decays to ssthresh, the sender abruptly resumes transmission, dumping a burst of back-to-back packets into the cleared path. This burst re-congests bottleneck buffers, inducing secondary packet drops and Retransmission Timeouts (RTO). In VPN tunnels, these bubbles cause interactive video calls to freeze and game latency to spike.

Mathematical Anatomy of RFC 6937: Proportional Rate Reduction Mechanics

RFC 6937 replaces transmission freezes with continuous, proportional packet pacing. Rather than halting transmission until FlightSize reaches ssthresh, PRR transmits new segments on every received Selective Acknowledgment (SACK), scaling the transmission pace to converge smoothly toward ssthresh over the entire recovery episode.

The algorithm tracks two central state variables:

• prr_delivered: Total volume of newly delivered data acknowledged by incoming SACK blocks since loss recovery began.
• prr_out: Total volume of newly transmitted or retransmitted data emitted since loss recovery began.

The PRR state machine calculates the exact number of bytes allowed to send upon each ACK using a proportional scaling formula:

Target_Ratio = ssthresh / RecoverFS
sndcnt = ceil(prr_delivered * Target_Ratio) - prr_out

RecoverFS represents the initial FlightSize when loss was detected. If ssthresh is half of RecoverFS, PRR sets Target_Ratio = 0.5. Consequently, for every 2 bytes acknowledged by the receiver, the sender immediately transmits 1 byte of data. Transmission never stalls, bottleneck queues drain gradually at a deterministic rate, and the pipe stays smoothly populated.

Boundary Dynamics: Comparing PRR-CRB and PRR-SSRB Operating Modes

While the proportional formula governs standard conditions, real-world network paths experience irregular ACK arrivals, loss of retransmissions, and sequence reordering. To guarantee stability, RFC 6937 specifies two complementary boundary modes: Conservative Rate Bound (CRB) and Slow Start Reduction Bound (SSRB).

+-------------------------------------------------------------+
|                 ACK Processed by TCP Stack                  |
+-------------------------------------------------------------+
                               |
                               v
               [Is FlightSize > ssthresh?]
                /                                    YES                         NO
              /                                        v                             v
+---------------------------+  +------------------------------+
|   Standard PRR or CRB     |  |       PRR-SSRB Mode          |
| sndcnt = min(PRR, Deliv)  |  | sndcnt = min(Deliv+1, Target)|
+---------------------------+  +------------------------------+

Conservative Rate Bound (CRB) for Out-of-Order and Heavy Drop Scenarios

When packet drops are severe or ACKs are delayed, FlightSize may remain significantly above ssthresh. In these circumstances, aggressive transmission could exacerbate buffer overruns. PRR-CRB acts as a safety limiter:

sndcnt = min(sndcnt, Delivered_Data)

PRR-CRB enforces that the sender never transmits more bytes than the receiver explicitly reported as delivered in the current ACK. By matching sending volume to verified departures from the network pipe, CRB prevents sender-induced queuing and protects against reordering anomalies.

Slow Start Reduction Bound (SSRB) for Latency-Sensitive Interactive Workloads

In contrast to severe loss, transient drops can cause FlightSize to plunge well below ssthresh. In classic TCP, an undersized FlightSize triggered conservative single-packet probing, prolonging recovery times.

PRR-SSRB detects when FlightSize < ssthresh and temporarily permits a controlled slow-start acceleration:

sndcnt = min(prr_delivered - prr_out + ssthresh - FlightSize, Max_Burst)

SSRB allows the sender to emit up to two packets for each delivered packet, rapidly rebuilding FlightSize up to ssthresh without inducing packet bursts. This mode proves invaluable for interactive SSH terminals, video conferences, and gaming VPN sessions, restoring target throughput in minimal round trips.

FlightSize vs CWND Synchronization: Eliminating Burstiness and Tail Drops

Classic Fast Recovery implementations frequently adjusted CWND directly during loss recovery, leading to erratic packet releases when exiting recovery. RFC 6937 decouples sndcnt calculation from direct CWND manipulation:

By synchronizing FlightSize continuously, PRR arrives at the exit boundary with FlightSize exactly matching ssthresh. No artificial burst is required upon returning to Congestion Avoidance, eliminating tail drops at recovery exit.

The Interaction of SACK, FACK, and PRR in Modern Linux Networking Stacks

Modern Linux kernels implement PRR as the foundational recovery engine underneath all congestion control algorithms. RFC 6937 depends on Selective Acknowledgment (SACK, RFC 2018 / RFC 6675) to count precisely how many bytes have left the network pipe on each incoming packet.

When Forward Acknowledgment (FACK) is enabled alongside SACK, the kernel accurately maps holes in sequence space, allowing PRR to distinguish between isolated loss events and massive packet drops. PRR calculates prr_delivered directly from newly SACKed contiguous byte blocks, providing precise pacing instructions to Fair Queuing (sch_fq) packet schedulers.

Encapsulation Traps: PRR Behavior Inside WireGuard and IPsec Tunnels

Deploying PRR within VPN environments introduces unique interactions between the inner transport layer and the outer encapsulation wrapper. When client applications communicate over WireGuard, IPsec, or OpenVPN tunnels, inner TCP segments are wrapped inside outer UDP or ESP headers.

Outer MTU Fragmentation and Ephemeral Loss Amplification

If tunnel Path MTU Discovery (PMTUD) is misconfigured or intermediate networks restrict MTU below 1500 bytes, inner TCP segments can trigger outer IP fragmentation. When an outer fragment drops, the entire inner TCP segment is lost:

• A 2% outer fragment drop can translate into a 4% to 8% inner TCP segment loss rate.
• Classic Fast Recovery collapses into repeated RTO states under these conditions.
• PRR mitigates this by maintaining steady packet pacing, preventing outer gateway queues from overflowing and minimizing fragment loss.

Interaction with BBR, CUBIC, and Reno Congestion Control Engines

PRR functions as a modular recovery controller operating beneath congestion control algorithms:

• CUBIC: Uses PRR by default in the Linux kernel (CONFIG_TCP_CONG_CUBIC). When CUBIC reduces window size by 30% upon loss ($eta = 0.7$), PRR paces transmissions with Target_Ratio = 0.7, providing smooth recovery.
• BBR: While BBR models bottleneck bandwidth directly, BBR implementations leverage PRR-inspired pacing principles during drain and probe phases to prevent queue pressure.
• Reno: When traditional loss-based Reno is deployed, PRR halves sending rates gracefully without the characteristic stalls of legacy Reno.

Benchmark Metrics: Latency Distribution and Buffer Draining Efficiency

Extensive production benchmarks demonstrate the measurable benefits of PRR over classic loss recovery across enterprise WAN and VPN connections:

By keeping the packet clock active, PRR prevents the pipeline starvation that historically degraded encrypted tunnel performance.

RiceGuard Pacing Architecture: Low-Jitter Multipath Transport for Global Users

VPNRice integrates PRR principles directly into its high-speed RiceGuard transport infrastructure. RiceGuard edge nodes serve thousands of concurrent encrypted user sessions across global Anycast points of presence.

To deliver uninterrupted gaming, streaming, and enterprise remote desktop connections, RiceGuard optimizes loss recovery at multiple layers:

1. Kernel-Level PRR Pacing: Every RiceGuard edge gateway runs modern Linux kernels tuned with PRR and Fair Queuing (fq), ensuring client packet loss never stalls transit pipelines.
2. Tunnel Buffer Optimization: RiceGuard dynamically calculates Maximum Segment Size (MSS) clamping at tunnel boundaries, preventing the outer fragmentation that disrupts PRR delivered-byte calculations.
3. Continuous ACK Clocking: By sustaining proportional pacing during packet loss, RiceGuard preserves smooth interactive responsiveness, eliminating the noticeable freezes common to conventional VPN services.

This architecture ensures that packet drops on cellular or public Wi-Fi links do not compromise overall connection quality.

Production Tuning Playbook: Kernel Parameters and Tunnel Buffer Optimization

Systems administrators and network architects can verify and optimize PRR performance across production Linux VPN servers using standard sysctl parameters:

• Verify PRR Kernel Support: Confirm that the kernel supports PRR (enabled by default in Linux 3.2+). Verify via /proc/sys/net/ipv4/tcp_congestion_control and ensure SACK is enabled (net.ipv4.tcp_sack = 1).
• Enable Fair Queuing Pacing: Deploy the FQ packet scheduler to enforce per-packet hardware pacing: sysctl -w net.core.default_qdisc = fq.
• Configure MTU and Clamping: Enforce MSS clamping on tunnel interfaces (iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) to prevent outer fragmentation.
• Monitor Loss Recovery Metrics: Inspect TCP recovery counters in real time using nstat -az TcpPrr* and ss -tie to monitor prr_delivered and prr_out behavior.
• Bufferbloat Prevention: Limit maximum socket write buffers (net.ipv4.tcp_wmem) to prevent excessive inflight data accumulation prior to loss events.