Resumen

  • RFC 3042 permite enviar datos que aún no se habían transmitido al llegar cada uno de los dos primeros ACK duplicados consecutivos, si lo permiten las ventanas.
  • El tráfico adicional puede generar suficientes ACK para alcanzar el umbral existente de tres duplicados, pero el emisor no debe aumentar cwnd.

En el caso de ventana pequeña que describe RFC 3042, la pérdida deja un segundo problema: quizá no haya suficientes ACK de vuelta para activar Fast Retransmit. Con una ventana de congestión (cwnd) de tres segmentos, si uno se pierde, como máximo regresan dos ACK duplicados. En esas condiciones, el emisor puede acabar esperando el temporizador de retransmisión.

Publicado en enero de 2001 por Mark Allman, Hari Balakrishnan y Sally Floyd, RFC 3042 añade Limited Transmit. Si el emisor tiene datos nuevos pendientes, DEBERÍA enviar un segmento nuevo al recibir cada uno de los dos primeros ACK duplicados consecutivos. Solo puede hacerlo si la ventana anunciada por el receptor deja espacio y si los datos pendientes de confirmación no superan cwnd + 2 segmentos. La regla más llamativa es negativa: el emisor NO DEBE aumentar cwnd por esos envíos.

Así se conserva una distinción importante. Limited Transmit arriesga una cantidad acotada de datos nuevos para mantener el ciclo de retroalimentación; no declara que haya desaparecido la congestión ni concede una ventana mayor. Tampoco retransmite de inmediato el segmento sospechoso. Si los segmentos nuevos y los ACK correspondientes llegan, puede aparecer otro ACK duplicado y alcanzarse el umbral tradicional de tres. La retransmisión pertenece entonces a Fast Retransmit, una regla anterior que RFC 3042 complementa, no reemplaza.

Los ACK duplicados no tienen una sola explicación. Pueden aparecer cuando llegan datos posteriores al hueco de secuencia, pero también por reordenamiento de paquetes. Retransmitir el segmento antiguo con el primer ACK respondería a una señal más débil. RFC 3042 prefiere enviar datos nuevos y mantener el reloj de ACK; sostiene que así se tolera mejor el reordenamiento. La ambigüedad no desaparece: el recuento de ACK es una inferencia del emisor, no una observación física del punto o la causa de la pérdida.

El mecanismo depende de varias condiciones: debe haber datos sin transmitir, la ventana del receptor debe permitirlos y FlightSize no puede superar cwnd + 2 segmentos. Si se usa SACK, RFC 3042 exige que el ACK duplicado lleve información SACK nueva antes de enviar datos en respuesta; RFC 2018 describe esa opción. Si falta una condición, o se pierden el segmento extra o su ACK, el procedimiento no garantiza evitar el timeout.

Más tarde, RFC 5681 integró los envíos de los dos primeros ACK en su secuencia consolidada de Fast Retransmit y Fast Recovery, manteniendo el tope de dos segmentos y cwnd sin cambios. Esa continuidad normativa ubica RFC 3042 en la historia de TCP; no prueba cómo se comporta hoy una implementación que no se ha medido.

La aportación histórica es acotada: corregir una escasez de retroalimentación en ciertas ventanas pequeñas sin rediseñar el control de congestión. El tercer ACK duplicado, la retransmisión autorizada y el ACK acumulativo posterior pertenecen a transiciones distintas. Ninguno, por sí solo, identifica la causa física de la pérdida ni demuestra que la aplicación haya recibido los datos esperados.

Fuentes