Summary

  • RFC 8084 requires a circuit breaker to observe a defined flow or aggregate within a metered ingress/egress section, compare it with a threshold across multiple intervals, and react only when the excessive condition persists.
  • A resulting trip proves neither the cause nor the location of a fault. The RFC expressly allows that the cause may not be evident at the source and that an application may not know that, or where, the breaker triggered.

An operations screen can make a trip look like an explanation. One status line turns red, a flow is stopped, and the phrase “congestion event” seems to supply a culprit. It does not. A circuit breaker is a deliberately narrow safety device. Its strength is that it can act when a bounded measurement has crossed a defined line without waiting for a complete theory of the system. Its danger begins when the action is reported as that missing theory.

RFC 8084, the March 2017 IETF Best Current Practice authored by Gorry Fairhurst, places several particulars ahead of a decision. Traffic enters a metered section at one or more ingress points and exits at one or more egress points. A breaker monitors a designated transport flow or aggregate in that scope. It applies a configured threshold over measurement intervals. The threshold condition must persist across multiple intervals before the circuit breaker is triggered. The response removes traffic from the metered section: it can terminate traffic or substantially reduce its rate.

That is already a meaningful receipt. It can say: this meter, over this declared traffic and this measurement window, observed enough persistent excess to execute its stated protection. It can support review of the threshold, interval, scope and reaction. It cannot silently expand its jurisdiction beyond those terms.

The RFC itself supplies the reason for restraint. Persistent excessive congestion can have different contributors: anomalous traffic, capacity being used for other purposes, a routing change, a misconfigured service, a network device, an admission controller or a policer. The list is not a diagnostic menu from which a log line may select one answer. RFC 8084 says that in many cases the cause is not evident at the source. It also recognizes that applications might not learn a breaker was triggered or where in the network it occurred.

So a trip cannot establish that a particular link was saturated, that a remote party behaved badly, that an ingress was the source of the problem, or that every flow sharing a path saw the same condition. It does not measure user experience, quantify capacity, show which traffic was displaced, or certify that ordinary congestion control failed. Nor does a successful traffic reduction prove recovery. A rate can fall because the breaker acted while the underlying condition continues elsewhere; recovery needs its own time-bound observations.

The distinction matters because safety controls are often made to carry governance claims they cannot bear. A breaker is not a judge of network intent. It is not a path map. It is not a root-cause engine. It is not a permission to write “resolved” into an incident record. It is a local reaction to an explicitly configured observation.

Heng Lu's Minimum Initial Specification and Running-Code Primacy offer a useful editorial test here. Preserve the small deterministic meaning that the running mechanism can actually verify; do not grant its record the authority of evidence held by a different mechanism. The breaker can account for its meter and reaction. Topology telemetry, queue observation, traffic analysis, configuration history, remote endpoints and user-facing systems must account for their own facts.

This does not make a trip weak. It makes it auditable. The investigation can begin with the exact ingress and egress definition, the flow or aggregate key, interval sequence, threshold version and precise reaction. It must continue, rather than end, with evidence about cause, location, impact and recovery.

Sources