Resumen

  • La revisión 11 del Internet-Draft de métricas CATS apareció tras una fusión del 4 de septiembre y añadió tiempos opcionales de observación y validez, además de criterios operativos. No es un RFC.
  • En agosto, los autores rechazaron deliberadamente incluir la identidad de la función en cada mensaje: prefirieron negociar las funciones fuera de banda al inicializar el sistema.
  • El nuevo texto ordena recoger ese acuerdo multifabricante en un manifiesto de configuración, sincronizarlo sin conexión y controlarlo por versiones; en producción, todos deben presumir puntajes comparables.
  • Ningún campo del puntaje identifica la versión, el resumen criptográfico o la época activa del manifiesto. Una firma válida y un dato fresco pueden seguir interpretándose con reglas distintas.
  • No hace falta renegociar algoritmos en tiempo real. Hace falta demostrar una identidad común antes de decidir, definir el repliegue ante diferencias y guardar el vínculo en un recibo.

El número siete necesita una genealogía

En el esquema de CATS, un selector de tráfico combina información de red y cómputo para escoger una instancia de servicio. El problema aparece antes de la selección: una latencia, una tasa de utilización y una cantidad de memoria no son comparables por sí solas. Las funciones de normalización convierten datos distintos en escalas comunes; las de agregación pueden producir métricas de categoría o un único puntaje global.

Un siete no significa nada estable si un fabricante cambió el rango de entrada, otro usa una curva distinta o sus pesos asignan más importancia a la red que al procesador. La revisión 11 reconoce esa dificultad y especifica una respuesta previa al despliegue. Todos los proveedores deben acordar rango, método y parámetros de normalización, fórmula y pesos de agregación y sentido de la comparación.

El acuerdo se compila en un manifiesto formal, se sincroniza fuera de línea durante la inicialización y se somete a control de versiones. Luego los componentes deben presumir que los puntajes recibidos aplicaron esas funciones y son plenamente comparables. No se exige negociación dinámica mientras CATS funciona.

Ese modelo llegó con una noticia verificable. La pull request 42 fue fusionada el 4 de septiembre; el commit resultante alimentó la nueva revisión. La página de Datatracker la muestra como documento activo del grupo CATS, todavía en “I-D Exists”. Es trabajo abierto, no un estándar terminado ni evidencia de uso en una red.

La omisión de la función fue una decisión

La secuencia pública de agosto permite evaluar el diseño con justicia. Un colaborador propuso que cada valor indicara la función que lo produjo, su hora de observación y su intervalo de validez. La pull request 41 daba forma al campo y a un registro donde la identidad incluiría parámetros fijos. Así, el selector podría separar tres casos: condiciones realmente distintas, cálculos distintos o un dato vencido.

El 25 de agosto, un coautor explicó la respuesta del equipo. La identidad de función no debía viajar en cada reporte. Los detalles entre fabricantes debían cerrarse fuera de banda al iniciar el sistema. Interpretar identificadores y modificar el algoritmo del selector durante la operación añadiría demasiada complejidad. La observación y la validez sí podían incluirse como campos opcionales.

El proponente aceptó el límite: el marco no prevé una renegociación por mensaje, y el acuerdo inicial puede ser más fuerte que repetir una etiqueta. Por eso la revisión 11 contiene Observation_Time y Validity_Interval, pero no Function. En la PR 41 se anotó que la PR 42 había incorporado los dos campos temporales; la propuesta original seguía abierta al cierre de la investigación.

No estamos ante una función olvidada. Estamos ante una frontera elegida. La pregunta correcta es si el manifiesto fuera de banda puede probar que sigue siendo común cuando llega el momento de usarlo.

El despliegue parcial cabe dentro del modelo

Supongamos un cambio de configuración. El productor A y el selector conservan M1. El productor B ya activó M2, que ajusta el límite superior de una normalización o el peso de una categoría. Ambos envían un 7 de nivel 2. Los mensajes proceden de claves autorizadas, tienen firma válida y llegan a tiempo. Para el selector, parecen equivalentes. En realidad, describen proposiciones diferentes.

Es un ejemplo hipotético; no prueba que exista una implementación fallida. Demuestra una propiedad del contrato. Source distingue medición directa, estimación, agregación o normalización. Observation_Time sitúa la captura y Validity_Interval acota su vigencia. La seguridad protege integridad, origen, autorización y frescura. Ninguna de esas respuestas dice qué manifiesto transformó la observación en 7.

Antes de la fusión, un revisor señaló exactamente el riesgo: en un sistema distribuido no se puede asumir que la sincronización siempre termina. Sugirió detectar y reportar actualizaciones fallidas o incompletas. El texto fusionado conserva el manifiesto y su control de versiones, pero no aquella frase. Es una observación individual, no una decisión del grupo; basta para mostrar que la falla era visible.

La revisión operativa de OPSDIR sobre la versión 10 había pedido comparabilidad multifabricante, posible identidad de políticas, calibración, manejo de fallos, expectativas de gestión y migración. La versión 11 responde mucho mejor que su antecesora. Incluye límites de anuncios rutinarios, actualizaciones por eventos, uso temporal del último valor bueno, degradación o exclusión de instancias, repliegue a datos de red y alarmas.

Pero un manifiesto desactualizado no siempre genera un valor absurdo. El componente puede estar sano, el número puede parecer normal y la firma puede ser correcta. La alarma de frescura se activa en otra dimensión. La anomalía semántica se oculta precisamente porque cada lado aplica coherentemente su propia copia.

Un recibo de interpretación

No conviene responder con el extremo opuesto. Obligar al selector a descargar curvas, pesos y límites con cada valor recrearía la complejidad que los autores quisieron evitar. Un control menor basta: identificador canónico y hash del manifiesto, dominio administrativo, ámbito de componentes, versión o época efectiva y estado de sincronización.

Productor y selector pueden atestiguar el hash activo. Esa identidad podría viajar en el mensaje, quedar ligada a una sesión autenticada o consultarse en el plano de gestión antes de admitir el puntaje. El formato concreto puede variar. Lo imprescindible es que la decisión posterior una cálculo e interpretación bajo la misma configuración.

Si los hashes difieren, la política local decide: rechazar, volver a métricas de nivel 1, usar solo información de red o esperar. El registro debe conservar el puntaje, los dos estados, el repliegue, la alarma y la condición de restauración. Los parámetros comerciales o técnicos no tienen que hacerse públicos; un resumen criptográfico identifica el manifiesto sin revelarlo.

El marco CATS limita estos acuerdos a un dominio administrativo y exige funciones comunes entre componentes. Esa centralidad facilita la prueba; no elimina los errores de distribución. El RFC 8911 muestra, en otro contexto, cómo una identidad de métrica puede quedar ligada a parámetros fijos. Es precedente conceptual, no mandato para CATS.

Fuentes

  1. Datatracker — definición de métricas CATS
  2. Revisión 11
  3. Revisión 10
  4. Historial en Datatracker
  5. Revisión temprana de OPSDIR
  6. Respuesta del coautor sobre el acuerdo fuera de banda
  7. Respuesta del colaborador
  8. Pull request 41
  9. Pull request 42
  10. Commit de fusión de la PR 42
  11. Marco CATS actual
  12. RFC 8911
  13. Heng Lu sobre reglas mínimas y decisión local