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 -----------------------------------------------------------------------