Resumen

  • draft-ietf-tiptop-quic-profile-00 plantea control de congestión abierto y basado en tasas, alimentado por horarios de misión, porque la pérdida, el retraso y los ACK pueden describir demasiado tarde un enlace intermitente.
  • La trazabilidad debe acompañar al calendario hasta la pila: emisor, autoridad aprobadora, trayecto, intervalo, supuestos de capacidad y memoria, cálculos, prioridades, sustitución, modo de reserva y resultados observados.

La orden llega antes que la evidencia del camino

Un orbitador ofrece a un vehículo marciano un paso de diez minutos. La siguiente oportunidad llegará casi dos horas después. Si un emisor aguarda a que los ACK describan el cuello de botella, habrá consumido parte del único intervalo útil. Si interpreta la espera del paquete dentro del orbitador como una cola congestionada, reducirá su ritmo por una causa que no existe cuando el enlace vuelva a abrirse.

La alternativa es operar con conocimiento previo. El centro de misión conoce la geometría, reserva antenas, combina enlaces de distinta capacidad y decide cuánto almacenamiento puede ocupar cada flujo. Un calendario activa la transmisión y también puede suspenderla. El transporte ya no extrae todas sus decisiones del tráfico: recibe una política preparada fuera de la conexión.

El borrador QUIC Profile for Deep Space formaliza este escenario. El 10 de septiembre de 2026 apareció como draft-ietf-tiptop-quic-profile-00, documento del grupo TIPTOP que sustituye a un trabajo individual. El llamado de adopción había finalizado el 2 de septiembre. Sigue siendo un Internet-Draft informativo, no un RFC; no pide registros a la IANA y puede modificarse o caducar. La adopción demuestra que el grupo quiere trabajar en el texto, no que cada recomendación ya tenga consenso general o uso operativo.

El bucle cerrado se queda sin tiempo

QUIC terrestre estima el RTT durante la vida de la conexión. RFC 9002 relaciona esa estimación con la detección de pérdidas y el temporizador de sondeo. El mismo transporte observa ACK, pérdidas y, cuando existe, ECN para regular el envío. Es una forma valiosa de coordinación distribuida: la ruta comunica sus límites mediante consecuencias visibles.

El espacio profundo deforma el reloj de ese mecanismo. La propagación a Marte suma minutos; una ocultación puede sumar horas; un relé guarda paquetes hasta que aparezca el siguiente enlace. La señal que regresa habla de un estado pasado y no distingue por sí sola una cola saturada de una espera deliberada. En las pruebas citadas por el borrador, un controlador convencional mantiene la entrega fiable, pero tarda más y puede perder órbitas completas.

Por eso el perfil recomienda que una implementación pueda usar control abierto basado en una tasa. El plano de gestión aportaría ritmo, ventana, RTT esperado y otros datos. Un orquestador podría variar la frecuencia de ACK o comunicar la MTU conocida del trayecto. La coordinación espacial —antenas, espectro, cómputo, almacenamiento— reemplaza parte de la inferencia reactiva.

No desaparece el control de congestión. Cambia de sede. La decisión que antes tomaba un algoritmo terminal ante una señal del camino pasa a depender de la organización que compone el horario y proyecta sus variables sobre QUIC.

El RTT inicial no es una medición

La diferencia se ve antes del primer intercambio. Mientras no llegue un ACK, la conexión carece de una muestra de RTT. Necesita una estimación inicial para sus temporizadores. Los 333 milisegundos habituales son incompatibles con una ruta cuyo recorrido esperado se mide en minutos u horas.

El caso Tierra–Marte intermitente del borrador agrega a la propagación el tiempo hasta el siguiente contacto. Un valor demasiado bajo provoca retransmisiones inútiles y puede cerrar la conexión antes de la primera respuesta. Uno excesivamente alto conserva la conexión, pero una pérdida del paquete Initial puede tardar muchas horas en recuperarse. La recomendación es aproximarse al máximo previsto sin multiplicarlo de manera arbitraria.

Ese máximo es una afirmación humana e institucional codificada en un número. Depende de qué órbita, relé, margen y escenario de fallo se hayan elegido. Es correcto usarlo para arrancar, pero no llamarlo «RTT del enlace» sin calificación. El RTT medido después pertenece a otro registro.

El timeout de inactividad añade una negociación. La duración efectiva es el mínimo de los valores de ambos extremos. Un operador puede planear una interrupción larga y descubrir que el par cerró antes. Conservar solo la configuración local oculta la decisión que realmente rigió la conexión.

Un calendario válido puede dar una orden inválida

La firma criptográfica de un plan responde quién lo emitió. No responde si tenía autoridad para comprometer una antena o la memoria de un relé compartido. La sintaxis tampoco resuelve cuatro límites.

El primero es el objeto. Un horario pertenece a una misión, un par, una dirección y un trayecto. No debería gobernar automáticamente otra sesión porque comparta el mismo host.

El segundo es la vigencia. Una efeméride, una disponibilidad de estación o una reserva comercial puede cambiar. Creación, aprobación, inicio, expiración y sustitución son momentos distintos.

El tercero es la derivación. Dos equipos pueden partir del mismo paso y escoger márgenes distintos para RTT, ventana o pacing. Sin la fórmula, el número final no explica el riesgo aceptado.

El cuarto es la colisión. Dos planes auténticos pueden reclamar el mismo recurso. La pila de transporte no está legitimada para decidir qué misión tiene prioridad basándose en el archivo más reciente.

Recibo de proyección entre plan y transporte

Cada cambio que pase del calendario a la conexión debería emitir un recibo versionado. No se trata de publicar detalles sensibles, sino de conservar una prueba accesible a quienes deben responder por el resultado.

El recibo identificaría a la organización emisora y al rol aprobador; misión, extremos, dirección y ruta; versión del horario y conjunto de datos de origen; intervalo efectivo y caducidad; observaciones orbitales o compromisos de capacidad; RTT mínimo y máximo; pacing, ventana, política de ACK, timeout y MTU; ecuaciones, márgenes y supuestos; capacidad y reserva de memoria del relé; prioridad y regla de conflicto; componente que convirtió la planificación en parámetros; y conducta de reserva ante ausencia, rechazo o vencimiento.

Una sustitución debe nombrar al plan anterior. También debe indicar si actualiza conexiones abiertas o solo conexiones nuevas. Ambos extremos registrarán el valor recibido, aceptado y activo. Un sistema de misión que muestra «enviado» no puede dar por aplicada una configuración en una nave que quizá no la recibió.

Las mediciones posteriores se anexan sin fusionarse con lo previsto: inicio real del contacto, RTT observado, bytes, pérdidas, ocupación máxima, oportunidades perdidas. Sirven para ajustar el próximo modelo. Si reescriben el plan original, la historia convierte la predicción en una certeza ficticia.

La coordinación no cabe en un solo protocolo

TIPTOP prevé coordinarse con los grupos de QUIC, TLS, TVR, DNSOP y DTN, con CCSDS, agencias y empresas. El perfil ya conecta atributos programados, frecuencia de ACK, reanudación cuidadosa, actualización de claves, MTU y almacenamiento intermedio. Cada frontera puede borrar un fragmento de procedencia.

Una API útil no debería exponer solo «establecer RTT». Debería permitir asociar el valor con el plan, el ámbito y el vencimiento. La telemetría debe distinguir entre dato ofrecido, dato aceptado y conducta efectiva. Si dos entradas compiten, la operación necesita un conflicto explícito, no la casualidad del último proceso que escribió memoria.

Esto tampoco exige un planificador planetario único. La pluralidad institucional es compatible con la interoperabilidad si cada autoridad conserva su frontera y si la transferencia entre ellas deja constancia. El IETF describe mecanismos; no asigna por ese hecho una ventana de una agencia a otra.

Qué no prueban las fuentes

No hay en el material revisado un incidente de vuelo atribuido a un horario QUIC falso o vencido. Las simulaciones son reproducibles y útiles, pero no representan todas las implementaciones ni condiciones espaciales. El borrador es versión 00. Una solución adecuada para Marte intermitente puede ser excesiva en un trayecto lunar corto y continuo.

Tampoco se sigue que el feedback deba abandonarse. Cuando las muestras llegan, corrigen la previsión; la propia propuesta separa escenarios. La tesis es limitada: si una entrada externa determina en tiempo real cuánto y cuándo envía el transporte, su cadena de autoridad es parte del funcionamiento de la red.

El espacio profundo lleva al extremo una regla general. La automatización no elimina el juicio; lo desplaza al dato que la máquina considera confiable. En este diseño, el control de congestión empieza en la reunión que aprueba el próximo contacto.

Fuentes

  1. Datatracker — perfil QUIC para el espacio profundo
  2. Historial de revisiones
  3. Revisión 00 archivada
  4. Repositorio fuente
  5. Carta del grupo TIPTOP
  6. Anuncio del borrador de grupo
  7. Llamado de adopción
  8. Resultado del llamado
  9. Acta TIPTOP de IETF 126
  10. Características y casos de uso
  11. Arquitectura IP para espacio profundo
  12. RFC 9000 — QUIC
  13. RFC 9002 — pérdidas y congestión en QUIC
  14. RFC 9308 — aplicabilidad de QUIC
  15. RFC 9959 — Careful Resume
  16. Borrador sobre frecuencia de ACK
  17. Modelo YANG de atributos programados
  18. Borrador de control BBR
  19. Registro QUIC de IANA
  20. Banco de simulación QUIC espacial