Resumen

  • RACK necesita dos hechos para declarar perdido un segmento anterior: que se haya entregado otro enviado más tarde y que el primero siga sin ACK después de un RTT estimado más una ventana acotada de reordenamiento.
  • TLP permite una sola sonda antes del RTO para obtener nueva evidencia en la cola del flujo. No certifica la pérdida ni desplaza al control de congestión, que conserva la autoridad sobre la retransmisión.

Cuando faltan paquetes para contar hasta tres

La recuperación rápida clásica interpreta tres ACK duplicados como señal de que un segmento anterior probablemente se perdió. La heurística funciona si detrás del hueco viajan suficientes paquetes para hacer hablar al receptor. En una respuesta breve o al final de una ventana, la pérdida puede quedarse sin testigos posteriores. El emisor acaba esperando el temporizador de retransmisión, diseñado como respaldo prudente cuando no hay mejor información.

El reconocimiento selectivo amplió la visibilidad. RFC 2018 permite que el receptor describa bloques de bytes recibidos fuera del frente acumulativo. RFC 6675 emplea ese marcador para recuperar pérdidas, aunque su prueba principal sigue contando secuencias SACK discontinuas o bytes por encima del hueco. Un camino que reordena, un receptor que agrupa ACK o un paquete duplicado puede alterar la cuenta. Tres indicios en el espacio de secuencias no expresan cuánto tiempo ha pasado.

RACK, Recent ACKnowledgment, mueve la inferencia al tiempo de transmisión. RFC 8985 fue publicado en febrero de 2021 como estándar propuesto de la vía Standards Track del IETF. Lo firman Yuchung Cheng, Neal Cardwell, Nandita Dukkipati y Priyaranjan Jha. Los perfiles oficiales de Cardwell en el IETF y Google Research documentan su identidad y su trabajo en redes; el mecanismo sigue siendo un resultado colectivo y no demuestra control presente sobre todas las pilas que lo implementan.

Dos condiciones antes de decir «perdido»

El emisor conserva la hora de la transmisión más reciente de cada segmento pendiente, también cuando ese segmento ya fue retransmitido. Al recibir un ACK o SACK que acredita datos enviados después de otro segmento aún no reconocido, RACK obtiene un punto de referencia: el camino entregó algo que salió más tarde.

Ese primer hecho abre la prueba, pero no la cierra. Un segmento S se considera perdido solo si hay entrega posterior y si S lleva sin reconocimiento al menos el RTT estimado más la ventana de reordenamiento. El RFC modela temporizadores virtuales por segmento; una implementación puede mantener un único temporizador para la caducidad más próxima sin materializar uno por cada paquete.

La granularidad es parte del contrato. RFC 8985 exige registrar el último envío de cada segmento con una precisión superior a una cuarta parte del RTT mínimo. También estima cuatro u ocho octetos adicionales por segmento, según la representación temporal. Es una estimación de diseño contenida en el documento, no una factura universal para cualquier sistema.

El ACK aporta una afirmación limitada: cierto rango llegó al receptor TCP. No dice por qué falta S, dónde hay congestión, si intervino un middlebox, si la ruta cambió o si la aplicación procesó los bytes. RACK no reconstruye la causa. Produce una conclusión operacional basada en orden de salida y tiempo transcurrido.

El reordenamiento compra tiempo

Una red puede entregar tarde sin perder. Por eso RACK suma una ventana de reordenamiento a su umbral. Dependiendo del estado descrito por el RFC, la ventana comienza en cero o en una fracción pequeña del RTT mínimo. Si un Duplicate SACK demuestra que una retransmisión fue espuria, el emisor aprende que el camino tolera desorden más profundo y puede ampliar la ventana. La recomendación es adaptar con DSACK y no superar el RTT suavizado.

La elección siempre paga algo. Una ventana estrecha repara pronto la pérdida real, pero duplica datos cuando el original solo venía retrasado. Una ventana amplia ahorra transmisiones inútiles, pero prolonga una ausencia verdadera. RACK no elimina esa incertidumbre: la hace visible y limitada en unidades de tiempo.

Para auditar una decisión hacen falta las premisas: hora del último envío del segmento sospechoso, hora del segmento posterior entregado, ACK o SACK que lo probó, estimación RTT, ventana vigente y DSACK que la modificó. Un contador agregado con la etiqueta RACK no permite distinguir una señal mejor de un criterio simplemente más impaciente.

TLP envía una pregunta de una sola pieza

Tail Loss Probe atiende el extremo silencioso del flujo. Su temporizador suele situarse alrededor de dos RTT suavizados, con las correcciones que RFC 8985 impone por ACK retardado y por la proximidad del RTO. Solo puede utilizarse con una medición RTT reciente y nunca debe haber más de una sonda TLP pendiente.

Cuando vence, el emisor manda datos nuevos si los tiene y la ventana de congestión lo permite. De no ser así, retransmite el segmento pendiente con mayor número de secuencia. La intención es provocar un ACK que revele el estado de la cola. Se permite que una sonda exceda temporalmente en un paquete una ventana de congestión llena, pero su coste sigue contabilizado y el siguiente ACK debe absorberlo.

Que salga la sonda no prueba que el original se perdiera. La respuesta quizá aporte la entrega posterior que RACK necesita, o muestre que el original llegó y solo faltaba movimiento en el canal de ACK. Si también desaparece la sonda, el RTO continúa como último recurso. TLP crea una oportunidad de observación; RACK decide qué significa.

Detectar no equivale a tener permiso para enviar

El veredicto de RACK no abre por sí mismo la ventana de congestión. RFC 8985 ordena esperar a que el algoritmo de control de congestión permita retransmitir. RFC 5681 reúne las obligaciones tradicionales y RFC 6937 recomienda Proportional Rate Reduction para regular los envíos durante la recuperación.

La frontera impide que un sensor más veloz se convierta en una licencia de ráfaga. La detección afirma que la evidencia basta para tratar un segmento como perdido; el controlador decide cuánto tráfico de reparación puede soportar la red. Hasta la excepción de una sonda sobre una ventana llena es pequeña, explícita y contable.

El RTO calculado según RFC 6298 tampoco desaparece. Garantiza progreso cuando ACK, SACK, RACK y TLP no generan una conclusión. El sistema completo reparte funciones: SACK describe llegada, RACK ordena pruebas en el tiempo, TLP solicita una respuesta, el control de congestión gobierna el ritmo y RTO protege contra el silencio total.

Lo que un buen reloj tampoco sabe

Una marca temporal precisa no transforma feedback TCP en certificación del camino. La entrega posterior no autentica al extremo, no identifica el punto de congestión ni separa por sí sola pérdida radioeléctrica, cambio de ruta y reordenamiento benigno. Incluso un veredicto correcto se limita al problema de recuperación del transporte.

RFC 8985 hereda las consideraciones de seguridad de SACK y señala una resistencia específica al ACK splitting: reconocer un byte adicional no hace avanzar la transmisión entregada más reciente que usa RACK. Eso reduce el beneficio de esa táctica concreta; no convierte cualquier ACK en información fiable ni aporta autenticación general.

RFC 9002 adopta para QUIC umbrales temporales y reconoce la genealogía de RACK-TLP. QUIC, sin embargo, posee espacios de números de paquete y reglas de ACK propias. El parentesco conceptual no autoriza a copiar constantes, estados ni fronteras de control sin análisis.

Una motivación histórica, no una promesa actual

El trabajo de 2013 «Reducing Web Latency: the Virtue of Gentle Aggression», del que Cardwell es coautor, estudió una muestra de tráfico frontal de Google. En ese contexto, el 77 % de las pérdidas observadas se reparaba mediante RTO en lugar de recuperación rápida. La combinación experimental analizada redujo la latencia media un 23 % y el percentil 99 un 47 %.

Las cifras muestran por qué las colas cortas merecían atención. No describen el Internet actual, no documentan un despliegue vigente de Google y no son garantías de RFC 8985. Su alcance correcto es histórico y acotado: los flujos breves pueden agotar los paquetes que generarían evidencia antes de agotar el tiempo de espera.

Fuentes