# In The Works
The RIPE Atlas team is working hard to improve our services. Here’s what we’re currently working on:
# Current Activities
# Better Public Statistics
UI / API Features
We are working on publishing clearer indicators, mostly in the form of graphs, on:
- Health of the result collection / delivery processes (in order to give better insight to users about when can they expect results for their measurements)
- Long-term statistics: how the population of probes, anchors, etc. developed over time.
# Simplified Sponsor Engagement
Other
We'd like to make it clearer what it means to step up as a RIPE Atlas sponsor, and what benefits this provides to the parties.
# Probe v5
Other
We're in the process of selecting and integrating a new version of the hardware probes ("v5").
# Measurement Data in Google BigQuery
Data Research
Working with large sets of RIPE Atlas data can be hard:
- It can take a long time to transfer result data
- It’s hard to write scripts to analyse this data and they don't always scale to the volume of data that's available in RIPE Atlas
- Combining RIPE Atlas data with other data sets can be tiresome
We’re investigated how to deliver our data into Google's BigQuery (opens new window), in addition to the current data flows. The ease of use and processing power available in BigQuery can help address many of these difficulties. This work helps researchers dealing with large volumes of RIPE Atlas data, and also operators who would like to dig into historical results to check or verify observed network issues.
This feature is currently in "public beta" stage. You can read more in our RIPE Labs article (opens new window).
# Probe Similarity
Features Research
Finding probes that are similar to others (in terms of their place in network topology) can be useful. It's also handy to find probes that are as different as possible in this respect. Examples include:
- Which set of probes will provide the user the best diversity in terms of behaviour for the budget that I have
- How can I replace a particular probe with the one that's the most similar to the original one?
- How can I replace a particular probe with the one that the is the most similar, but also fits the same constraints as the original probe, e.g. country or AS?
- How can I select a probe that is really similar to a set of probes that were previously selected?
We're working on adding functionality to address these question.
# Enhanced Notifications Control
UI / API Features
You might be interested in receiving a notification when we make updates or changes such as probe events, measurement events or credit line changes. We’re working creating a control panel so that you can manage which notifications that you want to receive, and how you receive them.
# Probe Dashboard
UI / API
We’re working on providing a better user experience for the Probe Dashboard. It currently provides a good overview about a probe’s status and data but there’s much more that you could get out of this dashboard as a host.
# Delivering the Website Using a CDN
UI / API
RIPE Atlas is built, managed and currently served from the RIPE NCC's network.
We’re working on delivering our content using CDN(s) to optimise interaction with the service from physically and topologically remote regions.
# Better RIPE IPmap
Features
RIPE IPmap (opens new window) is the RIPE NCC's infrastructure geolocation tool. It relies heavily on RIPE Atlas to enhance its data quality - and also serves as a data set for RIPE Atlas itself as well as for network operators and researchers.
We are working on various aspects of this service, including API and UI enhancements and more geolocation "engines".
# Improvements on Handling Probe Anomalies
Operations / Internal
With over 10,000 probes, we see several kinds of anomalies such as:
- Connecting probes
- Data collected and reported by probes
- Network anomalies
- Hacking or abuse attempts
We're working on functionality to deal with these anomalies flexibly by aggregating probe behaviour across probes, regions, hosts etc. to detect what's normal and what's abnormal when it comes down to day-to-day handling of probes.
# Sponsor / Ambassador / Probe Management
Operations / Internal
We're working on procedures and supporting functions to handle our logistics and partnerships. We expect to implement features and subsystems that map better to the use cases we have at hand.
# More Efficient Traceroute Measurements
Features
The current implementation has a number of compromises we had to accept when we first implemented this feature. We want to make traceroute measurements faster and more flexible.
# Next Generation Hardware Probe
Other
We are in the process of evaluating an alternative, more suitable hardware platform to provide stability and predictability to our hardware probe supply.
# Upcoming Activities
# New Measurement Types
Features
Our newer probes (v4 and up, including anchors and software probes) have fewer resource constraints. This means that we can try integrating the measurement code with existing libraries, such as the ones around DNS, DNSSEC, TLS, HTTPS, etc.
We intend to explore what kinds of measurements, based on this extended capacity, can be implemented that answer real-life measurement needs of the community.
# Simplified Quota Management
Other
There are controls in place to ensure fair resource use, such as a "maximum number of involved probes per measurement" and a "maximum daily spending limit" among others. While these limits can be relaxed upon request, this can be cumbersome.
We intend to simplify the resource usage management to as few controls as possible, while giving you more flexibility, without requiring manual adjustments.