Editor's note: These minutes have not been edited. +-----------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand | +-----------------------------------------------------------------------C Minutes of RTFM WG session at San Jose IETF, 0900 Wed 11 Dec 96 --------------------------------------------------------------- IMPLEMENTATION REPORTS: Stephen Stibler's experience developing IBM's RTFM implementation has clarified several aspects of the architecture which are reflected in the Architecture RFC and the Experimental MIB. The RTFM meter is implemented as a DPI RFC 1228 subagent and makes use of native multi-threading. Nevil Brownlee reported on current status and uses of NetraMet. NetraMet has been fully converted to use SNMP version 2C and extended to a 32-bit PC meter. The meter can now watch up to four interfaces and can do link-level passive monitoring with IP disabled on the monitored interfaces. In this configuration the monitor is not available as an IP destination, which eliminates the possibility of an IP-based security exposure from the monitored link. A secure network interface may be used to send collection data to a manager/reader. Collaboration with the OC3MON project has resulted in a version of the NetraMet meter which runs within the OC3MON monitor, implemented and tested in early December 1996. This, combined with experiments on 100Mbps Ethernets, demonstrates that the RTFM architecture scales appropriately to high-speed networks. NEW ATTRIBUTES AND CHANGES: Sig Handelman presented the three areas in which new attributes are being defined. The goal is to keep intact the original RTFM meter structure and its data reduction characteristics. Additions will be simple statistics which benefit from the ability of RTFM to identify and consolidate flows of interest with specific granularity across multiple protocol layers. The three areas are packet tracing for specific flows, simple aggregates over a time interval, and series of specific attributes such as packet inter-arrival times. Discussion demonstrated interest in packet inter-arrival times, tracing of specified packet attributes or header fields in exception conditions, and tracking of TCP window size. The question arose of whether we should implement threshholds and traps; this area was not covered by the internet draft. It was pointed out that RTFM's view of flows as basically bi-directional may simplify the measurement of certain delay metrics, such as measuring the time between a window offer and window accept or TCP SYN to ACK. A number of proposed changes to the Experimental RFTM Meter MIB were discussed: * The MatchingStoD attribute will allow a single rule to determine whether a packet is being matched with the addresses in 'wire' order (StoD) or in reverse order. It was agreed that this wuold be useful useful - it will be further discussed on the mailing list. * A mechanism for reading flow table rows was discussed briefly. This would replace the present method of reading parts of flow table columns. * Metering inside tunnels has been requested by NeTraMet users. The Architecture already provides for this by allowing Adjacent Addresses to include Peer Addesses - inside an IP tunnel, Adjacent Addresses are the IP addresses of the tunnel's end points. REVIEW OF WG STATUS: Accomplished Goals and Milestones: Jun 96: Submit 'Traffic Flow Measurement: Architecture' and 'Traffic Flow Measurement: Meter MIB' I-Ds for publication as Experimental RFCs. <<< Approved by IESG, now in RFC queue Sep 96: Submit 'Traffic Flow Measurement: Experiences with NetraMet' I-D as informational. <<< Approved by ADs, now in RFC queue Nov 96: Publish I-D on 'New Attributes for Traffic Flow Measurement' <<< published and available at IETF web site Dec 96: Select new attributes to be included in the proposed standard Traffic Architecture. After discussion, it was decided to put forward the existing Architecture and Meter MIB as proposed standards at the NEXT meeting. Proposed extensions should be sufficiently articulated in the meantime so that any modifications needed to the existing RTFM structures can be put forward as part of the proposed RTFM 'base' standard. The group's revised milestones are: March 97: Publish new I-Ds for Architecture and Meter MIB Publish revised I-Ds for 'Extended Attributes' April 97: Submit Architecture and Meter MIB I-Ds to IESG for publication as Proposed Standard RFCs August 97: Submit I-Ds on 'Extended Attributes' as Standards Track RFCs URLs: IETF WG Information: http://www.ietf.org RTFM Information: http://www.auckland.ac.nz/net/Internet/rtfm OC3MON information: http://www.nlanr.net/NA/Oc3mon/ Minutes by Cyndi Mills Minutes of the RTFM/IPPM Joint Session, 0900, Thu 12 Dec 96 ----------------------------------------------------------- Overview of RTFM Nevil Brownlee presented a brief overview of RTFM. RTFM has been a working group for about a year. It was an outgrowth of an earlier effort in accounting, meaning defining, measuring and flexibly aggregating flows of interest. The RTFM Architecture includes Meter, Manager, Meter Reader, Analysis Application, and Rule Sets. It allows you to download a lot of the analysis into the meter. It can replace tcpdump by putting front end data reduction at the meter. One may place meters far away over even slow links, and can pull back partially reduced data from the meters. Rule sets define bi-directional flows. RTFM has three levels of addresses - adjacent, peer and transport; this allows very detailed specification of flows. Nevil discussed how assymetric flows are handled by RTFM's bi-directional flow mechanism. Sig Handelman presented the three areas in which new RTFM attributes are being defined. The goal is to keep intact the original RTFM meter structure and its data reduction characteristics. Additions will be simple statistics which benefit from the ability of RTFM to identify and consolidate flows of interest with specific granularity across multiple protocol layers. The three areas are packet tracing for specific flows, simple aggregates over a time interval, and series of specific attributes such as packet inter-arrival times. DIFFERENCES between RTFM and IPPM RTFM IPPM ---------------------------- -------------------------------------- Passive Active Confidential Data User data not examined Real Usage Prepared stream Useful at edges and choke Useful at two points on opposite side points of IP clouds of IP clouds In-service meter Treats IP clouds as black boxes RTFM is an existing measurement IPPM is approaching performance technique with specific questions, developing/adopting metrics/tools technologies/tools and techniques which answer those questions. The above points summarise a lengthy and interesting discussion Others included: * The meter does not supply enough information to allow one to model the state of the TCP flow control at the endpoints. Being able to do so is possible with passive tools designed for the purpose. * Tools based on the RTFM meter might be strong at indicating *when* a problem is likely occuring, but comparitively weak at indicating *why* the problem is occuring. This indicates a complementary relationship -- not a problem. * As with all passive tools, use of the RTFM meter within the core of the Internet must honestly address significant privacy concerns. * Given the presence of asymmetric routes, any RTFM meter deployed within the core of the Internet will often see one direction of a two-way TCP flow. Very close time synchronization would be required to allow measurements on the two one-way flows to be patched back together. TECHNOLOGY INTERACTIONS between RFTM, IPPM and RMON RMON is different from RTFM. An RMON probe collects a wide variety of data from the monitored network; a Network Management Sysytem can use this data to display the network status to a user. RTFM performs useful front-end data reduction, and - through its rule sets - allows a user very detailed control over which flows are of interest, and what data is to be collected for each of them. At the same time, RMON and RTFM share the same basic MIB structure, making it possible for an RTFM meter to be implemented within an RMON probe. RMON2 provides higher-layer protocol analysis, and selective packet tracing. It was agreed that RTFM should focus on real-time aspects which RMON is not currently addressing. Several participants asked whether an RTFM meter might also operate as an (active) IPPM probe. Consensus was that this does not fit within the RTFM architecture, however it may well be useful to run such a probe on the same machine as an RTFM meter. There are a number of concerns shared by RTFM and IPPM. Clock synchonisation is vital so that measurements on several probes can be accurately corelated. The security of observed traffic data is also very important. The Argus package was discussed. Argus was designed as a method of saving packet information with enough detail to allow site managers to reconstruct packet streams months after an attempted security violation was observed. It differs from RTFM in that RTFM summarises information about all packets in a flow. There is a very high level of interest in monitoring TCP sessions, with several different groups actively working in this area. For this reason it will be sensible for RTFM to regard TCP session analysis as a low priority goal. PRIMARY REQUESTS FOR RTFM EXTENSIONS Focus first on extensions which are not provided by RMON and satisfy real-time needs, such as measurements which are useful in determining jitter and delay characteristics. For example: 1) Packet inter-arrival times. 2) Monitor flows so as to detect flows which are not responding to congestion control. =====================================================================