The concept of virtual probes is one that RIPE Atlas users have asked about for quite some time. Although we don't plan to make virtual probes available in 2016, we do plan to investigate this idea and develop some prototypes.
Some members of the RIPE Atlas community have asked us about the possibility of developing virtual probes for several years now (read the most recent RIPE Atlas mailing list discussion for more details, which begins here ). Because there are several advantages and disadvantages to this possibility, we plan to look into the idea further during 2016 and develop one or more prototypes to better understand the full scope of this potential project and the impact on the RIPE Atlas network.
There are several advantages to a virtual solution over the current hardware probes.
First, virtual probes would allow us to greatly extend the RIPE Atlas network. They would be installed by the users themselves and don't require shipping. This is a significant advantage, because we often encounter problems shipping probes to certain countries, where they tend to get held by customs or simply aren't delivered. This is especially prevalent in those areas that are under-represented in the RIPE Atlas network, such as Latin America, Asia and Africa.
Second, virtual probes can be installed anywhere, whereas hardware devices - even small ones like the RIPE Atlas probes - are difficult to install in certain places, either because of physical constraints or because of organisational restrictions on placing external hardware in a network.
On the other side of the argument, virtual probes would add complexity to the system.
We would need to spend resources on developing the concept, integrating this new type of probe into the RIPE Atlas infrastructure and supporting conceptually different types of probes going forward. We need to develop and
maintain procedures for keeping the virtual probes up to date, which could differ from our existing operations. We also need to think about back-end support and potential scalability issues.
Another issue is data quality. The host machine may not run continuously over long periods. It's also easier to tamper with results collected by a virtual probe. Finally, the virtual probes may not be able to distinguish between packet loss caused by an overload elsewhere on the host system and actual connectivity issues. As a result, the data supplied by virtual probes wouldn't be directly comparable to the data collected by hardware probes, making comparisons and correlations between all RIPE Atlas data difficult.
Clearly there are many issues to consider, and it's difficult to comprehensively understand the full scope and impact at this early stage because there are many questions that need to be answered. For example, which virtualisation technology will we use? How will we handle keys and firmware upgrades? How do we ensure the expected level of security of the whole system? What is the real cost to providing back-end support for this technology? How reliable will the data collected by virtual probes be?
We'll also need to gauge how popular this feature might be. There's certainly not enough value in all this work if the expected outcome is only a few dozen installations, while at the other extreme, operating thousands of virtual probes would radically change RIPE Atlas as we know it today.
To help us tackle these issues, we will conduct research in 2016 and develop one or more prototypes that can be tested so that we can make a decision based on actual data and more solid facts. Of course, we will look to the community for guidance throughout this process and will report our findings to you for open discussion and consideration once we have something to share. We will also let you know how you can get involved in testing the prototype(s) as soon as we're ready.
At this time, we only plan to explore the possibility of developing a virtual probe and *not* a virtual anchor. This is because RIPE Atlas anchors need to be stable, reliable measurement targets and we don't believe we can achieve the level of stability with a virtual anchor that we are currently able to achieve with the hardware version, for the reasons outlined above. Please see the mailing list discussion for more details.
As always, we want to know what you think about our plans. You can get in touch in the following ways:
- Leave a comment about this specific article below
- Subscribe to the RIPE Atlas mailing list for discussions with active users and RIPE Atlas developers: ripe-atlas [at] ripe [dot] net
- If you want to report a bug or problem: atlas [at] ripe [dot] net