[atlas] Summary of the discussions about previous proposals

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-nccs-data-centre-footprint/
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