2.7.22 Development of the Realtime Traffic Flow Measurement Architecture BOF (rtfm2)

Current Meeting Report

Minutes of the RTFM2 BOF, Thursday, December 14, 2000
Co-chairs: Brownlee, Bullard, Quittek

One-para summary ..

133 people attended, four Internet Drafts were presented. They were well-received and generated enthusiastic discussion. Strong support - and interest in participating and contributing - was expressed for a Working Group not only to develop these drafts, but also to address three further issues: push technology in the RTFM traffic Meter, a standard method for describing and reporting flows, and the development of a distributed metering system.

133 people were present About 1/3 of those present had some understanding of RTFM, making further introductions unnecessary. The agenda (as on the IETF meeting pages) was accepted without comment.

Nevil Brownlee presented his draft on 'Implementing New Attributes,' which proposes to implement enhancements to the current RTFM architecture. Most of these are part of RFC 2724, but 'list-valued' attributes and flow-size filters are new.
* Is it better to measure flows in the core or at access points? Performance issues may require us to modify abstraction; some discussion of core vs edge in the draft is needed.
* Could you measure BER within the RTFM framework? Because of layer boundary issues BER may not be a measurable metric.
* It may be hard to measure loss or delay because of asymmetric and performance issues. This may need to be addressed in the framework.

Juergen Quittek presented his draft on 'High-Level Interface to the Traffic Flow Measurement Architecture.' This proposes an improved interface for managing RTFM meters, making it easier to use them in network operations.
* Definition of flows, interface sand some specific applications are similar to those in INTSERV. It would be interesting to align flows and flow characterizations with those in the INTSERV definitions.
* The current RTFM meter control and data-gathering interfaces are not clearly distinguished. This could be improved. (Dan Romascanu)
* Accounting systems (used by ISPs) uses push technology, which is popular. The RTFM architecture would be improved if it included the ability to push flow data.
* Many vendors have proprietary strategies for flow collection and analysis. A new high-level interface should allow for more general flow collection mechanisms.
* The RTFM architecture document (RFC 2722) emphasises bi-directional monitoring above other modes of operation, suggesting that when you can't see both sides of the flows, the rTFM architecture would break down. This needs to be better explained.

Carter Bullard presented his draft on Remote Packet Capture, which would allow the capture of specified headers within packets at very high speeds, and their transmission (with a 'captured packet encapsulation header') back to a central metering point.

Georg Carle briefly presented his draft on Packet Capture Extensions, which proposes more efficient filtering and packaging of remotely captured packets before they are transmitted to the metering point.

Both speakers emphasised the need to address privacy concerns. In particular, the disclosure of user is addressed by both proposals, together with the need to authenticate and authorise access to captured data.
* How should we address clock synchronisation concerns? This is well covered within the IPPM Framework.
* This proposal introduces a lot of new functionality, which vendors may find difficult to integrate into their products. We intend to get some chip manufacturers involved so as to ensure that the proposal can actually be implemented.
* Does packet capture belong within RTFM2? RMON and RTFM are the primary IETF technologies that would use this form of packet capture, and RMON has a busy work schedule for most of next year. RTFM2 will work co-operatively with RMON and IPPM to develop this proposal.
* Support - indeed commitment - was expressed for the development of distributed metering systems within RTFM2.
* Can this be done at OC192? Yes, provided we can get chip manufacturers involved in the project. The important thing for RTFM2 is to produce a clean specification for packet capture.

Conclusion ..

The meeting provided two hours of interesting discussion. Support was expressed for the goals outlined in the BOF charter (2/3 audience raised hands), i.e.
a) Standardise some of the 'new attributes' described in RFC 2724. Extend the architecture, e.g. by adding 'list-valued' attributes to the RTFM meter.
b) Develop a high-level interface to RTFM, so as to make RTFM capabilities easily and directly accessible to new application programs.
c) Develop a high-speed remote packet capture ability, so as to provide a distributed source of packet data for RTFM meters.

However, the discussion introduced three further goals, i.e.:
1. Push technology issues in RTFM.
2. Standard for flow reporting.
3. Distributed metering..

Several attendees committed themselves to contribute to the proposed RTFM2 WG.

The BOF co-chairs proposed to send minutes of this meeting, together with a proposed charter for a new Working Group ,to the RTFM mailing list for further discussion. When rough consensus is reached, the co-chairs will discuss the proposed charter with our Area Directors, before asking them to submit it to IESG.

This proposal was strongly supported.


Implementing TCP Attributes
Remote Packet Capture
Real-time Flow Management 2 BOF
High-Level Interface to the Traffic Flow Measurement Architecture
Experience at Auckland with SRL and NetFlowMet