Resumen

  • RFC 6298 reinicia el temporizador cuando un ACK confirma datos nuevos, no cada vez que llega un ACK.
  • El temporizador se inicia al enviar datos, se detiene cuando todo lo pendiente está confirmado y, al vencer, retransmite el segmento no confirmado más antiguo.

La frontera confirmada decide el plazo

El temporizador protege los datos que siguen sin confirmarse. Si se envía un paquete con datos y el temporizador está inactivo, se inicia con el RTO vigente. Los envíos posteriores no desplazan por sí solos esa fecha límite.

La regla 5.3 exige algo más: el ACK debe reconocer datos nuevos. En ese momento avanza la frontera que el emisor conoce como recibida; por eso el temporizador se reinicia durante otro intervalo RTO para el estado restante.

Un ACK que repite la frontera anterior no cumple esa condición. De ahí se desprende que una serie de ACK duplicados no puede extender sin límite el plazo de los datos aún pendientes. Es una conclusión sobre esta regla del temporizador, no una afirmación de que los ACK duplicados carezcan de utilidad en TCP.

Cuando ya no queda ningún dato pendiente, el temporizador se apaga. Si vence, se retransmite el segmento más antiguo que aún no ha sido confirmado.

Obligación y recomendación

RFC 6298 establece como requisito que un segmento nunca se retransmita antes de que transcurra un RTO desde su transmisión anterior. Presenta el ciclo de inicio, detención y reinicio como un algoritmo recomendado para administrar el temporizador. No deben confundirse ambos niveles normativos.

El RFC no demuestra cómo funcionan todos los equipos actuales. Tampoco convierte esta regla en una explicación de ACK retrasados, muestras RTT, retransmisión rápida, SACK, control de congestión o retroceso exponencial.

Fuentes