TCP_QUICKACK Lab: Delayed ACK, Set-Once, and the Reassert Trap

Intro — what this post promises

TCP_QUICKACK is the ACK-side twin of the Nagle / TCP_NODELAY story. Folklore says “turn on quickack to kill delayed ACK.” On Linux the option is best-effort, often not sticky, and on this loopback the default already reported 1.

This is a hands-on lab with measured numbers:

1. What getsockopt(TCP_QUICKACK) returns after connect and after one echo.
2. Reuse 1-byte echo matrix: Nagle vs TCP_NODELAY × default / set-once quickack.
3. Write-write-read (WWR): set-once qa0 vs qa1 vs reassert after every send.
4. Many tiny writes: OutSegs deltas when you thrash quickack under Nagle.
5. How this sits next to the TCP_NODELAY lab (sender coalesce ≠ ACK policy).

Related links:

• TCP_NODELAY vs Nagle localhost lab
• Unix Domain Socket vs TCP localhost lab
• Why your average latency graph is lying (p50 / p95 / p99)
• HTTP Keep-Alive vs Connection: close lab

Lab honesty (1 Oct 2026 IST): Shared Linux lab box (8 cores, kernel 6.12). Python 3.13.5 TCP echo on 127.0.0.1. No Docker. No public bind. Affiliates: 0. This is a loopback microbench, not a WAN delayed-ACK capture.

Verdict up front: default QUICKACK after connect was 1. WWR under Nagle with set-once qa0/qa1 stayed ~18–20 µs p50. Reasserting QUICKACK=1 after every send under Nagle blew mean to ~12 ms (mean/p50 ~326×, p95 ~48 ms) and ~13× more OutSegs on multi-write.

What TCP_QUICKACK actually changes

Delayed ACK lets a receiver wait briefly before acknowledging a single small segment, hoping to piggyback on a reverse data segment. TCP_QUICKACK asks the stack for quick acknowledgements. On Linux it is documented as a mode that the stack may clear — not a permanent “disable delayed ACK forever” switch.

Related links:

• man 7 tcp — TCP_QUICKACK
• TCP_NODELAY vs Nagle localhost lab

Lab topology

Echo server + client on 127.0.0.1
Arms: reuse 1 B · WWR (2×32 B then read) · multi 16×8 B
QUICKACK modes: untouched default · set-once 0/1 · reassert 0/1 after each send
Also: getsockopt probe; /proc/net/snmp OutSegs Δ on multi-write

Probe: after create_connection, getsockopt(TCP_QUICKACK) returned 1. Set to 0 → 0. Set to 1 → 1. After one echo it still read 1.

Arm A — reuse 1-byte echo

n=2000 timed RTTs (after warmup):

On this chatty reuse shape, NODELAY still mattered more than set-once quickack. Default QA already looked “on.”

Arm B — write-write-read (the delayed-ACK shape)

Two 32 B writes, then one read. Classic place Nagle waits on an ACK.

Set-once qa0 vs qa1: both fine; no classic ~40 ms stall on this loopback. The failure mode we actually hit was reasserting QUICKACK=1 after every send under Nagle — p95 jumped into the tens of milliseconds and mean lied hard.

Stability×3 for WWR Nagle qa0 once p50: 18.9 / 31.3 / 17.6 µs (median 18.9).

Related links:

• Why your average latency graph is lying (p50 / p95 / p99)

Arm C — multi tiny writes + OutSegs

16 writes of 8 B, then drain. n=500.

Reassert-qa1 under Nagle did not “fix latency”; it fragmented the session (far more segments) and collapsed RPS. NODELAY still emitted more segments than Nagle set-once — same qualitative story as the NODELAY lab.

How to read these numbers

• Default QUICKACK=1 on this stack after connect — “enable quickack” is not always a change.
• Set-once qa0/qa1 barely moved WWR on loopback; do not paste WAN 40 ms folklore as our result.
• Reassert every write is a different experiment — and it was the pathological arm here.
• Pair with p95 / mean÷p50, not only p50, before declaring victory.

Pitfalls we hit (or avoided)

1. Assuming QUICKACK is sticky — man page says the stack may switch modes; reassert behavior is its own hazard.
2. Expecting a 40 ms localhost stall from set-once qa0 — we did not see it; honesty over folklore.
3. Thrashing setsockopt(QUICKACK,1) in a hot send loop — measured disaster under Nagle.
4. Confusing ACK policy with Nagle — fix the write pattern / NODELAY / buffering first.
5. Reporting only mean — reassert arm’s mean/p50 gap is the teachable failure.

Practical checklist

• getsockopt(TCP_QUICKACK) after connect before claiming defaults.
• Prefer app buffering or careful NODELAY over ACK-knob folklore for tiny writes.
• If you set QUICKACK, prefer set-once (or after known quiet points), not every send.
• Publish p50 + p95 + mean/p50 for WWR-shaped RPCs.
• Same-host µs paths: also consider UDS (separate lab).

Related links:

• Unix Domain Socket vs TCP localhost lab

Verdict

On this loopback box, TCP_QUICKACK defaults to 1 after connect. WWR under Nagle with set-once qa0/qa1 stayed ~18–20 µs p50. Reasserting QUICKACK=1 after every send under Nagle produced mean ~12 ms, p95 ~48 ms, and ~13× OutSegs on multi-write. Treat quickack as a sharp, best-effort tool — not a hot-path toggle.

Evidence path on the lab box: lab-evidence/30-tcp-quickack/results/. Affiliates: 0.