Summary

  • FALCON revision 00 samples forward-direction queue and flow-control state while a high-priority return packet travels back along a constructed reverse path; it promises fresher evidence, not a command.
  • Exact-link mapping, deployment gaps, sampling time, unavailable fields, aggregation, trust and local policy bound what that evidence can support.
  • A reroute or rate reduction needs its own applied-state receipt and an independent post-action measurement before leadership can claim improvement.

What arrived early

The proposal starts with a real timing problem. Conventional feedback often samples congestion on the forward path, completes the remaining journey, and only then returns to the sender. The queue that created the signal can also delay the signal. FALCON changes the geometry.

A forward packet, P, records node and ingress/egress interface identifiers. The receiver builds P', a high-priority return packet with an SRv6 segment list intended to traverse the exact reverse of the recorded links. Each capable node then samples the queue used by the monitored forward traffic. The source receives each sample after roughly the one-way propagation delay from that node rather than after the rest of the forward trip plus the return trip.

That is a narrower result than “sub-RTT truth.” Freshness measures the interval between sampling one piece of node state and its arrival at the source. It is not the sampling frequency. Nor is P' a simultaneous photograph: the distant hop is sampled before the near hop as the packet travels back.

Revision 00 was submitted on 28 September 2026 and expires on 1 April 2027. Datatracker records an active individual Internet-Draft in state I-D Exists, without a stream, Area Director, shepherd, standards level or RFC number. Its performance claims are design analysis, not a disclosed implementation or trial.

Reconstructing the link is part of the evidence

The reverse route does not appear merely because the forward packet listed routers. Under ECMP or parallel links, node SIDs are insufficient. The receiver needs a mapping from each recorded node/interface pair to an adjacency SID so that P' reaches the hop on the interface through which P actually left. That mapping is operator-provisioned or learned through a control plane, and its distribution is outside this revision.

An operational record therefore needs the captured node and interface identifiers, the mapping version used to construct the segment list, the member link where aggregation exists, the monitored traffic class and the timestamp. If the monitored flow is rehashed or rerouted, the draft says the old-path state should be discarded.

Partial deployment makes the boundary sharper. A non-capable node does not record itself. The intervening segment is unobserved, and ordinary forwarding there may not reproduce the reverse of the forward path. A gap marker is not cosmetic; it limits the section of the path to which a root-cause claim can attach.

Two queues, two questions

FALCON distinguishes the Forward Queue from the Flow-Control Buffer. The first is the egress queue for the monitored class on the forward interface. The second is receiving-side buffer accounting that can trigger PFC or another hop-by-hop throttle. A deep Forward Queue does not by itself show how close a node is to throttling its upstream neighbour, because the trigger can use different accounting and a dynamic threshold.

With both records, a source may infer that a large queue not itself throttled is a congestion root while upstream queues stopped by backpressure are victims. But the inference is scoped to the sampled path, class, instant and fields. A node unable to expose a requested value should mark it unavailable. Silence must not be promoted into a zero.

Aggregation trades detail for bounded packet size. A running sum can report path queuing delay; a maximum can retain a bottleneck value and node identifier; a minimum can preserve least headroom. These are useful summaries, but they cannot later answer every per-hop question that the discarded list might have answered.

A notification is not an instruction

The draft passes per-hop state, delay and bottleneck information to a congestion-control or load-balancing function, then explicitly leaves the reaction out of scope. Its companion FANN framework is even clearer: detection, generation, delivery, consumption, action and recovery are separate stages, and a notification is action-agnostic.

That separation is operationally necessary. A controller may reduce rate, avoid a link, move a flow, wait for a second sample or do nothing because application priority, path diversity, cost and stability rules point elsewhere. Multiple sources reacting identically to the same apparently better alternative can create a new hotspot. The earliest warning does not own the routing table.

The fast lane is also an attack surface

P' receives high-priority treatment so that the return queue does not erase the freshness advantage. That priority is locally mapped from DSCP and must be reserved, bounded and policed. Otherwise ordinary traffic can claim it, or notification volume can starve other critical traffic.

Forged or modified returns could trigger unnecessary rate cuts or a worse path. The source should match a return to an outstanding P, for example with a nonce. The receiver must validate that every SID belongs to the local domain, preserve the forward source as the final destination and rate-limit generation. IOAM integrity protection can reduce tampering; it cannot prove that the selected action is wise.

FALCON is confined to a single administrative SR and IOAM domain. Boundary filtering, controlled disclosure and local trust policy are part of the mechanism, not deployment polish. Queue depths, topology and flow-control thresholds can themselves be sensitive.