Resumen

  • rLEDBAT permite que el receptor imponga una meta de baja prioridad (RLWND) sin sustituir el control de congestión del emisor.
  • El envío queda limitado por min(cwnd, RLWND, fcwnd); una ventana pequeña no prueba por sí sola que la aplicación receptora esté saturada.
  • La evidencia útil debe conservar candidatos, muestras temporales, factor Window Scale y la transición gradual necesaria para no retirar crédito ya anunciado.

El cliente remoto toma una decisión local

La ventana de recepción siempre ha protegido al host que recibe. RFC 9840 añade una decisión distinta: aunque haya búfer disponible, el receptor puede anunciar menos espacio para que una descarga de actualizaciones, copia o sincronización no aumente la cola frente al tráfico interactivo.

La capacidad real es fcwnd; la meta rLEDBAT es RLWND. El receptor anuncia su mínimo. El emisor todavía aplica su ventana de congestión cwnd, de modo que la autoridad final es SND.WND = min(cwnd, RLWND, fcwnd). Tres razones independientes producen una sola cifra operativa.

El mecanismo funciona precisamente porque el servidor no necesita comprender la intención. Respeta la ventana como cualquier TCP. Sin embargo, un registro del servidor ve menor demanda y una captura ve menor ventana, pero ninguno sabe si el cliente estaba lleno o estaba siendo cortés. Convertir el mínimo en causa es un error de observabilidad.

Tampoco desaparece el emisor. Cuando cwnd es menor, manda la congestión. Ante pérdidas, la retransmisión y el control estándar siguen siendo esenciales. rLEDBAT compone una autoridad adicional; no monopoliza el flujo.

El descenso tiene memoria

La ventana autoriza un rango de secuencias. Si el receptor ya adelantó el borde derecho, no debe encogerlo de golpe. Para llegar a una RLWND menor, reduce el valor anunciado conforme llegan bytes y mantiene el borde previamente prometido. El ajuste puede requerir aproximadamente un RTT.

Por eso, el primer paquete tras una decisión no contiene necesariamente la nueva política completa. Un panel que compare objetivo y anuncio sin bytes en vuelo ni cronología confundirá cumplimiento de TCP con respuesta lenta. La recepción probatoria debe incluir instante de decisión, objetivo, anuncios sucesivos y fin de convergencia.

El reloj aporta una señal, no una verdad

El receptor usa TCP Timestamps para seguir cambios del retardo directo. El desfase constante entre relojes se cancela, pero no la resolución, la deriva o los valores repetidos. ACK retardados, cola de retorno y retransmisiones también afectan la calidad. Una pérdida al final puede no dejar un segmento posterior que revele el hueco; el emisor sigue siendo la autoridad de recuperación.

RFC 9840 prevé filtrado y exclusiones. Esas decisiones deben quedar junto a RLWND: muestras brutas y aceptadas, razones de descarte, retardo base, RTT y resolución. Guardar solo la salida hace imposible revisar el controlador.

Una escala negociada demasiado pronto

Window Scale amplía el rango pero reduce la fineza de cada unidad. Con factores altos, un control suave se convierte en saltos grandes. El RFC advierte que más de 11 puede resultar demasiado grueso y aconseja menos de 12, sujeto a experimentación.

La escala se negocia al abrir la conexión. No es un parámetro que se corrija cómodamente cuando aparece la oscilación. Optimizar para ventanas enormes puede bloquear después el control delicado de fondo. Todo ensayo debe segmentar resultados por factor de escala.

Lo experimental es la interacción

RFC 9840 es Experimental, producto del IRTF/ICCRG. Quedan abiertas las interacciones con algoritmos del emisor, AQM, L4S y reinicios tras inactividad. Dos bucles con señales y tiempos distintos pueden oscilar; CoDel, PIE, ECN o L4S alteran el entorno; un retardo base antiguo puede distorsionar el reinicio.

La media de caudal no basta. Hay que registrar distribución de cola, pérdida, ECN, demanda de aplicación, las tres ventanas, periodos inactivos y control de congestión del emisor, comparando con TCP ordinario.

La documentación de Delivery Optimization y el material de Apple prueban que los sistemas operativos gestionan tráfico de fondo, no que una versión concreta implemente RFC 9840. El despliegue exige código, medición controlada o declaración del proveedor; una forma de caudal parecida no identifica el protocolo.

Seguridad y procedencia

Los tiempos de llegada y timestamps no autentican el estado de la cola. Un atacante en ruta capaz de retrasar o alterar observaciones, o de inyectar un segmento antiguo plausible, puede empujar la política. El impacto puede parecer “solo” una descarga lenta, pero aplazar parches o copias cambia el riesgo.

Conviene separar observación bruta, muestra filtrada, decisión y anuncio. Metas, filtros y política de escala deben versionarse como cambios de software. El tráfico diferible no admite evidencia descartable.

Fuentes