Summary

  • In an ongoing Diameter credit-control update, Tx expiry under RETRY_AND_TERMINATE grants service while the request remains pending; a later delivery failure or temporary-error result terminates it.
  • The effective policy can override local configuration. Moving an established credit-control session also requires failover permission and state handling, not merely another reachable server.

The surprising word in RETRY_AND_TERMINATE is not “terminate”. It is the interval the name leaves out. An established service can still be delivered after a client-side timer expires, even though the applicable failure policy ultimately calls for termination. That is a specified transition, not evidence that an operator has misconfigured its network.

The relevant case is narrow. A Diameter credit-control client has sent an update for an ongoing session and is waiting in the PendingU state. Under RETRY_AND_TERMINATE, expiry of the application timer Tx permits service and leaves that request pending. If a later event establishes failure to send, or delivers the defined temporary-error outcome, the same policy instead calls for termination. These are different events in RFC8506, section 7, Table 4, supported by the failure procedures in section 5.7.

For a manager, this changes the question from “Do we fail open or closed?” to “Which event ends our willingness to keep serving?” The answer cannot be obtained from a policy label alone.

A deadline is not yet a verdict

Session-based credit control reserves units and updates their use. Units may represent time, data volume or a service quantity, not simply a cash balance. Intermediate requests can occur as a grant is consumed, when its validity expires, or when relevant service conditions change. Section 5.3 also allows a request to be made in advance to avoid interruption. The pending window therefore belongs to a continuing exchange over consumption; it is not a new, unlimited grant invented by the client.

The distinction becomes concrete when the events are placed beside one another. All three rows below concern an ongoing update with RETRY_AND_TERMINATE, not the first authentication of a subscriber.

Event while the update is pending Specified consequence
Tx expires Grant service and remain PendingU
A successful update answer arrives Stop Tx and return to Open
Failure to send or a temporary-error notification occurs Terminate service and return to Idle

Here, “temporary error” is a protocol category, not a loose description of any delay. Likewise, failure to send includes cases in which the destination, and an applicable alternative, cannot be reached or the request ultimately times out. Treating all these observations as one generic timeout discards the distinction the state machine makes.

RFC8506 recommends a Tx value of ten seconds in section 13. That recommendation does not establish the timer configured in any particular network, still less a universal ten-second exposure cap. The credit-unit validity timer and the server's session supervision timer serve other purposes. Their expiry cannot simply be substituted for the client event that determines whether service continues.

Three policies, several limits

Section 8.14 defines TERMINATE, CONTINUE and RETRY_AND_TERMINATE; TERMINATE is the default when the failure-handling attribute is absent. In PendingU, TERMINATE ends service at Tx expiry. CONTINUE shares the temporary continuation at Tx expiry with RETRY_AND_TERMINATE, but differs at the later failure-to-send or temporary-error event: CONTINUE permits service, whereas RETRY_AND_TERMINATE terminates it. Retrying an alternative also depends on failover support and availability.

None of this makes every negative answer optional. Table 4 terminates service on an explicit END_USER_SERVICE_DENIED answer regardless of the failure-handling policy. Nor can the ongoing-session table be projected onto every initial exchange: the first interrogation combined with an AA-Request has its own state machine and disconnects on Tx expiry. Credit authorization is the RFC's subject; service-specific authentication and authorization are outside its scope. A continuity policy is not a blanket authentication bypass.

Even the policy in force may not be the one visible in a local configuration file. Section 5.7 gives the home AAA server's value precedence over the local value, while a value received from the credit-control server in its answer overrides the existing setting. A defensible account of an incident would need the effective value and its provenance at the relevant transition. A screenshot of the default would not settle the matter.

A backup address does not move a session

Maintaining service while an answer is pending and moving the credit-control stream to another server are separate decisions. Sections 5.7 and 8.4 require attention to CC-Session-Failover for an ongoing session. When that attribute is absent, FAILOVER_NOT_SUPPORTED applies, and the credit-control message stream must not be moved to an alternative server. Selecting a backup for a new session is a different case. Ordinary peer failover along the transport path is also distinct and can produce duplicate requests without authorizing a stateful session migration.

The RFC says that session and account state should move between primary and secondary servers, and that implementations supporting session failover must detect duplicate and out-of-sequence messages. It does not supply the inter-server state-transfer mechanism. Session-Id and CC-Request-Number identify requests; their presence is not evidence that a deployment has correctly replicated reservations or handled duplicate processing. Reachability is only one part of continuity.

Accounting remains equally important. Section 5.7 recommends a backup accounting flow. Its example combining CONTINUE with DELIVER_AND_GRANT expressly depends on collecting accounting information and exchanging it with the credit-control server. Continued service therefore does not mean free service, unmeasured use, or a proven billing loss. The final interrogation described in section 5.4 still concerns reporting use and settling unused reservation. Releasing a server-side reservation is not, by itself, proof that the client has stopped delivery.

What this evidence can establish

The official RFC record identifies a March 2019 Proposed Standard that obsoletes RFC4006. The RFC8506 errata search returned no matching entries when checked on 8 September 2026. Neither fact establishes adoption, conformance, an actual outage or a financial loss. This analysis concerns specified behavior and the questions it raises for an implementation review.

Lu Heng's argument that reality, not advocacy, is BTW Media's product supplies the editorial discipline here: explain the mechanism before declaring it prudent or reckless. His essay on agency at the core of internet governance offers a lens for asking who chooses and who bears consequences. It is not evidence that a particular Diameter operator has misaligned incentives. The operational fact is more modest, and more useful: a pending decision can coexist with real service consumption.