- Cada vez que se envía un segmento, el TCP arranca un temporizador y espera
el correspondiente ACK. Si se termina el tiempo antes de que se confirme
positivamente el segmento (recuérdese que no se utilizan confirmaciones
negativas), el TCP asume que dicho segmento se perdió o corrompió, y lo
retransmite.
- El problema radica en que las redes IP poseen latencias muy variables debido a
su tamaño, heterogeneidad, variación de la carga, nivel de congestión, etc. Por
este motivo el TCP utiliza un algoritmo adaptativo para calcular los time-outs.
Estima el RTT promedio como
donde:
-
EstimatedRTT
- es la estimación del RTT,
-
SampleRTT
- es la medida del último RTT (medido como la diferencia en tiempo
entre el instante en que se envía el segmento hasta que se recibe su
confirmación) y
-
α
- es un número entre 0 y 1 de tal forma que si α ≈ 0 entonces tiene mayor peso
la última medida del RTT, y si α ≈ 1 entonces EstimatedRTT es menos
dependiente de SampleRTT. La especificación original del TCP recomienda
que 0.8 ≤ α ≤ 0.9.
Finalmente, la estimación (promedio) para el time-out es
El algoritmo original no funciona correctamente cuando ocurre una retransmisión. En esta
situación, el emisor no puede saber si el ACK recibido se corresponde con la primera o la
segunda transmisión (problema de la ambigüedad del ACK). Si supone que es con la
primera y no ocurre así, el SampleRTT medido sería demasiado largo. Si
supone que es con la segunda y esto no es cierto, el cálculo es demasiado corto.
Gráficamente:
Ambos errores son perjudiciales para el cálculo del TimeOut:
- Si el SampleRTT (y por lo tanto el TimeOut) es más grande de lo
que debiera ser, las retransmisiones ocurrirán con un periodo superior. Así,
el siguiente SampleRTT tras una retransmisión tenderá a crecer, y así
sucesivamente. En consecuencia, un TimeOut excesivamente grande provoca
a la larga una infrautilización de los enlaces.
- Si el SampleRTT (y por lo tanto el TimeOut) es erróneamente pequeño, el
emisor retransmitirá innecesariamente antes de recibir el correspondiente ACK.
Esto provocará de nuevo que el SampleRTT sea erróneamente pequeño y así
sucesivamente hasta llegar a una situación de equilibrio donde en promedio
cada segmento se retransmite 1 vez. Por tanto, un TimeOut excesivamente
pequeño incrementará la congestión de los enlaces.
La solución:
Ignorar los RTT’s de los segmentos retransmitidos para computar el
time-out.
Estimar el RTT sólo para los segmentos que no son retransmitidos acarrea un nuevo
problema. Supongamos que debido a un aumento en la carga de la red o de la congestión,
el RTT aumenta por encima del time-out, lo que provoca una retransmisión. Como el
TCP va a ignorar el RTT de los segmentos retransmitidos, nunca va a actualizar la
estimación para el RTT mientras las latencias sigan siendo altas y el ciclo continuará. Por
este motivo, además:
Cada vez que se retransmite se dobla el time-out, hasta alcanzar 2×MSL
[4].
El motivo de este aumento exponencial del time-out obedece a que normalmente un aumento
en las latencias se debe a problemas de congestión y ante esta situación lo mejor es
disminuir rápidamente la frecuencia de las retransmisiones.
Por desgracia, la mejora del algoritmo básico realizada por Karn y Partridge no funciona
cuando los niveles de congestión son altos, ya que las latencias son muy variables. En esta
situación es muy importante no colapsar aún más la red usando time-outs demasiado
bajos.
La mejora propuesta por Jacobson y Karels consiste en tener en cuenta además
la variación de los RTT’s, no sólo su media. Intuitivamente, si la varianza es
baja, entonces EstimatedRTT es más fiable. Por otra parte, una varianza alta
significa que EstimatedRTT no debe ser considerado con tanto peso a la hora de
calcular TimeOut. De esta forma, el cálculo actual del time-out en el TCP
es
donde:
- 0 ≤ δ ≤ 1 es un factor que mide lo que Diff afecta al nuevo cálculo del
RTT y
- 0 ≤ρ ≤ 1 es otro factor que hace lo mismo con la desviación estadística del
RTT.
- Un ejemplo real [13]:
