Resumen

  • La versión del 2 de octubre del borrador SIMAP del grupo NMOP incorpora REQ-CONGESTION: el tráfico de un enlace de protocolo SIMAP no debe causar congestión persistente. La revisión 13 no incluía ese requisito.
  • Los enlaces sobre transportes con control de congestión, como TCP, cumplen la condición de transporte. Si no existe ese control, como en el ejemplo de UDP, el borrador limita el despliegue a entornos controlados con capacidad preasignada o reservada y exige acotar el volumen generado por el servidor. El texto sigue siendo un Internet-Draft, no un RFC aprobado.

La actualización continua de un mapa tiene una paradoja operativa. Cuantas más preguntas contesta y más cambios transmite, más recursos pide a la infraestructura que observa. No basta, por tanto, con comprobar que el dibujo es correcto. También importa el coste de obtenerlo. La revisión 14 de Service & Infrastructure Maps, SIMAP, introduce una condición explícita para ese coste.

La nueva cláusula de la sección 4.3 pide que los enlaces de protocolo impidan que el tráfico SIMAP produzca congestión persistente. Al cotejar draft-ietf-nmop-simap-concept-14 con la versión 13, el cambio aparece como una adición concreta. El texto considera suficiente el control de congestión del transporte en enlaces basados, por ejemplo, en TCP. Para enlaces que no cuentan con ese mecanismo, pone el ejemplo de UDP y exige dos cautelas: un entorno controlado con capacidad reservada o aprovisionada de antemano y un límite al tráfico que puede generar el servidor.

La palabra «ejemplo» importa. El documento no prohíbe UDP en toda circunstancia ni elige una implementación concreta de SIMAP. Tampoco proporciona un umbral numérico que pueda copiarse a un acuerdo de capacidad, ni afirma que exista un despliegue UDP cuyo tráfico haya causado un incidente. Lo que hace es asignar una obligación al diseño y al entorno de una futura vinculación protocolaria. Una elección de transporte no sustituye el examen de la carga real, aunque su control de congestión satisfaga esta condición particular.

REQ-PERFORMANCE ya estaba en el borrador anterior. Para topologías grandes propone acceso incremental, filtrado o paginado y, cuando convenga, flujos o suscripciones. Son recursos para acceder mejor a los datos, no una demostración automática de que el servicio no congestiona la red. Una sucesión de páginas solicitadas a demasiada velocidad sigue consumiendo capacidad. Una suscripción eficiente para un cliente puede dejar de serlo cuando se multiplica el número de clientes. El nuevo requisito obliga a no mezclar esas dos pruebas.

El RFC 8085, al que remite la nueva redacción, explica el antecedente: UDP no incorpora control de congestión, por lo que las aplicaciones deben asumir esa responsabilidad. No es una publicación nueva ni un registro de fallos de SIMAP. La revisión 14 toma esa guía como contexto para definir las condiciones de un enlace sin control a nivel de transporte. El estado del Datatracker sigue siendo el de un borrador activo del grupo de trabajo, destinado a un RFC informativo y pendiente de seguimiento del Area Director.

Al evaluar una propuesta, convendría separar la frescura del mapa, la completitud de la topología y la carga de sus consultas y actualizaciones. Si la vinculación carece de control de congestión, haría falta documentar además qué entorno está realmente bajo control, qué capacidad se ha reservado y cómo se limita el volumen del servidor. Esta es una inferencia editorial para la aceptación operativa, no un procedimiento de certificación emitido por la IETF. No convierte la novedad en una orden inmediata de migración.

Un mapa puede ser preciso y, sin embargo, una mala carga para la red. La revisión pone nombre a una decisión que a menudo queda escondida detrás de la utilidad de la herramienta: cuánto tráfico está autorizado a gastar el observador.

Fuentes