Summary

  • A restarted reader could retrieve accumulated counts from a continuing meter, subject to retained flow state, stable measurement context and counter limits. RFC 2063, §§2.5–3.3.
  • Missing collections removed temporal detail. Independent readers could preserve observation opportunities, but asynchronous records were not interchangeable snapshots. RFC 2063, §2.5.

Consider a hypothetical outage: a meter reader stops collecting, while its meter keeps counting. When the reader restarts, a larger cumulative total and the flow’s first and latest packet times may still be available. With the same bucket, unchanged rules, sufficient retained state and no ambiguous counter wrap, the increase can be recovered. The missing intermediate observations cannot be recreated. This is the recovery model in RFC 2063, §§2.5 and 3.1.

In January 1997, Nevil Brownlee of The University of Auckland, Cyndi Mills of BBN Systems and Technologies, and Greg Ruth of GTE Laboratories, Inc. published the architecture for the IETF’s Realtime Traffic Flow Measurement work. It was Experimental, explicitly outside Internet-standard status; it organized information, requirements and implementation tradeoffs rather than specifying a protocol. Its background reached to November 1991’s RFC 1272. The official RFC 2063 record identifies it as obsolete, superseded by RFC 2722.

Three custodians of the evidence

A flow was a constructed grouping of otherwise independent IP packets, bounded by start and stop times: rules matched observed attributes to an accountable entity at a chosen granularity. That entity might be a host, user, network or group, without establishing an authenticated payer. Each counted packet belonged to one flow in the 1997 scheme; overlapping analytical views required disjoint underlying buckets and postprocessing. RFC 2063, §§2.1 and 3.3.

Managers chose flow definitions, sampling, table capacity and inactivity controls, plus each reader’s meters, collection interval, flows and attributes. Meters held cumulative packet/byte counts and activity times; reading was not supposed to clear those counts. Readers transported usage data into per-meter disk files. These were distinct functions, not necessarily separate machines. RFC 2063, §§2–3 and 5.

Usage records carried meter identity, timestamp, collection rules ID, flow descriptors and counts. Interpretation also required the meter’s identifiable Rule Set ID and flow start time: reused addresses could belong to a fresh bucket. Applications supplied the derived rates. RFC 2063, §§2.7, 3.2 and 5.1–5.2.

The total and its missing shape

Subtracting comparable endpoint counts establishes added volume. With the corresponding observation times, that difference supports an interval average. The deduction is narrower than a traffic history: first/last activity times cannot locate intervening bursts or recover their peaks. Those details depended on observations that the absent reader never made. RFC 2063, §§2.5 and 3.3.

Readers could collect whole tables, individual rows or selected attributes without synchronization. Equal intervals with different phases could therefore produce different records without implying corruption. Extra meters on the same segment protected against meter failure; extra readers protected collection continuity. Overlapping cumulative records could not simply be summed as additional traffic. RFC 2063, §§2.2–2.5.

The meter’s memory sets the boundary

RFC 2063 called for idle flows to be collected by at least one reader before reclamation, but left multiple-reader minimum/list policy for further development. Its LastCollectTime and inactivity controls informed reuse. Memory pressure could trigger coarser standby rules and shorter collection intervals; limited loss might be accepted to keep the meter running. Thus retained totals depended on surviving state, usable identity and counter capacity. RFC 2063, §§3.2, 4.5–4.6 and 5.3.

The contemporaneous Experimental RFC 2064 Meter MIB made flow-table indexes stateless, allowing independent scans; TimeFilter/GetBulk selected changed rows and attributes. Registered-reader last/previous collection times guided reclamation, while flowReaderTimeout could remove an overdue reader. A reader wrote flowReaderLastTime when starting a pass: that did not certify an atomic, completed-table snapshot. A failed write of that collection marker could obstruct reclamation even while reads proceeded. The 1997 architecture allowed one controlling manager per meter/reader; RFC 2064 already distinguished a master manager.

October 1999’s Informational RFC 2722 retained the loss-of-resolution boundary and clarified the goal of collection by all registered readers before reclamation, with timeout removal of failed readers. It allowed concurrent rulesets/managers and described alternating identical rulesets on one meter for identical old-set records, without promising simultaneous switching across meters. Those clarifications, and the later RFC 2720 Meter MIB, cannot be projected onto every 1997 installation.

A different failure, a different recovery

Under RFC 2063, §6.3, a manager outage should leave metering and reading underway. An impending meter shutdown could prompt final collection; an uncontrolled restart required discovery and correct rules to be reloaded. Traps were proposed notifications, not guaranteed delivery. Reloading configuration cannot restore vanished state or unmeasured packets. Transport remained unspecified by the architecture, with integrity/confidentiality delegated to management and collection protocols. Tariffs were outside scope; counts alone authorized no rate and established neither invoice validity, payment nor useful delivery. RFC 2063, §§1, 5.3 and 10.

Sources

The RFCs establish design and chronology, not deployment prevalence, product compatibility or NetFlow/IPFIX ancestry. Lu Heng’s later essays provide interpretive lenses, not evidence of the historical authors’ intentions.