Introduction
The main objective of this project is to create an infrastructure
to facilitate the collection, desimination, and understanding of
network measurement data. It is not focused on designing new
techniques for measuring particular network properties, but rather
to provide a simple and convenient infrastructure for saving and
displaying the results of existing measurement procedures.
For example, one may wish to measure round-trip latency between a
pair of hosts over a period of time. One method for doing this is
to use the common "ping" program. The "ping" program is then
incorporated into the infrastructure and measurements are saved in
a database. Various servers run to actually run the program and
save the measurement data, but if a more accurate way is later
found to measure the quantity, then that method can be encorporated
into the infrastructure. In other words, the focus is not on the
way the measurement is actually taken, but rather on the storing,
accessing, and viewing of the data, either by users, network
enginneers, or possibly the applications themselves. One could
envision in the future an application accessing a network measurement
infrastructure and reporting back to the user any problems that
might exist.
The Measurement Infrastructure Model
Given any network application, there are a set of network properties
which determine how well that application performs. For example,
an application may be dependent upon, among a variety of other
properties, the jitter associated with a UDP flow, If the application
performs poorly, how can a network engineer determine the reasons
for its failure? Can the user do this, or possibly can the
application itself determine the reasons?
The goal of this project is to create an infrasture which facilitates
network measurements. The model used for this infrastructure is
portrayed in the following diagram:
The infrastructure consists of a measurement server who's role is
to collect measurements from clients and store them, offer those
measurements to an interested querier, and display the data in some
reasonable format for anyone trying to interpret the data. The
data itelf is collected by measurement clients and sent to the
server for storage.
In more detail, here is a description of the measurement server.
The package of programs associated with the infrastructure is called
"msmnt", so we label the server as the "msmnt-server".
- Define a storage method for the collection of data. This should be
independent of the protocols for accessing the data. It might consist
of an SQL server or simply a collection of flat data files.
- Define a collection of hosts and measurement types which are supported by
this server.
- Define a protocol for the receiving of data from an "msmnt-client".
- Define a protocol for the desemination of data from the server to
interested parties.
- Provide a means for displaying the data in graphical format or
other interpretive formats.
In simple terms, the msmnt-server provides an interface for the receiving and
sending of data, in addition to graphical interpretation. The server is
essentially
a daemon in front of a database server that performs specific data collection
tasks.
The msmnt-clients actually do the measurements and report back to the
msmnt-server. The clients may take a variety of forms. For example,
a client might be a daemon that wakes up every so often and performs
a round-trip latency test from the host on which it resides to another
fixed host. The daemon then summarizes its data and contacts the msmnt-server,
sending the appropriate quantities. A more complicated example uses the
well know program called "iperf" to measure udp flows from one host to
another. The msmnt-client would then be running on both hosts, and
when the source wants to perform a measurement, it contacts the destination,
which ensures that the iperf daemon is running. The source then sends
the data stream, and the msmnt-client on the destinations reads the results
(in this case, it is the receiving "iperf" that reports the data) from
"iperf" and sends them to the msmnt-server. Moreover, it is clear that in a multicast
environment, there might be more than just pairs of clients involved,
so the msmnt-clients need to be generally defined. The general properties
of a measurement-client are as follows:
- Define a measurement property and an action for describing how to
measure that quantity.
- Measure the quantity and report the corresponding data to the
msmnt-server. The server must be capable of receiving such data.
The next section describes the current status of the project.
Current Status
Currently, the msmnt package is in minimal in nature. The measurement
server is limited to just the database itself, in particular a mysql
database, and only one form of a msmnt-client exists. The client is
a simply a measurement between host pairs and measures round-trip latency,
hop count, and tcp thruput. A configuration scheme exists for the
msmnt-clients, and a graphing scheme also exists on the server.
In more deatil, the status is as follows:
- The msmnt-server.
- Database. The database is currently a mysql database.
- Daemon. The msmnt-server daemon doesn't exist at this point.
Currently, all clients report data back to mysql directly
to the database itself. (Access routines exists also, as described
below, but they also talk directly to the database.)
- Viusalization. There is a graphing routing defined on the server
that allows users to select the measurement type, two timestamps,
and the respective host data, and then plot the associated data.
- The msmnt-clients.
- Client Pairs. The current daemons are restricted to measurements
between pairs of hosts. These include round-trip latency, hop
count, and tcp thruput. Measurements currently under study
are udp thruput and the data associated with such flows.
The clients write data directly to the database rather than
to the msmnt-server (see above).
- Configuration. A configuration scheme has been defined for
the clients.
- Miscellaneous support programs.
- Access to the data is supported through a program which talks
directly to the database. Support tables can be obtained,
and data between pairs of hosts with bounded timestamps can
be obtained.
To Do List
This section will document the many things that need to be worked on
during the lifetime of the project:
- To Do
- Make the php script graphing the data much more robust. It must
check to see that date strings and such are accurate. Also,
make the selected values come back the same as the user previously
selected.
- Standardize timestamps to GMT. Currently data is collected using
timestamps which look like "YYYYMMDDHHMMSS", but they are defined
simply in the local time zones.
- Write server daemon.
- Done
|
