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.
Background
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.
Advantages
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.
Disadvantages
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.
Next Steps
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.
Virtual Anchors
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.
Feedback
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
Comments 4
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Leo Vegoda •
"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" I suppose it depends on what you are trying to measure. If you are trying to measure the user (possibly an IoT device of some kind) experience then that's totally valid. Would I be right in thinking that a combination of both hardware and virtual probes would help get a clearer focus on what is causing poor experiences and so inform efforts to improve the situation? If that's the case, virtual probes could be a very good thing.
M. Taj. •
Considering the multi-platform development costs, I may also add: Cons: - The problem of User Trust - Variation of resources available on each computer at different times - Instabilities caused by tunnels and random connection changes on the portable devices Pros: - Ability to see internet through mobile devices - Measuring access through mobile networks - Way Deeper penetration of the project with much lower cost Those variations can be handed by keeping extracted data separate from those of hardware probes and comparing the results from both networks. I also support the idea of deploying the same firmware as anchors on dedicated VM's in datacenters around the globe. In both cases, ambassadors are good point to start a prototype test. Also consider getting projects like dd-wrt & open-wrt involved and let their users choose whether to register into atlas or not. Regards, M.T.
Wilfried Woeber •
Comment #1: Leo has put my thoughts regarding the potential value of virtual probe into a nice paragraph already, thanks! Comment #2: for the moment I'd approach the issue with the concept of adding a 3rd category of probes. We already got the small harware ones (V1, (a couple of V2 - still alive?) and V3, with a V3bis for wireless being considered), plus the anchors (beta and production). Thus adding another category may be "just" an extension of the family? Comment #3: regarding supported hosts or platforms - I am not up to speed with virtualisation technology at the moment, unfortunately, but my idea would be to package the thing into a bootable image that can be launched on different hosts/platforms. Then take it from there. I may be completely off-track though. Looking forward to more comments and ideas, Wilfried
Zakaria Al-Qudah •
I strongly advocate the introduction of virtual probes. Overall, the virtual probes are not going to replace hardware probes. We can have them in parallel. When we do measurements over virtual probes we are aware of the underlying issues. Yet, virtual probes have the ability to uncover things that current hardware probes do not (e.g., 3G and LTE networks, greater coverage, etc). I think having the two systems in parallel creates the best value. -- Zak.