RIPE 33

Test Traffic WG - RIPE 33 (Vienna)

11:00 6 May 1999


Chair: Matthew Robinson
Scribe: Dave Wilson


No changes to published agenda.

1. Presentation by Henk on currentstatus and future plans
=========================================================

Now available at http://www.ripe.net/test-traffic/Talks/9905_ripe33/

Administration
--------------

Manpower: Fotis Georgatos started with the project on April 1st,
bringing the number of people in the group to 3. Duties include
sysadmin, data quality monitoring, primary contact for user
queries.
Mailing lists: there are thre (all @ripe.net)
tt-wg: open to all
tt-host: for sites that host TT boxes
tt-ops: day to day operations, recently switched to ticketing system
Test Box Installation
---------------------
First series of boxes has been shipped.
The second series of 20 machines arrived February 1st. A request
for hosts went our March 1st, and 19 confirmed applications were
received. Installation begam April 1st and the first box went
fully operational April 24th.
Future Series of Test Boxes
---------------------------
Installing the clock is a problem. Two solutions:
1. Low loss coax cable
This cable is good up to about 45m, but is expensive and
hard to install.
2. Clock in separate box
Connected using up to & over 200m of standard cat5 cable.
This resulted in clock offsets which can be compensated for.
At present the offset must be measured manually - an automatic
system is being looked into.
FUture hosts will have to pay for TT boxes. This is roughly EUR 2,500.
Their operation will be the same as current boxes; a single "black box"
that measures the network.
Some hosts wish to buy more boxes for private experiments. They can
either buy the assembled box or get the hardware specs from the TT
group and assemble their own.
Clock hardware is being tested. An implementation will be decided on
before RIPE-34.
Analysis
--------
Data Quality Monitoring
This begins with regular checks of the weekly delay and loss
plots, and antenna conditions. Problems are reported to the
hosts.
DQM will be automated and expanded as the project proceeds.
Analysis Framework
A new analysis machine was ordered with 90GB of disk space +
tape juke box.
- This will automate the initial processing
- Daily plots generation will move to this machine
- Data will be stored in ROOT making it easier to test
new analysis ideas
- Easier access to data for hosts (by FTP)
First version is expected at the end of May 1999.
Comparison of RIPE-NCC and Advanced Data
----------------------------------------
The idea here is to perform the same tests using different
equipment. They should yield the same results - this needs
to be checked. Both implemented one-way delay and loss tests
according to IPPM-drafts, from Amsterdam to New York, starting
October 26.
The graphs show a delay of around 50ms during the night. The
initial peak to ~200ms is at 0800h, and the delay stays
consistently up to about 200ms until 1800h, when it drops back
to ~50ms.
Both sets of test equipement yielded very similar results. A
query was raised about differences in the graphs; this was due to
the higher sample size of Advanced data.
Percentile delays over a 2-month period were also presented;
similar results.
The conclusion is that two independent implementations of
one-way delay and loss drafts measured the same effects.
Delays versus Packet Size
-------------------------
These measurements were taken over 5 days of data. Points without
valid clocks were removed and mean delays were analysed.
On LANs, delay peaks for different packet sies are similar in
shape but shifted in time. Delay vs. packet size is a linear
function up to the MTU, at which point it levels out because
of fragmentation.
Transatlantic, delay versus packet size is again linear up to
the MTU, but packets with size above the MTU are dropped.
In the future, fragmentation flags will be added to the data
so that fragmented packets can be tracked.
This may be a useful method to measure effective throughput
without saturating a link - it will need to be looked into
further.
N-Squared Problem
-----------------
With N test boxes, the number of possible paths to measure is
N(N-1), which is of the order of N-squared.
However, not all combinations are interesting and need to be
measured. If we eliminate those paths that are the sum of other
paths, we can lose data that does not add much to the result.
That lost data can be dervied later if needed.
Networks change over time so hard coding this scenario is
impossible. We need to be able to dynamically update
configuration files.
This approach is suggested:
1. Always measure from a test box to a well-defined subnet
of test boxes. e.g. major exchange points, and other boxes
selected by the host.
2. For other paths, develop an algorithm to dynamically add
or remove paths from the list of measurements.
Summary
-------
- The measurement network will double in the coming months
- Cross checked RIPE NCC & Advanced data
Comments
--------
Randy Bush noted that this is the best analysis going on today
for real-world use with a theoretical and now tested basis.
2. TT WG Charter
================
Draft 3 was presented. No reactions at the meeting; any changes
could be discussed on the mailing list.
3. Data disclosure policy
=========================
There is concern that marketing depts. will get hold of the data
and publish league tables of ISPs.
Former policy was: hosts could only access their own data. This
has since been relaxed.
Before data can be put into the public domain, restrictions must
be set, otherwise ISPs will be reluctant to host a test box.
No comments; this can be taken to the mailing list.
4. New Services
===============
1. Delay & loss alarms
- Can see events, inform test box hosts
- Calculate mean and percentile delays and losses for a time interval
Compare to previous intervals, exclude night/day effects, etc.
If delays/losses are observed outside the expected range, send an
alarm.
- Alarm is by email first, moving to SNMP.
Query: Could the alarm process be overridden by scheduled tickets?
Yes, this must be done. The rulesets of a network management system
should be able to deal with this.
2. Long Term Trends
- Do delays/losses change over time?
- Parameterize losses/delays, following RFCs.
- Plot over time
- Look for effects.
3. "Quality of the Network"
- Summarise parameters from daily plots on a single page
- Define derived metrics as needed
- Needs study and discussion
4. Other Services
- Resources are available to implement other services based
on TT data. No implementation schedule was available yet;
the TT-WG is a suitable place for discussion.
AOB: none.
- Can see events, inform test box hosts
- Calculate mean and percentile delays and losses for a time interval
Compare to previous intervals, exclude night/day effects, etc.
If delays/losses are observed outside the expected range, send an
alarm.
- Alarm is by email first, moving to SNMP.
Query: Could the alarm process be overridden by scheduled tickets?
Yes, this must be done. The rulesets of a network management system
should be able to deal with this.
2. Long Term Trends
- Do delays/losses change over time?
- Parameterize losses/delays, following RFCs.
- Plot over time
- Look for effects.
3. "Quality of the Network"
- Summarise parameters from daily plots on a single page
- Define derived metrics as needed
- Needs study and discussion
4. Other Services
- Resources are available to implement other services based
on TT data. No implementation schedule was available yet;
the TT-WG is a suitable place for discussion.
AOB: none.