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:
· RTFM Working Group - New Attributes for Traffic Flow Measurement
· Traffic Flow Measurement: Meter MIB
· Traffic Flow Measurement: Architecture
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 |
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.
Submit to IESG for consideration as Proposed Standard RFCs.
April 1998 WG Last Call for New Attributes I-D.
Submit to IESG for consideration as Informational RFCs.
Example: SNMP ToTurnaroundTimes
Getting NeTraMet 4.1