Editor's note:  These minutes have not been edited.


REALTIME TRAFFICE FLOW MEASUREMENT WORKING GROUP 
MEETING, MONTREAL, 26-JUN-96

Minutes produced by Cyndi Mills and Nevil Brownlee 


REVIEW OF CURRENT DOCUMENTS

The current 'traffic flow measurement architecture' and 'traffic flow 
measurement meter mib' documents have been submitted for publicaton 
as experimental RFCs.

The 'experiences' document was published as an Internet Draft in May. 
Two changes were suggested:
(1) The term describing the former 'fail' or 'retry' action 
(indicating that an address has not matched a rule during a pass 
through the rule set) will be changed to 'NoMatch.' (2) In response to 
the question of whether flow type attributes should 
contain both source and destination separately; the consensus was that 
both should remain unless there is a specific future need to reduce the 
generality of the architecture. 

The original intention was to revise RFC 1272. The group agreed to 
leave RFC 1272 as is with its accounting focus, and produce new 
background information focussed on traffic flow measurement. This 
should address specifically the definition of flows as used in traffic 
flow measurement.

PRESENTATIONS

Presentations were made by the two current implementors of the traffic 
meter.

Sig Handelman has deployed the IBM implementation in a multi-
Ethernet environment. The meter has contained over 64,000 flows while 
maintaining good performance. Since the meter runs on a Unix system, 
the collection mechanism writes active flows periodically to a disk file 
for later collection by a bulk transfer mechanism. 

The NetFlow presentation by Nevil Browlee demonstrated uses of 
timing information provided by the meter to pinpoint 'interesting' 
flows, for example the protocols and attributes of short high-rate flows 
(bursts) and long-lived flows (sessions). Plots produced by NetFlow 
illustrated useful techniques for visualising complex relationship of 
flow age, protocol composition, and volume. 


NEW ARCHITECTURE FEATURES

The group agreed that the basic architecture is appropriate in its 
present form and began discussions to identify those attributes which 
might be added to extend its usefulness. In particular, the working 
group expressed the need for some of these new attributes to support 
emerging services and real-time flows. These discussions centered 
around requirements and features needed for the following areas: 

IP version 6
The working group should verify that the current architecture supports 
IPv6 and identify any desirable new attributes to support additional 
features of IPv6.

Application-layer attributes
In support of application level gateways (e.g. EDI, firewalls) and 
application level services (file transfer, messaging, etc.) there was 
interest in reporting generic application units (where the meaning of 
the unnamed unit is determined by the application, e.g. files for ftp, 
pages for html, etc) as well as generic error measurement (failures, 
sessions, retransmissions,...). A third set of capabilities would be the 
addition of application-defined pairs (name + count pairs.)

Rule Table matching extension
Proposed was an extension which would allow a rule table to 
distinguish between a source-dest and a dest-source match. 

Interpacket times
For the purpose of measuring jitter and delay, specifically in real-time 
applications such as audio and video packet streams, the working group 
desires an optional means for collecting interpacket delays and spacing. 
Interpacket times indicate either the time between packet sent and 
received (e.g. ping) or between two consecutive packets flowing in the 
same direction (e.g. video stream).

Support for resource-controlled flows
Additional attributes may be needed which support the comparison of 
expected and actual traffic flows.

Other Discussion
Sometimes it is necessary to use a single meter to collect information for 
several different purposes, e.g. deciding "who is using my network?" 
(which requires address aggregation and long collection intervals) and 
"how well is my network performing?" (which requires protocol 
aggregation and short collection intervals). The current architecture 
allows a meter to run two rule sets simultaneously, and for the flow 
data to be collected by multiple meters in an aysnchronnous manner.

REVIEW OF WORKING GROUP GOALS AND MILESTONES 

The working group produced a revised set of goals and milestones as 
follows:

Jun 96: Submit 'Traffic Flow Measurement: Architecture' and 
'Traffic Flow Measurement: Meter MIB' I-Ds for publication as 
experimental RFCs

Sep 96: Submit 'Traffic Flow Measurement: Experiences with 
NeTraMet' 
I-D for publication as RFC

Nov 96: Publish I-D on 'New Attributes for Traffic Flow Measurment' 

Dec 96: Select which new attributes will be included in the new 
proposed standard Traffic Flow Architecture. 

Mar 97: Submit architecture document(s) as proposed standard 
Begin work on implementation document

Jun 97: Submit implementation document for publication as an RFC 


ACTION ITEMS

The RTFM working group maintains a web page at 
http://www.auckland.ac.nz/net/Internet/rtfm/TOP.html Document 
editing team:
Cyndi Mills, Greg Ruth, Nevil Brownlee, Robert Bradshaw Revise 
experiences I-D:
Nevil Brownlee
Generate new background information:
Cyndi Mills
Edit new atttributes:
Greg Ruth, Sig Handelman

-----------------------------------------------------------------------