[Scamper-dev] scamper
Bradley Huffaker
bhuffake at caida.org
Wed Apr 30 17:21:44 PDT 2003
I would like to begin dicussion of how similar scamper should be to
skitter. Ryan, Dan, and I have just finished a overview of skitter and it's
supporting systems.
The most pressing topic is about leaving scamper as it currently stands,
a single run application, or make it more skitter like, continiously
probing it's destination list until halted externally.
Also do we wish to make the fileformat compatable with the current skitter
so we can reuse the skcollect (etc) code?
---------------------------------------------------------------------------
skitter
---------------------------------------------------------------------------
WARNING: This is a pre-release of skitter. Please do *not* redistribute
this package in any form without explicit written consent from CAIDA.
Description
===========
skitter is an IP path measurement system. skitter measures the
forward IP path and RTT to a (potentially large) set of destinations.
It traces many paths in parallel, using a configured packet rate. The
results are stored in ARTS files (which may be processed using the
arts++ package).
Installation
============
Please see the INSTALL file for installation instructions.
system overview
===========
There are two machines involved in the skitter process, for any given site.
There is the skitter box, often called the monitor, and there is skcollectd
box, often called the server. The skitter box does the actual measurement,
and stores the data locally. The skcollectd box then connects to the
skitter box, and downloads the data and stores it. The skitter box also
downloads updates, twice daily, to its destination list (a list of IP
addresses the skitter box is to traceroute to) For convenience, we
download these updates from the skcollectd box.
The skitter box itself runs two processes: skitter, and skdatad. skitter
does the actual traceroutes, and stores the data in a file, while skdatad
listens to a port (typically 3100) and serves that data file. The
skcollectd part is also composed of two processes: skcollectd, and
sksorter. skcollectd has a list of skitter boxes. It connects to each
skitter box's skdatad process, in order. It authenticates itself using
kerberos 4. Once it has downloaded the data into a temporary spool
directory, it launches sksorter, which sorts the data and stores it into a
directory structure as follows: /base_dir/<monitor-name>/<year>/<two digit
month>. The file itself looks like: <monitor-name>.<8 digit date
format>.arts.
The destination list update system is a simple set of scripts and a web
server. Basically, each client has a script which uses curl (a
command-line file-downloader) to download a destination list (usually
each monitor tries to download a file with the same name as the monitor).
The web server, to make remote firewall administration less confusing, is
run on the same machine as the skcollectd process. The transaction is over
SSL, and each monitor has a client SSL certificate that provides
authorization to download destination lists.
skitter overview
================
skitter attempts to keep within its target packet rate by setting
the active window. This window contains the list of destination which
are currently being probed. The window polls through the whole list
then closes. skitter then prints out all the information collected
in the last cycle in the destination. It waits one minute before it
probes the list again. It is also during this waiting period that the
destination list can be changed if an interrupt is detected.
When a destination is added to the active window skitter begins to
send ICMP echo requests towards it. If skitter fails to receive
a response from either the destination or a ICMP TTL expired message
from a router it will send another ICMP packet.
If skitter fails to get a response for the last 3 packets or receives
the ICMP TTL expired packet it will increment the current TTL target
for the destination before sending the next packet.
There are three cases were skitter would stop incrementally
approaching the destination:
A response was received from the destination.
In this case skitter logs the TTL which got a response and
logs the TTL value in the response packet. The destination
is removed from the active window.
An IP address sent a TTL expired packet from two different
TTLs. It is assumed that a loop has been found. The second
occurrence is stored to show where the loop was found.
5 TTL values have been probed 3 times, each without
a single response. A final packet is sent with a TTL of 255.
(The number of non-responding hops probed before giving up is
called the gapLimit, and is configurable, with a default of 5.)
An ICMP unreachable packet was received. The ICMP code is recorded
and the destination is removed from the active window.
skitter removes a destination from the active window in the following
cases:
A response was received from the destination. This can be
a response to the incremental TTL increase or when the
TTL is set to 255.
In this case skitter logs the TTL which got a response and
logs the TTL value in the response packet. The destination
is removed from the active window.
An ICMP unreachable packet was received. The ICMP code is recorded
and the destination is removed from the active window.
skitter has failed to get a response after three attempts and
TTL equals 255.
terminology
===========
monitor
-----------
The machine that is running the skitter process.
Each skitter monitor is capable of running a single destination
list at any given time.
destination lists
-----------
The list of IP addresses which are to be probed by skitter.
cycle
----------
A single complete run though the destination list of a single
monitor.
trace
----------
A single combined Round Trip Time (RTT) and forward IP path
from a single monitor to a single destination.
trace overview
==============
Source and Destination - IP addresses in standard dotted octet
notation.
----------------------
Source - the IP address of the skitter monitor. The first IP
address in all paths measured by this monitor.
Destination - the IP address of the final destination to which the
packets were sent in a given trace. The last IP address of the
measured IP path.
Time - UNIX timestamp
-------
The meaning of this parameter is different in different versions of
skitter.
version 0-9-a3 or earlier (files collected before 2001/02/06):
In I and C type traces - time when the reply was received
from the destination
In N type traces - time when the current cycle (one pass
over all monitored addresses) of probing started.
Same value for all N-type traces in a cycle.
version caida-1.1 (files collected after 2001/02/07):
In all types of traces - time when the skitter send the
first probing packet to this destination.
RTT (Round Trip Time) - in milliseconds
---------------------
The amount of time elapsed between the packet leaving the skitter
source and the reply from the destination arriving back at the
source. Skitter will always take the first such reply from the
destination; later replies are thrown away.
Count
--------
The Time To Live (TTL) of the first probe packet for which a reply
was received from the destination. Since the packet had to travel
through that many routers to reach the destination, this number
represents the distance from the source to the destination measured
as `the number of hops'.
haltReason
--------
This stores the reason skitter stopped incremental probing. It
does not mean indicate that a response was not received from
the destination, since a response could still be received from
the 255 TTL packet. This may take on the following values:
k_gapLimitExceeded - maximum number of non-responding TTL
hops found.
k_loopDetected - an IP address responded at two different TTLs.
k_icmpUnreachable - A ICMP unreachable type was received.
k_noHalt - skitter received a response from the destination
before it stopped incremental probes.
haltReasonData
--------
This stores any extra information which might be stored in
case the haltReason is set.
For k_gapLimitExceeded: the currently configured gap limit
For k_loopDetected: loop length
For k_icmpUnreachable: the ICMP code
For k_noHalt: no value
#--------------------------------------------------------------------------
# Daniel McRobb <dwm at caida.org>
# skitter development team <skitter-dev at caida.org>
# CAIDA
#--------------------------------------------------------------------------
# @(#) $Name: $
# @(#) $Id: README,v 2.3 2003/04/30 00:09:16 rkoga Exp $
#--------------------------------------------------------------------------
--
Bradley Huffaker Terrorism is the price of Liberty
CAIDA/SDSC/UCSD Tyranny is the price of Security
More information about the Scamper-dev
mailing list