Summary

  • RIPE NCC's Q3 2026 plan says limitations on probe farming and features for selecting “dissimilar probes” were completed in Q2.
  • The checked public API documentation lists the ordinary selector types but does not name a dissimilarity mode, metric or version.
  • Existing readback fields can show requested and scheduled probes, yet they do not by themselves explain why one eligible vantage point was chosen over another.
  • A bounded selection receipt would make the service's diversity choice inspectable without exposing private hosts or claiming that any sample represents “the Internet”.

The word “dissimilar” carries more than one possible test

A network measurement starts before the first packet leaves a probe. It starts when somebody decides which probes count as a useful sample. That decision can be explicit—use these ten probe IDs—or delegated to RIPE Atlas: choose fifty worldwide, select within a country, draw from an ASN, or reuse the participants of an earlier measurement. The resulting ping or traceroute may be perfectly recorded while the selection that gave it evidential meaning remains only partly visible.

“Dissimilar” sounds intuitive until it has to be implemented. Two probes can differ in hardware and sit behind the same access network. They can have different public prefixes but share a last-mile provider, metro, upstream or cloud host. They can appear in different ASNs while depending on one physical facility. Conversely, two software probes in one large operator's address space may observe materially different paths from distant sites. No single label—country, ASN, prefix, hardware or software—settles independence.

This is why the completion statement matters. The Q3 2026 RIPE Atlas plan says that limitations on “probe farming” and features allowing selection of “dissimilar probes” were completed in Q2. It does not say merely that diversity is desirable. It describes finished product work. That statement creates a reasonable public question: what choice did the service make, and where can a user see it?

The right answer need not be source code or a secret abuse rule. It can be a stable public contract that identifies the method family, the attributes it considers at a safe level, and the record left behind when the selector runs.

The history began with a bias problem, not a purity test

The public discussion was more careful than the label “probe farming” can make it sound. In a preserved RIPE Atlas mailing-list thread, a participant reported many software probes in the same prefix and repeated results in a country-level selection. The concern was practical: a researcher who did not inspect the probe list might mistake repetitions from similar vantage points for broader evidence.

That report is not an adjudication. It does not establish motive, abuse or a defect in every result from those probes. Similar probes can be useful for controlled comparison, failure detection and measurement of local variation. A service that simply deletes similarity would lose information along with duplication.

The 13 May 2024 Measurements and Tools Working Group record preserves the institutional response. RIPE NCC said it had contacted users operating many probes and found reasonable explanations in most, though not all, replies. The chosen simple rule was to limit the number of software probes from the same IP address or prefix. Softer approaches—reduced credits for excess probes or similarity metrics—were left as possible later steps.

That distinction should survive in the current product record. Admission limits decide which probes can enter or earn incentives. Selection logic decides which eligible probes perform a particular measurement. A rule for the first problem can improve the pool without explaining the second. Calling both “diversity” hides two separate decisions, two affected parties and two kinds of evidence.

The archived quarterly plans make the sequence visible: community discussion was completed in Q2 2024, while implementation of probe-farming limits continued into 2025. The current plan then records completion in Q2 2026 and adds dissimilar-probe selection to the finished work. This is a credible development history. It is not yet a reproducibility history.

The public API records criteria, not the diversity judgment

The present probe-selection manual is concrete. A probes array states how many probes are requested, the selection type and its value. The documented types are region, countries, prefix, ASN, explicit probes and a previous measurement. Tags can include or exclude candidates. Combined requests are validated independently, and each accepted item becomes a participation request.

The participation-request contract adds useful administrative facts: action, description, an identifier and creation time. It lists area and country alongside the other selector types. But neither checked contract names dissimilar as a selector or documents a field for a diversity model, model version, threshold, candidate-set identity or classified exclusion.

That absence must be described narrowly. It does not establish that the web interface lacks the feature. It does not establish that an undocumented parameter is unavailable to selected users, or that the backend is not applying a diversity rule to ordinary random selections. It establishes only what a reader of the checked public contract can verify: the request vocabulary does not explain a dissimilarity decision.

The user-defined measurement guide sharpens the problem. It says the default is fifty probes selected randomly worldwide and describes random selection by area, country, prefix or ASN. It also warns that a specifically requested probe is not guaranteed to run, because it may be disconnected or too busy. A sample can therefore differ from the request for at least two reasons: selection among eligible candidates and later scheduling availability.

Those reasons should not be collapsed. If a probe was excluded to increase diversity, that is part of the sampling method. If it was selected but could not be scheduled, that is an execution state. If it later disconnected and was replaced, that is a subsequent event. The final list alone cannot always tell which path occurred.

RIPE Atlas already holds many pieces of a better record

This is not a demand for a new scientific bureaucracy. The current measurement-read contract already exposes requested and scheduled counts and can return participation requests, participant logs, current probes, probe sources and probe records as optional fields. Probe IDs and public metadata allow researchers to inspect a sample after the fact. Authors can publish their own lists and methods.

Those are substantial counterweights to the criticism. An expert who chooses probes manually can often create a more suitable design than a generic diversity feature. Publishing every internal scheduling detail could expose host information or teach actors how to game admission controls. Stable randomness may be undesirable if it lets a hostile target predict every future vantage point. And an API need not expose every convenience offered by a graphical interface.

But these points do not remove the narrower concordance problem. If RIPE Atlas itself selects a sample under a completed “dissimilar” feature, the public result should allow a reader to distinguish that choice from ordinary random selection, manual curation and availability-driven substitution. Otherwise the label is informative at announcement time but unavailable when the measurement becomes evidence.

The missing object is a bounded selection receipt. It need not reveal the identity of a private host or the full candidate pool. It should bind the measurement and participation-request IDs; selection time; requested count; user-visible criteria; an eligibility-snapshot identifier; diversity mode and method version; safe attribute classes used; selected probe IDs; numbers and broad reasons for exclusions; substitutions; later participant changes; and corrections. Where randomness matters, the service can publish a commitment or reproducibility token rather than an exploitable seed.

Most importantly, the receipt should state what it does not prove. It proves how RIPE Atlas made a choice under a named method. It does not certify that the resulting probes represent every user, network, country or political constituency. It does not convert topological variety into statistical representativeness. It does not turn a platform decision into a scientific conclusion.

A selection record protects both the service and the researcher

Without a versioned record, a later reader may attribute a difference to the Internet when it came from a changed selector. The reverse error is also possible: a researcher may blame a product change for variation caused by probes becoming unavailable. If the public method evolves—and it should be allowed to evolve—historical measurements need to retain the version that selected them.

The burden is not symmetrical. RIPE NCC owns the shared selection implementation and knows when it changes. A researcher owns the hypothesis, interpretation and any extra filtering. The probe host owns neither conclusion merely by providing a vantage point. A receipt allocates these responsibilities instead of pushing all uncertainty onto the final paper or dashboard.

This is also why the article should not be turned into an accusation about the reported ASN or about software probes generally. The system benefits from wider deployment, including places where hardware is difficult to deliver. Diversity controls should preserve useful clusters when users ask for them while preventing an unexamined default from presenting concentration as breadth.

RIPE Atlas has done the difficult part: it recognised the problem, consulted its community, adopted a bounded admission response and says it completed a selection feature. The remaining work is documentary. Name the public selector or explain the surface on which it operates. Version the method. Leave a compact receipt. Then “dissimilar” becomes more than a reassuring adjective; it becomes a testable property of one recorded selection.

Sources

  1. RIPE Atlas quarterly planning, Q3 2026
  2. Archived RIPE Atlas quarterly plans
  3. RIPE Atlas mailing-list thread on possible software-probe farming
  4. May 2024 Measurements and Tools Working Group archive
  5. RIPE Atlas probe-selection API manual
  6. RIPE Atlas participation-request API contract
  7. RIPE Atlas user-defined measurement guide
  8. RIPE Atlas measurement-read API contract