Resumen

  • RFC 9616 resuelve una ceguera de los overlays: dos túneles pueden contar igual aunque sus demoras sean radicalmente distintas.
  • La solución no usa el RTT bruto. Mide entre vecinos, suaviza con memoria, convierte mediante dos umbrales y limita cambios con histéresis.
  • El coste resultante describe una decisión de control configurada; no prueba por sí solo latencia de aplicación, capacidad, pérdida, encaminamiento efectivo ni experiencia del usuario.

La topología de ejemplo de RFC 9616 parece construida para revelar una trampa administrativa. Tres routers están en París y otro en Tokio. Desde A hasta D existen dos rutas con el mismo número de saltos: una pasa por B, también en París; otra pasa por C, en Tokio. Si el coste sólo cuenta saltos, ambas rutas tienen la misma dignidad y el tráfico puede escoger el rodeo remoto en aproximadamente la mitad de los casos.

No hace falta que falle un enlace. No hace falta que un router mienta. La abstracción simplemente perdió la distancia al encapsularla dentro del túnel.

RFC 9616 añade una observación de ida y vuelta a los intercambios ordinarios de Babel. La mejora es concreta: una red puede distinguir el camino local del remoto sin consultar una base geográfica ni sincronizar todos sus relojes. Pero la mejora cambia la pregunta. Antes faltaba una señal; después hay que decidir cómo convertirla en autoridad de encaminamiento.

Una medición que no necesita una hora común

RFC 8966 permite métricas bastante libres. Los Hello e IHU ya mantienen la vecindad. La extensión coloca un timestamp en el Hello, conserva en el vecino el tiempo de origen y el de recepción, y devuelve ambos datos en un IHU acompañado por otro Hello con marca temporal.

El emisor calcula RTT = (t2 - t1) - (t2' - t1'). Los términos de cada resta pertenecen al mismo reloj. Por eso A y B pueden empezar sus contadores en instantes arbitrarios. La técnica se atribuye a Mills, con antecedente en RFC 891 y relación conceptual con la disciplina temporal de RFC 5905.

La extensión ocupa poco estado y poco cable. El registro IANA Babel Parameters asigna el tipo 3 al sub-TLV Timestamp. Un Hello incorpora cuatro octetos y un IHU ocho. Una implementación antigua que no entiende el sub-TLV puede ignorarlo y seguir procesando el contenedor.

La sencillez del formato no elimina la procedencia. El momento exacto de tomar la marca importa. Debe ocurrir lo más tarde posible antes de entregar el paquete a la pila y lo más temprano posible después de recibirlo. De otro modo, parte de la espera local se presenta como demora del enlace. El documento sugiere incluso reservar espacio con PadN y sustituirlo al enviar: la posición de medición forma parte del dato.

El contador también envejece

Los timestamps son enteros de 32 bits en microsegundos y dan la vuelta aproximadamente cada 71 minutos. Un reinicio puede devolver el reloj a otro origen. La extensión recomienda descartar muestras cuando una marca parece futura o tiene más de tres minutos, sin perder por ello la actualización del estado del vecino.

Esto separa continuidad de observación y validez de muestra. Un enlace puede seguir activo mientras una muestra concreta deja de ser admisible. Un cuadro que sólo conserva el promedio borra esa diferencia. Para investigar un incidente hacen falta recuentos de aceptaciones, rechazos, edad y reinicios.

Además, el RTT pertenece a la relación entre dos vecinos Babel. No incluye de manera automática toda la cola del trayecto, la respuesta de un servidor, una retransmisión de transporte o una dependencia de aplicación. Aun una muestra perfecta puede ser un predictor incompleto del servicio que preocupa.

La demora bruta no puede mandar

El RTT fluctúa. Una ráfaga crea una punta. Dos caminos similares se cruzan alrededor de una media. Y la propia selección modifica el valor: el camino rápido recibe tráfico, se congestiona, se vuelve lento, pierde tráfico y vuelve a parecer rápido. El control puede perseguirse a sí mismo.

El estudio primario A delay-based routing metric analiza esa dinámica. Reporta ausencia de oscilación en pruebas reales y periodos del orden de minutos en configuraciones adversas construidas. Es una razón para adoptar salvaguardas, no una garantía para cualquier red.

RFC 9616 recomienda tres pasos. Primero, un promedio exponencial: RTT := α RTT + (1 - α) RTTn. Alpha debe estar entre 0,8 y 0,9; 0,836 es el valor recomendado. La memoria amortigua el ruido y también retrasa la verdad nueva.

Segundo, una función de coste limitada. Por debajo de rtt-min, el coste queda en C. Entre mínimo y máximo, crece de forma lineal. Por encima de rtt-max, la penalización deja de crecer. Los valores recomendados son 10 ms, 120 ms y 150.

Tercero, histéresis. Un cambio pequeño en la zona intermedia no basta para reemplazar la ruta. La red compra estabilidad a cambio de reacción.

Los umbrales escriben la política operativa

Con 10 ms como mínimo, un enlace de 1 ms y otro de 9 ms pertenecen a la misma clase. Esto evita que pequeñas variaciones locales muevan tráfico. También impide que la métrica distinga una diferencia que algunas aplicaciones sí valoran.

Con 120 ms como máximo, un enlace de 130 ms y otro de 500 ms reciben la misma penalización adicional. El techo evita que valores extremos dominen y desestabilicen. Cuando todos los caminos son malos, también puede ocultar cuál es menos malo.

Reducir rtt-max aumenta estabilidad y aplana una parte mayor del mundo. Aumentarlo conserva información y abre más espacio a fluctuaciones. La penalización máxima determina cuánto pesa la demora frente al coste nominal acumulado. Ningún número contiene por sí mismo ancho de banda, pérdida, precio o importancia de la aplicación.

Los valores predeterminados son hipótesis razonables para ciertos overlays de área extensa. No son una política universal. Adoptarlos requiere decir qué significa “local”, a partir de qué demora conviene evitar un enlace y cuánto retraso de convergencia puede tolerarse. El propietario de estas respuestas debe ser visible.

Una ruta tranquila puede estar atrasada

El RFC advierte que el algoritmo reacciona despacio. Tras un cambio de RTT, puede mantener durante segundos o minutos una ruta subóptima. En una infraestructura fija, esa lentitud protege de oscilaciones y reordenamiento. En una red con gran movilidad, conserva información antigua justo cuando la topología cambia con rapidez.

Por eso “pocas modificaciones de ruta” y “ruta correcta” son métricas diferentes. La primera observa estabilidad. La segunda exige conocer el estado físico y el objetivo del servicio.

Las pruebas deben incluir transiciones. Cambiar propagación sin variar capacidad; variar capacidad sin alterar propagación; añadir carga; reiniciar un vecino; esperar un wrap; mover un nodo. En cada caso hay que fechar muestra, promedio, coste, candidato, selección, RIB, FIB y primer paquete. Si la prueba comienza cuando todo se estabilizó, oculta el precio de la estabilización.

La red mixta sigue viva, pero habla varios dialectos

El diseño permite que routers sin la extensión ignoren los sub-TLV. Los nuevos y antiguos pueden convivir sin crear bucles ni patologías por esa mezcla, aunque el camino sea subóptimo. Es una propiedad importante: la publicación del estándar no obliga a una migración simultánea.

Sin embargo, continuidad no es uniformidad semántica. Una vecindad puede usar RTT, otra saltos y otra pérdida. La ruta completa suma decisiones que no observan el mismo fenómeno. Durante un despliegue gradual, la capacidad debe inventariarse por enlace, no sólo por versión del equipo.

La prueba debe cruzar fronteras: un nodo antiguo que se convierte en tránsito, un nodo nuevo que deja de anunciar timestamps, una ruta que alterna zonas de métrica. “Compatible” prueba que el protocolo opera. No prueba que todos los costes sean comparables ni que el servicio sea óptimo.

El límite tampoco debe confundirse con RFC 9647. El modelo YANG trata la visibilidad de configuración y estado. RFC 9616 trata la fabricación del coste desde una señal de demora. Exponer el estado no verifica el significado de la señal.

Privacidad y calidad comparten el mismo interruptor

La marca temporal parte de un origen arbitrario, por lo que no revela directamente hora civil, zona horaria o arranque. Aun así, un reloj local preciso puede ayudar a inferir ubicación física. Un nodo puede no enviar Timestamp; sus vecinos vuelven al recuento de saltos.

La elección protege una superficie y reduce otra. No es correcto obligar a exponer la señal como si el rechazo fuera una avería. Tampoco es correcto suponer que retirar la señal no cambia rutas. La decisión necesita una amenaza documentada, un comportamiento alternativo y una medición del efecto.

Aquí aparece una virtud del diseño delgado: el mecanismo es interoperable y la adopción permanece local. La disciplina posterior consiste en no transformar una opción local en una afirmación universal de calidad.

Del timestamp al usuario, sin saltarse recibos

El primer recibo fija procedencia: versión, ubicación del timestamp, reloj, wrap, reinicio, muestras aceptadas y descartadas. El segundo congela la transformación: alpha, umbrales, penalización, coste nominal e histéresis.

El tercero registra la decisión: costes candidatos, ruta elegida, causa y tiempo de asentamiento. El cuarto demuestra ejecución: RIB, FIB, siguiente salto, captura de paquetes y pérdida. El quinto pertenece al producto: percentiles de latencia, rendimiento, finalización y errores.

Si sólo existe el coste, la afirmación debe ser modesta: “el algoritmo configurado asignó menor coste”. Para decir “la ruta mejoró el servicio”, toda la cadena necesita cerrarse.

Fuentes