Resumen

  • draft-xiao-fann-fast-cnp-with-proxy-05 separa la notificación en dos: el nodo congestionado envía UDP al proxy y el proxy fabrica un CNP estándar para el emisor RoCEv2.
  • El paquete final puede ser válido y útil sin mostrar la versión del mapa QP, la identidad del punto congestionado ni cuántas notificaciones eliminó el límite local.

El emisor recibe un CNP estándar y reduce la velocidad del Queue Pair señalado. Lo que no ve es la operación anterior: un router congestionado envió otro mensaje, el proxy consultó una asociación aprendida del tráfico y creó un paquete nuevo. Entre ambos momentos pudo descartar entradas por frecuencia.

La revisión 05 de Fast Congestion Notification Packet with Proxy, fechada el 29 de septiembre, aborda una incompatibilidad real. Un router P de una VPN puede estar en otro dominio de encaminamiento y no tener el Source QP que exige un CNP RoCEv2 convencional. El proxy aporta alcance y memoria.

La identidad del flujo se reconstruye

El formato 1 lleva al puerto propuesto TBD1 el quíntuple IP y el Destination QP de 24 bits copiados del tráfico que causó la congestión. La IP de origen identifica al emisor. Si protocolo y puerto indican RoCEv2, el proxy debe generar un CNP estándar.

Para ello necesita convertir Destination QP en Source QP. Mantiene un mapa entre ambos dentro del contexto de las direcciones de origen y destino. La revisión nueva deja claro que debe estar donde pasen tanto el tráfico RoCEv2 de ida como el de vuelta para aprender esa relación. El primer mensaje no trae una respuesta autosuficiente; depende de una memoria operacional.

El formato 2 usa TBD2, el mismo quíntuple y un NRP Selector ID. El selector sirve para localizar Source QP o identidad VPN mediante otros mapas. No certifica su propia interpretación. Dos proxies con tablas de distinta edad pueden recibir los mismos campos y tomar decisiones distintas.

Anunciar capacidad no demuestra que la tabla esté bien

El nodo congestionado descubre el proxy mediante Proxy Node Capability asociada a prefijos de los emisores. IS-IS y OSPF reciben bits P propuestos; BGP, un TLV dependiente del siguiente salto con la dirección del proxy.

Ese anuncio responde dónde enviar el primer mensaje. No acredita que el proxy haya observado los dos sentidos, que conserve el QP correcto, que la función esté activada, que no esté bajo presión o que el segundo CNP haya llegado. Conservar el bit al cruzar un área preserva una afirmación de control, no el estado del plano de datos.

La divergencia temporal es el riesgo práctico. El prefijo y el PNC pueden permanecer mientras cambia la ruta real. La asociación QP puede caducar mientras el proxy sigue anunciado. El NRP puede reasignarse sin que la capacidad cambie. Un indicador único de “proxy disponible” mezcla tres ciclos de vida diferentes.

El límite protector hace incompleta la secuencia

El borrador describe una traducción uno a uno en condiciones normales, pero permite descartar mensajes recibidos cuando su frecuencia supera el límite del proxy. La política es local. La sección de seguridad recomienda límites al generar y recibir, exige filtrado en la frontera del dominio y mantiene la función desactivada por defecto.

La defensa frente a denegación de servicio es sensata. También rompe cualquier inferencia de que el número de CNP recibidos equivale al número de eventos de congestión. El paquete final no incluye identificador del primer evento, contador de descartes, motivo, versión del mapa ni identidad del nodo que detectó la cola.

Por eso, el silencio no significa necesariamente “sin congestión”. También puede significar selección incorrecta del proxy, anuncio obsoleto, fallo de mapa, filtrado, función apagada, límite activo o pérdida del segundo tramo. Y recibir un CNP no basta para localizar el cuello de botella ni para contar todo lo que ocurrió.

Compatible no quiere decir trazable

El CNP traducido cumple una función legítima: permite reaccionar a un emisor que no entiende el nuevo formato interno. No hace falta degradar ese valor para reconocer su límite probatorio.

El error sería tratarlo como recibo completo. UDP aporta entrega de datagrama y suma de comprobación, no autenticación causal entre los dos mensajes. El formato estándar no prueba el momento en que llegó el primero, la tabla consultada, las entradas suprimidas ni la recuperación de la cola.

La operación necesita unir recibos. En el punto congestionado: contadores de cola y primeros mensajes. En encaminamiento: ruta PNC exacta. En el proxy: generación y edad de los mapas, aceptaciones, descartes y salidas. En el emisor: CNP recibidos y cambio de tasa. En el servicio: rendimiento, latencia y finalización. Sólo la correlación permite separar señal, traducción y efecto.

La revisión 05 es un Internet-Draft individual sin stream, AD responsable ni posición formal de IETF. Los puertos, bits y códigos siguen pendientes. La mención de una implementación que usa paquetes marcados con ECN queda fuera del alcance y no constituye formato definido, despliegue ni prueba de interoperabilidad.

El criterio ejecutivo es exigir que el proxy deje un rastro de la decisión que el CNP estándar ya no puede transportar. Sin ese rastro, la automatización puede reducir una tasa; no debería asignar culpa con la misma confianza.

Fuentes