Resumen

  • Un ACK acumulativo posterior puede confirmar muchos segmentos aunque la ruta inversa haya perdido las señales intermedias necesarias para crecer o recuperarse con rapidez.
  • Reducir tráfico de ACK puede aliviar el enlace ascendente y, al mismo tiempo, aumentar ráfagas, retrasar Fast Retransmit o degradar la equidad; cada resultado necesita su propio recibo.

La captura final parecía tranquilizadora: el número acumulativo cubría todos los bytes enviados. La conclusión inmediata fue que la ruta de retorno había cumplido.

Faltaba otra pregunta. ¿Qué ACK duplicados, bloques SACK y separaciones temporales no habían llegado? TCP puede conservar el progreso de secuencia y perder a la vez evidencia de recuperación. Un ACK posterior sustituye valores acumulativos anteriores, pero no recrea el momento ni el patrón en que el receptor los emitió.

RFC 3449, publicado en diciembre de 2002 como BCP 69, estudió esta tensión en rutas asimétricas. Sus escenarios son históricos; su método sigue siendo actual: no convertir una confirmación correcta en prueba de todo el bucle.

El ACK tiene más de una función

Un ACK indica hasta dónde avanzó el TCP receptor. También abre la ventana de envío, alimenta el crecimiento de congestión y, mediante repeticiones o SACK, ayuda a localizar pérdidas. No certifica que la aplicación haya persistido o usado los datos.

En una ruta equilibrada, la llegada de ACK proporciona un reloj aproximado al emisor. El cuello de botella directo espacia datos, el receptor responde y ese espaciado vuelve. Si la ruta inversa tiene poca capacidad, alto coste por paquete o cola compartida, el reloj puede dilatarse, perder pasos o comprimirse.

Por eso la unidad de prueba no es un contador de bytes. Es una secuencia con identidad de observador, dirección, tiempo y política de cola.

La cola corta conserva el total y descarta el orden

Una cola inversa poco profunda pierde ACK cuando la tasa de confirmaciones supera su servicio. Como son acumulativos, un mensaje superviviente puede cubrir varios segmentos anteriores. La transferencia puede terminar sin contradicción de bytes.

Pero el emisor recibió menos acontecimientos. Un algoritmo que aumenta la ventana por ACK puede crecer más despacio. Ante pérdida directa, pueden faltar tres ACK duplicados o información SACK suficiente para activar una reparación pronta. Esperar al temporizador produce un resultado muy distinto aunque el ACK final sea correcto.

El mismo mensaje superviviente puede abrir de golpe una ventana grande y provocar una ráfaga. La propiedad que protege el progreso acumulativo también concentra la acción.

La cola profunda cambia el reloj

Si el buffer es profundo, los ACK esperan en vez de caer. Salen más separados: ACK dilation. El emisor se regula por el cuello inverso y la gran capacidad descendente queda ociosa.

El RTT crece y varía, la ventana tarda más en evolucionar y la temporización de retransmisión se vuelve más difícil de interpretar. No basta con ver bajo uso directo y alta latencia. Hace falta una observación direccional de la cola para unir causa y síntoma.

El ejemplo de RFC 3449 usa 10 Mbps de bajada, 50 Kbps de subida, datos de 1.000 bytes y ACK de 40 bytes. El cociente normalizado k = 8 demuestra un mecanismo; no describe una oferta comercial viva.

La compresión fabrica una ráfaga

El tráfico ascendente grande puede bloquear ACK pequeños. Al liberarlos juntos, la red entrega al emisor un grupo más compacto que el emitido por el receptor. El emisor responde con datos concentrados y puede desbordar una cola directa.

ACK compression y ACK dilation son deformaciones opuestas. Ninguna cambia necesariamente el valor acumulativo, pero ambas cambian lo que el emisor hace y lo que el investigador puede inferir del tiempo de llegada.

La evidencia debe comparar emisión del receptor, entrada y salida del cuello, recepción del emisor, tamaño de ráfaga y pérdida posterior. Si solo existe el último punto, el origen del impulso queda sin atribuir.

Filtrar no equivale a recuperar

ACK Filtering elimina confirmaciones acumulativas redundantes antes del cuello inverso. Puede ahorrar paquetes, pero los stretch ACK supervivientes autorizan más datos. RFC 3449 lo clasificó como experimental y lo condicionó a mitigación de ráfagas.

ACK Decimation aplica selección mediante cola o descarte y puede preservar aún menos señales útiles. El documento favorece filtering cuando sea viable, sin convertirlo en recomendación universal. Alterar delayed ACK más allá del límite ordinario tampoco fue recomendado: el receptor no suele conocer la ruta inversa con precisión suficiente.

Un MSS mayor sin fragmentación de router puede reducir ACK por byte cuando lo permite el PMTU. Crear segmentos que luego se fragmentan no es equivalente y no fue recomendado. La etiqueta de cada técnica importa porque cambia la unidad de fallo.

Reconstruir crea evidencia sintética

ACK Reconstruction intenta insertar ACK después del cuello para suavizar el reloj. Esos mensajes no son nuevas observaciones del receptor; proceden del estado blando de un intermediario. RFC 3449 la calificó no recomendada y señaló riesgo de amplificación si entradas maliciosas provocan tráfico generado.

Una reconstrucción necesita identidad del agente, origen y caducidad del estado, límites de tasa y conducta ante reinicio. Sin esos recibos, una línea temporal limpia puede mezclar hechos del receptor con una estimación de red.

Pacing del emisor es distinto: distribuye la acción autorizada sin fingir nuevas observaciones. Se consideró experimental y exige estimación de tasa. Cambia la ráfaga, no repone ACK duplicados ni prueba la entrega de aplicación.

Prioridad puede ocultar otro perdedor

Servir ACK primero reduce su espera, pero puede dejar sin servicio los datos ascendentes. Por ello RFC 3449 no recomendó ACKs-first como política general. Fair queuing protege mejor flujos diferentes, aunque debe medirse bajo la mezcla real.

Muchos remedios transparentes necesitan leer o modificar cabeceras TCP. Cifrado e integridad pueden impedirlo. La protección no está fallando: está negando al intermediario una autoridad que el diseño quizá había supuesto.

El éxito de una descarga no debe excluir la aplicación que subía datos, la seguridad que protegía cabeceras ni el flujo que perdió su turno.

Doce recibos para una conclusión

Registrar rutas directa e inversa, capacidades, coste MAC por paquete, tráfico cruzado, disciplina de cola y profundidad de buffer. Conservar la política de ACK y los tiempos reales del receptor.

Después, atribuir pérdida, filtering, decimation, compression, reconstruction y scheduling. En el emisor, guardar separación de ACK, progreso acumulativo, duplicados/SACK, ventana, pacing y distribución de ráfagas.

Pérdida directa y recuperación son otro recibo. Goodput, carga ofrecida y equidad son otro. Finalización autenticada de la aplicación y resultado de usuario vienen al final. Rollback y ruta alternativa prueban si el mecanismo era causal.

Límite de evidencia

RFC 3449 no demuestra el comportamiento actual de ningún operador, red satelital, cable, radio, implementación TCP o controlador nombrado. k = 8 es un ejemplo. CUBIC y trabajos posteriores cambian la dinámica, no eliminan la dependencia de ACK y recuperación.

Los principios de Heng Lu sobre especificación inicial mínima y primacía del código en ejecución son lentes editoriales declaradas. Favorecen mitigaciones limitadas y verificables en lugar de una regla universal; no aportan mediciones de despliegue.

Fuentes