Summary

  • In RFC 7683, OC-Reduction-Percentage = 100 requests abatement of all matching new traffic a reacting node would otherwise send; the loss algorithm expressly does not guarantee an absolute traffic reduction.
  • A defensible operational claim needs the report, its active overload-control state, request-level treatment and measured traffic joined by time, scope and node identity. The number alone cannot prove zero traffic, zero useful throughput or zero user impact.

A command dressed like a result

The ambiguity begins with grammar. “One hundred percent reduction” sounds like an observation made after the fact. In Diameter Overload Indication Conveyance, it is an instruction issued before the result is known. RFC 7683 defines the OC-Reduction-Percentage value as the portion of traffic a sender is requested to reduce compared with what it would otherwise send. At 100, all of that in-scope traffic is to receive abatement treatment because the reporting node is severely loaded and has ceased processing new messages.

That statement is strong, but its object is narrow. It describes requested treatment at a reacting node. It is not a counter on the reporting node, an end-to-end flow total, a record of successful diversion, a customer-impact measure or a receipt from every participant in the path. Reading it correctly does not weaken the standard. It preserves the very distinction that makes the control useful: intent can travel quickly even when outcome measurements arrive later.

Ben Campbell is an apt guide to that distinction. The IETF Datatracker describes him as a real-time communications specialist who has served on the IAB, as ART Area Director and as chair of several working groups. He is named on RFC 7068, the Diameter overload requirements; RFC 7683, the base DOIC mechanism; and RFC 8583, which separates load information from overload instructions. Across those documents, the recurring discipline is to say exactly which node knows what, and what it is asking another node to do.

What the loss algorithm actually promises

RFC 7683 separates the reporting node from the reacting node. The reporting node decides that an overload condition requires less traffic and sends an Overload Report, or OLR. Its method for deciding the reduction amount is implementation-specific. The reacting node receives that report, maintains overload-control state, or OCS, and decides which individual request messages receive abatement treatment. That selection method is also implementation-specific.

For the default loss algorithm, the reacting node must apply treatment to the requested percentage of new request messages. But the specification then states the boundary plainly: because the algorithm is stateless, it does not guarantee an absolute reduction in traffic. It guarantees that the requested share of new requests will be selected for treatment.

Treatment is not synonymous with disappearance. Depending on application rules and available paths, a selected request may be diverted to another destination or throttled. RFC 8581 makes diversion the preferred treatment for peer overload and requires throttling when alternate peers lack enough capacity. From the overloaded node’s viewpoint, successful diversion may reduce arrivals. From the network’s viewpoint, the request still exists and may increase load somewhere else. From the application’s viewpoint, a throttle may produce an error, a retry, a delayed transaction or a failed operation. Each is a different measured object.

Scope lives in the overload-control state

Even the word “all” is conditional. RFC 7683 initially defines host and realm reports. A host report applies to host-routed requests; a realm report applies to realm-routed requests. The state is also associated with an Application-ID. RFC 8581 later adds a peer report for agent overload, matched through the Application-ID and the peer’s Diameter identity.

A request therefore has to match the active OCS before the reduction percentage matters. Traffic for a different application, realm, host or peer may sit outside that state. A Diameter client that does not support the extension may never establish the same control state. A report inserted by the wrong peer must be ignored under RFC 8581’s SourceID rule. “100 percent” without report type, application, source, recipients and validity interval is an orphaned number.

The state has time and order as well as scope. An OLR carries a sequence number and a validity duration. A newer sequence updates a matching state; an equal or older one is ignored. Changes to duration or reduction parameters require a sequence increment. A new sequence must remain greater than unexpired earlier reports of the same application and report type even across a reporting-node reboot. Those rules make a forensic question possible: which version was active at a particular reacting node when it classified a particular request?

Silence does not close the condition

Operational dashboards often treat a missing field as a return to normal. DOIC explicitly refuses that shortcut. When an answer arrives without an OC-OLR, the reacting node does not delete the OCS; absence of the report means “no change.” The reporting node can signal the end of a condition with a validity duration of zero, and an existing state also expires when its duration runs out.

Even then, the transition is controlled. RFC 7683 advises a reacting node emerging from a 100-percent reduction to proceed conservatively, for example with probe messages, rather than jump immediately to unrestricted traffic and drive the reporting node back into overload. RFC 8581 uses the same controlled ending for peer-report state. A graph that marks recovery at the first message without an OLR is therefore not merely imprecise. It contradicts the state machine.

Three reports can describe one path

RFC 8581 also blocks a second tempting arithmetic error. A message can carry host, realm and peer overload reports at the same time. The reacting node first handles host or realm abatement, then applies peer abatement to messages that survive, taking prior treatment into account to avoid oscillation.

These percentages are not three independent loss gauges. Adding them, or applying each to the original request population, invents a denominator that the protocol never supplied. An audit has to reconstruct the sequence of classification and treatment. How many requests entered the candidate set? How many matched the host or realm state? Which survived? Which of those then matched peer state? Which were diverted and which were throttled? Only those denominators turn policy percentages into accountable counts.

Load is a hint; overload is a request

RFC 8583 gives another useful guardrail. A Diameter node always has load, while overload is an exceptional state; the relationship between being fully loaded and declaring overload can be vague. A load report is informational, a hint used in balancing or anticipation. An OLR is an explicit request to reduce offered load—effectively a contract between the reporting and reacting nodes.

The two numeric scales even run differently. In the Diameter Load mechanism, a higher value means lower actual load: 65535 represents zero load and 0 represents 100-percent load. In RFC 7683’s reduction percentage, 0 means no abatement is needed and 100 requests treatment of all matching traffic. A data pipeline that stores both as an unlabeled “percent” field can reverse the operational meaning while remaining numerically tidy.

RFC 7068 supplies the outcome measure the control messages cannot. It calls overall useful throughput under load the ultimate measure of a solution’s value. That requires observation. A report can establish what was requested; a state record can establish what a node believed active; selection logs can establish which requests received treatment; counters can establish arrivals and diversions; throughput and application telemetry can establish whether useful work continued. None can impersonate the next.

The receipt chain an incident review needs

A credible record begins with the reporting decision: node identity, Application-ID, report type, reason for declaring overload and the implementation version that calculated the reduction. It then preserves the exact OLR—sequence, validity, algorithm and reduction percentage—with send time.

The next receipt belongs to each reacting node. Did it advertise support? Did it receive the report from an acceptable source? Did the sequence create or update its OCS, or was it ignored as stale? What interval did that node consider the state active? The third receipt is request-level treatment, joined to the matching OCS: normal routing, diversion or throttle.

Only then should an analyst open the counters. Compare offered traffic at the reporting node with the counterfactual baseline used by the sender, traffic sent toward alternates, rejected or retried requests and useful throughput over the same interval. Finally, connect protocol outcomes to application latency, errors and completed transactions. If one link is missing, write the narrower claim. “A 100-percent OLR was active at Node A” can be correct when “traffic was zero” is not known.

Sources