- TCP usa un reloj de retransmisión para determinar si debiera
retransmitir un segmento. ¿Por cuánto tiempo debiera
durar el intervalo de timeout?
- El problema en establecer un valor para este timeout es que la varianza
en tiempos de ida y vuelta es mucho mayor que en el nivel de enlace.
El promedio y varianza pueden cambiar rápidamente mientras
que la congestión crece y desparece. Si el timeout es demasiado
largo el rendimiento sufre, pero si es demasiado corto hay retransmisiones
innecesarias.
- Se usa un algoritmo debido a Jacobson. TCP mantiene un variable
RTT para cada conexión con una estimación del tiempo
de ida y vuelta. Si el próximo segmento toma M segundos, se
actualiza RTT según RTT = alpha RTT + (1-alpha)M. Un valor
típico para alpha es 7/8.
- Dado RTT hay que elegir todavía un timeout de retransmisión.
TCP normalmente usa beta RTT, donde beta debiera ser proporcional
(más o menos) a la desviación estándar. Se usa
la desviación promedia D, donde D = alpha D + (1-alpha)|RTT
- M|. alpha puede ser distinta a la previa.
- Finalmente, el timeout normalmente es RTT+4D.
- Un problema en la estimación de RTT es lo que pasa cuando
se retransmite un segmento. Cuando el acuse llega, no es claro si
refiere al primer segmento mandado o a la retransmisión. El
algoritmo de Karn es no actualizar RTT con los acuses de segmentos
retransmitidos. En vez de eso, se dobla el timeout con cada timeout
hasta que los segmentos llegan sin timeout.
- TCP mantiene también un reloj de persistencia. El emisor
lo usa para prevenir el bloqueo indefinido en el caso donde el emisor
cree que la ventana del recibidor es cero y la actualización
del recibidor fue perdido.
- Algunas implementaciones usan un reloj de keepalive (mantener vida)
para determinar si el otro lado todavía está allí,
y si no, desconectar. Una desventaja es que puede matar una conexión
debido a una falla temporal de la red.
|
|
|