Summary

  • NeTraMet tested each packet against the active rule set. The rules could ignore protocols, reverse direction, mask addresses, push selected attributes and define what NeMaC later wrote, so the record was a configured projection rather than a packet transcript.
  • Performance optimisations made that projection executable: related tests became hashed groups, address masks became one-byte indices, and compile-time limits shaped which rule sets could run.
  • When the flow table filled, the meter could move from production rules to coarser standby rules and then to default rules; after restart it began on defaults until the manager restored policy, with the documented setup allowing up to five minutes of loss.

The packet met a policy before it met a counter

RFC 2123 was published in March 1997 as an Informational record of three years’ experience with the IETF’s traffic-flow measurement architecture. Its subject was not a passive tap that copied the wire. NeTraMet was a meter with a Packet Matching Engine. NeMaC combined the manager that downloaded rules with the reader that collected the results. Analysis programs then turned collected rows into rates, plots and reports.

That four-stage chain matters. A packet arrived at one observation point, but the row that emerged depended first on the installed rule set. Rules could test a protocol, address or computed class; push selected values into a flow; ignore a packet; jump to another rule; or retry the match with source and destination reversed. The rule file also carried a format telling NeMaC which attributes to collect and write.

Direction was therefore not a universal property carried intact from the network. One rule example classified traffic relative to two gateways. Another retried a failed match in the opposite direction so a well-known endpoint or local network could become the flow’s source. That was useful normalization, but it was still a decision. To interpret a row, an analyst needed to know which convention had created it.

The RFC Editor record and IETF Datatracker preserve the document’s status: implementation experience, not an Internet Standard and not testimony about every installation. The current RFC 2123 errata search reports no matching errata. That absence does not certify a deployment or a downstream inference.

Ignored traffic left no negative receipt

The clearest evidence boundary appears in an optimisation. If a site cared only about IP, there was no benefit in buffering and parsing Novell or EtherTalk packets. NeTraMet inspected the active rule set to discover which Peer types were interesting. An unwanted protocol could be discarded after its type was identified, with no further processing. If no rule used adjacent addresses, those values did not need to be copied either.

The optimisation was faithful to the configured question. It was also irreversible for that observation path. A later flow file could show counted IP traffic; it could not prove that no other protocol crossed the segment. It could show that the meter executed its interest set; it could not reconstruct attributes the rule set had chosen never to retain.

This was not a flaw hidden from the architecture. The contemporaneous RFC 2063 explicitly put requested data reduction near the measurement point so less material had to be transported and analysed. RFC 2123 supplied the running implementation. The gain in efficiency and the loss of unselected detail were the same design choice viewed from opposite sides.

Compilation changed cost without making the record neutral

Large classification rule groups could contain hundreds of address tests. Sequential evaluation was too slow, so NeTraMet found groups that tested the same attribute with the same mask and compiled them into hashed lookups. The setup cost was paid once before the new rule set ran. At packet time, the meter masked the attribute, computed a hash and traversed a usually short chain. Small groups stayed sequential because the minimum group size was fixed at compile time.

Address masks created another cost. A flow needed both the masked address and enough information to distinguish real zero bits from bits that had been ignored. Rather than store a complete mask for every address field, the described NeTraMet version built a mask table and stored one-byte indices. Its maximum number of masks was compile-time bounded, up to 256.

These were elegant optimisations. They allowed richer classification within the processing and memory budget, and they reduced later data volume. But they also made the retained row inseparable from the exact executable rule representation. A report did not simply describe an address seen on the wire. It described an address after a particular mask, rule path, direction convention and compiled limit had acted on it.

Memory pressure changed the question while measurement continued

NeTraMet’s maximum flow-table size was selected when the program started. Flow structures were allocated in blocks and reclaimed by an incremental garbage collector. Recovery depended on inactivity and on evidence that known readers had progressed far enough to collect the data. If collections lagged, the meter could run out of space.

The architecture did not answer that pressure by pretending capacity was infinite. Above HighWaterMark, the meter was expected to use a standby rule set. At Auckland, standby rules could resemble the production file while pushing much less information. The coarser set sometimes allowed the meter to keep running for a day or two after a reader failed and preserve accumulated totals for later collection.

At FloodMark, NeTraMet switched to its built-in default rule set so garbage collection would not consume so much time that the manager became unreachable. The document reports that 65 percent for the high-water mark and 95 percent for the flood mark worked well in practice, but those were experience values, not universal safe settings.

Continuity of process was therefore not continuity of meaning. A row collected before pressure, one created under standby rules and one created under defaults could all be valid, yet answer different questions at different granularity. “The meter stayed up” proved availability of a mechanism. It did not prove unchanged coverage.

Restart created a policy discontinuity

The restart sequence made the distinction starker. After power failure or another restart, the meter began on rule set 1, its built-in default. NeMaC periodically compared sysUptime with the previous value. If uptime moved backwards, it inferred a restart, downloaded backup and production rule sets, and asked the meter to resume production policy.

The documented operating example used a five-minute keepalive and a fifteen-minute collection interval. RFC 2123 says that a restart could therefore lose up to five minutes of data before the rule sets were downloaded. Five minutes was not a protocol guarantee; it was the consequence of that chosen monitoring interval. A different installation could have a different exposure.

Nor was the problem only missing packets. Until restoration, the default rules could classify traffic differently from the production set. A clean post-restart counter did not prove continuity with the pre-restart series unless rule identity, meter uptime and the recovery boundary accompanied it.

An index was a location, not an identity

Flow-table positions were reusable. Once garbage collection reclaimed a record, the meter could assign the same FlowIndex to a new flow. RFC 2123 therefore required the combination of FlowRuleSet, FlowIndex and StartTime to identify a flow uniquely. An index alone was a slot, not a durable subject.

The same caution applied to collection. NeMaC could read only selected columns to reduce SNMP traffic. Rows might become active after the first column had been read; NeMaC read the widest columns first and ignored rows appearing later until the next collection. A successful poll was useful evidence, but it was not an atomic snapshot of one frozen table.

The RFC 2064 Meter MIB supplied the control objects behind many of these interactions. The later RFC 2722 architecture clarified and revised the model in 1999. Those later clarifications belong to their own date. They cannot be projected backward as proof of what every 1997 NeTraMet site ran.

A benchmark measured one machine, not the evidence chain

RFC 2123 reported performance observations: a 10 MHz 286 sustained about 750 packets per second, a 25 MHz 386SX about 1,250, and users reported peaks near 3,000 on a 40 MHz 486 without packet loss. A lightly loaded FDDI test on a SPARC 10 used about one percent of the processor.

Those figures described particular hardware, code paths and workloads. They did not certify universal losslessness. Even a packet-loss benchmark could not establish that the active rules selected the right attributes, that the reader completed an atomic collection, that the report applied the right transformation, or that a tariff was authorized. RFC 2123 also left integrity and confidentiality to the management and collection protocols rather than defining them in detail.

Lu Heng’s later Running-Code Primacy offers a disciplined way to read the record: ask what the running system actually executed, not what a symbolic label seems to promise. Minimum Initial Specification keeps local operating choices with implementers instead of turning one configuration into universal authority. Reality Layers supplies the final separation: document, executable rule, collected row and network outcome may align, but none is the other’s receipt.

RFC 2123’s durable achievement was to expose measurement as a chain of custody. The manager chose the question. The meter projected packets through a versioned rule set. Resource pressure could lower resolution. The reader captured a non-atomic view. Analysis produced the claim. A traffic record was valuable precisely because that chain could be named—not because the row was allowed to impersonate the wire.

Sources