Passive ISMA 9901 survey question answers

Abha Ahuja

Paul Barford

Kathy Benninger

1. Kathy Benninger
   Pittsburgh Supercomputing Center
   Systems Engineer
   
   My activities in this area are only very recent so please see my answer to 2. below.
2. Integration of OC3mon to monitor PSC's production network.
3. Work with production and research networking staff to analyze and understand the implications of data collected from PSC's OC3mon.
4. OC3mon
5. From my admittedly brief exposure to working with monitoring via OC3mon, one of the critical issues seems to be deciding what data to look at. Perhaps underlying that issue is identifying precisely what it is that we hope to find out from the data.
6. Identification of relevant URLs covering tools or initiatives in this sector:
   

Nevil Brownlee

Keith Burden

Ramon Caceres

Kavitha Chandra

k claffy

Stephen Donnelly

Phil Emer

Shobha Erramilli

1. Shobha Erramilli, Research Scientist in the Computer Communications Research group in Bellcore. Involved in network level performance and QoS measurement in IP and ATM networks.

2. Co-developed Bellcore's Differentiated Services testbed and tools for measuring Internet service quality measures such as IP throughput, packet loss ratio and one-way packet delay. The testbed consists of passive monitors and analysis software that capture IP packets along a given path and compute the various performance metrics on a per-class basis. A Web-based controller is used to schedule the passive monitors, the traffic streams and the subsequent analysis.

3. Extending the previously described tool to analyze the service quality metrics on a per-flow basis. Also, plan to integrate the passive monitoring tool into a network traffic management system.

4. tcpdump for collecting packets, NTP for synchronizing monitor clocks and netperf for generating traffic on the testbed.

5. Metrics that are easily measureable, give an accurate picture of both network conditions and user-perceived performance. Lighweight monitors , either standalone or integrated with network elements, need to be deployed in the network so that they can be integrated with the congestion management and capacity planning functions

6. (no URLs given)

Wenjia Fang

Steve Feldman

Anja Feldmann

1. Anja Feldmann
   AT&T Labs-Research
   
   The importance of the Internet is rapidly growing. In the Internet the intelligence is in the end-systems. Because of the diversity of these systems, their applications, and the communication protocols the Internet is a beast. Existing analysis is hardly scratching the surface in providing abstractions and understanding that are taken for granted in other contexts. This includes understanding how user behave, how traffic matrices change, and how to provide performance guarantees. Over the last years I have been involved in building and maintaining an measurement infrastructure for collecting data about an ISP. Most of my research has focused on the science of understanding, describing, and modeling this data.
2. Together with A. Gilbert, and W. Willinger, I am investigating how the state of the network is influencing the spacing of packets and thus leaves a signature on small time scale network measurements. We have empirically established the presence of complex scaling phenomena (i.e., multifractal scaling) in data traffic over small time scales and identified its main cause -- networking mechanisms such as TCP and end-to-end congestion controls. A mathematical framework based on wavelets, cascades, and multifractals builds the foundation for analyzing and describing the observed small-time scaling properties of the measured traffic. We have demonstrate that the new mathematical framework is capable of detecting and identifying local irregularities in a given set of network measurements.
   
   Regarding the interactions with applications I together with G. Glass, R. Caceres, F. Douglis, M. Rabinovich are using real HTTP traces to evaluate the performance of WWW caching for modem users. The results clearlz demonstrate that the interactions of the network with the application behavior matter.
3. Understanding which timescale is relevant for which aspect of traffic engineering in the Internet.
4. Tools: tcpdump, (httptrace extension to tcpdump that can extract full HTTP headers), Perl, Splus, Wavelets, NS, lots of disk space:-)
5. See above. Understanding the beast of an Internet.
6. Identification of relevant URLs covering tools or initiatives in this sector:
   
   

Vince Fuller

1. Vince Fuller, Senior Network Architect at GTE Internetworking. One of the members of the GTE-I group which designed and built the current GTE-I backbone and are in the process of building its next-generation replacement. Involvement with Internet stats and metric analysis has been the development of some simple tools for monitoring and charting link utilization on the network and in specifying traffic flow information needed from tools developed by other groups (mainly based on cflowd data collection).

2. Working with other groups in GTE-I to use information derived from cflowd analysis to do quantify data transport costs and do capacity planning.

3. Continuation of above.

4. Am a consumer of reports generated by tools that analyze cflowd data.

5. It is essential that the costs involved transporting data be accurately quantified and recovered. If this problem is not solved, it will not be possible to continue to scale the Internet as providers cannot indefinitely continue to build expensive infrastructure without the cost of doing so being covered.

6. (no URLs supplied)

Ian Graham

Hervé Guy

Sig Handelman

Stan Hanks

1. Mr. Hanks has been at the forefront of change in internetworking for nearly twenty years, starting with experimental work in distributed computing during the early days of TCP/IP on the ARPAnet. He is responsible for the invention of the GRE tunneling protocol and deployment of the first carrier IP VPN in 1991, development of a metropolitian area Layer Two facility that grew into MAE East, and has been involved in many NSP and ISP start-up efforts. Mr. Hanks graduated from Rice University with degrees in computer science and electrical engineering, which were followed by five additional years there in the Ph.D. program in computer science. He has been active in many user organizations, standards bodies, and task forces. He is currently active in the Optical Internetwork Forum, USENIX, and CAIDA.

2. Investigating passive monitoring in very high speed networks, and implications of TAG/MPLS on the requirements for passive monitoring software. Working to develop model for flow modeling of streamed media and other non-HTTP Internet applications.

3. Traffic engineering in the Enron Communications network will largely become dependent on data collected from passive monitoring. Making sure that we have the right tools to do the job is one of my critical path items.

4. N/A at this point. I'd be happy to talk about what we have a little further down the line.

5. Passive monitoring at ethernet speeds when you have 400 MHz processors isn't much of a challenge; passive monitoring with anything like real-time analysis for 10 Gb/s networks, particularly for substreams that take a significant fraction of that bandwidth, is going to take significant hardware assist.

   The ability to tie data from passive monitoring into SLA policing will also be an interesting challenge.

6. N/A

Ted Hardie

1. Ted Hardie, Director of Engineering, Equinix.

   Ted is currently responsible for the group which handles network management, benchmarking, and research for Equinix. As an Internet Facilities provider, Equinix is interested in understanding the general characteristics of network flows through its facilities and specifically interested in how to enable effective public and private peering.

   Prior to joining Equinix in November of 1998, Ted worked on the NASA Science Internet project. While at NASA, he managed development and deployment of all services offered by the NASA NIC and led several efforts to analyze application layer network traffic over NASA networks. He also served for two years as the elected chair of NASA's webmasters' working group, coordinated adoption of web technologies and protocols. Ted began working with the Internet as a member of the technical staff of the SRI Network Information Systems Center.

2. Equinix is in the early stages of development of passive monitoring service offerings for its facilities. Current work concentrates on developing systems of sufficient size to store and analyze data which can be derived from OC-12 and OC-48 network flows.

3. As a neutral party, Equinix does not plan to require that those present at its facilities use any specific monitoring technology for peering sessions with other participants. Equinix does, however, plan to provide the tools needed to monitor both public and private peering sessions and to encourage its customers to use those technologies and share the data thereby derived. Equinix will monitor the use of network services it provides at its exchanges and share that data with the customers using those services.

4. Equinix is currently investigating both tools based on heuristic sampling of data flows and on processing real-time capture of flows.

5. The technical challenges in this area are actually fairly standard scalability issues: getting fast backplanes, linking in fast storage devices, writing code for speedy processors. The analytical challenges are far from standard, however, as there isn't a lot of agreement on what we're looking for in all this data. For any dataset of this size, it's very easy to tune out the interesting information accidentally. Our challenge is to pose the right questions as we go through the analysis. What characteristics of the flow are of interest: number of packets, packet sizes, source network/AS, destination network/AS, unicast v. multicast, type of data, type of service, quality of service indicators, route appropriateness, presence of vpn or tunnel, and any of a raft of other possibilities? Before we can say which characteristics we should look at, we need to know what question we're answering. Do we want to know how well routing arbitration works? Do we want to know whether multicast delivery of data type X results in lower overall packet traffic over a link? Or do we want to know simply how much of the traffic flow is a retry, an ACK or a SYN?

6. No relevant URLs are available at this time.

Rene Hatem

Andrew Heybey

1. I worked on Bellcore's T1 and ATM network traffic recorders. Mark Sullivan and I built the Tribeca network traffic analysis system to be used with those monitors (Sullivan & Heybey, "Tribeca: A System for Managing Large Databases of Network Traffic". Proceedings of the 1998 USENIX Technical Conference).
   At Niksun, I am building passive network monitors as described below.
2. We have built passive monitors for Fast Ethernets, FDDI, Frame Relay over T1, T3. An ATM OC-3 monitor is currently under development. The monitors act as data recorders as well and record all the data coming in to disk or to fast tape drives. We also have a suite of software tools for filtering, demultiplexing on various attributes such as IP header fields, link level headers etc. Users interface with the system either through a Java interface or programatically via a query language API. Users can define and compile their own queries. This makes the system easily extendable and user customizable and we view this as a key differentiator. The query language is specialized for doing network traffic processing. An installation of the system typically consists of multiple (time) synchronized recorder/monitors. This is allows for one way delay and packet loss computations. Multiple application level performance statistics are collected and correlated to lower level traffic statistics. Relational database access to some higher level aggregates (tcp flows for example) is provided for easy integration into existing corporate and data warehousing/billing environments. Results of user defined queries can be integrated into the relational database system as well.
3. An ATM OC-12 monitor/recorder is currently in the planning stage. We are also working with other vendors in the area of network planning and optimization in order to provide integrated solutions to network design and operations problems.
4. We can provide a demonstration of the monitor in action as well as examples of the system could be used (how queries can be written and executed etc.). In terms of any demo requirements, all that we need is a VGA projector.
5. Defining and benchmarking metrics that directly relate to user-perceived service quality will be a major challenge, if network monitoring is to have significant relevance to the end user. Such metrics could be defined and levels mapped into diffserv codepoints. In terms of challenges, the impact of ipsec on network monitoring will have to be carefully assessed.

Ken Keys

1. Ken Keys, CAIDA, engineer on CoralReef project

2. Development and packaging of Coral passive analysis software tools

3.  

4. ocXmon hardware for capturing raw packet headers

   Coral libraries developed at CAIDA

Stas Khirman

Bo Kim

1. Bo Kim

   Postdoctoral research fellow, Center for Advanced Computation and Telecommunications, University of Massachusetts Lowell

2. I am developing time-series modeling methodologies for traffic measurements obtained from passive monitors. Our goal is to determine what class of such models (linear/non-linear, etc.) may be appropriate to capture a parametric representation of traffic flows. By tracking such parameters through traffic monitors one may be able to design traffic shapers to alter the correlation characteristics (ex. whitening filters) of flows in a differentiated services Internet. I am also considering the application of the work developed in my doctoral thesis (Optimal Feedback Control of ABR in ATM Networks) to the problem of feedback control of data traffic represented by time-series models. We are interested in seeing how congestion control protocols alter the traffic correlation characteristics. In our preliminary results, we have demonstrated that TCP congestion control mechanism can cause an iid source traffic to exhibit periodic correlation features during network congestion. In the passive monitoring and modeling context, I am interested in understanding what measurements or network states other than the monitored traffic may be necessary to fully describe the traffic flow at a site.

   Using tcpdump for capturing measurements off the campus lans.

3. Our group is setting up the OC3Mon utility on the campus backbone.

4. Perl, statistic tools, visualization tool using AVS.

5. Reflecting these analysis results of the network traffic measurements on the design and performance of the Internet.

Aaron Klink

1. Aaron Klink, Developer, Network Monitoring and Performance Group, Qwest Communications

2. We are working with Cisco engineering to improve Netflow.

3. In the future, we will be using passive monitoring tools for usage-based billing, traffic flow analysis, and other internal tasks.

4. We currently use Cisco Netflow. The strength of Netflow, at this point, is Cisco's desire to work with us to improve the product. We also use in-house developed tools to analyze the data collected by Netflow.

5. We would like the ability to configure what data is provided, as opposed to the current method of collecting all data and parsing out what is not wanted.

6. (no URLs supplied)

T. V. Kurien

1. T. V. Kurien
   Niksun, Inc.
   kurien@niksun.com

   I have been involved in the area of data mining of network data for several years. In Bellcore, I was working on efficient classification and clustering algorithms for high dimensional data sets. These algorithms were applied in the area of fraud detection and data visualization for SS-7 traffic. At Niksun, I am working on the definition and monitoring of metrics that directly reflect user-perceived QoS as well as implementing the relational database functionality in NIKSUN's NetVCR product.

Will E. Leland

Jed Martens

Matt Mathis

Sean McCreary

1. Sean McCreary, CAIDA

2. Locality analysis of backbone Internet traffic, IPv4 address space utilization patterns in the backbone

3. Measuring self-similarity in backbone traffic

4. OC3mon for collecting backbone packet traces, CoralReef for building analysis software

5. The greatest challenge is the development of monitoring tools that will allow data collection at OC48 speeds and higher. Without the ability to collect data at these speeds, analysis of the characteristics of backbone traffic will become impossible.

6. (no URLs supplied)

Tony McGregor

Daniel McRobb

Greg Miller

Sam Mokbel

Tracie Monk

David Moore

1. David Moore, CAIDA, lead on CoralReef project
2. • packaging and developing coral passive analysis tools, automated report generation, unix ocXmon drivers, and libcoral libraries (perl & C).
   • looking at basic network characterization metrics from passive measurements
   • examining checksum failures and attempting to detect/identify hardware failures in routers, as well as software and end host problems.
3. • characterizing network game traffic
     
     
   • looking at interarrival time statistics for aggregated traffic mixes
     
     
   • working with more network managers to develop tools which can provide better measurements for solving local operational problems
4. • tcpdump - for capturing and filtering packet traces on LANs
     
     
   • ocXmon - for capturing raw packet header traces, as well as capture platform for running other specific real-time continuous collection/analysis tasks
     
     
   • various analysis tools that caida has developed, in particular coral libraries in perl and C (part of coralreef package) which allow quick prototyping of analysis software from multiple trace file formats
     
     
   • looking glass route servers such as route-views.uoregon, etc, looking into using mrtd to track announcements/withdrawals directly
5. • analysis of large-scale behaviour of tcp dynamics
     
     
   • dealing with IPSEC, NAT, caches
     
     
   • providing common access libraries to differing data file formats (with different types of elided or merged data) so tools needn't be rewritten for every dataset out there
     
     
   • organized data collection in a manner which allows long term trend analysis, both with sumarrized and raw trace data. lots of bookkeeping, storage problems here as well.

Teunis Ott

1. Teunis J. Ott
   Bellcore
   Senior Scientist

   Started the ethernet measurements that led to the discovery of fractal behavior many years ago.

   Did theoretical studies of TCP (the square root formula, stationary behavior of TCP, now also transient behavior of TCP).

2. With data from an ISP, produced model for customer behavior in NNTP. Gave a ``proof of concept'' that with sufficient knowledge of the source behaviors it is possible to do reasonably sophisticated link engineering.

   Currently working on models for Internet Games (Quake).

3. Produce a source model for at least one interactive Internet Game. Update source models for Internet Telephony and Web Traffic. Attempt to produce a classification of source models.

   Translate source behaviors into rules for link engineering.

   As you see, I am more into analyzing the data than into taking the measurements. I want to learn more about taking the measurements!

4. I do not consider myself an expert on tools. I will come to learn.

5. Flexible, easy to use tools that can take ``full traces'' (including time stamps. Tools that can do this on a variety of types of links and link speeds. Analysis tools that can scrub out sensitive information yet keep enough of the data fields to allow study of tunneling behaviors.

   In both the NNTP work and the Quake work we had to work with headers only. We found it useful to develop a ``library'' of patterns in foreward and backward directions that make it possible to pretty much reconstruct what the customer did from headers only (headers client -> server AND server -> client). This seems a useful approach whenever only headers are available (i.e. much of the time!).

6. I am not the right person for this question.

Dave Plonka

1. Dave Plonka, University of Wisconsin - Madison. I'm a Systems Programmer in Network Engineering Technology, within our Division of Information Technology (DoIT).

   Recently I've released a perl package called "Cflow" which understands cflowd flow files. (This has been announced in "comp.dcom.sys.cisco".) Also, I've released a package called "NetTree" that I've found useful to summarize flow statistics by network or subnet.

   I have experimented with analyzing the flows produced by cflowd to identify machines on our campus which have had their security compromised. (This can sometimes be determined by observing their responses to scans and probes from the outside world.)

2. We've done bug fixes and enhancements to cflowd (cflowd-1-3b2). These enhancements allow cflowd to be used with version 1 PDU of Cisco's NetFlow export data. Some of this was, unbeknownst to me, executed in parallel with Daniel McRobb's efforts - at the time I was unaware that the cflowd code was being maintained.

   Also, we've built and are using a flow analysis package that can identify inbound and outbound traffic from a campus or site. (In some cases, such as with multipoint ATM interfaces on Cisco routers, it is not sufficient to determine whether or not the traffic is intracampus based solely on the interface ifIndex.) Also, been working with integrating MRTG's graph generation with cflowd so that I can plot the use of services (httpd, nttp, etc.) over time. The resulting GIFs are suitable for a WWW page.

3. I'd like to build a well-defined perl interface for, and add the continuous graphing capabilities to, passive monitoring tools other than cflowd. My interest in other flow-based systems (such as ocXmon) is so that I can gather statistics where the routers might be from other vendors.

4. MRTG While it doesn't fit in the same class as flow-based monitoring tools MRTG is a good example of how historic data can be compressed so that it doesn't become unmanageable. cflowd we chose to implement cflowd first, over oc3mon, because we peer with external entities at multiple points (i.e. multiple routers). To analyze inbound and outbound flows to the campus would have required us to build and maintain multiple oc3mons. cflowd uses flow export data from our existing Cisco border routers. oc3mon I found the documentation to be confusing, the perl analysis scripts to be undocumented. While a couple members of our team managed to assemble a working oc3mon, it is usually not used currently.

5. The formal packaging (to ease implementation) and quality documentation of monitoring and anlysis packages is critical to their success, IMHO.

   Developing flexible analysis tools so that users can reduce the raw data but still be able to answer all sorts of questions about traffic is difficult. It's what led me to using perl to parse the flows so that the powerful scripting language can be used to crunch the data and report upon it.

6. (no URLs supplied)

Marc Pucci

1. Marc F. Pucci
   marc@bellcore.com
   Bellcore
   Senior Scientist

2. I have designed and deployed pasive network monitors to collect and analyze several terabytes of complete payloads on T1 and OC3 links. Analysis has ranged from protocol summaries to session behavior to delay and loss statistics.

3. Increasing speeds push the limits on existing tools and monitors. I am still interested in building collectors that gather all traffic and complete payloads.

4. 8 line T1 HDLC monitor
   1 line OC3 ATM monitor
   both designed and developed at Bellcore
   Various suites of software for prelimainary analysis of collected data.

5. A) Gathering at higher speeds,
   B) Processing in real time based on what we learn from A).

6. (no URLs supplied)

Ronn Ritke

1. My name is Ronn Ritke and I am a 5th year Ph.D. student in the Computer Science Department at UCLA. I advanced to candidacy for the Ph.D. in Feb. 1998. My dissertation topic is Network Measurement and Analysis. I have measured computer network traffic at UCLA for 3 years. I just finished a paper that involved trace-driven simulations (UCLA Technical Report # 980023).

2. Currently I am taking campus level FDDI traffic traces at UCLA and measuring some of the network traffic into and out of the the Computer Science Department at UCLA. In addition to these efforts, I am in the process of obtaining some Sonet and ATM traffic traces. Some of the traffic traces are used as input to trace-driven simulations (see UCLA Technical Report # 980023). In a cooperative effort, I have supplied raw and processed traffic traces to other researchers at UCLA.

3. My future plans involve: a) Using network traffic traces as input for trace-driven simulation.
   b) Possible collaboration with Hans-Werner Braun in traffic trace analysis and/or trace-driven simulation.
   

4. Tools - tcpdump is the main tool I have been using to get traffic traces. A number of software tools have been created to process the raw traffic traces into the desired format.
   • interp - processes the output of tcpdump and puts it into a very specific format.
   • interpcol - provides the capability to select one or more of the six fields (columns) to be written to an output file.
   • interprow - writes to output only the rows that meet the desired criteria.
   Interprow and interpcol can be used repeatedly to process data into a specific format. For example - the tcpdump output contains the following information for each packet, arrival time, source IP address and port number, destination IP address and port number and packet length. Once interp has formatted the tcpdump output, interpcol can be used to write to an output file only the arrival time and packet length columns. Interprow can be used to have only the packets with lengths greater than 0 or only the packets whose arrival time was less than some value written to an output file.

   A number of other software tools have been developed for differrent traffic trace analysis and processing.

5. Cooperation of passive monitoring researchers with other researchers. For example I have processed Computer Science dept. level traces, FDDI campus level traces and ATM cell traces for another researcher at UCLA for use in modeling self-similar network traffic.

   Continued use of passive monitoring to monitor traffic on different networks and network types and to obtain accurate characterizations of new and existing network applications, protocols, etc.

6. The interp, interpcol and interprow software will soon be available via the web.

Jeff Rizzo

1. Jeff Rizzo is currently employed with Equinix, as Senior Network Engineer, and is the engineering lead for their passive monitoring project. Before joining Equinix, he was senior network engineer at PAIX, where he worked with customers to monitor their switch port usage. Prior to that, he worked at Netcom's Network Operations group where part of his duties included both analysis of Netcom's traffic exchange with other ASes and providing usage statistics to network customers.

2. Equinix is in the early stages of development of passive monitoring service offerings for its facilities. Current work concentrates on developing systems of sufficient size to store and analyze data which can be derived from OC-12 and OC-48 network flows.

3. As a neutral party, Equinix does not plan to require that those present at its facilities use any specific monitoring technology for peering sessions with other participants. Equinix does, however, plan to provide the tools needed to monitor both public and private peering sessions and to encourage its customers to use those technologies and share the data thereby derived. Equinix will monitor the use of network services it provides at its exchanges and share that data with the customers using those services.

4. We are currently in the process of evaluating tools which might benefit us, including the possibility that some may need to be built in-house.

5. One of the more challenging aspects of what we are trying to accomplish is deciding what the 'interesting' things to track actually *are*. And, of course, the analysis and display of the gathered data in a format which conveys meaning.

6. No URLs at this time, sorry.

Glenn Sager

Scott Shoaf

1. R. Scott Shoaf, Senior Member Technical Staff at SBC Technology Resources, Inc. working in the Internet Technologies group.

2. Providing ADSL traffic analysis to the SBC Internet subsidiary. This analysis is to determine ADSL network growth, application usage, and traffic flow patterns as related to the traditional Internet traffic trends.

3. Future plans include the integration of passive monitoring devices with active network/application monitoring tools to provide an end-to-end coverage of network performance.

4. New to high speed data collection, mostly experienced with enterprise collection tools

   Compuware EcoScope - good tool for application discovery and reporting, but limited to LAN and low-speed WAN topologies. Provides good visualization of the discovered network. No ability to collect TCP flow data.

   RMON probes

   snoop w/ basic analysis

   HP Internet Advisor and NAI Sniffer analyzer tools

5. A method of standardized performance metrics that allow for cross-platform verification of data analysis. Also, I hope to see the coupling of passive and active monitoring devices to provide a robust end-to-end analysis of network traffic along with the correlation/analysis tools to pool and reporting on captured information.

6. (no URLs supplied)

Michael Tesch

1. Michael Tesch, CAIDA, developer(?), FreeBSD Oc3mon and Oc12mon work. coral reef stuff.
2. FreeBSD Oc3mon and Oc12mon work.
3. Do some analsis.
4. Coral Reef.
5. ?
6. ?

Kevin Thompson

Marcelo Torres

1. Marcelo Torres, Network Engineer at GTE-Internetworking. Use network traffic statistics to produce traffic models used in capacity planning activities. Investigation into the area of statistical inference for traffic models.

2. Consumer of cflowd data for constructionn of traffic models

3. Interested in developing traffic models that capture short time scale behavior. Would like to learn more about cflowd and the tools used to gather data and their limitations and how those limitations are changing over time.

4. We rely on cflowd data, and the output of in-house tools that process this data. We have a difficult time handling the quantity of data generated and have to limit our measurement periods as a consequence.

5. From a capacity planning standpoint, the ablility to sample intelligently and capture traffic statistics on time scales of interest is quite a challenge and of increasing importance. Would also like to see monitoring accurate monitoring of queue occupancy at router interfaces and tools that make it easy to use this data in non-real time and in a real-time control setting.

6. Can't think of anything new to add here

Brynjar Viken

Jonathan Wang

1. Name: Jonathan L. Wang
   Organization: Bellcore
   Title: Senior Research Scientist
   Activities relating to Internet statistics: Jonathan currently manages a research program in Bellcore that aims at providing Bellcore's clients a comprehensive and state-of-the-art solutions to Broadband and Internet traffic management. The research activities include traffic data collection, traffic/performance characterization and modeling, and practical traffic management solutions. In the past several years, this research program has been involved in the data collections and traffic analyses from several working networks including SS7/AIN, Frame Relay, and ATM.

2. Current activities: continuing development of passive monitoring tools and data analysis methodologies for high-speed networks and broadband applications.

3. Future plans: research and development of a network (traffic) management architecture solution and its associated set of software/hardware tools for supporting next generation networks.

4. Tools used:
   • Monitoring tools: custom-built Frame Relay and ATM traffic data vacuum
   • Data analysis tools: custom-built statistical analysis software
   • Simulation: custom-built simulation software in various languages
   Strengths: custom-built, relatively easy to modify, relatively fast
   Weakedness:
   • The need to develop new monitoring tools (maybe, from stretch) and adapt to newer technologies and higher speed
   • Statistical analysis tool is not capable of handling large volume of data due to software limitation
   • Simulation software becomes very complex and slow if detail (protocol) modeling is required/implemented

5. Critical requirements:
   • New monitoring tools/architecture
   • Modeling capability/physical explanations of models
   • Model/traffic predictability
   • Bridge the gaps between research and reality: what needs to be collected regularly through routers, etc.
   • Information sharing

6. No public URL is available for Bellcore's research programs at this time

David L. Wasley

1. David L. Wasley, UC Office of the President; Co-Chair, Internet2 Measurements Working Group; Project Director, CENIC CalREN-2 Network.
2. The I2 Measurements WG is preparing a requirements document for both passive and active measurements across the Internet2 national infrastructure.
3. See above for a start. I am personally planning to develop models for network costs allocation based on passive monitoring data.
4. We are recommending to the I2 technical community that all gigaPOPs install OCxMON, Surveyor, and some form of netscarf-like monitor.
5. Collecting sufficiently granular data at OC12 and above; verifying QoS/CoS parameters as requested by flows; understanding multicast behavior; ...
6. Identification of relevant URLs covering tools or initiatives in this sector:
   
   None for the I2MWG yet -- 'real soon now' !

Robert Williams

Matt Zekauskas