Questions about Archipelago (Ark)?
Please send questions or comments regarding Ark to
ark-info@caida.org.
Acceptable Use Policy (AUP)
CAIDA seeks sites interested in becoming a part of our next generation
measurement infrastructure. The first step toward participation
comes through negotiation of an AUP
in line with site-local policies. Archipelago provides a flexible
coordination and control mechanism that allows us to work with sites
to craft and implement custom AUPs that allow our monitors to take
measurements and behave as dictated by site's local policies.
- Hardware Requirements
- What is the minimal hardware required to run the Archipelago software?
We have Ark running on a 400MHz PII with 64MB of RAM. However, new deployments
should plan for at least a PIII with 256MB of RAM and 4GB of disk.
- What is the preferred hardware?
A host outfitted with a 1.5GHz PIV with 512MB of RAM and 15GB of disk does nicely.
- Should we provision dedicated or can we share the hardware platform with other applications?
Ark prefers a dedicated host to avoid any potential interferences
when doing timing-sensitive measurements. This also allows us
to lock down the system to impose a systemwide security
mechanism and policy using FreeBSD jails and packet filtering.
However, as exemplified by the fact that Ark can happily run on the 400 MHz PII with 64MB of RAM
described above, its resource consumption makes it a fairly friendly shared application.
- Operating System Requirements
We use stock FreeBSD 6.x. We have experience in remotely managing
the OS, including keeping it patched and doing remote OS upgrades.
We like to minimize the amount of work hosting organizations have
to do on our behalf.
- Usage Patterns
- How much CPU does the system consume, on average?
CPU usage is currently minimal, even when doing continuous large-
scale traceroute measurements at 100pps. Even the 400MHz PII is 90%
idle. For a more modern PIV box, CPU usage is hardly noticeable. We
do not foresee doing computationally intensive workloads (almost all
Internet measurements are I/O bound). We may decide to push out some
preparatory work to the monitors in the future (such as preprocessing
BGP tables), which would increase CPU usage, but we do not anticipate
ever requiring large amounts of CPU resources.
- What are the average memory requirements?
Memory usage is currently minimal (< 35MB in all Ark processes).
In fact, many of our boxes have only 128MB of RAM. Nevertheless,
a box with 512MB provides an ideal platform for hosting our current
experiments with room for future possibilities.
- How much network bandwidth does Ark require, on average?
We run our current traceroute measurements to every routed /24
prefix at 100pps for about 35kbps of outgoing traffic. That produces
about 5MB of trace data per hour which we download to a CAIDA host
concurrently with the measurements. This exemplifies typical
bandwidth requirements for an active measurement. We might run a
few measurements concurrently, each having about that much bandwidth
usage (or more likely less). We do not plan to host any services
(web, content, or distributed hash table) that can potentially
generate a lot of traffic. Nor will we do any high volume bandwidth
measurements (a la Iperf), since we would like to avoid generating
complaints from recipients of measurement traffic.
In general, we try to perform measurements in ways that reduce the
likelihood of complaints. For example, we do relatively low volume
and low frequency measurements (from the point of view of individual
destinations) and prefer to avoid probing the same destinations
repeatedly.
Because complaints do occasionally occur, we try our best to direct the
complaints to us rather than to the site hosting a monitor. An
important way is by setting up the reverse mapping for a monitor IP
address to either monitor.ark.caida.org
(e.g., san-us.ark.caida.org)
or monitor.ark.caida.site-domain
(e.g., san-us.ark.caida.ucsd.edu).
We have weighed the possibility of running a lightweight webserver on
the monitors themselves that would describe the measurements, but
based on an evaluation of the security vs. benefits tradeoff
(something we have considered for many years in the context of the
skitter infrastructure), it is not our general policy to set up such a
webserver. We can, however, do so upon request by the site hosting
a monitor.
Hosting sites should simply forward any complaints they receive to us.
We will respond to the complaints, and if necessary, add destinations
to our no-probe list which will prevent future complaints from the same
destination.