From owner-rtfm@auckland.ac.nz Thu Aug 3 22:54:27 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09272 for ; Thu, 3 Aug 2000 22:54:24 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id MAA26875; Fri, 4 Aug 2000 12:52:45 +1200 (NZST) Received: from compaq-nb.ietf.marconi.com (bluebottle.itss.auckland.ac.nz [130.216.4.28]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id MAA26855 for ; Fri, 4 Aug 2000 12:52:39 +1200 (NZST) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: Minutes of Pittsburgh RTFM meeting Message-ID: Date: Fri, 4 Aug 2000 13:55:55 +1300 (DST) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Minutes of the RTFM get-together, Pittsburgh, Wed 2 Aug 00 The meeting was held in South 3, starting at 1140; nine people attended. The main purpose of the meeting was to consider whether there are new items which would justify restarting the RTFM Working Group. For this to happen we must produce Internet Drafts which describe the proposed work items, making it clear why the item is something which needs to be standardised, and demonstrating that there is good support for it. Three possible work items were discussed: 1. A method of changing rulesets while they are running on an RTFM meter Marcelo Pias (BT, London) gave a short presentation of work done by himself and independently by Juergen Quittek (NEC, Berlin). The need here is for an API which can be used when developing new RTFM-based applications so that the developer - Doesn't have to understand the details of SNMP and the Meter MIB - Doesn't have to create rulesets using SRL Such applications would provide methods of - Creating new rulesets, and adding rules to them - Making a copy of a running ruleset - Interchanging a new ruleset with a running ruleset Rulesets created in this way would probably be fairly simple, but be targeted at particular application areas. The work item will include - Defining the API (and all the functions it provides) - Specifying any extensions to the meter architecture which are needed to support the API - Considering what happens to existing flows in a meter when a running ruleset is changed *** Marcelo and Juergen will write an I-D: Generalised Meter Interface 2. Extending the RTFM Architecture (and Meter MIB) to cover some of the New Attributes Nevil Brownlee (University of Auckland) has implemented all of the distribution-valued attributes from RFC 2724, and has about 18 months of experience in using them. These need to be added to the Architecture document, and the Meter MIB needs to be extended so as to describe how distribution values are stored and retrieved. Recently a need for a new kind of attribute value - list-valued - has arisen, as follows. - All of the RTFM address attributes have values in each packet for both directions of their flow, e.g. every packet has values for both SourcePeerAddress and DestPeerAddress. The RTFM packet-matching algorithm depends on having both of these, so that they can be swapped when attempting a match in the reverse direction - Attributes such as DSCodePoint and NetFlow's NextHop have only one value in each packet, hence they can't be used in packet matched - Instead, we can build two tables of (value, count) pairs, one for each direction of the flow. I describe such a pair of tables as a list-value *** Nevil will write an I-D: RTFM Attribute Extensions 3. A Standard Packet Capture Architecture Carter Bullard (Quotient) raised the need for new architecture for capturing packets. Packet capture would be done on a remote box, with the captured packets (from one or more such boxes) sent back to a central point. Design goals for the system include: - Capture packets efficiently at high link speeds - Record accurate (sub-microsecond) timestamps for each packet - Record only a specified part of each packet, e.g. IP header, UDP/TCP header, first n bytes of payload, etc. - Provide various kinds of filtering and/or sampling, e.g. only UDP/DNS packets, only packets to/from 10.0.0.1, every nth packet, etc. - Packets should be sent to the central point with a header which includes the timestamp, the interface and the host it was captured on Such a packet capture system could sit well with an RTFM meter, or within an RMON probe (probably depending on whether one wants to specify filters using RTFM attributes or RMON protocol IDs); Carter will talk to RMON and IPPM about it. Georg Carle (GMD-Fokus, Berlin) also has a strong interest in this activity. He presented some slides of his proposed architecture for policy-based packet capture, including authorisation and sampling algorithms. *** Carter and Georg will write an I-D: Packet Capture Architecture Next steps: The people listed above will write their I-Ds, posting copies to the RTFM list from time to time. When the I-Ds are complete the authors will publish them as individual I-Ds (they can't be RTFM I-Ds since the RTFM WG is dormant). Once the I-Ds are published I'll ask our ADs for a BOF session at the next IETF, i.e. San Diego in December 2000. To do this we should aim to get the I-Ds published by the beginning of October. The meeting finished at 1355. Notes by Nevil Brownlee. Disclaimer: I've expanded my written notes with what I remember of our discussions. If I've got it wrong, please post corrections to the list. -------------------------------------------------------------------- Marcelo has sent me a copy of his slides. I'll put them (together with these minutes and any other presentation slides) on the RTFM web page. Cheers, Nevil +---------------------------------------------------------------------+ | 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 From owner-rtfm@auckland.ac.nz Tue Aug 8 14:09:16 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01157 for ; Tue, 8 Aug 2000 14:09:15 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA25620; Wed, 9 Aug 2000 04:26:46 +1200 (NZST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id EAA25612; Wed, 9 Aug 2000 04:26:39 +1200 (NZST) Received: from riogrande.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Aug 2000 17:26:27 +0100 Date: Tue, 8 Aug 2000 17:25:33 +0000 (UTC) From: Marcelo Pias To: n.brownlee@auckland.ac.nz cc: rtfm@auckland.ac.nz Subject: ECN attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Nevil, Last January I started some experiments/implementation for ECN(Explicit Congestion Notification) described in RFC 2481. My proposal would be to add a set of attributes for ECN measurements (QoSEcnCongestionExperienced...) as either packet distribution or packet trace forms. Perhaps this may be covered in your I-D re distribution values and MIB extensions... Cheers. Marcelo From owner-rtfm@auckland.ac.nz Wed Aug 30 09:36:58 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28903 for ; Wed, 30 Aug 2000 09:36:57 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA29548; Wed, 30 Aug 2000 23:33:36 +1200 (NZST) 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 XAA29543 for ; Wed, 30 Aug 2000 23:33:31 +1200 (NZST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA09582; Wed, 30 Aug 2000 13:31:44 +0200 (CEST) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id NAA08370; Wed, 30 Aug 2000 13:31:44 +0200 (CEST) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Wed, 30 Aug 2000 13:31:44 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: Undisclosed recipients: ; Subject: PAM2001 Call For Papers 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 Call for papers A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 Program Committee: Henk Uijterwaal RIPE-NCC, NL, Conference Chair Nevil Brownlee U.Auckland, NZ Randy Bush Verio, USA kc Claffy CAIDA, USA Les Cottrell SLAC, USA Geoff Huston Telstra, AU Daniel Karrenberg RIPE-NCC, NL Ian Graham U.Waikato, NZ Yasuichi Kitamura APAN, Japan Will Leland Telcordia, USA Tony McGregor U.Waikato, NZ Ronn Ritke NLANR, USA Rick Whitner Agilent, USA 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. Papers are invited from the research, provider and any other communities on topics in the areas above, or any other area of network traffic measurement. Areas of interest include, but are not limited to: 1. 'Experience' papers, which describe practical uses of measurements, especially in large networks. 2. Papers on modelling network traffic, in particular if they are backed up by measurements of real traffic. 3. Papers describing network research that can be applied to existing networks. Extended abstracts (about 500 words, plain ASCII preferred) must be submitted by e-mail to pam2001@ripe.net by 12 November 2000. Paper submissions must contain the following: paper title, full name(s) of the author(s), organisational affiliation(s) and 1 email address where the author(s) can be contacted. Abstracts will be reviewed and acceptance notified no later than 18 December 2001. Papers, maximum 15 printed pages, must be submitted electronically by 5 March 2001. Details of acceptable paper formats will be published on the conference web site, http://www.ripe.net/pam2001 There will be an opportunity 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. The program committee is investigating the possibility of organising one or more tutorial sessions in conjunction with the conference. Proposals for tutorials (about 500 words, plain ASCII) should be sent by email to the conference chair by 12 November 2000. The workshop will be held at the Barbizon Golden Tulip hotel in Amsterdam. Special room rates will be available for the conference. The conference fee will be (approximately) 175 Euro (US$165). The exact conference fee and details on registration will be published on the workshop's web page late November. The conference fee will include a printed copy of the papers selected for presentation at the workshop. Papers selected for publication will also be published on the web. Important dates: * 12 November 2000: Deadline for abstracts * 18 December 2000: Notification of acceptance * 5 March 2001: Final papers due * 23-24 April 2001: Conference 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.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780).