Summary

  • RFC 1272 argued that endpoint IP addresses could not tell a provider which directly adjacent administrative domain carried traffic across its boundary.
  • Boundary meters could support reconciliation, but the useful detail depended on topology, selected granularity, storage, collection cost and security.
  • The memo separated usage reporting from billing and enforcement, and left the disputed choice between counting packets on router entry or exit unresolved.

The missing name was the neighbor

An IP packet has source and destination addresses. That makes it possible to count traffic between endpoints, but it does not by itself say which neighboring network delivered the packet into a provider’s domain. If traffic from one end system can arrive by different adjacent domains, a complete record of the endpoints still cannot answer the provider’s narrower question: whose network did this traffic cross at my boundary?

RFC 1272’s answer was not to make every network account for every user on the Internet. Its model focused an administration on its own domain and the adjacent domains directly connected to it. One provider could measure the traffic crossing its boundary with a neighbor and exchange a statement with that neighbor. If the neighbor needed to allocate its own costs further downstream, that became the neighbor’s responsibility. The design was recursive: each administration accounted for the relationship it could observe, rather than pretending to possess a global view of the end user.

That distinction changes where a meter matters. A host can observe traffic at an endpoint. A router at a network boundary sees traffic entering or leaving the local domain and can provide evidence about an adjacent interconnection. The memo said IP headers alone did not contain this intermediate-system identity; lower-layer information or configuration about boundary components could be needed. A packet’s endpoint fields and a provider’s accounting boundary answered different questions.

Measurement had a price of its own

The location of a meter was only one design choice. RFC 1272 described dedicated network monitors, line monitors, software meters inside routers and coordinated “router spiders.” The most convenient place depended on the topology and the service being measured. Boundary placement could help a provider and consumer compare their accounts, but it was not a universal command to instrument every router.

The memo treated detail as an economic and technical decision. A meter might count by port, network or host; add packet attributes; retain counters or timestamps; and report at different intervals. Each additional entity/attribute combination could require another flow record. More granular records consume memory and processing, and more frequent reports consume bandwidth and collector capacity. If full accuracy and reliability were required, every packet had to be examined. For some goals—understanding behavior, tuning a network or approximating a cost share—sampling might be adequate at lower expense.

Those are different evidentiary standards, not interchangeable methods.

Collection itself also had to be protected. The authors described usage information as sensitive and identified confidentiality, integrity and control of collection as concerns. They discussed acknowledgements and retransmission, redundant collectors, or backup storage at the meter as possible ways to preserve data. A number collected at a router was not automatically a trustworthy, complete account merely because the meter sat at a boundary.

A count was not an invoice or a rule

RFC 1272 explicitly narrowed its purpose. It provided background for a usage-reporting architecture, not an Internet standard. It said reports could help a subscriber understand behavior, help a provider measure policy compliance or contribute to cost allocation. But reporting alone could not enforce a policy, and the document did not recommend billing practices. It did not solve who should pay for retransmitted packets.

One question was intentionally left open: should an accounting system count a packet when a router receives it, or only when the router forwards it? A router may discard packets under congestion. Counting entry reflects resources consumed by offered traffic; counting exit avoids charging for traffic not forwarded. RFC 1272 required that an architecture be capable of either choice because the dispute turned on policy and context, not a universal technical answer.

Later, RFC 2722 specified a traffic-flow measurement architecture. That later work is part of the history of measurement systems, not proof that a particular billing model or the whole 1991 accounting vision became operational. RFC 1272’s lasting design question is more modest: what can an administration actually know at its boundary, and how much measurement is worth paying for? The answer has to preserve the chain from observed flow, to identified neighbor, to report, to any later price or enforcement decision. None follows automatically from the IP addresses at the packet’s ends.

Sources: RFC 1272; RFC 2722; RFC 2990.