RIPE 32

RIPE 32 Test-Traffic WG meeting - 28 Jan 1999

Chair: Martin McCarthy
Scribes: Rene Wilhelm & Daniel Karrenberg
Attendees: 29
Status of TestTraffic project at RIPE NCC
-----------------------------------------
presentation by Henk Uijterwaal:
[Now online at http://www.ripe.net/test-traffic/Talks/9901_ripe32/]
- measurement network expanded from 12 to 15 active nodes
- 20 more boxes will arrive in February, these will be free
- expect to build more boxes this summer, hosts will have to
pay, more details at the May meeting (RIPE33)

- Antenna problems, follow up on what was reported at RIPE31
- using low loss coax; tests at three sites indicate this works
fine upto about 50m cable length
- GPS receiver in separate box, extend RS232 cable; test in the
NCC office: length of 225m works fine. However, there is a not
yet understood offset in the delays of 30 microseconds. Further
investigation needed, not an option for the February series
of boxes.

- Analysis
- decided to use ROOT (http://root.cern.ch/) analysis framework:
data storage, plotting facilities, command & batch mode, macros
- in the future: data sets made available as ROOT files,
accompanied by example macros on the web-site.
- will continue to run a standard analysis at the RIPE NCC
- lots of interesting effects in the data; three case studies
were shown.
- plans for next months
- expand measurement network, better user support, standard
analysis
- SNMP, trend analysis, new measurements, compare results from
RIPE and ANS, analysis suggested by users
- IPPM-WG at IETF43
- We have a lot of data, but all "low level" metrics
- ISPs and customers want "real performance numbers",
"derived" metrics
- "develop services" but what do ISPs really want?
- more discussion at next IETF, but we need input


Questions:
Q. Can TestTraffic box and Merit probe be combined ?
A. Daniel: routing information service is on the NCC activity plan
but dormant; if enough interest, project could be revived
and then TestTraffic boxes could be used in data collection.
If people are interested in that, please tell the NCC!
Henk: you can combine data yourself; routing info from merit box
delay measurements from TT box.
Q. SNMP: will it be used to poll routers? If an interface
is packed, packet loss is sure to happen.
A. No, the idea is more to use it to trigger alarms or
deliver (summarized) data. Hosts have expressed interest,
as they have it in their network monitoring software.
Q. Do you ping intermediate hosts
A. No, these are one way source->destination delay measurements
Daniel: with 100+ boxes it will be difficult to process data
from the full N x (N-1) mesh; try to find common spots in
topology, but deduce redundancy from data, no assumptions
from the configured set-up.
Q. Do you perform bandwith measurements?
A. With the "pathchar" utility? No. pathchar tries to
determine available bandwidth by sending bursts of data.
Have to be carefull with that, can't do it frequently:
don't want to (over)load hosts' connections and don't
want to interfere with delay measurements.

Q. Can rate limites on ICMP traffic affect the measurements?
A. No. We are not sending ICMP, but UDP packets; more freedom
in changing parameters, less susceptible to special treatment
by the network.
Q. How many boxes are on exchange points or other neutral sites?
A. Apart from the two boxes at RIPE NCC, all current boxes are
located at ISPs; however, we have one ready for installation at
the LINX.

New Chair
---------
Current chair has to resign, due to health. It was decided to
try and settle this via the group's mailing list before the next
meeting. Daniel pointed out that, although he would be happy to
be the group's chair, he feels it's not appropriate for the NCC
to chair RIPE working groups.
[NOTE: Matthew Robinson of Planet Online Ltd. volunteered Sat. Jan 30]
A.O.B.
------
Daniel asked the group for input on policies towards accessing the data:
we have the instruments, we know what we measure; at the start the policy
(written down in RIPE-180) was conservative: the participating host only
got access to the data involving the testbox at his site. Later on this
was weakened: all hosts can get access to all data (plots and routing
vectors on the web-site). Now we get to the stage where the project
receives more publicity and people not involved want access to the data.
Have to decide in the next few months on what to do and how. Need
brainstorming now.
A lively discussion followed.
It was felt there should only be one policy for accessing the data:
no special agreements with specific hosts. Policies should be developed
and discussed in the WG. Hosts should get the option to stop participating
when policy is changed (they already do).
Some concerns were raised about publishing the (raw) data to the general
public: without detailed explanation of what was measured it leaves too
much room for interpretation.
Current chair has to resign, due to health. It was decided to
try and settle this via the group's mailing list before the next
meeting. Daniel pointed out that, although he would be happy to
be the group's chair, he feels it's not appropriate for the NCC
to chair RIPE working groups.
[NOTE: Matthew Robinson of Planet Online Ltd. volunteered Sat. Jan 30]
A.O.B.
------
Daniel asked the group for input on policies towards accessing the data:
we have the instruments, we know what we measure; at the start the policy
(written down in RIPE-180) was conservative: the participating host only
got access to the data involving the testbox at his site. Later on this
was weakened: all hosts can get access to all data (plots and routing
vectors on the web-site). Now we get to the stage where the project
receives more publicity and people not involved want access to the data.
Have to decide in the next few months on what to do and how. Need
brainstorming now.
A lively discussion followed.
It was felt there should only be one policy for accessing the data:
no special agreements with specific hosts. Policies should be developed
and discussed in the WG. Hosts should get the option to stop participating
when policy is changed (they already do).
Some concerns were raised about publishing the (raw) data to the general
public: without detailed explanation of what was measured it leaves too
much room for interpretation.
Too simple derivatives like a ranking of ISPs should be avoided.
A strawman was suggested: Allow publication freely but do not allow
usage in advertising, promotional material and any other marketing
context.
Conclusion: next step is to open up more: target at engineers,
avoid marketing department, avoid ranking of ISPs.
To effectively implement policy it was suggested that the NCC should keep
copyright / intellectual property right on data and derivatives of it;
should journalists want to publish results to a wide audience, they
have to contact RIPE NCC first.
Daniel re-iterated that the RIPE NCC, being neutral, will not do things
that would harm ISPs as a whole. He encourages those with ideas in the
policy arena to communicate them on the list (tt-wg@ripe.net).
....
Henk