- ripe-atlas - mailman.ripe.net

RIPE Atlas infrastructure maintenance on 11 June 2024
by Robert Kisteleki 07 Jun '24

07 Jun '24

Dear RIPE Atlas users, On 11 June 2024, between 8:30-11:30 (CEST) we will carry out maintenance of the central RIPE Atlas infrastructure. The UI, APIs, access to stored results and metadata, as well as measurement scheduling will be unavailable. During this time results will still be still collected and stored. We apologise for the inconvenience this may cause. Regards, Robert Kisteleki, for the RIPE Atlas team

1 0

How to be more helpful...
by Mike 01 Jun '24

01 Jun '24

OK, here's my "problem." For starters I think the Atlas project is a great thing for the Internet, and I thank my local ISP, Comcast (USA), for encouraging me to sign up. But here's the thing for me. I have so many millions of points accumulated. When I see a message on this message list about someone asking for, say 20 million points, by the time I see that message, the requester has already received, typically, more than twice the number of points requested. (and I will say right now, private requests for points will be ignored) So my question becomes... I participate in this amazing project with a measurement device. But I also want to participate in the project by helping others, I guess I am asking, is there a way I can contribute points without having to check the list every hour or so?

2 1

Atlas UI updated
by Stephen Suess 28 May '24

28 May '24

Hi Atlas fans, We got a lot of useful feedback at RIPE88, and have just released some changes to production. Here are some of the highlights: - NEW: Pref for setting Mine tab as default for lists when logged in (instead of Public) - CHANGE: Improved sorting of minRTTs, no reply, n/a - CHANGE: Measurement form now using modal popups for probe selection to clarify interaction - CHANGE: When adding probes in the measurement form, it will now ask you if you want to keep the default probes or remove them - CHANGE: Rework map legend enable/disable logic when clicking on labels - CHANGE: RD bit set true by default for new DNS measurements If you want to see the full list of what has changed, you can check the release notes here: https://atlas.ripe.net/docs/releases/website/2024-05-28.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

TraceMON pages broken?
by Malte Tashiro 28 May '24

28 May '24

Hi, it seems like the TraceMON widget is currently broken. The tracemon-dist.js [0] file appears to be missing, which is required by the main traceroute-widget-main.js [1] file. Tried with Chromium and Firefox and both the old [2] and new [3] way. Would be happy about a fix :) Best, Malte [0] https://www-static.ripe.net/static/rnd-ui/atlas/static/measurements/widgets… [1] https://www-static.ripe.net/static/rnd-ui/atlas/static/measurements/widgets… [2] https://atlas.ripe.net/measurements/9333344/#tracemon [3] https://atlas.ripe.net/tracemon/9333344

2 1

Delays?
by Ernst J. Oud 14 May '24

14 May '24

I experience delays on creating measurements. Even after 2 minutes, a measurement is not running, eventually it will but it used to take a couple of seconds. My streaming api calls now time out… Is this known? Will it approve or do I need to change my scripts so that they wait longer? Regards, Ernst J. Oud

3 2

API advice to pull data from multiple measurements
by techtebatoye＠gmail.com 14 May '24

14 May '24

Hi, I would like to pull data from DNSMON probe measurements to build a real-time view. Considering the combination of IPv4/IPv6, UDP/TCP, multiple nameservers per TLD, it quickly adds up to 150+ measurements. I started with the streaming API, sending register messages for the measurements of interest, but quite quickly I am getting errors with "slow_down" response. I could not find the rate limit values in the documentation of the streaming API. Using the HTTP API would also mean hundreds of API calls, one per measurement. What is the recommended way to regularly pull data from many measurements, to avoid rate limiting or generating too much load on the API ? Regards

2 1

New Atlas UI launched
by Stephen Suess 13 May '24

13 May '24

Hello Atlas community, We are very happy to announce that after months of development and testing, we are today launching major changes to the Atlas UI: - NEW: Simplified navigation - NEW: About pages for Atlas moved to www.ripe.net/ripe-atlas - NEW: Dashboard - All Users: Quick Start, News Flash, QuickLook Measurement, Credits, My Measurements, Messages, API Keys, Quotas - Probe Hosts: My Probes - Anchor Hosts: My Anchors - RIPE NCC Members: Monthly Credits Claim - Ambassadors: Probe Management, Events - NEW: System status indicator on dashboard and table in Statistics - NEW: Measurement detail pages - Overview, Results, Details and Manage tabs - Ability to add or remove probes from a measurement - Participation requests - Improved map overview with summary insights - Standalone pages for TraceMON and LatencyMON - NEW: Preferences page - NEW: Feedback page You can find the full list of changes in the release notes: https://atlas.ripe.net/docs/releases/website/2024-05-13.html We hope you find these changes useful and we welcome your feedback. We will be demoing and discussing these in detail at the upcoming RIPE meeting as well. Kind regards, Stephen Atlas UI

1 0

Summary of the discussions about previous proposals
by Robert Kisteleki 13 May '24

13 May '24

Dear all, In response to community feedback, as well as to the observed behaviour of RIPE Atlas, earlier we put out some proposals about some aspects of future behaviour of RIPE Atlas. We’d like to summarise what we’ve heard so far (written responses as well as verbal discussions we participated in), and the path we plan to take based on these. Probe farming: There were many voices who agreed with some form of limiting this behaviour. We were also asked to reach out to users who are using many probes this way now. We did and the short summary is that most (but not all) answers give reasonable justification. Conclusion: we’ll add the relatively simple proposed rules (in short: limit the number of software probes from the same IP/prefix). Later on we can consider softer approaches, e.g. reducing the number of credits given to hosts with excess probes or using probe similarity metrics. Measurement aggregators: We proposed to embrace this existing phenomenon, ask these users to in the future give the system an indication about the distinct clients they serve, and perhaps step up as sponsors in such cases. We received many responses to this proposal. For the most part, current aggregators who responded stated that they have no significant issues with providing such client information – in an anonymised way of course. At the same time some of them stated that adding a “mandatory sponsorship” would discourage them from using RIPE Atlas in the future. Some argued that by having enough credits to do so, they were in fact contributing positively to the network already, and in fact some of them are or were sponsors. Conclusion: we’ll add the features needed to implement such aggregations, and work on incentives for these users to become RIPE Atlas sponsors. We’ll also add the need for proper attribution to the service, similar to what the commercial use policy describes. We may also look at additional requirements to ensure proper funding for our membership services. Data retention principles: This proposal was a high level one and we received limited feedback. One discussion raised how “financially sustainable” is defined; perhaps the best summary of this is the recent RIPE Labs article published by our CTO Felipe: https://labs.ripe.net/author/felipe_victolla_silveira/reducing-the-ripe-ncc… Conclusion: we are implementing our data storage and access features along the principles we laid out. For transparency, we’ll also include summaries of proposals we put out earlier (see: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/), for which we haven’t provided a written conclusion. Remove per-hop “late” packets from traceroute [LATE-PACKETS]: we only heard support for this, therefore it’s in our plans now. Measure well-known CDNs [CDN-HTTP]: Multiple responses argued that by selecting a “short list” of CDNs that are included by default, there’s an implicit statement and/or bias in the system towards bigger providers, contributing to some aspects of centralisation. Others pointed out that this approach reflects the reality of generic users, since the majority of the content they consume is provided by said CDNs. In addition, there were some voices supporting this proposal because of the value it provides to (smaller) CDNs or because it incentivises probe hosts to join or to keep their probes connected. Based on these discussions we’ll not go ahead with a full set of CDN measurements; however we’ll try a smaller scale experiment to discover the potential benefits to all users. Generic HTTP measurements [GENERIC-HTTP]: the discussions centered around some reiterations of the previous arguments (i.e. the safety of both the probe host and the providers’ sides) and if/how the proposed opt-in activity of the probe host would help this. Given these arguments, and that only a few voices expressed their explicit support for this, we’ll put this activity on hold; we can revisit this if/when the community wishes so. Add support for STARTTLS measurements [STARTTLS]: there were lengthy discussions about how certain SMTP servers may react to such incoming measurements. The general agreement was that this measurement type can be useful, with the confirmation that these checks will explicitly stop after STARTTLS (i.e. they will not have the ability to even try initiating sending mails or such). Remove support for non-public measurements [ONLY-PUBLIC]: the discussion raised both arguments for and against changing the system’s behaviour. Some people also raised the possibility of making private measurements more costly (in terms of credits). We’d also like to note the reference to the data retention principles (private measurement results are not available to all users, therefore we’ll only store them for a limited time). All in all, for the time being we do not plan to make behavioural changes about this feature. Regards, Robert Kisteleki RIPE NCC

1 0

ASN in probe application page vs. probe ASN status / dynamic ?
by vom513 10 May '24

10 May '24

Sorry for the title gore, hard to summarize this in one line. I was wondering why does the application page ask for ASN, if once the probe is running and connected the ASN is automatically determined ? I just had to flip my home internet to our backup provider and after a bit my home probe changed it’s ASNs as hoped/expected. If this is dynamic - why even ask on the application page ? Thanks. PS: Talking about a software probe here in case that makes a difference.

1 0

Meaning and the future of the project
by Petr Kutalek 08 May '24

08 May '24

Hello, I have been involved in this project for over 12 years. For the last few weeks I have been wondering what the point of this is. OK, I have given out credits to students for research, though sometimes they do not even say thank you. The firmware on the probes has not changed for years, the front-end except for cosmetic changes also does not go through shocking developments (still the same bugs), new features are not implemented, just discussed (e-mail notifications) etc. So I would actually just like to ask: - How many people are working full time on this project at RIPE? - What is the priority for RIPE? - What is the future? Any realistic plans? Thank you, Petr

4 3