[davidbell217]

Fixes #14092.

The cumulative-ACK removal loop in handleRcvdSegment skips the Outstanding decrement for previously-SACKed segments, on the premise that SetPipe() already accounted for them. That premise only holds during loss recovery — SetPipe() is a no-op otherwise — so a segment SACKed outside recovery (benign reordering, RACK correctly declaring no loss) and then cumulatively ACKed leaks its packet count into Outstanding permanently. On long-lived bulk transfers over reordering-but-lossless paths the phantoms accumulate until sendData's Outstanding < SndCwnd gate throttles a healthy connection (details and repro in the issue).

The fix: track packets newly SACKed while no recovery is in progress in a sender-local counter (sackedOutsideRecovery), consume it when those segments are cumulatively ACKed, and reset it wherever Outstanding is recomputed or reset wholesale (recovery entry, RTO, full window drain). Recovery-path accounting is unchanged.

Why not something simpler — both obvious one-line shapes were implemented and measured, and each breaks an existing test for a legitimate reason:

• Decrement unconditionally in the removal loop's SACKed branch (the shape originally suggested in the issue): double-subtracts segments SetPipe() already accounted for — SACKed during recovery, cumulatively ACKed at/after exit, where leaveRecovery has already run before the removal loop. Breaks TestSACKRecovery (post-recovery pacing sends beyond the expected window).
• Decrement at SACK arrival (in walkSACK): frees congestion-window slots before the cumulative ACK — effectively unbounded limited transmit — and only covers RACK-enabled senders. Breaks TestRACKWithWindowFull (a transmission observed after a zero-window ACK).

The counter shape keeps the conservative cumulative-ACK release point, never touches segments SetPipe() accounted for, and works with RACK on or off.

Verification

• New regression test TestSACKedThenAckedSegmentLeavesOutstanding (both RACK on and off): fails before the fix with Outstanding = 3, want 2 — exactly one phantom packet after a SACKed-then-cumulatively-ACKed segment — and passes with it.
• tcp_sack_test.go and tcp_rack_test.go e2e suites pass with the fix.
• In the reordering testbench from the issue (195 ms RTT, ±15 ms jitter, 3 % reordering, zero loss, netstack-to-netstack): wedged transfers drop from 12/12 to 3-4/12 with this fix alone (the residual is the separate spurious-recovery-response gap, filed separately).

Assisted-by: Claude Code

[tamird]

Could we skip segments that end at or before sb.Start here? Inserting this SACK block cannot change whether those segments are covered. The sender still walks past them to find the block, but it can skip both the append and the second scoreboard lookup. A partially overlapping segment still needs both checks because adjacent SACK blocks can merge.

I timed one new SACK near the end of a 128-segment send queue in handleRcvdSegment, with RACK disabled. stock is this PR and fixed adds the overlap check.

                                                │    stock     │               fixed                │
                                                │    sec/op    │   sec/op     vs base               │
SACKAccountingQualification/queue=128/sack=far    3604.5n ± 1%   937.2n ± 5%  -74.00% (p=0.000 n=8)

Allocations fell from seven to two per ACK. Both versions gave the same Outstanding count for duplicate and partially overlapping blocks, including across sequence-number wrap. One-line change · Benchmark and controls.

Posted by Codex on behalf of @tamird.

[adios-404]

In my reordering runs (RACK on, 25% of data packets held 15 µs, no loss) this PR cut the median 20 MB fetch from 2.47 s to 0.254 s.

I rebased it onto master 5f7e73a and added tamird's review change (skip segments that end at or before sb.Start). Only tcp_sack_test.go conflicted.

Two more changes. After a timeout the scoreboard is empty, so the peer's SACKs for earlier segments look new, and they were subtracted from Outstanding after the timeout had zeroed it. The walk now stops at writeNext, with a test. And the regression test runs on a manual clock: on master its RACK case failed without the fix in only 22 of 30 runs.

bazel test //pkg/tcpip/transport/tcp/... passes (27 of 27).

David, will you update this PR, or are you happy for me to open the rebased copy with you kept as the author and tamird credited?

[davidbell217]

In my reordering runs (RACK on, 25% of data packets held 15 µs, no loss) this PR cut the median 20 MB fetch from 2.47 s to 0.254 s.

I rebased it onto master 5f7e73a and added tamird's review change (skip segments that end at or before sb.Start). Only tcp_sack_test.go conflicted.

Two more changes. After a timeout the scoreboard is empty, so the peer's SACKs for earlier segments look new, and they were subtracted from Outstanding after the timeout had zeroed it. The walk now stops at writeNext, with a test. And the regression test runs on a manual clock: on master its RACK case failed without the fix in only 22 of 30 runs.

bazel test //pkg/tcpip/transport/tcp/... passes (27 of 27).

David, will you update this PR, or are you happy for me to open the rebased copy with you kept as the author and tamird credited?

Thanks @adios-404, and thanks @tamird for the review. Please go ahead and open the rebased copy. Link it here and I'll close this one once it's up.

[adios-404]

Opened as #17684, with you as the author. Thanks, David.