From owner-rtfm@auckland.ac.nz Wed Jan 3 10:46:13 2001 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26095 for ; Wed, 3 Jan 2001 10:46:11 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA26634; Thu, 4 Jan 2001 02:57:11 +1300 (NZDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA26629 for ; Thu, 4 Jan 2001 02:57:09 +1300 (NZDT) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id OAA19191; Wed, 3 Jan 2001 14:53:19 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id OAA14070; Wed, 3 Jan 2001 14:53:19 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 3 Jan 2001 14:53:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Undisclosed recipients: ; Subject: PAM2001 registration opens Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Passive & Active Measurement: PAM-2001 Registration Opens A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 As the Internet has grown over the last decade the need for precise measurement of network traffic has become steadily more apparent; most of today's Internet Service Providers and many of their large network customers are collecting and analysing traffic data for the purposes of performance monitoring, network engineering and cost recovery, but the engineering quality of these measurements vary. A steadily growing number of research groups have been working in the areas of: - Active Measurements, i.e. sending test packets and observing their progress through the Internet, - Passive Measurements, i.e. observing actual traffic on 'live' networks, - Performance Metrics, i.e. developing measures or indicators which can be used to characterise traffic behavior, - Traffic Statistics, i.e. attempting to understand and develop models of 'real' Internet traffic, and - Visualisation, i.e. finding effective ways to display what's happening in a network. After the successful workshop PAM2000 in Hamilton, New Zealand, in April 2000, the RIPE NCC will be organising another workshop on this topic in Amsterdam in April 2001. Registration for this workshop has now been opened. To register online, go to: http://www.ripe.net/cgi-bin/pamreg Also available on the web-site are the preliminary program: http://www.ripe.net/pam2001/program.html as well as general information on the workshop: http://www.ripe.net/pam2001/ and hotel information: http://www.ripe.net/pam2001/hotels.html Rooms are available at the conference hotel. The rate is 285 Euro/night (including taxes, approximately 255 US$). To reserve a room, call, fax or email the hotel. Contact details can be found on the web page. If you prefer to stay in another hotel, then there are rooms available in all price classes between 35 Euro/night and 1500 Euro/night within a 5 km radius of the conference site. A selection of hotels and links to reservation sites can be found on the webpage. There are still opportunities for participants to present measurement equipment and software. Proposals for demonstrations (about 500 words, plain ASCII) should be sent by email to the conference chair at pam2001@ripe.net by 5 March 2001. Contact information: * PAM 2001 c/o RIPE-NCC Singel 258 1016 AB Amsterdam The Netherlands * Phone: +31.20.5354444 * Fax: +31.20.5354445 * Email: pam2001@ripe.net * Webpage: http://www.ripe.net/pam2001 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) From owner-rtfm@auckland.ac.nz Sun Jan 7 22:37:39 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13249 for ; Sun, 7 Jan 2001 22:37:37 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id OAA21691; Mon, 8 Jan 2001 14:49:13 +1300 (NZDT) Received: from violin.dcs.uky.edu (violin.dcs.uky.edu [204.198.75.11]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA21672; Mon, 8 Jan 2001 14:49:09 +1300 (NZDT) Received: from homer.dcs.uky.edu (IDENT:swami@homer.dcs.uky.edu [204.198.75.144]) by violin.dcs.uky.edu (8.9.1a/8.9.1) with ESMTP id UAA13269; Sun, 7 Jan 2001 20:49:05 -0500 (EST) Date: Sun, 7 Jan 2001 20:49:05 -0500 (EST) From: Swaminathan Natarajan To: rtfm@auckland.ac.nz cc: n.brownlee@auckland.ac.nz Subject: Response message too large? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello, I am trying to use NeTraMet and NeMac to measure packets matching a source-destination address pair and DSCodePoint value every 10 secs. The command I use to start NeTraMet is: ~swami/bin/NeTraMet -r readComm -w writeComm -i eth1 -k -l & The command I use to start nemac is: ~swami/bin/NeMaC -b ~swami/netramet/share/NeTraMet/mibs/mib.txt -c10 -r rules.rule -t -v -L nemac.log -F nemac.flow 192.168.76.32 writeComm netramet and nemac are run in the same machine which is linux(debian) and eth1=192.168.76.32. netramet gives no errors but nemac generates no flow file and generates the foll. log file. nemac.log *************log file****************** 21:25:05 Sun 7 Jan 2001 -- Starting NeMaC: NeTraMet Manager & Controller 4.4b8 21:25:05 Sun 7 Jan 2001 -- meter_info(): Error in packet, reason = Response message would have been too large. 21:25:05 Sun 7 Jan 2001 -- Couldn't get meter info from 192.168.76.32! 21:25:05 Sun 7 Jan 2001 -- Does community writeComm have read or write access to the meter? 21:25:05 Sun 7 Jan 2001 -- meter_info(): Error in packet, reason = Response message would have been too large. 21:25:05 Sun 7 Jan 2001 -- meter_info(): Error in packet, reason = Response message would have been too large. 21:25:05 Sun 7 Jan 2001 -- 192.168.76.32: No response 21:25:10 Sun 7 Jan 2001 -- meter_info(): Error in packet, reason = Response message would have been too large. 21:25:10 Sun 7 Jan 2001 -- meter_info(): Error in packet, reason = Response message would have been too large. 21:25:10 Sun 7 Jan 2001 -- 192.168.76.32: No response 21:25:15 Sun 7 Jan 2001 -- meter_info(): Error in packet, reason = Response message would have been too large. 21:25:15 Sun 7 Jan 2001 -- meter_info(): Error in packet, reason = Response message would have been too large. 21:25:15 Sun 7 Jan 2001 -- 192.168.76.32: No response 21:25:15 Sun 7 Jan 2001 -- ruleset_util(Destroy): Error in packet, reason = noCreation 21:25:15 Sun 7 Jan 2001 -- ... flowMIB.flowControl.flowRuleSetInfoTable.flowRuleSetInfoEntry.flowRuleInfoStatus.0 21:25:15 Sun 7 Jan 2001 -- NeMaC Shutting down ************END************** The error has obviously something to do with SNMP message exchanges. But I have not been able to figure out the cause/solution to the problem (i believe the ruleset is correct). Can anyone help me?! Are there any resources that describe error messages generated by nemac/netramet? I would gratefully appreciate your help! Thanks! Swami. From owner-rtfm@auckland.ac.nz Mon Jan 8 00:00:05 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14178 for ; Mon, 8 Jan 2001 00:00:04 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id QAA08040; Mon, 8 Jan 2001 16:43:11 +1300 (NZDT) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id QAA08033 for ; Mon, 8 Jan 2001 16:43:10 +1300 (NZDT) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: RTFM2 BOF minutes, mailing list info Message-ID: Date: Mon, 8 Jan 2001 16:43:47 +1300 (New Zealand Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: Herewith the minutes of the RTFM2 BOF held at the 49th IETF meeting in San Diego. I've updated the RTFM web page (www.auckland.ac.nz/net/Internet/rtfm) to include these minutes, with PowerPoint files for each of the presentations at the meeting. The web page also has information about this mailing list and its archive. Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P 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. Discussion: * 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. Questions: * 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. Comments: * 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. ------------------------------------------------------------------ From owner-rtfm@auckland.ac.nz Mon Jan 29 23:34:04 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17211 for ; Mon, 29 Jan 2001 23:34:02 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id PAA17920; Tue, 30 Jan 2001 15:37:26 +1300 (NZDT) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id PAA17913 for ; Tue, 30 Jan 2001 15:37:25 +1300 (NZDT) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: DRAFT charter for proposed RTFM2 WG Message-ID: Date: Tue, 30 Jan 2001 15:38:04 +1300 (New Zealand Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: Back in December we held a well-attended BOF session at the San Diego IETF meeting. Consensus of the meeting was that not only were there worthwhile things for a new Working Group to do, but there were people at the meeting who were preapred to do the work. The BOF minutes (on the RTFM home page at www.auckland.ac.nz/net/Internet/rtfm) record our consensus that we should work on a draft charter on the RTFM email list. I've been waiting for some guidance on a proposed charter from our Area Directors, but I see that scheduling is open now for the next IETF meeting in Minneapolis next March. If we want a session there, we need to get moving. To kick off discussion, I've attached a draft WG charter below. Would you please read it, and: a) If you think the draft charter is badly worded, doesn't say the right things, or leaves out things which you think are important, send your comments to the list. b) If you (and/or your company) would be prepared to work on documents, please, please send a note saying which ones either to the list, or directly to me. If a new WG is to be chartered, we need to demonstrate strong support for it, and well-defined goals. Tell us what you think! Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P Charter for a Proposed RTFM2 Working Group **** DRAFT **** Fri 15 Dec 00 **** In October 1999 RFCs 2720-2724 were published, specifying the RTFM Traffic Measurement Architecture. Since then many sites have been using the NeTraMet implementation for production traffic data collection, and others have used it as the basis of further developments in the field of network traffic measurement. From this development work a need has arisen to extend the RTFM Architecture. Furthermore, over the last few years interest in flow measurement has steadily increased, and many commercial products for this are now available. Experience in this field indicates that although the current RTFM architecture provides a very general definition of flows and an effective method of collecting flow data, there is a clear need for new, standard approaches to this problem. As well as extending the original RTFM architecture, the Working Group will develop new approaches to traffic flow measurement, as follows .. Goals: 1 Develop a standard for describing traffic flows, and for reporting them from a meter to a flow flow data collection system. Such a standard would meet a clearly-expressed need for many system vendors. 2 Define a distributed metering architecture to support metrics defined within the IPPM framework, e.g. one-way delay, connectivity, one-way loss rate. This architecture will include remote packet capture, and will addres privacy concerns such as the inadvertant disclosure of user information and the need to authenticate and authorise access to captured data. 3.1 Develop a high-level interface to the current RTFM system, so as to make RTFM capabilities easily and directly accessible to new application programs. 3.2 Standardise some of the 'new attributes' described in RFC 2724. Extend the RTFM architecture, e.g. by adding 'list-valued' attributes to the RTFM meter. Milestones: Documents [questions, comments/suggestion please.. - what other documents will be needed? - what should be in the documents (ideas for a 'contents' list for each would be very welcome!) - who's volunteering to contribute to them? - when could first drafts be ready? ] * RTFM2 Flow Definition and Reporting Scheme Defines a flexible description of flows which all vendors can use when configuring meters. The flow definitions should be flexible enough to handle layer 2, 3 and 4/5 attributes, making them suitable for traffic engineering, accounting, and network operations for at least all IETF-specified protocols. Specifies protocol for reporting flow data from meters. * Requirements for Distributed Metering * Architecture for Distributed Metering * Remote Packet Capture Protocol * Distributing Metering Control Protocol * High-Level Interface to RTFM * Revised RTFM Architecture * RTFM Meter MIB Extensions -------------------------------------------------------------------------------