<div dir="ltr"><div>Dear Ben,</div><div><br></div><div>In short: yes. There were a couple of responses to the approach/limits proposed. We reached out to the users who are over those limits and have gotten some replies with justifications. The implementation of said rules is in in the plans now.</div><div><br></div><div>Regards,</div><div>Robert</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 2, 2024 at 1:44 PM Ben Cartwright-Cox <<a href="mailto:ripencc@benjojo.co.uk">ripencc@benjojo.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Did anything come of this? I just ran a measurement to spot check<br>
something and the same AS47583 probes make up a "hilarious" amount of<br>
results: <a href="https://atlas.ripe.net/measurements/70655999#probes" rel="noreferrer" target="_blank">https://atlas.ripe.net/measurements/70655999#probes</a><br>
<br>
On Tue, 20 Feb 2024 at 23:16, Ben Cartwright-Cox <<a href="mailto:ripencc@benjojo.co.uk" target="_blank">ripencc@benjojo.co.uk</a>> wrote:<br>
><br>
> Those limits seem reasonable enough,<br>
><br>
> My own intuition would suggest values of:<br>
><br>
> X=2<br>
> Y=3<br>
> Z=5<br>
><br>
> But otherwise, I welcome such a change being implemented!<br>
><br>
> On Tue, 20 Feb 2024 at 15:43, Robert Kisteleki <<a href="mailto:robert@ripe.net" target="_blank">robert@ripe.net</a>> wrote:<br>
> ><br>
> ><br>
> > > Is there an immediate way to report these probes other than this<br>
> > > mailing list?  I don't know of one and so I'm here :)<br>
> ><br>
> ><br>
> > Dear Ben and others,<br>
> ><br>
> > Each new, connected RIPE Atlas probe provides incremental value to the<br>
> > system and its users, but this value decreases with similarity to<br>
> > existing probes ("diminishing returns"). At the same time connecting a<br>
> > probe and processing results from it has some costs, so we'd like to be<br>
> > conscious of the cost/benefit ratio.<br>
> ><br>
> > Since the potential pool of software probes is almost infinite, in<br>
> > response to the highlighted case, we'd like to propose the following<br>
> > mid-term approach:<br>
> ><br>
> > * No user/account should be allowed to run more than X SW probes from<br>
> > the same IP (X=3 ?)<br>
> ><br>
> > * No user/account should be allowed to run more than Y SW probes from<br>
> > the same IPv4/24 IPv6/48 (Y=5 ?)<br>
> ><br>
> > * Regardless of the user/account, no more than Z SW probes should be<br>
> > allowed from the same IPv4/24 IPv6/48 (Z=10 ?)<br>
> ><br>
> > X, Y and Z are defaults, can be changed per account. This is done in<br>
> > order to facilitate corner cases and overstepping the limits, if this is<br>
> > warranted (given a good explanation). We are also reaching out to the<br>
> > current "peak users" to understand their use cases and motivations - the<br>
> > above limits can be enforced depending on the responses.<br>
> ><br>
> > In the longer term we believe a more flexible approach is to base this<br>
> > on what has been termed "probe similarity metrics": a new probe that is<br>
> > really similar to some existing one has less value to the system,<br>
> > therefore after reaching a low enough limit it can be refused, or<br>
> > alternatively, simply not gaining credits for its owner. This<br>
> > diincentivises creating "probe farms".<br>
> ><br>
> > Regards,<br>
> ><br>
</blockquote></div>