---

Key Concepts

skitter determines the unidirectional IP path from its location (defined as the source) to one or more destinations. A unidirectional IP path is defined as the IP devices traversed by IP packets traveling from a source to a destination at a single point in time. Because skitter does not use any source routing, the network layer will always determine the path of a skitter probe.

Note that a point in time is nonsensical for skitter measurements in most cases. It is not possible to obtain a path measurement instantaneously without simultaneous access to all IP devices along the path. The IP record-route option would allow some accuracy for the first 9 hops of any path, but is not reliable in many cases: some routers drop packets with options; some ignore the options and reply without them; still others reply with garbage. Hence skitter uses a method similar to that of traceroute, probing each hop along the path by incrementing time-to-live (TTL) in the IP header. The method for determining how skitter labels IP hops is as follows: the Nth hop in an IP path is the device that sends an ICMP TIMEXCEED message in response to a packet with a TTL of N.

Kernel Modification for Timestamp Accuracy

To improve the accuracy of its round-trip time measurements, CAIDA added a kernel module to the FreeBSD Unix operating system on which skitter runs. While this timestamping may be insufficient for one-way measurements or detailed correlation across skitter platforms, it does provide an indication of performance variations across the infrastructure. By comparing data across various sources, analysts can identify points of congestion and performance degradation or areas for improvements in the infrastructure.

Short Individual Path Polls and Overall Poll Cycles

In order to collect data showing changes in paths over a period of time. skitter must track the path changes from one poll to the next. The span of time taken to determine a particular path should be short, since we're interested in a snapshot-like measurement of the path. At the same time, skitter needs to determine paths to many destinations in a short period of time, which requires polling paths in parallel. These two requirements are in conflict, and require that we compromise.

skitter Packets: Format and Rate

skitter packets have a simple singular format. Look here for details.

The user should have coarse control of skitter's output packet rate, while input packet rate is under the influence of network vagaries. In operational use thus far, the amortized input rate seems reasonably close to the outbound rate, but the reality of the system is that input packet rates can be very bursty and synchronization can develop. We do not aggravate congestion collapse since we do not become more aggressive in the face of loss, and we do not allow a high input packet rate to increase our output, but we do not yet use the input packet rate and an estimator to control output packet rate. Skitter's parallel polling of paths in its breadth-first search will exacerbate the synchronization effect, as will low RTTs, low RTT variance, and high fanout on outbound paths.