We're thinking about implementing WiFi measurements in RIPE Atlas, and we want to know what you think. There are several different ways we could do this - find out more below and then take our poll to make your voice heard!
For an update on our plans to implement WiFi measurements in RIPE Atlas, please see RIPE Atlas WiFi Measurements - Part 2
We're always thinking about ways to improve the RIPE Atlas network and make this service as useful as possible for as many people as possible. As we're approaching 10,000 connected probes, we thought it was a good time to take stock and think about what our next steps might be in order to continue serving the wider Internet community.
Using RIPE Atlas probes to conduct WiFi measurements is something we've been discussing with the RIPE Atlas community for some time already . The hardware used as the basis for the current (third) version of probes (called v3 probes) are wireless routers, but in configuring the probes for use in RIPE Atlas, we decided not to provide software to support WiFi because we wanted to keep the host's traffic separate from the probe in order to ensure the host's privacy. Recently, however, some users have asked about the possibility of allowing these measurements because they're interested in monitoring wireless networks, and believe this use case could help us expand the reach of the RIPE Atlas network.
What do we mean by WiFi measurements?
Before outlining the reasons that it might be beneficial to allow the probes to do WiFi measurements, it's important to understand exactly what we mean when we talk about this. What we do NOT mean is that the probes would connect to the RIPE Atlas infrastructure over a wireless Internet connection. Instead, they would behave just as regular probes do now, being physically connected to a network, connecting via Ethernet to the RIPE Atlas infrastructure and receiving firmware updates, etc. this way. They would conduct all of the same built-in measurements that the regular probes do now. Conducting WiFi measurements would simply mean connecting to a specific WiFi network (with optional authentication), performing measurements over this new connection, then closing down the WiFi connection. These WiFi measurements would be user-defined measurements about the availability of a nearby wireless network specifically chosen as a target by the user setting up the measurement ahead of time - the probes would not scan for nearby wireless networks themselves.
Use cases and benefits
The idea to do WiFi measurements was first proposed by GÉANT , the European data network for the research and education community . They are interested in using RIPE Atlas probes to measure the availability of eduroam, their world-wide wireless network developed for the international research and education community, which is used by many universities around the world.
Of course, anyone interested in testing a particular wireless network's connectivity and availability - whether they run the network themselves or they're an interested customer - could perform their own WiFi measurements to monitor their own network or troubleshoot issues using RIPE Atlas probes around the globe. How many probes would be available for these sorts of measurements would depend on the way that we implement this feature.
This feature could attract new probe hosts interested in deploying probes throughout their networks, and could help expand the RIPE Atlas network, to the benefit of all RIPE Atlas users.
Candidate hardware for the next generation (v4) RIPE Atlas probe
Different implementation scenarios
There are a few different ways we could implement this. The major differences between them have to do with whether we implement WiFi measurements for the current v3 probes or we need to switch to a new generation of probes for this, and whether this is an opt-in feature for probe hosts. (Note that v1 and v2 probes are not capable of supporting WiFi measurements). Here are the main possible scenarios, with the advantages and disadvantages for each from our perspective:
1. Make WiFi measurements available for all existing and future v3 probes (and continue to use only v3 probes).
Advantages: This approach is the simplest for us from a technical and administrative point of view, because it would simply involve turning on the wireless capability fo all v3 probes, and would avoid having to keep track of different kinds of probes (i.e. those that support WiFi measurements and those that don't).
Disadvantages: Some RIPE Atlas users could feel this is a violation of the original terms they agreed to when volunteering to host a probe and might decide to unplug their probes from the network.
2. Make WiFi measurements available as an opt-in feature for all existing and future v3 probes
(and continue to use only v3 probes).
Advantages: This would allow for the largest number of probes being available for WiFi measurements, making the RIPE Atlas network the most useful for those interested in these types of measurements. Users would be able to opt-in to supporting WiFi measurements only if they choose to do so. From an administrative and technical standpoint, this feature could be implemented with probe tagging, which means a relatively small amount of development work from our end.
Disadvantages: Some current probe hosts might not trust us to ensure their choice about whether to enable WiFi measurements is carried out, or be upset that we changed the way the v3 probes are being used (even if only by some hosts) and could decide to unplug their probes from the network.
3. Keep v3 probes as they are and make WiFi measurements available only for the next generation of probes (v4 probes).
Advantages: Users will have full control over whether their probe is capable of performing WiFi measurements.
Disadvantages: From a technical point of view, this option would require significant resources in order to configure a new version of the hardware to support the measurements. Administratively, this is the most complicated option because it would involve keeping track of two types of probes (v3 and v4 probes), with all the associated logistical challenges.
4. Stop distributing v3 probes and make WiFi measurements available by default (but with an opt-out option) for the next generation of probes (v4 probes).
Advantages: This would encourage users to allow WiFi measurements, making this feature more useful for those interested in these measurements. Users could still decide to opt out of supporting WiFi measurements.
Disadvantages: Administratively, this would require development on our end in order to switch to the v4 probes and keep track of two types of v4 probes (those that have opted out and those that haven't).
Take the poll - tell us what you want!
As you can see, there's no clear-cut "winner" - at least not from our perspective - which is why we need your input. What do you think? Which scenario would you prefer? Let us know by answering our poll and we'll take the votes into account as we move forward in coming up with the best solution possible, both from a technical standpoint and in meeting the needs of our community. (Please note that the poll is closed now.)