Resumen

  • El plan del tercer trimestre de 2026 sitúa en Q2 la finalización de los límites al «cultivo» de sondas y de las funciones para elegir sondas disímiles.
  • Los contratos públicos revisados no incluyen un selector de disimilitud ni explican una métrica, una versión o el conjunto de candidatos evaluado.
  • Los registros disponibles muestran la petición y las sondas programadas, pero no siempre la razón por la que se eligió una candidata y no otra.
  • Un recibo de selección acotado permitiría auditar el muestreo sin exponer a los anfitriones ni convertir diversidad técnica en representatividad social.

«Disímil» no es una propiedad evidente

Una lista de cincuenta sondas puede parecer amplia y seguir observando una sola dependencia. Dos equipos con direcciones de prefijos distintos pueden compartir acceso metropolitano, proveedor de nube o salida internacional. Dos sondas dentro del mismo ASN pueden estar en ciudades y rutas completamente distintas. El tipo de dispositivo tampoco resuelve la cuestión: hardware y software describen cómo se ejecuta el agente, no necesariamente qué dominio de fallo observa.

Por eso una función de disimilitud necesita un predicado. Puede repartir por país, ASN o prefijo; puede utilizar latencia hacia anclas, similitud de rutas, etiquetas o una combinación. Cada opción responde a una amenaza de sesgo diferente. También puede producir resultados distintos según la hora, porque la conectividad, la carga y la elegibilidad cambian.

El plan trimestral de RIPE Atlas es significativo porque habla de trabajo completado. Señala que los límites al «probe farming» y las funciones para seleccionar sondas «dissimilar» terminaron en Q2 de 2026. Mantiene aparte, como trabajo en curso, el soporte para agregadores de mediciones. No conviene mezclarlo: un agregador plantea quién encarga una medición a través de un intermediario; la disimilitud plantea cómo se compone la muestra.

La respuesta al problema original fue deliberadamente prudente

La conversación conservada en la lista de RIPE Atlas partió de una observación concreta. Un participante encontró numerosas sondas de software en el mismo prefijo y resultados repetidos al pedir una selección en un país. Temía que un investigador que no examinara la lista confundiera esas repeticiones con evidencia procedente de muchos puntos de vista.

No fue una sentencia sobre la intención del anfitrión. Tampoco prueba que las sondas cercanas carezcan de valor. Las repeticiones sirven para comparar implementaciones, detectar fallos locales y medir variación dentro de una red. El problema aparece cuando una selección predeterminada les asigna un peso que el usuario no conoce.

El archivo del grupo Measurements and Tools de mayo de 2024 recoge la contestación de RIPE NCC. Tras contactar a usuarios con muchas sondas, la organización dijo que la mayoría ofreció razones plausibles. La medida sencilla acordada fue limitar el número de sondas de software desde una misma dirección o prefijo. Reducir créditos y usar métricas de similitud quedaron como posibilidades posteriores.

Los planes históricos muestran que la discusión de cambios de comportamiento se cerró en Q2 de 2024 y que la implantación de límites siguió durante 2025. La secuencia es útil porque separa consulta, decisión y ejecución. Sin embargo, todavía no identifica qué versión de una lógica de selección actuó sobre una medición concreta.

También separa dos controles que suelen confundirse. La admisión decide cuántas sondas similares pueden estar disponibles o recibir incentivos. La selección decide cuáles de las admisibles participan en un experimento. Una regla por prefijo puede reducir concentración en el inventario sin describir el criterio usado en cada muestra.

El contrato visible conserva criterios, no la decisión completa

El manual actual de selección explica el arreglo probes: cantidad solicitada, tipo y valor. Los tipos documentados son región, países, prefijo, ASN, identificadores de sondas y una medición previa. Se pueden incluir o excluir etiquetas, combinar solicitudes y recibir avisos cuando una parte no es válida. Cada elemento aceptado se convierte en una solicitud de participación.

El contrato de solicitudes de participación añade acción, descripción, identificador y fecha de creación. Enumera asimismo área y país. Pero en los contratos revisados no aparece un tipo llamado dissimilar, ni campos para la versión de un método, sus señales, la fotografía del conjunto elegible o el motivo de escoger una sonda frente a otra.

La afirmación debe quedarse ahí. La ausencia en esas páginas no demuestra ausencia en la interfaz gráfica o en el backend. Puede tratarse de una comodidad de la web, de una regla aplicada al azar predeterminado o de un mecanismo aún no descrito. Tampoco demuestra un defecto. Lo verificable es más estrecho: la API pública que define la selección no ofrece un nombre estable para la capacidad declarada como completa.

El manual de mediciones definidas por usuarios añade una dificultad operacional. La opción predeterminada elige al azar cincuenta sondas en todo el mundo. Incluso una sonda pedida por ID puede no ser utilizada si está desconectada o demasiado ocupada. El resultado final puede variar por la regla de muestreo o por la disponibilidad posterior.

No son la misma causa. La exclusión por diversidad pertenece al diseño de la muestra. La falta de capacidad pertenece a la programación. Una sustitución después de una desconexión pertenece al historial. Una lista de participantes sin clasificación temporal puede borrar esas diferencias.

No hace falta publicar un mecanismo explotable

El contrato de lectura ya contiene buena parte de la materia prima. Muestra cantidades solicitadas y programadas; opcionalmente devuelve solicitudes de participación, registros, sondas actuales, fuentes y fichas de sondas. Un investigador puede guardar IDs, publicar su filtrado y reconstruir análisis.

El argumento contrario es fuerte. Quien formula una hipótesis específica debe diseñar una muestra adecuada, no delegar toda responsabilidad en un botón. Revelar detalles de controles contra abuso puede facilitar su evasión. Una semilla aleatoria pública podría hacer previsibles los puntos de observación. Y la interfaz web no tiene por qué expresarse siempre como un nuevo tipo de API.

Estas cautelas permiten diseñar un recibo limitado. Debería enlazar el ID de medición y el de solicitud; instante y cantidad; criterios visibles; referencia a una fotografía de elegibilidad; nombre y versión del modo; clases no sensibles de atributos considerados; sondas seleccionadas; cantidades y motivos generales de exclusión; sustituciones y correcciones. Una prueba criptográfica de compromiso puede conservar reproducibilidad sin publicar una semilla utilizable.

El recibo documentaría una decisión de la plataforma, no la verdad estadística. No afirmaría que la muestra representa a todos los usuarios de un país, a todas las redes de un ASN o a «Internet». Tampoco convertiría una distribución geográfica en independencia de rutas. Simplemente permitiría saber qué eligió el servicio y bajo qué versión.

La memoria del método importa cuando cambia la plataforma

La selección debe evolucionar. Nuevos tipos de sondas, mejor información topológica o riesgos de privacidad pueden justificar otra regla. El peligro aparece si el sistema conserva paquetes y gráficos, pero no la identidad del método. Dos consultas idénticas en fechas distintas pueden producir muestras distintas sin que un revisor sepa si cambió la red, la disponibilidad o el selector.

RIPE NCC controla admisión, incentivos, elegibilidad, selección y programación. El usuario controla pregunta, destino, tiempo e interpretación. El anfitrión aporta una perspectiva sin responder por la conclusión. El recibo hace visible esa división de autoridad.

La tarea pendiente es pequeña frente al trabajo técnico ya declarado: nombrar públicamente el modo, versionarlo y conservar una reconciliación entre petición, elección y ejecución. Entonces «disímil» dejará de ser una promesa general y pasará a ser una propiedad comprobable de una muestra determinada.

Fuentes

  1. Plan trimestral Q3 2026 de RIPE Atlas
  2. Planes trimestrales archivados
  3. Debate sobre posible concentración de sondas de software
  4. Archivo de mayo de 2024 del grupo MAT
  5. Manual de selección de sondas
  6. Contrato de solicitudes de participación
  7. Guía de mediciones definidas por usuarios
  8. Contrato de lectura de mediciones