Resumen
- RFC 10053 permite que CATS seleccione un contacto del servicio visible para el cliente con datos de red y de cómputo. Ese contacto puede atender una o varias instancias internas; por tanto, la selección no identifica por sí sola cuál procesó finalmente la solicitud.
- Las métricas del contacto pueden combinar varias instancias de servicio, y un agente de métricas también puede agregar datos de varios contactos. La ruta elegida o un promedio tranquilizador describe la superficie de encaminamiento, no acredita la ejecución de una solicitud concreta ni la calidad de su resultado.
La entrada se ve; lo que ocurre detrás, no
Pensemos en una consulta a un catálogo de productos. El cliente dirige la búsqueda a un identificador de servicio; el sistema compara dos sitios, uno con una ruta más corta y otro con más capacidad de cómputo disponible. Selecciona un contacto alcanzable y dirige allí la solicitud. Para el cliente, ese contacto es la puerta de entrada. Puede procesar la solicitud o decidir qué instancia interna hará el trabajo.
RFC 10053 separa esas funciones deliberadamente. Una instancia de servicio es el conjunto de recursos en ejecución que aplica la lógica del proveedor. Un contacto del servicio es una función de cara al cliente que recibe solicitudes y puede atender una o varias instancias. También puede distribuir el trabajo hacia ellas, como un balanceador. La RFC dice que tanto los clientes como los componentes CATS tienen oculta la selección que ocurre más allá del contacto.
Por eso conviene precisar qué significa que «CATS eligió el servicio». El selector de rutas de CATS, o C-PS, usa información de agentes de métricas de servicio y de red para elegir un reenviador CATS de salida, quizá también un contacto, y una ruta. La decisión determina por dónde entra la solicitud en la estructura del proveedor; no identifica automáticamente la instancia que ejecutará el trabajo.
Cada métrica tiene un alcance
La RFC advierte expresamente que la selección puede no mostrar qué instancia invocará el cliente, por ejemplo, en contextos jerárquicos o recursivos. Por ello, las métricas del contacto pueden ser agregados de varias instancias de servicio. La sección 4.2 permite además que un agente de métricas agregue las de varios contactos, las mantenga separadas o haga ambas cosas. Son dos niveles distintos: uno puede resumir las condiciones de las instancias que atiende un contacto; otro, reunir condiciones de varios contactos antes de publicarlas al selector.
Esto no convierte en falsa una métrica agregada. Obliga a saber qué mide. Un promedio del contacto puede servir para elegir una entrada y, al mismo tiempo, decir poco sobre las solicitudes más lentas, sobre qué backend recibió una petición concreta o sobre el resultado que devolvió. Del mismo modo, un agregado del sitio puede facilitar la escala sin equivaler a la medición de cada contacto. La RFC deja las decisiones de despliegue al proveedor y no prescribe un algoritmo único de selección.
El clasificador CATS puede mantener los paquetes de una solicitud en el contacto seleccionado. La sección 4.4 describe la afinidad con el contacto: los paquetes de un flujo permanecen en el mismo contacto y la misma ruta para reducir el reordenamiento y las variaciones imprevisibles de latencia. Es una propiedad útil de reenvío, pero no abre una ventana hacia la distribución interna del contacto. El marco no define un registro que vincule cada decisión CATS con la instancia backend y el resultado de la solicitud.
Pensemos en un contacto que deriva consultas del catálogo a varios índices internos. Si uno de ellos se vuelve más lento tras un cambio de carga, el indicador agregado del contacto aún podría parecer aceptable. CATS podría seguir dirigiéndose a ese contacto sin observar el desequilibrio ni saber qué solicitudes lo sufrieron. Es una consecuencia posible del límite de visibilidad descrito por la RFC, no un incidente observado ni un resultado medido en un operador concreto.
La división es intencional. RFC 10053 afirma que el proveedor conserva el control de los recursos internos y de la lógica del servicio; la manera en que organiza el servicio queda fuera del alcance de CATS. El marco combina condiciones de red y cómputo para encaminar tráfico, pero no especifica cómo inspeccionar el planificador backend del proveedor. El operador de red no debería deducir más de lo que muestran las señales, y el proveedor no debería presentar un contacto seleccionado como prueba del resultado de una solicitud individual.
RFC 10054 amplía el planteamiento del problema y los requisitos de CATS, pero aquí la pregunta es más concreta: ¿qué se sabe después de que el tráfico llega al contacto elegido? La respuesta depende de las trazas y métricas que el proveedor decida exponer por separado. Las RFC no exigen una API universal de despacho backend, una traza por solicitud ni un recibo del resultado. Un despliegue puede añadir esos controles, pero su existencia debe comprobarse aparte.
La evidencia se detiene en el contacto, salvo que alguien la extienda
La diferencia importa cuando un cambio de encaminamiento parece reducir la latencia, pero el equipo de aplicación observa resultados dispares. La ruta y el contacto seleccionado explican adónde llegaron los paquetes. Sin evidencia adicional del proveedor, no explican qué instancia interna procesó cada solicitud, si dependía de un componente degradado o si su respuesta cumplió el objetivo del servicio.
Un informe riguroso puede afirmar: «CATS seleccionó este contacto con estas métricas y este alcance». Para afirmar «este backend atendió correctamente la solicitud» hace falta evidencia del servicio. Para afirmar «el servicio mejoró» se necesita una medida del resultado asociada con la solicitud o la cohorte pertinente. Son afirmaciones distintas, aunque luego se unan en un sistema de observabilidad.
RFC 10053 es un marco arquitectónico limitado a un único proveedor de servicio. Deja abierto tanto el algoritmo exacto de selección como el diseño interno del servicio. Sirve para entender el límite del encaminamiento, no para prometer que el contacto elegido muestre todas las decisiones posteriores.
Fuentes y alcance
- RFC 10053 en HTML, en particular las secciones 1, 2, 3.4.1–3.4.6, 4.2–4.4 y 5; texto completo; ficha del RFC Editor.
- Las versiones HTML y texto de RFC 10054 aportan contexto sobre el problema y los requisitos de CATS.
- El borrador de definición de métricas CATS, revisión 13 explica la terminología; sigue siendo un borrador, no una garantía de telemetría desplegada.
- La página del grupo de trabajo CATS documenta el área de trabajo del IETF; RFC 9522 aporta contexto general sobre ingeniería de tráfico.
- RFC 10053 describe un marco, no el despliegue de un proveedor concreto. Los ejemplos de agregación son escenarios analíticos, no afirmaciones sobre un operador identificado.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
