Nevil Brownlee,
University of Auckland, New Zealand
Position Statement for
NSF Workshop on Internet Statistics Measurement and Analysis
Measurement of network traffic flows using the
Internet Accounting Model, RFC 1272
Traffic flows between two 'end' points, 'source' and 'destination.'
Each end point is specified as a set of attribute values. End-point
attributes include adjacent, peer and transport addresses, peer and
transport protocol type, etc. Every flow also has 'general' attributes
such as byte and packet totals for each direction, time the flow's
first and last packets were seen, etc.
Traffic is measured by a meter. The set of flows of interest to a
meter is specified by a 'rule set.' Flows are bi-directional, with
the rule set specifying which end-point is the source. The rule set
also specifies how flows are to be aggregated; this data reduction can
significantly reduce the volume of data to be collected from a meter.
Flow data is recovered from a meter by one or more 'collectors.' One
or more collectors may retrieve data from a meter asynchronously, and
the set of attribute values retrieved may be different for different
collectors. A collector may collect data from any number of meters.
Meters and collectors are co-ordinated by a manager. The manager is
responsible for downloading rule sets to meters, and for configuring
collectors.
NeTraMet: a Public-Domain implementation of the Accounting Model
NeTraMet has been available since October 1993, and is now in widespread
use. It provides a combined manager/collector (NeMaC) which runs on Unix
systems, and a meter (NeTraMet) which runs on Unix systems or DOS PCs.
NeTraMet's hardware requirements are modest - a 40 MHz 386 with 640 KB
of memory can cope with 3,000 Ethernet packets per second, and a Unix
workstation can measure traffic on an FDDI ring.
Although most sites use fairly simple rule sets, some have reported
using rule sets containing between 600 and 1700 rules.
Most sites use Netramet to collect traffic data for management purposes
such as planing and cost recovery, but it has also proved useful for
other purposes such as:
- Measuring transit traffic through links
- Detecting traffic caused by misconfigured hosts (e.g. DNS servers)
- Measuring performance of WWW caches
Challenges for Traffic Measurement
- NeTraMet relies on seeing all packets on a network segment. This
is simple for bus and ring topologies but impossible when switches
or routers are used to subdivide a network. A standard method of
measuring traffic flows is urgently needed; once the standard is
established vendors can implement it within switches and routers.
Existing Internet standards such as MIB-II and RMON provide monitoring
ability for network segments, but do not address the problem of
measuring flows directly.
- One question of particular interest to service providers is that of
estimating the link capacity required to support a specified level
os network service. This is a complex issue, since the
characteristics of bursty packet traffic are not well understood.
- Better ways of specifying how flows are to measured (in NeTraMet
terms, better ways of producing rule sets). One thing which will
help will be the widespread adoption of provider-based addressing.
- Ways of measuring traffic through complex internets need to be
be developed further. At a provider level one needs to know how much
transit traffic is passing through a network; this is equally
important at a national level.
Update, 11 march 96
Since we've started weekly time-series and
distributions plots, we've noticed that
the Auckland data is a lot `spikier' than that from
most other sites.
We think this is because we have our access rate and CIRs
a lot higher than our average load, so we don't see any limiting
imposed by the Frame Relay PVC management. The other universities
tend to run their PVCs closer to their CIRs. Over the last
month or two Canterbury has increased its
CIR significantly, and we believe that
their time-series plots have got spikier. We're
looking into this further - stay tuned!