Robert Kisteleki

Plan of Action for RIPE Atlas Anchor VMs

Robert Kisteleki
0 You have liked this article 0 times.

Members of the RIPE Atlas community have asked us to implement RIPE Atlas vantage points as Virtual Machines (VMs). In order to address these requests, we came up with a plan of action.

Several members of the RIPE Atlas community have asked us before about our plans for implementing RIPE Atlas anchors (or probes) as Virtual Machines. Even though some others have reservations about this idea, the opportunity to extend our measurement system into networks where installing physical devices is difficult, or even impossible, is very intriguing.

In a separate but related thread we've also been approached by operators who believe that "measuring the cloud" would be beneficial for both the community (as it also provides data about general network health) and the users of these services (as such measurements would benefit all cloud users at the same time).

Our plan of action, outlined below, addresses these cases.

Running a pilot to evaluate VM anchors

During the first two quarters of 2018, we'll run a pilot in order to:

  1. Evaluate the amount of changes needed to our systems
  2. Get familiar with the additional operational needs
  3. Perhaps even survey the demand for such a service

More specifically, we define two "tracks" of installing Virtual Machines that act as RIPE Atlas anchors:

  1. The first track (A) will involve one or two cloud providers that offer VMs to the public. The intention here is to get familiar about what it takes to use a "standard service" for the VMs.
  2. The second track (B) will involve at least one other partner who is otherwise not providing VMs as a public service offering but is a willing partner to provide this for the pilot. This is meant to understand what it would take to invite volunteers from the community who are willing provide VMs in their networks for the cause.

We intend to partner up with Amazon Web Services for track A and with Measurement Lab for track B. The two tracks may run in parallel, the exact details on this are not decided yet. Initially we'll install a handful of servers with each partner. If all goes well, we may extend the scope of the pilot to other entities or individuals who are inclined to be forerunners.

The VMs that we'll set up will act as full-feature RIPE Atlas anchors: they will be a part of the so-called "anchor mesh", meaning they will be measured by other anchors and probes, and will also act as probes. In other words, they will act just like regular anchors. They will be tagged appropriately in order to let people exclude them from their measurements, or to the contrary, to use these specifically for other measurements.

Towards understanding some unknowns

During the pilot we expect to get a better understanding of how such a feature would work in real life. For example, virtually each cloud provider has their own management interface to initialise or reboot VMs. Dealing with too many of these could be an unwarranted effort. On the other hand, if we gain enough insight during the pilot to understand what the commonalities are between these (and the other individual supporters from track B), then we could be able to streamline our procedures and provide a means to scale this approach to match the expected demand.

It would also be nice to get a feeling for how much "expected demand" there would be for such a feature. For example, it's reasonable that one can estimate the total number of POPs for the common cloud providers, with the assumption that we would prefer one anchor in each POP. However, we don't have a good indicator of how many "other" (track B) partners would potentially be interested. Our support infrastructure will need a different approach depending on the order of magnitude. So, for example, either during or after concluding the pilot we'll be able to carefully grow the network in this aspect and check if this approach is sufficient or not.

We're also curious to see if worries that have been presented before are warranted. For example, are measurement results from or towards VM anchors distinguishable from hardware ones? Opinions seem to differ on this, but we expect to have sufficient data to analyse here. We intend to execute our own analysis on this, and we would be happy to see if others are interested as well. 

Concluding the pilot

Running this as a pilot doesn't imply a long-term commitment. Even though we see a lot of potential, we have to see if the benefits outweigh the downsides. Once we conclude the pilot, we'll make and publish our evaluation on this. If deemed successful, increasing the amount of partners and servers is definitely an option we look forward to. 

0 You have liked this article 0 times.

You may also like

View more

About the author

I am the leader of the Research and Development team at the RIPE NCC leading a dedicated team of thinkers to support the RIPE community by providing network research, data analysis and prototype tool development and services including RIPE Atlas and RIPEstat.

Comments 7