In 2013 and 2015 we provided high-level reports on the status of our plans for our technical services and tools. It is time for an update. In this first article we will focus on RIPE Atlas.
RIPE Atlas is a globally distributed active measurement network with a variety of unique features. One of the main differentiating factors of RIPE Atlas is our measurement infrastructure design. Currently, measurements are performed by three different types of hardware: RIPE Atlas version 1 probes (v1), RIPE Atlas version 3 probes (v3) and RIPE Atlas anchors. These devices, which are distributed across the globe, perform different types of measurements. As well as being able to run a set of pre-defined measurements, users can also schedule measurements themselves. All of the measurement results, as well as measurement meta-data, is stored and indexed and is searchable and accessible through our API and web interface.
Benefits and use cases of RIPE Atlas have kindly been documented by numerous community members on RIPE Atlas: User Views and Use Cases. This new article is meant to document some of the insights of the service and to share our plans with you.
As of the time of writing, we have over 9,700 RIPE Atlas probes, along with 250 RIPE Atlas anchors - compared to 8,000 probes and 117 anchors at the same time in 2015.
Figure 1: New Arrivals are new hosts who connected a RIPE Atlas probe in the last ten days
So far, about 7.5 million measurements have been specified by our users: some use a few probes while others use a lot; some measurements are ongoing while others are one-offs. There are about 14,000 measurements running concurrently at the moment, collecting roughly 4,500 data points per second, or 400 million per day.
Last year we worked hard on a more detailed set of APIs to interact with the system, which eventually replaced the old “version 1” APIs. While the baseline number of API calls is steadily increasing, these interfaces are also handling bursts of calls coming from various measurement campaigns.
While we are happy with the recent growth of the RIPE Atlas network, we would like to see the network expand further still, and we are thereby focusing on underrepresented areas of the Internet, both in terms of geography and topology. Measurement accuracy and distribution requirements really depend on use cases, but generally speaking, we think we will have attained a good sample base once we represent about 10% of active ASes over the Internet.
In 2015 we were covering 9.6% of active Autonomous Systems (ASes) announcing IPv6 prefixes. Today we are covering 9.3% of ASes announcing IPv6, even though there are almost 4,000 more active RIPE Atlas probes. This means we need to act fast to be able to catch up with Internet growth so as to keep the RIPE Atlas network a statistically relevant network.
For ASes announcing IPv4 prefixes, we used to have a coverage of 5.6% whereas today, with 2,000 more probes, we have a coverage of 5.9%, or 3,368 networks. Those numbers signal that IPv4 Internet is growing much slower than the IPv6 Internet. At the same time, it tells us we need more active RIPE Atlas probes to be able to achieve our 10% goal.
A linear projection based on IPv4 Internet coverage, which suggest continuing probe distribution using current models and following current probe activation trends, indicates we would need about 6,700 new active probes today to reach that goal. Extrapolating the data with the growth trend from the past two years, we will need to activate roughly about 9,000 probes in the coming two years in order to reach our 10% coverage goal.
Adding the probes that will eventually drop off the network and the ones that will never get activated, we will need to ship roughly 11,000 probes in the next 24 months. That would be 5,500 RIPE Atlas probes each year. For the remainder of 2017 we are aiming to ship another 5,000 probes.
As mentioned in the RIPE NCC Technical Services Update 2015, we reduced the cost of the probe hardware and shipping by a third and now we are having an even closer look at adding further measures for efficiency where we can introduce them. These will be focused on increasing the activation rates to a higher number than we have achieved at present as well as improving the lifecycle of probes. This will be mainly achieved by selection of our new probe hardware.
New version of RIPE Atlas probes
Some of the older probes showed signs of instability after a while (please refer to RIPE Atlas: Countering Hardware Issues with Better Firmware for details). We were able to trace most of these issues back to the unreliability of the memory sticks that we ship along with the probes. After a certain number of writes, these sticks became unstable and caused a diverse range of random issues. We have mitigated most of the unwanted effects by altering the RIPE Atlas probe firmware and by only allowing a minimal number of writes to the USB disks. But that is not a permanent solution. We need reliable Internal storage, which needs to be bigger than that available for the average run-of-the-mill wireless router, for us to be able to run this.
Also, with new and potentially more powerful measurement types and the increasing frequency of measurements, we need more resources on the probes. We will need more processing power and possibly more memory on the probe itself.
In addition to all that, we are looking for a good price point and global availability of this new hardware. This reduces the number of options, but we have one or two candidates that we are now testing rigorously! Our current plan is to reveal the new hardware in 2017. Please watch this space.
RIPE Atlas anchors
As mentioned above, we have booked good results, together with the community, to deploy more RIPE Atlas anchors, both in the RIPE NCC service region as well as distributed globally. We still see a steady flow of new organisations joining the project and contributing anchor hardware, so we expect this trend to continue further in the coming period. Unfortunately, we have recently learned that the hardware manufacturer behind the anchor hardware, Soekris, is reorganising their production. We follow the developments closely and have some alternative hardware options under review, that we might switch to in the case that Soekris would decide to cease manufacturing the hardware that we currently use.
Figure 2: Location of RIPE Atlas anchors
Shipping and handling
We are aiming to optimise our shipping methods, the activation rates of the RIPE Atlas probes as well as the retention rates. In other words, we want to ship probes as cheaply as possible to the host, either directly or with the help of our ambassadors. We also need to ensure that users actually enable probes and keep them online as much as possible.
We collected a lot of feedback on how to improve on the points above. We learned that, for example, in some parts of the world, it is critical for the probe hosts to receive power adapters together with the probes. We generally do not ship RIPE Atlas probes with the adapters since the probes require normal 5v power from a USB source and many users power the probes through other means.
Shipping an adapter could increase costs, and in some parts of the world there are strict safety regulations and requirements to be taken into account. Then there's the more general issue of ensuring plug compatibility across different regions. Ultimately, we've not yet made a firm decision on the issue yet, and we're also bearing in mind that more modern hardware may require a higher grade power source to operate.
All of these issues can be resolved, but they add to the cost of shipping and handling RIPE Atlas probes. We are working to find a reliable solution.
Another common issue is that of import laws: some countries have complex customs regulations, which means that shipping or transporting even a single probe over their borders can be tricky. That’s why we have formed strategic partnerships with APNIC, LACNIC and AFRINIC. They are a great help for us to overcome these logistical issues. In the past two years, we have invested in this model with a bit more focus on the APNIC region as the demand was clear in that region. The results were very encouraging. We now have many more RIPE Atlas probes in the APNIC service region. During the process we learned that once we kick-start the process, we can experience tremendous growth with minimum resources. We have reached that point in our collaboration with APNIC and now we are aiming to repeat the same practice with AFRINIC and LACNIC.
It is important to mention that the Internet Society, in collaboration with AFRINIC, has raised funds for ten RIPE Atlas anchors in Africa. Two of them are already up and running. We are aiming to work even more closely with AFRINIC in order to support deployment of more probes and anchors.
APNIC started a similar initiative and last year they funded 15 RIPE Atlas anchors in their region. This year they are committed to fund another five.
LACNIC is also actively supporting RIPE Atlas, for instance by sponsoring RIPE Atlas anchors in their service region. Last year, LACNIC sponsored four anchors, and there are plans for six more. LACNIC staff is also helping us with probe distributing.
As of late 2016 and early 2017 we’ve been working on a feature to perform measurements over WiFi connections – assuming the probe is otherwise up and running using the regular wired interface. The original intention behind this use case is to target widely distributed, federated networks such as eduroam. In this case, a win-win situation seems achievable: RIPE Atlas gains a bigger footprint by reaching previously uncovered networks, whereas sponsors of these measurements get useful, previously hard to collect insights into the actual behaviour of their network.
It seems relevant to note here that the wireless capabilities will not be added as a default to any RIPE Atlas probes. We currently foresee that the WiFi-enabled probes will be of a specific hardware type that will only be available to a subset of probe hosts. Also note that WiFi measurements are also active only, i.e. there's no scanning for WiFi signals even on WiFi-enabled probes. As indicated above, the target audience for this feature is complementing our current group of hosts, so there is no use for WiFi capabilities on regular RIPE Atlas probes.
We intend to continue these efforts in 2017 and beyond, and will report more on this effort as it develops.
Virtual RIPE Atlas
We are also considering various options regarding the use of “virtual probes”. These would be probes where the physical device is replaced by a Virtual Machine provided by the host. These would have the benefit of being able to reach providers who otherwise would be reluctant to install external hardware. But we also need to consider the costs: the operational risks of less understood running environments, the changes caused in the operational model, dealing with “noisy neighbours”, the need for mechanisms to avoid “fast flux” deployments, etc.
This work is only just beginning, and as with the WiFi measurements, we’ll report back to the community on these efforts.
In summary, whilst we’ve seen a great deal of growth in the RIPE Atlas network since our last technical update, our efforts are still very much geared toward achieving more effective deployment. We still need to push the network’s rate of expansion in order to keep up with the general growth of the Internet and to achieve our goal of representing 10% of active ASes. At the same time, we continue testing solutions for countering probe hardware issues, assessing methods for improving the proportion of connected probes, and coming up with cost-effective options for shipping. Plans are also in progress for further enhancing RIPE Atlas’s features and developing entirely new solutions for existing issues such as virtual RIPE Atlas.
In order to stay up to date on all the latest technical developments from the RIPE NCC, be sure to follow RIPE Labs. Coming up, we have two articles in the making that will provide further insights into the different technical services provided by the RIPE NCC. The first will provide an update on our plans for DNS services, such as K-root and reverse DNS, while the second will delve into the details on a variety of tools we offer, such as RIPEstat, DNSMON and OpenIPMap.