Subject: [ipfix] RTFM compared with IPFIX

From: [email-masked]
Date: Thu, 7 Mar 2002 11:03:46 -0800 (PST)

Hi everyone:

I promised KC Norseth I'd write some notes comparing RTFM
with IPFIX, and here - at last - they are.  They're intended,
after discussion and editing, to go into the IPFIX Architecture
draft.  Comments, improvements, etc. please ...

Cheers, Nevil

RTFM compared with IPFIX

(A) Definition of 'flow'

RTFM and IPFIX both use the same definition of flow; a flow is a set
of packets which share a common set of end-point address attribute values.
A flow is therefore completely specified by that set of values,
together with an inactivity timeout.  A flow is considered to have
ended when no packets are seen for at least the inactivity time.

RTFM flows are bidirectional, which has given rise to some confusion.
At the simplest level, a flow information exporter may achieve this
by maintaining two unidirectional flows, one for each direcion.  To
export bidirectional flow information, e.g. to- and from- packet counts,
for a flow from A to B, the exporter has only to search its flow table
to find the matching flow from B to A.

RTFM, however, takes bi-directionality a stage further, by including
in the RTFM architecture [RFC 2722] a fully-detailed algorithm for
realtime matching of the two directions of a flow.  This was done
for two reasons, to reduce the memory required to store each
flow (common address attributes for each direction), and to allow
for attributes which required fine detail for the two directions,
e.g. short-term bit rate distributions [RFC 2724].
** So far there has been no suggestion that IPFIX should do this.

(B) Configuration and Management

The RTFM architecture specifies a complete system for gathering
flow information.  It defines three entities,
 - Meters are very similar to IPFIX exporters.
 - Meter Readers are very similar to IPFIX collectors.
 - Managers co-ordinate the activities of meters and meter readers,
      and download configuration to them.

Note that the whole RTFM system is asynchronous, many readers may
collector flow data from a meter, and any reader may collect flow
data from many meters.

Rulesets allow the user to specify which flows are of interest,
which are the source and destination ends of each flow, and
what level of address granularity is required in the metered flows.
For example, on may select all packets from 192.168/16, but
build flow information for 192.168/24.  RTFM selection is
done by testing under masks, and the masks do not have to
use consective ones from the left.  Non-contiguous masks were
considered important for handling some OSI protocols, but the'
need for that has diminished considerably.

The RTFM approach is based on RMON, in that if a user wants to collect
flow data for some particular set of flows, this can be achieved by
writing a ruleset, i.e. an SRL program [RFC 2723], to specify what
flows are of interest, requesting a manager to download that ruleset
to a meter, and requesting the manager to have a meter reader
collect the flow data at specified intervals.

The details of how the manager communicates this information to meters
and meter readers is not specified in the architecture.  RTFM has a
Meter MIB [RFC 2720], which is a standard which can be used to
configure a meter, but nothing is said about how to configure a meter
reader.

The extent to which IPFIX should specify how meters or exporters
should be configured is, at this stage, an open question.  Clearly
a collector needs some way to be sure of what it's collecting,
e.g. by receiving 'templates' from the meter.

RTFM and IPFIX both leave parts of the system unspecified.  For RTFM
flow data to be useful one must know the ruleset used to configure the
meter, but a user can specify the ruleset.  For IPFIX one knows what
the data is from the templates, but we have yet to determine whether
in-band configuration will be supported.

(C) Data Model details

(C.1) Count in one bucket

Within a ruleset, a packet may only be counted on one bucket, i.e. it
may only be included in one flow.  This means that the meter does not
have to keep track of overlapping flows - if such aggregation is
required, it must be done after the raw flow data has been read by a
meter reader.

>From time to time one may wish to collect flow data for different
levels of aggreation at the same time.  RTFM allows a meter to run
several rulesets at the same time, and meter readers must specify
which rulesets they are collecting data from.

The 'count in one bucket' rule, together with the ability to run
multiple rulesets, has proved very simple and effective in practice.

(C.2) Counter wrapping

For its packet- and byte-count attributes RTFM uses continuously-
incrementing 64-bit counters, which are never reset.  This makes
asynchronous meter reading easy, any reader simply has to remember its
previous reading and compute the difference.  The only caveat is that
the meter should be read often enough to avoid situations when the
counter has cycled more than once between readings.

(C.3) Sampling issues

RTFM provides 1 out of N sampling as a configuration option, so
that some metering interfaces may only process every Nth packet.
The RTFM Arcitecture [RFC 2722] does not discuss the statistical
implications of this, merely saying that users will need to
satisfy themselves that sampling makes sense in their environment.

RTFM makes no provision for flow sampling.  Recently there has been a
lot of interest in flow sampling schemes which favour the 'most
important' flows, perhaps we need to consider this for IPFIX.  At this
stage, however, the effect of simpler schemes (e.g. 1 out of N flow
sampling) is onlypoorly understood.

(D) Application/transport protocol

RTFM has a standards-track Meter MIB [RFC 2720], which can be used
both to configure a meter and to read flow data from it.  The MIB
provides a way to read lists of attributes with a single Object
Identifier (clled a 'package'), which dramatically reduces the SNMP
overhead for flow data collection.  NeTraMet, a widely-used
open-source RTFM implementation, uses SNMPv2C for configuration and
data collection.

SNMP, of course, normally uses UDP as its transport protocol.
Since RTFM requires a reliable flow data transport system,
an RTFM meter reader must time out and resend unanswered SNMP requests.
Apart from being clumsy, this can limit the maximum data transfer
rate from meter to meter reader.  SNMP over TCP would be a better
approach, but that is currently an IRTF project.

On the other hand, RTFM does not specify an application protocol in
its architecture, leaving this as an implementation issue.  For
example, a team at IBM Research implemented a RTFM meter and meter
reader in a single host, with the reader storing the flow data
directly into a large database system.  Simlarly, many NeTraMet
user run the meter and meter reader on the same host system.

A need for high flow data rates highlights the need for careful
systems design when building a flow data collection system.  When data
rates are high, and it is not possible to use a high level of
aggregation, then it makes sense to have the collectors very close to
their exporters.  Once the data is safely on a dedicated host machine,
large volumes of it can be moved using 'background' techniques such as
FTP.

The RTFM architecture only specifies a pull model for getting
data out of a meter.  To implement push mode data transfer would
require specification of triggers to indicate when data should
be sent for each flow.

-------------------------------------------------------------
   Nevil Brownlee                     Internet Researcher
   Phone: (858) 534 8338                 CAIDA, San Diego

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/