2.7.9 Realtime Traffic Flow Measurement (rtfm)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97

Chair(s):

Gregory Ruth <gruth@gte.com>
Nevil Brownlee <n.brownlee@auckland.ac.nz>
Sig Handelman <handel@watson.ibm.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:rtfm@auckland.ac.nz
To Subscribe: majordomo@auckland.ac.nz
In Body: subscribe rtfm your-email-address
Archive: ftp://ftp.auckland.ac.nz/pub/rtfm/archive

Description of Working Group:

This working group has three main objectives:

* Consider current issues in traffic flow measurement, such as

- Security issues relating to both traffic measuring devices and to the data they produce.

- Policy issues relating to traffic measurement and usage accounting, for example any requirements these may place on emerging network protocols

- Existing work in traffic flow measurement, including that of IETF Working Groups such as bmwg/ippm, rsvp and rmonmib, as well as that by vendors and independent researchers

* Produce an improved Traffic Flow Model considering at least the following needs:

- wider range of measurable quantities, e.g. those relating to IPv6, and to class of service - simpler ways to specify flows of interest - better ways to control access to measured flow data - strong focus on data reduction capabilities - efficient hardware implementation

* Develop the RTFM Architecture and Meter MIB as 'standards track' documents with the IETF.

Goals and Milestones:

Feb 96

  

Submit set of revised Internet-Drafts and of RFC1272 to the IESG for considertation as Experimental Protocols.

Mar 96

  

Produce outline for 'New Traffic Flow Model' document

Jul 96

  

Submit 'New Traffic Flow Model' document as an Internet-Draft, and begin working on an implementation document.

Jul 96

  

Submit Internet-Draft on Flow Meter MIB.

Nov 96

  

Submit Implementation document as an Internet-Draft.

Nov 96

  

Submit 'New Traffic Flow Model' to the IESG to be considered for publication as an RFC.

Mar 97

  

Submit Implementation Internet-Draft to the IESG to be considered for publication as an RFC.

Jul 97

  

Submit Meter MIB I-D to IESG for consideration as Propsed

Aug 97

  

Publish revised and extended I-D on 'New Attributes'

Aug 97

  

Publish revised 'Architecture' I-D to cover new attributes

Dec 97

  

Submit I-Ds on 'New Attributes' and 'Architecture' for consideration as Proposed Standards

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2064

E

Traffic Flow Measurement: Meter MIB

RFC2063

E

Traffic Flow Measurement: Architecture

RFC2123

 

Traffic Flow Measurement: Experiences with NeTraMet

Current Meeting Report

Minutes of the Realtime Traffic Flow Measurement (RTFM) WG

Reported by Cyndi Mills

Scott Bradner discussed multicasting and its associated management and measurement issues, as set out in draft-bradner-multicast-problem-00.txt. Important issues include scaling, making multicast tools mirror their unicast predecessors, and making sure that multicast information is both pertinent and easily understood.

Sig Handelman reviewed the 'New Attributes' I-D, and asked for more input from the mailing list as to what further attributes should be considered, and how the new attributes should be implemented.

Nevil Brownlee explained how he had implemented the 'Distribution-Valued' attributes in NeTraMet, illustrating this with plots of TurnaroundTime for SNMP packets. It was suggested that two-dimensional distributions would also be interesting.

Nevil presented a proposal for using TCP sequence numbers as an indicator of the quality of a TCP stream. This was discussed; consensus was that the total number of TCP bytes transferred would be a useful RTFM attribute, but first and maximum sequence numbers would not. 'Skip' and 'retransmission' counters would also be useful, but these could not be aggregated.

Ian Graham and John Cleary of The University of Waikato reported via Nevil that they are measuring IP transit times (with real-time live transit time histograms across the Internet) using ATM. For details see http://atm.cs.waikato.ac.nz.

The IBM meter continues implementation of the RFCs and new I-Ds. They intend to make it available in some fashion in 1998.

Version 4.1.0 of NeTraMet was released on 26 Nov 97 and is fully RFC (and I-D) compliant. The NeTraMet 4.1 source files include 32-bit OC3MON source; OC3MON includes a NeTraMet meter as one of its analysis modules. New work includes a meter using input from Cisco NetFlow to observe packets. Some implications of this were discussed.

NetFlow reports terminated flows, rather than being able to check on flow status and "watching" current flows. With NetFlow running in a router you get source and destination AS numbers, which NeTraMet doesn't otherwise collect. NeTraMet cannot control what flows NetFlow reports, but can perform data reduction of them.

The WG reviewed its Goals & Milestones. The consensus of the meeting was that the Architecture and Meter MIB I-Ds need no further changes. A revised version of the New Attributes I-D will be published shortly. The WG's Goals and Milestones were revised as follows:

January 1998 WG Last Call for Architecture and Meter MIB I-Ds.

April 1998 WG Last Call for New Attributes I-D.

Slides

Example: SNMP ToTurnaroundTimes
Getting NeTraMet 4.1

Attendees List

go to list

Previous PageNext Page