|Working Group:||Test Traffic|
- content to the Chair of the Working Group.
- format to webmaster _at_ ripe _dot_ net.
Chair Alexander Tudor
Scribe Rene Wilhelm
- Agenda bash,
- Approve RIPE 51 minutes.
2. TTM Status Report
- Included in 3(a)
3. New Directions for TTM
a) NCC's ideas on new directions for TTM (Andrei Robachevsky)
b) 2005-11/Multicast Monitoring (Gert Doering)
c) 2005-10/Consumer Broadband Monitoring (Alex Tudor)
4. Open Microphone
Agenda and RIPE 51 minutes were approved
3a. RIPE NCC's ideas on new directions for TTM (Andrei Robachevsky)
Andrei Robachevsky reflects on 8 years of Test Traffic Measurements by RIPE NCC, the good things, the not so good things, the maintenance and deployment issues. Some of the assumptions made in the design of TTM no longer hold, have been overtaken by developments. Operator interest in running a TTM box in their networks is stable at best, as indicated by the number of active test boxes.
Andrei continues his presentation with ideas on how to improve, increase the value of TTM; e.g. move the focus from network to application, do more composite measurements, measure on demand, report results immediately. The architecture of TTM could evolve to be multi-tier, simple collectors and more complex aggregators.
Gert Doering remarks that for the multicast proposal he sees measurements being done continuously, not just on demand. The idea is to have a report available, a place to go and check measurement data, the moment something is reported to be broken. For the normal delay measurements he rarely looks at individual data points, but it's very helpful to have these data when a customer comes along with complaints; if the data confirms network has been up all month, he can point that out to the user and stress that measurements were done by an independent organization.
Brian Nisbet comments that HEANET also value the current continuous delay measurements and the large dataset. Although TTM results are not checked on a day to day basis, there is real value in having data available when something goes wrong. In addition TTM data has been used numerous times in network design.
Geert Nijpels reports that AMS-IX use the current delay data for (quality) statements to their customers. They do not have much interest in more complex, composite measurements but don't mind the TTM platform extended as long as the near real time output via port 9148 of packets send and received (including incoming delays) remains accessible.
Henk Uijterwaal answers he can see a mixed model: continue collecting the delay data, but only produce plots on demand. At the moment RIPE NCC creates thousands of plots a day, which takes significant resources but hardly anyone ever looks at them.
Daniel Karrenberg feels the discussion in tt-wg is a good starting point; input regarding the usefulness of long time series and one-way delay measurements is valuable. The transition to a new operational and business model for TTM must be done in a good way; develop in test traffic working group but also interface with NCC-services WG and with the RIPE NCC board who are responsible for finances.
The discussion concluded with the observation that nobody in the meeting opposed the general directions outlined by Andrei. It was decided to form a task force, a core group of interested people, who would look into further developing the ideas and moving things forward. Brian Nisbet, Neil O'Reilly and Geert Nijpels volunteered, joined from the RIPE NCC side by Daniel Karrenberg, Henk Uijterwaal and Andrei Robachevsky.
3b. Policy proposal 2005-11: Multicast Monitoring (Gert Doering)
Gert Doering explains the idea is to have a reachability plot for multicast, which will allow operators to more quickly see when something breaks in multicast. The specifics of how to implement it are left to the RIPE NCC. The proposal has been circulated on the tt-wg list, received some support and no strong opposition.
Daniel Karrenberg agrees measuring multicast is interesting, but he doesn't like the binary "do it yes/no" question posed by the policy development process. He would like to see work being done on other things too, the restructuring of the TTM service and consumer broadband monitoring. Implementing multicast monitoring is something RIPE NCC could take on at a lower priority.
After some more discussion it was concluded that the best course of action would be to first move TTM to the new model and the consider adding multicast monitoring as one of the services.
3c. Policy proposal 2005-10: Consumer Broadband Monitoring (Alex Tudor)
The proposal was posted to the mailing list last October. Not much discussion, but no opposition either. Alex asks the attendees if anyone is against CBM, opposes consumer broadband monitoring being part of the new open platform.
Daniel Karrenberg expresses his concerns about starting a service with RIPE NCC membership funds that might only be beneficial to a small subset of the members. Personally he likes it a lot, but it could end up being perceived as a threat by service providers.
Neil O'Reilly proposes to start with a proof of concept implementation with limited scope. A pilot implementation which highlights what could be done with a CBM service, what value it could have.
It was agreed setting up this pilot would be the next step for the CBM proposal
4. Open Microphone
Geert Nijpels: at RIPE 50 there was a presentation by Thomas Wana on improving accuracy of clocks. Is anything being done with that? Have some of these been deployed?
Henk Uijterwaal: some things were purely academical, others turned out to be less practical in operating the TTM service.
no other business.