Resumen

  • Un calendario de costes ALTO entrega una secuencia de valores para intervalos futuros, de modo que una aplicación pueda elegir cuándo, además de dónde, enviar tráfico.
  • Los valores son orientación publicada por un proveedor, no órdenes de encaminamiento ni garantías de precio, latencia o capacidad.
  • Un despliegue seguro vincula el calendario con su tipo de coste y sus mapas dependientes, recibe cambios recientes y conserva una alternativa cuando la previsión deja de describir la red.

El intervalo más barato es una afirmación

Pensemos en un planificador que debe replicar un volumen grande antes del amanecer. El servidor ALTO muestra un coste menor entre dos zonas después de las 02:00. El planificador espera. No ha cambiado BGP, no ha reservado un circuito ni ha dado una instrucción a un router. La aplicación ha aceptado una afirmación: para este origen, este destino, este tipo de coste y este intervalo, más tarde parece preferible a ahora.

RFC 7285 define Application-Layer Traffic Optimization para aplicaciones que pueden elegir entre varios extremos. Un mapa de red agrupa direcciones en identificadores definidos por el proveedor, los PID. Un mapa de costes publica valores dirigidos entre esos grupos.

La vista es deliberadamente abstracta. El operador puede ofrecer una clasificación ordinal o números que no sean magnitudes reales, preservando su topología, sus políticas de ingeniería y sus condiciones comerciales. Por eso un 20 no significa necesariamente veinte milisegundos, veinte euros o veinte enlaces congestionados. Si la métrica no declara una unidad real, lo importante es la comparación entre opciones dentro de la misma vista.

Añadir tiempo no añade certeza

RFC 8896 incorpora el Cost Calendar. En lugar de un solo valor por pareja de origen y destino, el servidor devuelve una matriz de costes para intervalos consecutivos. Los metadatos fijan el comienzo, la duración de cada intervalo y cuántos existen. Así, una aplicación puede decidir no solo dónde conectarse, sino cuándo ejecutar un trabajo aplazable.

El calendario puede construirse a partir de patrones pasados, una ventana de mantenimiento o un ciclo que suele repetirse. Es conocimiento operativo útil, pero sigue siendo prospectivo. Un corte de fibra, una multitud inesperada, un fallo de caché o un cambio de ruta pueden convertir la franja anunciada como tranquila en una hora de máxima carga.

El contexto temporal no es un adorno. El cliente debe conocer el inicio, el huso horario, los límites de los intervalos, el tipo de coste y las versiones de los mapas que dan significado a los PID. Aplicar la matriz de mañana al mapa de hoy, o leer la tercera celda con una hora desplazada, crea una decisión que el servidor nunca recomendó.

La vigencia tiene su propio protocolo

El ALTO original permite volver a descargar un recurso. Eso resulta costoso si un mapa grande cambia solo en unas pocas celdas y puede llegar tarde para una decisión inmediata. RFC 8895 define un flujo de actualizaciones mediante Server-Sent Events. El servidor puede enviar un reemplazo completo o un cambio incremental con JSON Merge Patch o JSON Patch.

El flujo es una segunda superficie de control. El cliente tiene que asociar cada evento al recurso y a la versión base correctos, respetar el orden y reconocer una interrupción sin fingir que la última copia sigue vigente. Un parche pequeño aplicado al calendario equivocado puede ser peor que una respuesta ausente: deja una agenda creíble que ningún editor publicó.

Por ello RFC 8896 recomienda combinar el calendario con las actualizaciones incrementales. Ver una conexión SSE abierta no demuestra frescura. La prueba consiste en que un cambio del editor llegue al estado de decisión del planificador como el mismo cambio, con versión trazable y retraso acotado.

La orientación cambia aquello que pronostica

El calendario no solo describe la demanda; puede desplazarla. Si muchos clientes reciben el mismo intervalo barato, todos pueden postergar sus tareas hacia él. La ventana se llena porque se anunció vacía. RFC 8896 llama expresamente la atención sobre este efecto de retroalimentación.

La granularidad implica una elección. Un calendario grueso oculta mejor la información sensible y cambia menos, pero concentra más clientes. Uno fino distribuye mejor las decisiones y, a cambio, revela más sobre la operación y exige más actualizaciones. La red puede querer evitar un enlace caro; la aplicación puede querer cumplir un plazo. El protocolo permite coordinarse sin borrar esa diferencia de incentivos.

La misma información también sirve a un adversario. Un cliente comprometido podría escoger el momento que parezca más favorable para tráfico abusivo. La autenticación prueba quién publicó la guía, no que todo lector vaya a usarla bien.

Lo que demuestra el registro RFC

Las normas demuestran el modelo de datos: ubicaciones definidas por el proveedor, costes dirigidos, intervalos y un canal para reemplazos o parches. También prueban que el diseño contempla previsiones obsoletas, retroalimentación, orientación autenticada pero perjudicial, inestabilidad del cliente y abuso.

No demuestran que un operador concreto ejecute ALTO, que una cifra represente un precio real ni que un traslado particular vaya a mejorar. Una RFC define cómo expresar una recomendación. Solo la evidencia del servicio y del cliente puede probar que fue actual, adecuada y eficaz.

Fuentes