Summary

  • RFC 3334 treated accounting as a configurable observation chain. Policy could select flows, attributes, accuracy, sampling, aggregation, report intervals, destinations, retention and access before an accounting record existed.
  • A missing or coarse record therefore could not prove zero use. It might reflect measurement scope, collector filtering, export loss, aggregation or expiry. The document was Experimental and explicitly separated accounting configuration from charging tariffs and final billing.

The bill began before the counter moved

The intuitive story of usage accounting begins with a neutral meter: traffic occurs, a counter observes it, and a billing system later decides what it costs. RFC 3334 described a more political sequence. Business arrangements and service choices produced accounting policies. Those policies configured the machinery that generated, transported and stored the evidence. Only downstream did charging derive a cost and billing turn that cost into money.

That layering matters. Accounting was not the invoice, and its policy was not a tariff. The architecture separated metering, collection, accounting, charging and billing. A charging policy might apply different cost metrics to the same accounting data. A billing policy might decide invoice form and schedule. The accounting policy decided what data would be available to either one.

RFC 3334 was published in October 2002 as Experimental. It proposed building blocks and message sequences in the generic AAA framework rather than an Internet Standard or a mandatory policy language. Its value lies in showing, unusually clearly, that a record of consumption is manufactured by an observation contract.

Two meters could omit the same traffic at different times

The document distinguished static and configurable meters. A static meter observed flows at a fixed granularity, perhaps producing more raw data than the charging process needed. Filtering and aggregation then occurred at the collector or another downstream stage. A configurable meter behaved differently: metering policy selected the flows it would collect in the first place.

The distinction changes the meaning of absence. If a static meter saw a flow and a collector later dropped it, a sufficiently preserved raw feed might recover the observation. If a configurable meter never selected the flow, no downstream query can reconstruct its counters. Both pipelines can produce the same final record, but their evidentiary gaps arise at different boundaries.

Policy controlled more than inclusion. It could set flow granularity, from a five-tuple microflow to a coarse network aggregate; choose attributes; determine measurement intervals and timestamp accuracy; and configure sampling. At collection it could choose push or pull, aggregation and report intervals. At storage it could choose destination, retention period and access list.

The result was not simply “usage data.” It was usage data under a particular scope, resolution, clock, sampling method, transformation path and retention promise. Remove any one of those receipts and later readers may assign the record more precision than the measurement ever possessed.

Conditions turned business categories into visibility

An accounting policy joined conditions to actions. Conditions could match customer or user identity, IP address, time of day, service class or an accounting type. Actions could request a record structure, destination, reporting frequency, storage interval, access rights, flow granularity and meter accuracy.

This allowed one customer to receive detailed interim indications while another received a coarse end-of-session record. A premium service might be measured more finely than a standard service. The physical packets did not change when an “accounting type” changed. The system's attention did.

That flexibility supported product differentiation and customer preferences. It also made comparisons conditional. Two providers could both report “bytes used” while observing at different points, sampling at different rates, grouping flows differently or retaining different attributes. A roaming record crossing domains carried meaning only if the parties shared the policy semantics.

The tempting mistake is to treat an accounting category as a description of reality. “Standard accounting” is not a natural property of a flow. It is a bundle of settings chosen by a provider. A dispute cannot be resolved by the record alone if the bundle that produced it is missing.

Aggregation traded future questions for present scale

Large volumes made filtering and aggregation practical necessities. Yet every aggregation settles questions in advance. Combining microflows by customer preserves a customer total while discarding which destination or application contributed. Combining intervals preserves volume while erasing bursts. Sampling reduces collection cost while adding estimation uncertainty. Short retention makes storage affordable while closing the window for appeal.

These trades are legitimate when explicit. They become dangerous when a surviving total is later treated as if all discarded dimensions had never mattered. An aggregate can answer the question it was designed for and remain useless for another question: security attribution, performance diagnosis, inter-provider settlement or customer challenge.

RFC 3334's meter example contained an unusually direct warning. NeTraMet or NetFlow collection did not guarantee exact accounting data and should not be used where exact data were required. That sentence blocks a common evidentiary shortcut. A familiar telemetry technology does not supply accuracy by reputation. Exactness needs a measured error model, loss evidence and a fit-for-purpose requirement.

Export introduces further gaps. A counter can be correct at the observation point while datagrams are lost on the way to a collector. A collector can receive records and apply the wrong template or aggregation. Clock disagreement can change interval attribution. Each stage needs its own receipt.

Push and pull moved policy across trust boundaries

Accounting policies could be local, received from another AAA server, or supplied by a customer. A push model delivered a policy for local installation; a pull model requested it from a remote party. Exchange made roaming and outsourced accounting possible, but it also moved executable measurement intent across organizational boundaries.

RFC 3334 warned that actions were not the only dangerous part. Evaluating a malicious or accidental condition could itself consume resources or trigger unwanted behavior. A receiver therefore had to validate both condition and action before evaluation. Authentication of the sender was necessary but insufficient: an authenticated policy could still exceed authorization or impose an unsafe workload.

Policy provenance should include author, issuer, approval, version, activation time, scope and the exact translation into device configuration. An Application Specific Module might convert a generic policy into NeTraMet rules or collector filters. The successful conversion receipt did not prove that two different implementations produced semantically identical measurements.

Integrated and discrete accounting saw different worlds

In integrated accounting, the measurement process lived with the service and could use service-specific information. IP telephony accounting, for example, might incorporate call-signalling data. Discrete accounting treated measurement as a separate service that could cover web, file transfer or voice for several providers.

Neither view was universally superior. Integrated accounting could see application events unavailable to a generic meter, but it was tied to the service's own interpretation. Discrete accounting could centralize control and outsourcing, but it observed from a different point and required explicit agreement on parameters and dispute resolution.

Observation point therefore belongs in the record's provenance. Bytes seen at an ingress edge, an application server and a downstream exporter are not interchangeable. Retransmissions, encapsulation, caching and failed sessions can make each counter correct for its location while totals disagree.

Later flow standards did not repair old evidence automatically

RFC 2903 and RFC 2904 supplied the generic AAA and authorization setting. RFC 2975 discussed accounting management, while RFC 2924 catalogued attributes. RFC 2123 defined NeTraMet. RFC 3954 later documented NetFlow version 9, and RFC 7011 with RFC 7012 standardized IPFIX protocol and information-model foundations.

Those documents help readers understand the surrounding mechanisms. They do not prove that RFC 3334's architecture was deployed, that a historical provider used a particular configuration, or that an old record had IPFIX semantics. Standards succession is context, not retroactive instrumentation.

The same restraint applies to missing records. Absence can mean no resource use, but it can also mean the policy excluded the flow, the observation point missed it, sampling did not select it, export failed, aggregation removed the dimension, access was denied or retention expired. The record alone cannot choose among these explanations.

Every total needs its observation contract

A defensible accounting claim begins with five receipts. The policy receipt records conditions, actions, version and authority. The configuration receipt shows how the policy was translated and actually applied. The coverage receipt names meter type, observation point, scope, clock and accuracy. The transformation receipt records sampling, filtering, aggregation and export loss. The custody receipt records destination, access, storage and deletion.

Charging and billing add their own policies after those five. A final invoice cannot be used backwards to prove the completeness of the meter. Nor can an accounting total prove that unrecorded use was zero.

RFC 3334's durable lesson is that measurement is a choice before it is a number. The meter counted what policy made visible. Responsible operators preserve the field of view with the count.

Sources