Administración de relojes

  • 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.
   
../Conexión en TCP/Administración de relojes