CAIDA Ark Traceroutes

[m-appel]

Description

There are two CAIDA traceroute datesets available:

1. The IPv4 Routed /24 Topology Dataset
2. IPv4 Prefix-Probing Traceroute Dataset

The first contains traceroutes to all routed /24 prefixes on the Internet (one random IP per prefix). However, the targets are distributed over all Ark monitors (197 at the moment). Thus, one measurement cycle contains all targets, but each target is only measured from one monitor.

The second one has a coarser target set, consisting of one random IP per announced BGP prefix, but the entire target set is covered by each monitor. A subset of 13 monitors participates in this measurement. In general, new data should be available daily, but it looks like some monitors can be slow.

Since the measurements run in cycles that guarantee a specific target coverage, Ark data should (for our purposes) be preferred to the RIPE Atlas topology measurements, which result in a more random sample of sources/targets.

For IPv6 only the equivalent to the /24 dataset is available: Ark IPv6 Topology Dataset

Modeling

The proposed modelling looks as follows.

reference_org: CAIDA
reference_name:
caida.prefix_probing_v4 or caida.probe_data_v4 for IPv4
caida.probe_data_v6 for IPv6

New nodes

1. ScamperTrace: Represents a single traceroute. Properties are the traceroute metadata and an additional id property that uniquely identifies the traceroute. Proposing to use <monitor>-<cycle_id>-<#> where # is an increasing number per monitor.
2. ScamperMonitor: Since we do not know the public IP of the Ark monitor, we need to add this node as the traceroute source. It can be connected with a Country to enable regional queries. Property is only name of the monitor. We can also try to get the ASN from here.

Relationships

(:ScamperTrace)-[:SRC]->(:ScamperMonitor)
(:ScamperTrace)-[:DST]->(:IP)
(:ScamperTrace)-[:HOP]->(:IP)

(:ScamperMonitor)-[:COUNTRY]->(:Country)
(:ScamperMonitor)-[:LOCATED_IN]->(:AS)

The HOP relationship contains the metadata of the specific hop (TTL, RTT, etc.) and thus allows reconstruction of the traceroute order.

-[:LOCATED_IN]->(:AS) is consistent with existing modelling of

(:AtlasProbe)-[:LOCATED_IN]->(:AS)

The IP nodes are connected to Prefix nodes via postprocessing.

Open Questions

• Which of the two datasets do we want to import?
• Do we include only successful traceroutes?
• Are the suggested reference names okay? These refer to the names of the datasets on the FTP server and are thus precise. A more general caida.ark_traceroutes might be easier to understand though.