Well, a suggestion. Suppose that every time a probe does its test, it also reads <something> from RIPE that tells it the address of the target to probe next. This would allow RIPE (passing along your instructions, or executing its own) that could implement any of a variety of scenarios, and change them from time to time. On Apr 27, 2012, at 3:20 AM, Alexander Mayrhofer wrote:
Hello,
i'm figuring how RIPE atlas could be most useful for assisting in monitoring our Ancast Network, and came up with the following idea:
The Atlas network has a big advantage over other monitoring /measurement networks, which is obviously its sheer size (and topological diversity). Rather than using the Atlas network for pure performance measurements, i would love to be able to use Atlas for reachability measurements (and understand which Anycast location attracts traffic from which region, and how this changes over time). These reachability / topology discovery measurements do not need to be nearly as frequent as the performance measurements, but should utilize all available probes.
So, instead of being able to use 10 probes to run a continous performance test (say, DNS query every 300 seconds), i would rather like to be able to use a very high number of probes (best case: "all"), but have each of the probe eg. perform just one traceroute per day (or, even once per week would be enough). This would give me an excellent overview about the topology, but is not possible using the current limits of the UDMs.
However, instead of allowing users to allocate measurements to a much higher number of probes, this functionality would also be possible be adding some "probe round-robin" feature to the control infrastructure, for example "randomly allocate a new set of probes every xx seconds".
If that feature would exist, i could implement the above reachability test with the following parameters:
Test: traceroute Number of probes: 10 Measurement interval: 3600 Swap probe-set interval: 10800 (NEW feature)
(which would re-allocate new probes every 3 hours, theoretically working through all 1500 probes about every month?). An obvious alternative would be functionality where i could "queue" "single-shot" measurements for the whole network (since chances are low i would get every probe if they are randomly assigned).
comments? Suggestions? Alternatives?
Alex Mayrhofer Head of R&D nic.at