Skip to content

CONCEPT Cited by 1 source

ACK clock

Definition

The ACK clock (or self-clocking) is the foundational transport-layer phenomenon by which each round-trip's ACKs from the receiver trigger the sender's next transmission. It is the implicit pacing signal that keeps a well-behaved TCP / QUIC sender in step with the network's actual carrying capacity without requiring an explicit clock — the network itself meters the sender via the rate of returning acknowledgments.

In Van Jacobson's 1988 framing, ACK clocking is what makes loss-based congestion control work at all: the sender transmits a packet, the receiver ACKs it, the ACK triggers another send. At steady state, packets go out at roughly the bottleneck-link's service rate because ACKs come back at that rate.

Canonical diagnostic use: oscillation period matching RTT

The 2026-05-12 Cloudflare quiche CUBIC death-spiral post is a textbook instance of using the ACK clock as a diagnostic fingerprint:

"The key clue is the oscillation period: ~14ms matches the RTT. Whatever is triggering the recovery/avoidance flip is happening once per round trip, in lockstep with the connection's ACK clock; the self-clocking rhythm in which each round-trip's ACKs from the client trigger the server's next send." (Source: sources/2026-05-12-cloudflare-when-idle-isnt-idle-how-a-linux-kernel-optimization-became-a-quic-bug)

The connection's RTT was configured at 10 ms; the observed state-transition period was ~14 ms (configured RTT + ACK-processing variance and scheduler jitter); and this coincidence told the team the trigger was being driven by the ACK clock itself, narrowing the search to bugs that fire on every ACK cycle.

Why ACK-clocked failures are a distinct bug class

Bugs triggered by the ACK clock have a periodic signature that matches RTT — they do not look like random noise, and they do not look like attacker-driven bursts. Three diagnostic properties:

  1. Period ≈ RTT across the whole connection. This pins the trigger to the return-path of ACKs, not to a wall-clock timer or a jitter distribution.
  2. Repeats indefinitely while conditions hold. Because ACKs keep arriving, the trigger keeps firing. The 2026-05-12 instance showed 999 state transitions in 6.7 s.
  3. Disappears when conditions change. When bytes_in_flight no longer reliably reaches zero every ACK (either because cwnd grows or because loss changes the ACK-arrival pattern), the trigger stops firing and the bug's visible symptoms disappear. This is why tests that never drive a CCA into minimum-cwnd miss it.

The ACK clock and download-direction bugs

On a download (server → client), ACKs travel client → server. The server's CCA runs server-side; the server's state machine is what's driven by the ACK clock. The 2026-05-12 post makes this explicit:

"Because this is a download (server to client), the ACKs in question travel client to server, and CUBIC's state machine runs on the server side: every time those ACKs land, bytes_in_flight drops to zero and the server sends the next two-packet burst, which is what triggers the bug."

Pacing vs ACK-clocking

Modern transports layer pacing (an explicit clock that meters sends within an RTT, e.g. cwnd / RTT bytes/s) on top of ACK clocking:

  • ACK-clocking alone produces bursty sends because the sender releases all allowed packets immediately when ACK headroom becomes available.
  • Pacing smooths the bursts by spreading sends across the RTT. Critical on high-bandwidth paths where a full cwnd bursted out faster than the bottleneck link can absorb will cause intermediate-buffer overruns.
  • Both coexist. Pacing sets the rate within an RTT; ACK clocking sets the rate across RTTs.

Seen in

Last updated · 542 distilled / 1,571 read