Test Traffic Working Group Minutes from RIPE 48

• content to the Chair of the working group.
  
• format to webmaster@ripe.net.

Minutes from the Test Traffic Measurements Working Group session
Held on the 5th of May 2004 at 11:00-12:30 and 14:00-16:00

Chair: Alex Tudor
Notes: Ruben van Staveren
Attendees: 40 (session 1), 30 (session 2)

The administrativia where quickly dealt with, appointed as scribe for the sessions was Ruben van Staveren of RIPE NCC. There where no any other agenda items added.

----------------------------------------------------------
--------------------
* TTM report from the RIPE NCC (status and plans) by Henk Uijterwaal

See http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-tt-status.pdf

HIGHLIGHTS

Mentioned from the previous working group session where SCoLe, Delay Tomography and OWAMP and whether RIPE NCC should be involved in these efforts.

OWAMP will be looked into, the others not for the time being.
ftp://ftp.ripe.net/rfc/rfc3763.txt

The operational aspects of TTM will be moved out of the New Projects group and to RIPE NCC's operational department. Software maintenance will be moved to RIPE NCC's software engineering department. This will take place somewhere between July - September, a definitive schedule has yet to be made.

In that period it is assured that service levels will not drop and should even increase after the transition.

On the TTM Sales front, the service fee has been reduced to an annual 1000 euro's. The possibility of sponsoring hardware is also being considered, if certain conditions have been met. Being a academic network, for instance.

The DNSMON service will be turned into a regular one, a draft service is available and a final one will be ready before the CENTR meeting in June.

The plans between now and RIPE 49

* Update the presentation of our data on the website
* Look into using OWAMP for the measurements
* Percacci numbers
* Bandwidth measurements

QUESTIONS (Q=Question/A=Answer/R=Remark)

Q: About the development in TTM and the move to production.

A: A couple of test boxes remain as a test bed, the NCC internal ones in the new structure the possibility will remain to test software in the production environment. Internal organisation is different.

Q: About collaboration between routing and test traffic
A: Presentation of randy bush in the routing wg shows that it is very promising to do so, installing tb's and route collectors at the same spot
R: (dfk) Researchers can combine results for themselves already. having a tb at the same spot as a route collector is nice but not needed

------------------------------------------------------------------------------
* Internet 2 - Richard Carlson
See http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-tt-carlson.pdf

ABSTRACT:

The Internet2 End-to-End Performance Initiative (E2E piPEs) is developing tools and procedures that will improve network performance for multiple scientific domain communities.

This collection of integrated tools includes:

1. One-way delay measurements, using the OWAMP tool, across the Abilene national backbone core network.
2. Throughput measurements, using the BWCTL tool, across the Abilene network.
3. Configuration and throughput testing, using the FLM tool, between a user's desktop computer and the Abilene network.

In addition to these data collection tools, middleware and analysis tools are being developed to combine the individual results into a coherent picture of the end-to-end network path. This talk will describe how these individual components are being integrated into a single network measurement infrastructure, providing end users with a simple method for solving network performance problems.

(There where no questions or remarks after the presentation)

------------------------------------------------------------------------------
* Experiences with a Multi-Protocol network monitor - Andrew Moore
See http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-tt-multi.pdf

ABSTRACT

For a number of years we have been developing and using a Multi-Protocol network monitor (one which can analyze network, transport and application protocols simultaneously). We arrived at a specific architecture to perform line-rate capture and data-reduction to record interesting data without loss of information. Alongside it's development has been the implementation of a special-purpose visualizer - suitable for displaying data at multiple layers of the protocol stack. I will describe features of the architecture, demonstrate the visualizer and discuss some recent experience with applying our monitor to network traffic classification.

QUESTIONS (Q=Question/A=Answer/R=Remark)

Q: About payload inspection verses flow heuristics. what is the false positive ratio ?
A: heuristics are 99.9% of the time just fine.

------------------------------------------------------------------------------
* SCAMPI - Arne Oslebo
See http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-tt-scampi.pdf

ABSTRACT

SCAMPI is a two-and-a-half-year European project to develop a scalable monitoring platform for the Internet. The project has several objectives including the development of a new monitoring API that will make it easier to develop monitoring applications, developing new monitoring applications that demonstrates the usefulness of the new API and also to develop a hardware adapter capable of doing passive monitoring at speeds of 10Gb/s.

This presentation will give a general overview of the project and some technical details of the various components will be discussed. There will also be a live demonstration of Flowrep, a WEB based Netflow reporting application that has been developed as part of the project.

(After the presentation Arne did a demonstration of SCAMPI FlowRep)

------------------------------------------------------------------------------
* How I use my test-box in daily operations

After being introduced by the working group chair the following persons gave a small presentation about they used their test box in day to day operations.

- Brian Nisbet - Network Engineer, HEAnet
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-tt-35.pdf
- Dave Wilson - Senior Network Engineer, HEAnet (IPv6 aspects)
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-tt-ipv6-routing.pdf
- Antoine Delvaux, BELNET
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-tt-box-daily.pdf

Comments from New Projects about the 97.5 percentile noise build up in Antoine's plots: Might be a host based problem, and we will know for sure in a few weeks.

A remark about auto configuration: We can't do that because we need to know the address in advance

------------------------------------------------------------------------------
* Closing business

The Chair invites all to come with suggestions and ideas, in person or email

* In the plenary, the session was summarized by the chair as follows:

Lessons and ideas from our presenters:

Rich Carlson/Internet2:

- Measurement infrastructure under separate administration ought to develop a common data interchange format.

- Web100 (or other method of stack instrumentation_ can enrich the TTM platform functionality.

Andrew Moore/Cambridge University/Intel Laboratories & Ande Ozlebo/UNINET:

- TTM metrics that require hard real-time scheduling (i.e. cannot be subjected to the variations of pre-emptive multi-tasking) have to migrate to hardware
- as more services (e.g. root server monitoring) migrate to the TTM platform, scheduling deterioration needs to be quantified in order to assure the continued success of the TTM service - consider experimental deployment of the DAG6 or Combo card based scheduling sensitive metrics

Brian, Dave & Antoine:
- illustrate how to use TTM in root cause analysis
- show how to debug routing policy (IPV6 illustrated but method is applicable to IPV4 as well).

------------------------------------------------------------------------------