Summary

  • RFC 9808 gives a downstream CDN two portable objects: one advertises capacity limits; the other identifies near-real-time utilization metrics. The upstream CDN can compare them before delegating traffic.
  • The advertisement is expressly advisory. It is not a guarantee, commitment or reservation of capacity, and it cannot prove that a particular request was admitted, delivered on time or completed successfully.

Consider an upstream CDN choosing where to send the next wave of requests. A downstream partner advertises a hard egress ceiling, a lower soft ceiling and a current utilization feed. The observed value is below the soft ceiling, so the upstream increases delegation. Minutes later, another applicable limit—sessions, perhaps—binds first. The downstream refuses some requests.

Nothing in that sequence makes the original advertisement false. It makes its scope visible. A capacity envelope was offered as input to a decision. It was not a purchased reservation, an admission token or a delivery receipt.

That distinction is the centre of RFC 9808, published on the Standards Track in July 2025. The document adds two capability objects to the Content Delivery Network Interconnection, or CDNI, Footprint & Capabilities Advertisement Interface. FCI.CapacityLimits describes how much traffic a downstream CDN says may be delegated. FCI.Telemetry describes the measurement sources against which current utilization can be read.

The RFC Editor record names Andrew Ryan, Ben Rosenblum and Nir B. Sopher as the authors. The IETF Datatracker preserves the document history and status. The IANA CDNI Parameters registry records both payload types, a generic telemetry-source type and six initial capacity-limit types.

The specification says the quiet part plainly: the information is advisory and represents no guarantee, commitment or reservation of capacity. This is not disclaimer language bolted onto an otherwise binding mechanism. It is the mechanism's boundary. The downstream exposes a machine-readable view; the upstream owns the traffic-delegation decision; live request handling remains downstream; delivery and user outcome occur later still.

CDNI exists because content delivery can cross organizational boundaries. RFC 6707 describes an authoritative or upstream CDN that may redirect some requests to a downstream CDN better positioned to serve them. Business arrangements among the content provider, upstream CDN and downstream CDN are outside the technical specification. An interoperable capacity field therefore cannot silently become the parties' commercial promise.

The CDNI framework in RFC 7336 separates asynchronous advertisements from the synchronous act of serving an individual request. It also leaves the upstream's choice to redirect as a local decision. RFC 9808 supplies better evidence for that decision without transferring the decision itself.

FCI.CapacityLimits is more disciplined than one attractive number. Every limit is scoped to the footprint on the enclosing advertisement. A value for one address range, autonomous system, country or other footprint cannot be promoted into a whole-network ceiling. RFC 8008 treats footprints and capabilities as constraints that help an upstream decide whether a downstream is a candidate; it does not define a universal ranking or promise of reachability.

Several limits may apply at once, and RFC 9808 requires the upstream to consider them with logical AND. It cannot choose the most generous dimension and ignore the rest. Egress may be below its ceiling while request rate, sessions, storage objects or cache size is exhausted. The six registered types—egress, requests, storage size, storage objects, sessions and cache size—make that multidimensional character explicit.

maximum-hard is mandatory. It states the maximum unit of capacity available for use. maximum-soft is optional and must be lower; it identifies the point at which the upstream should reduce traffic before reaching the hard ceiling. If the soft value is absent, it equals the hard one.

Those names are easy to overread. “Hard” describes the relationship between two declared thresholds. It does not turn the higher number into a reservation held aside for this upstream. Nor does “available for use” prove that an individual request will encounter the same state when it arrives. Other constraints, measurement delay, policy, failures and traffic outside the observed relationship can intervene.

FCI.Telemetry keeps a limit tied to an observable metric. A telemetry source has a stable identifier, a type, exposed metrics and optional source-specific configuration. Each metric has a stable name. A capacity limit can point to one source ID and one metric name, preventing the upstream and downstream from comparing nominally similar numbers drawn from different definitions.

The optional metric fields are operationally important. time-granularity says what interval the value represents. data-percentile says whether it is, for example, a median; if the percentile is absent, the metric is the mean. latency says how far the measurement trails real time. A utilization value can therefore be correctly calculated and still be too delayed for an aggressive delegation increase.

This is why “near real time” is not a timestamp. A five-minute average reported twenty-five minutes late describes a different decision surface from a one-minute mean that trails reality by seconds. Both can be syntactically valid. The risk lies in treating the first as if it were the second.

RFC 9808 allows current utilization to appear inline with a capacity advertisement, but does not recommend that pattern for ordinary use because rapidly changing values make the response harder to cache. The intended design is a relatively stable envelope plus a separately polled telemetry source. Limit and utilization are related, but they have different update rates and evidence lifetimes.

The capacity advertisement itself also ages. Its validity follows the underlying transport's Time to Live, such as HTTP Cache-Control. If the transport provides no TTL, the parties must agree on one out of band. A cached hard ceiling can remain valid within its declared lifetime while becoming a poor guide to a sudden event. The upstream must know both what the number means and how old its authority is.

Aggregation creates another boundary. If an upstream delegates traffic through several downstream CDNs and later reports its own utilization, it must include the delegated usage. Otherwise outsourced traffic can disappear from the upstream view even while it remains real to capacity and cost. The telemetry object helps close that accounting gap; it cannot ensure that every reporting system aggregates it correctly.

The distinction becomes sharper beside the separate CDNI trigger interface. RFC 8007 lets an upstream request prepositioning, invalidation or purge work and poll a status resource. That command lifecycle does not substitute for capacity advertisement, and capacity advertisement does not prove a trigger completed. RFC 8006 carries content-distribution metadata without making metadata receipt identical to content acquisition or delivery.

For operators, the practical model is a chain of bounded evidence:

  1. the RFC and IANA assignments define portable vocabulary;
  2. one FCI response states a downstream envelope for a scope and lifetime;
  3. one telemetry source reports measured use under a named method and delay;
  4. the upstream reconciles every applicable limit and chooses a delegation rate;
  5. the downstream admits, delays or refuses a particular request under live state;
  6. delivery telemetry records what was actually served; and
  7. application evidence records completion, latency, quality or failure.

A contract may attach prices, credits or remedies to some stages. The protocol does not write that contract. It gives the parties less ambiguous evidence with which to operate and later explain their decisions.

Minimum Initial Specification, Localized Future Decision and Voluntary Adoption argues for a thin shared layer that enables interoperability while leaving later decisions local. RFC 9808 fits that architecture: it standardizes the envelope and measurement references, yet leaves each upstream free—and responsible—to choose how cautiously it delegates.

Running-Code Primacy supplies the next test. Publication does not prove that a downstream emits the objects, that an upstream consumes every constraint, that telemetry arrives on time, or that the request router changes behaviour. Those are implementation and observation questions.

Reality Layers supplies the final discipline. A well-formed ceiling is real as a statement. A utilization sample is real as an observation under a method. Neither is a reservation. Neither is a successful request. Naming the boundary makes the evidence useful without pretending it can carry more authority than it has.

Sources