Minutes TTM sessions RIPE 48 (draft #2)

[Ruben van Staveren <]

RIPE 48 - Amsterdam

==============================================================================

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


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 organization 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

* Concluding Remarks

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).

==============================================================================