TCP SACK RFC 6675: Conservative Loss Recovery and Pipe Control in VPNs

Modern encrypted tunnels operate across unpredictable media, including interference-prone Wi-Fi, cellular handovers, and high-latency routing paths. Under these conditions, packet drops rarely occur as isolated mishaps. Instead, transient queue bursts and radio fading cause multiple segment losses within a single round-trip time (RTT).

Under legacy cumulative acknowledgment architectures—such as TCP Reno and NewReno in RFC 5681—recovering from multiple dropped segments requires successive round-trip intervals. Because standard cumulative acknowledgments report only the highest contiguous sequence number, the sender cannot identify non-contiguous delivered segments. Consequently, the transmission pipeline repeatedly stalls, frequently tumbling into an expensive Retransmission Timeout (RTO) that decimates sustained throughput.

To resolve this limitation, the Internet Engineering Task Force (IETF) codified RFC 6675: A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP (obsoleting RFC 3517). Using the explicit sequence block notifications defined in RFC 2018, RFC 6675 establishes a rigorous mathematical accounting model known as the Pipe algorithm. This specification allows a sender to identify and repair multiple dropped packets in a single RTT, maintaining continuous pipeline clocking and preventing throughput collapse over high-loss VPN links.

[Legacy TCP Reno: One Loss per Round-Trip Iteration]
Sender: Transmits Segments 1, 2, 3, 4, 5, 6, 7, 8
Network: Drops Segment 2 and Segment 5
Receiver: Receives 1, 3, 4, 6, 7, 8 -> Generates DupACKs acknowledging Segment 1
Sender: Retransmits Segment 2 after 3 DupACKs
Receiver: Receives retransmitted Segment 2 -> Emits partial ACK for Segment 4 (stops at gap 5)
Sender: Retransmits Segment 5 only after a full RTT delay!
Result: Two RTTs required; high probability of timer expiration and link stall

[RFC 6675 SACK Conservative Loss Recovery: Instant Multi-Loss Repair]
Sender: Transmits Segments 1, 2, 3, 4, 5, 6, 7, 8
Network: Drops Segment 2 and Segment 5
Receiver: Emits SACK blocks: [3-4], [6-8] (Acknowledging non-contiguous arrivals)
Sender: Computes Pipe; IsLost() confirms Segments 2 and 5 are missing simultaneously
Sender: Retransmits BOTH Segment 2 and Segment 5 within the current RTT!
Receiver: Receives both segments -> Immediately emits cumulative ACK for Segment 8
Result: Zero pipeline stalls; full congestion window utilized without timeout

The Multi-Packet Drop Dilemma: Why Reno Stalls in High-Loss Networks

In transport protocol engineering, the efficiency of loss recovery determines real-world throughput far more than peak wire capacity. When a connection experiences packet drops, the sender must distinguish between minor packet reordering and actual physical frame destruction.

The Limits of Classic Fast Retransmit: One Loss per Round-Trip Time

Classic TCP Fast Retransmit operates on a threshold of three duplicate acknowledgments (DupThresh = 3). While effective for single drops, its diagnostic capability degrades catastrophically when an enterprise link drops two or more packets out of a single flight:

                    ┌─────────────────────────┐
                    │    TCP Sender Window    │
                    └────────────┬────────────┘
                                 │
           ┌─────────────────────┴─────────────────────┐
           ▼                                           ▼
[Reno / NewReno Pipeline]                    [RFC 6675 SACK Pipeline]
  - Tracks single HighACK                     - Computes explicit Pipe variable
  - Partial ACK triggers 1 repair             - Identifies all gaps in single flight
  - Multi-drop requires N * RTT               - Re-injects missing data immediately
  - Risk of RTO: VERY HIGH                    - Risk of RTO: MINIMAL
  - Throughput: Drops to crawl                - Throughput: Sustained line-rate

When Reno receives a partial acknowledgment, it cannot determine whether subsequent packets in the flight were delivered or lost. The sender must wait another full round-trip delay to receive feedback on the next sequence hole. If the sender congestion window is small, there are insufficient subsequent packets in flight to generate three duplicate ACKs for the second lost segment, guaranteeing an RTO collapse.

Pipeline Freezes and Spurious Timeouts in Encrypted VPN Tunnels

When transport traffic is encapsulated within secure VPN tunnels, multi-packet drop events produce compounded penalties:

1. Head-of-Line Blocking: In tunnel sessions, application buffers freeze while waiting for stream gaps to fill.
2. Buffer Jitter: As packets stall, encryption contexts queue up, escalating host memory consumption.
3. Timer Expirations: When cumulative ACKs freeze, the RTO timer expires, collapsing cwnd to 1 MSS and resetting ssthresh.
4. Throughput Oscillation: The tunnel oscillates between line-rate bursts and deadlocks, degrading interactive streaming, voice, and database replication.

Architectural Foundations of RFC 6675: The Mathematical Pipe Model

RFC 6675 transforms loss recovery from a guessing game into a deterministic calculation. Central to this specification is the Pipe variable, which provides an estimate of the total data volume currently traveling through the network.

                    HighData (Highest Sequence Number Sent)
                     │
                     ▼
  ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
  │  1  │  2  │  3  │  4  │  5  │  6  │  7  │  8  │  Segments in Flight
  └─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘
     ▲     ▲     ▲     ▲     ▲     ▲     ▲     ▲
     │     │     │     │     │     │     │     │
  HighACK  │  [SACK Block 1] │  [SACK Block 2]     │
           │                 │                     │
           └── Lost (Hole)   └── Lost (Hole)       └── Not Yet SACKed

  RFC 6675 Pipe Calculation:
  Pipe = (HighData - HighACK) - SACKedBytes - LostBytes + RetransBytes

The Pipe Variable: HighData, HighACK, and Exact In-Flight Accounting

The sender maintains exact state variables governing the boundary of transmitted information:

• HighData: The highest sequence number transmitted by the sender so far.
• HighACK: The highest cumulative sequence number acknowledged by the receiver.
• HighRxt: The highest sequence number among all segments retransmitted during the current recovery episode.
• Pipe: The exact number of unacknowledged octets presumed to be actively consuming network resources.

The fundamental invariant of RFC 6675 dictates that data transmission must strictly respect the congestion window:

$$\text{Pipe} < \text{cwnd}$$

Only when Pipe falls below cwnd is the sender permitted to transmit additional data segments into the network.

IsLost() and SetPipe(): Identifying Packet Holes Without Guesswork

To determine which segments are lost, RFC 6675 introduces the deterministic routine IsLost(SeqNum):

1. A segment is declared lost if more than DupThresh (default 3) segments with sequence numbers higher than SeqNum have been selectively acknowledged by the receiver.
2. A segment is also declared lost if an acknowledgment confirms octets at least $(\text{DupThresh} - 1) \times \text{MSS}$ higher than SeqNum.

The SetPipe() routine traverses the scoreboard of unacknowledged data, deducting both SACKed bytes and confirmed lost bytes from the nominal flight size while adding back active retransmissions:

$$\text{Pipe} = (\text{HighData} - \text{HighACK}) - \text{SACKed} - \text{Lost} + \text{Retrans}$$

By isolating verified losses from delivered segments, the sender calculates the available capacity in the pipe with precision.

NextSeg() Decision Engine: SACK Loss Recovery in Action

When Pipe < cwnd, the sender core engine calls NextSeg() to select the next packet to transmit. This decision engine enforces strict prioritization rules.

              ┌────────────────────────────────┐
              │     Incoming ACK with SACK     │
              └───────────────┬────────────────┘
                              │
                              ▼
              ┌────────────────────────────────┐
              │    Update Scoreboard & Pipe    │
              └───────────────┬────────────────┘
                              │
                              ▼
                      Is Pipe < cwnd?
                              │
              ┌───────────────┴───────────────┐
              ▼                               ▼
            [No]                            [Yes]
              │                               │
              ▼                               ▼
       Inhibit Sending              Execute NextSeg() Engine
                                              │
                              ┌───────────────┴───────────────┐
                              ▼                               ▼
                     [Lost Segment Exists?]         [No Unsent Lost Segments]
                              │                               │
                              ▼                               ▼
                     Retransmit Lowest Hole         Transmit New Data Segment
                     Update HighRxt                 (HighData + 1)

Prioritizing Retransmissions Over New Data: Preserving Flow Conservation

The NextSeg() algorithm adheres to three sequential rules:

1. Lost Data Rule: If there are segments marked as lost by IsLost() that have not yet been retransmitted in the current recovery episode, NextSeg() returns the lowest sequence number among them. Repairing missing data always takes absolute priority over transmitting fresh application payload.
2. New Data Rule: If no lost segments remain eligible for retransmission, and Pipe < cwnd, the sender transmits fresh data starting at HighData + 1. This maintains flow conservation and prevents pipeline draining.
3. Re-retransmission Protection: Any segment already retransmitted in the current recovery episode whose highest byte is $\le \text{HighRxt}$ is skipped unless specifically declared lost again by subsequent SACK feedback.

Rescue Retransmissions: Preventing Tail Drop Stalls in Narrow Windows

A subtle edge case occurs when packet drops happen at the tail of a small window. If a connection with a window of 4 packets loses the last 2, the receiver returns at most 1 DupACK with a SACK block. In this scenario, IsLost() never reaches 3 SACKed segments, and Pipe equals cwnd, causing the connection to freeze until RTO timeout.

RFC 6675 resolves this through Rescue Retransmissions:

• If Pipe < cwnd, no lost segments exist under IsLost(), and no new data is available, the sender may retransmit a single unacknowledged segment from the flight tail.
• This rescue packet elicits a fresh SACK acknowledgment from the receiver, generating the ACK clocking needed to resolve ambiguity and prevent an RTO stall.

Enterprise Kernel Architecture: RiceGuard High-Loss Transport Optimization

To deliver high-speed performance across turbulent networks, VPNRice incorporates RFC 6675 deep inside its transport pipeline through RiceGuard:

                    ┌─────────────────────────┐
                    │    Application Traffic  │
                    └────────────┬────────────┘
                                 │
                    ┌────────────▼────────────┐
                    │     RiceGuard Core      │
                    └──────┬───────────┬──────┘
                           │           │
          ┌────────────────▼───┐   ┌───▼────────────────┐
          │ RFC 6675 Pipe Engine│   │ Anti-Loss Scheduler│
          └────────────────┬───┘   └───┬────────────────┘
                           │           │
                    ┌──────▼───────────▼──────┐
                    │ Encrypted L3 VPN Tunnel │
                    └─────────────────────────┘

1. Dynamic Scoreboard Management: RiceGuard maintains high-speed bitmapped scoreboards in kernel space, eliminating memory allocation overhead during high-volume SACK processing.
2. SACK Exhaustion Hardening: In compliance with security guidelines, RiceGuard implements robust verification against malformed SACK sequence storms, preventing denial-of-service vulnerabilities (such as CVE-2019-11477).
3. Synergy with PRR and BBR: RiceGuard integrates RFC 6675 pipe accounting with Proportional Rate Reduction (RFC 6937) and BBR congestion control, ensuring smooth pacing and preventing packet bursts during multi-drop recovery phases.

Diagnostic Auditing: Verifying SACK Pipe Telemetry on Linux Gateways

Network administrators can inspect and audit TCP SACK recovery operations on modern Linux distributions using standard socket diagnostics.

Inspecting SACK Blocks and Pipe Metrics with the ss Utility

The ss utility exposes deep TCP internal state variables for active connections:

# Query active HTTPS and VPN transport sockets with internal TCP metrics
ss -tin "sport = :443 or dport = :443"

Key output fields to monitor during loss recovery:

• sack: Verifies that SACK negotiation succeeded during the initial three-way handshake.
• retrans: Current count of retransmitted segments in flight.
• lost: Number of segments classified as lost by the kernel loss detector.
• sacked: Number of segments confirmed delivered via SACK scoreboard blocks.
• cwnd and ssthresh: Real-time values of the congestion window and slow-start threshold.

Sysctl Tuning and Kernel Parameters for net.ipv4.tcp_sack

The Linux kernel implements RFC 6675 principles through core sysctl parameters in /proc/sys/net/ipv4/:

# Verify that SACK support is enabled
sysctl net.ipv4.tcp_sack

# Enable standard SACK processing (default is 1)
sudo sysctl -w net.ipv4.tcp_sack=1

# Enable duplicate SACK (DSACK, RFC 2883) for enhanced loss disambiguation
sudo sysctl -w net.ipv4.tcp_dsack=1

# Verify host-wide SACK recovery statistics
cat /proc/net/netstat | grep -E "TCPSackRecovery|TCPSackFailures"

In the /proc/net/netstat telemetry output:

• TCPSackRecovery: Number of successful recovery episodes driven by SACK scoreboard processing.
• TCPSackFailures: Number of times SACK recovery failed to repair losses and fell back to an RTO timeout.
• TCPSackRecoveryFail: Recovery episodes aborted due to window constraints or receiver reneging.

Production Benchmarks: Throughput Resilience Under Packet Loss

In rigorous testbed evaluations simulating international enterprise tunnels subjected to random packet loss and latency variations, RFC 6675 demonstrates decisive superiority over legacy recovery schemes:

By replacing blind guesses with exact pipe tracking and targeted multi-segment repairs, RFC 6675 guarantees that encrypted VPN tunnels remain fast, reliable, and immune to throughput collapse over imperfect physical links. Combined with modern transport engineering, SACK loss recovery provides the bedrock for continuous, low-latency enterprise communication.

Get VPNRice.