We realize that the presentation of the measurement results is a
delicate matter. We plan to organize this in close coordination
with the ISP's concerned and the relevant RIPE working groups.
The schemes presented below represent a first idea which certainly
needs refinement as the project progresses.
We foresee 3 different levels of disclosure of the data:
Experts: The experts at the NCC will, of course, have
access to all data that is collected with our test-boxes.
Participating ISP's: Each ISP that installs a test-box
will get access to all data related to his network (but not
to data related to somebody else's network).
Non-participating ISP's: They
will only have access to global quantities derived from the data.
The general public: The general public will have access to
global quantities derived from the data, but with a more detailed
explanation describing how the data should be interpreted.
During the initial phases of the project, the data will be distributed under
a non-disclosure agreement. Both the experts at the RIPE-NCC and
the participating ISP's can use the raw data for any analysis that they
find interesting but both sides agree not to publish any results
until the results have been verified (see section 5) and
both sides agree that that they are meaningful, correct and can be
published. The details of this agreement will be worked out with the
participating ISP's.
There will be several ways in which the data can be accessed:
Test-box:
The test-box will have a mechanism that will return the results
of the last set of measurements from this box to the ISP
where the box is located.
Server:
All information about an ISP will be available for that ISP only
on the central computer for the project at the RIPE-NCC.
Reports:
Finally, we will use automated tools to extract summary plots
from the data. These plots will be made available on a regular
basis.
Two different kinds of reports may be made available:
Reports with data relevant to a single ISP
and reports with data relevant to all ISP's.
The plots in the first category will be made to that particular
ISP only, whereas the other plots will be made available to
the entire Internet community. In the latter case, the plots
will be presented in such a way that it is not possible to trace
the data back to a particular ISP.
The format in which the data will be presented will be decided in
mutual agreement with the participating ISP's.
In the initial phase, we foresee the following plots:
Delays between two test-boxes.
Length of the routing-vector. This information can be cross-checked
against the number of hops that the delay measurement packets saw
between sender and receiver.
Packet loss (# messages received/# messages sent).
From the reference numbers in the packets, the receiving machine can
determine which packets actually arrived and estimate the packet
loss along the way.
Percentage of the connections working.
A connection between two points is considered broken if less than a
pre-defined fraction of the test traffic messages sent over that
connection actually arrives. From that, we can determine the percentage
of the connections in the entire sample that is actually working.
Time of arrival of the last message from host X.
This provides another way to determine if a connection is working and
to calculate the fraction of connections that are working.
Number of changes in the routing vector.
More plots will be defined as the project progresses.
All these quantities will be plotted as a function of time of the day. In
addition, the path information will be made available in some sort of
data-base.
As soon as the individual plots are understood, we will start generating summary
plots. These summary plots will contain information about 1 particular ISP
(for example, the average delay to or from this ISP) or even more global
quantities (like the average delay on the Internet).
As soon as we are confident that exceptional behavior (for example, the
delay between two points suddenly doubles) is an indication of a network
problem rather than a problem with our test-boxes, we can start to
generate warning messages to flag these conditions. There are several
ways to detect these conditions, including quantities exceeding a certain
threshold, test, Kolgomorov tests against known usage patterns,
and so on.
you are here: RIPE -> RIPE Document Store
test, Kolgomorov tests against known usage patterns,
and so on.