Skip to content

CONCEPT Cited by 1 source

False idle detection

Definition

False idle detection is the failure mode where a congestion controller (or any rate-adaptive transport component) concludes that its peer / application has stopped sending, when in fact the peer is still trying to send but is rate-limited by a small window, small buffer, or another steady-state constraint.

The structural cause: the controller picks a cheap proxy signal for "idle" (e.g. "the send buffer is empty", "bytes in flight is zero", "no recent write()") that is correct at large windows and wrong at minimum windows, because at minimum windows the same signal fires every RTT from normal rate-limited operation.

Canonical wiki instance

The 2026-05-12 Cloudflare quiche post (Source: sources/2026-05-12-cloudflare-when-idle-isnt-idle-how-a-linux-kernel-optimization-became-a-quic-bug) is the canonical instance. quiche's 2020 port of Linux TCP CUBIC's after-idle adjustment used bytes_in_flight == 0 as the idle predicate inside on_packet_sent(). The signal is true when:

  • Case A — application genuinely idle. The peer hasn't had data to send for a while; both bytes_in_flight and last_ack_time are old. CUBIC should shift its epoch forward by the idle duration to preserve the growth-curve shape.
  • Case B — congestion-limited (false idle). cwnd has collapsed to the two-packet minimum after a loss event. Every round trip, both packets are ACKed, bytes_in_flight momentarily drops to zero, then the next burst goes out. The application has data, the peer is processing ACKs, and the network is idle for microseconds — not seconds.

The 2020 quiche port conflated A and B. When triggered by B at minimum cwnd, it fed delta = now − last_sent_time ≈ RTT into CUBIC's epoch adjustment as if it were idle duration, pushing the recovery boundary into the future on every send and triggering the CUBIC minimum-cwnd death spiral.

Why it's a recurring design hazard

The post names the underlying lesson explicitly:

"'Idle' is harder to define than it sounds. Normal pipeline delays at small windows can look like idleness to simple checks."

Three structural reasons false idle detection is hard to get right:

  1. The signal is ambiguous at the boundary. Any signal based on "current occupancy" (bytes-in-flight, queue depth, recent-writes count) is state-dependent, and state-dependence breaks at window corners.
  2. Absence of traffic ≠ absence of work. A peer at minimum cwnd wanting to send a GB of data produces the same instantaneous signal as a peer that has sent nothing for an hour.
  3. Measurement anchors matter. "Time since last send" and "time since last ACK" are different measurements — the 2026 quiche fix hinges on using max(last_ack_time, last_sent_time) so that the most-recent activity (either direction) anchors the idle calculation.

The corrective pattern

Use the most recent activity timestamp across both directions, not just one. The 2026 fix to quiche is the canonical instance:

let idle_start = cmp::max(cubic.last_ack_time, cubic.last_sent_time);

See patterns/measure-idle-from-last-ack-not-last-send for the full pattern. This generalises beyond CCAs: any rate- limiter / quota-bucket / window-tracker that wants to distinguish genuine idleness from steady-state rate-limited operation should anchor on the most-recent activity signal, not on the most-recent "drain" signal.

  • Application "send buffer empty" callbacks. Fires both on genuine idleness and on small-window saturation.
  • TCP SO_SNDBUF drain detection. Same ambiguity — the application's buffer empties naturally on small-window operation and on genuine idle.
  • Pacing timers. A pacing interval that elapses "with no sends" may reflect either "no data to send" or "network refused data" — indistinguishable without a secondary measurement.

Seen in

Last updated · 542 distilled / 1,571 read