Está en la página 1de 4

ESCUELA POLITÉCNICA DEL EJÉRCITO

DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA

INTERNET WORKING

TEMA:

Algoritmos Fast Recovery y Fast Retransmiton

ALUMNO:

Tnte. Marcelo Garzón Muñoz.

NIVEL:

Octavo Nivel A”.

FECHA:

21 DE JULIO DEL 2010


FAST RETRANSMIT Y FAST RECOVERY

Para remediar el problema de los largos períodos de inactividad atados al timeout, se ha


introducido el mecanismo de Fast Retransmit. Con este mecanismo el TCP no tiene
innecesariamente que esperar a que venza el timeout para poder retransmitir un segmento.
Está previsto que el receptor mande el ACK relativo a un segmento, aunque no se hayan
recibido aún los segmentos anteriores a éste. El transmisor deduce del número de ACK
duplicados qué recibe, si el segmento se ha perdido o bien está sufriendo solamente retrasos.
En efecto, un ACK duplicado indica el hecho tal que el receptor no puede mandar un ACK
relativo a un segmento llegado fuera de orden, ya que está esperando recibir de uno
precedente.

Algoritmo Fast Retransmit

Este algoritmo de retransmisión rápida fue propuesto en 1990 por Van Jacobson como mejora
de TCP. Su objetivo es acelerar la retransmisión de segmentos de datos perdidos si se dan
ciertas circunstancias

a) que el segmento se haya perdido.

b) que se haya producido una reordenación de los segmentos en la red por algún determinado
motivo y el segmento en cuestión esté aún pendiente de llegar y lo haga desordenadamente

Este algoritmo utiliza ACKs duplicados (3 duplicados, en total 4 ACKs) como señal de que
hay congestión y hay que retransmitir, sin esperar a que venza el timeout. Menos de 3 ACKs
duplicados podrían ser por desorden, no por pérdida

El mecanismo de Fast Retransmit prevé, que en caso de se reciban que 3 ACK duplicados
(3DUPACK) relativos al mismo segmento, se procede a la retransmisión del segmento, sin
esperar a que venza el timeout. Este mecanismo permite beneficios en el throughput y reduce
el número de timeout.
Dentro de la mejoras que aporta fast retransmit podemos decir que Se retransmite antes, Se
evita que ocurra timeout y No se vacía la red es decir seguimos enviando mensajes y
recibiendo ACKs

Algoritmo Fast Recovery

Este algoritmo de recuperación rápida entra en funcionamiento, principalmente, en


situaciones en las cuales la congestión de la red es más o menos moderada y muy puntual y
pudieran producirse a ráfagas sucesivas, con tendencia a desaparecer de forma rápida. Ante
este hecho, de desaparición rápida de la congestión, puede que no compense bajar al mínimo
el valor de la ventana de congestión, cwnd, y entrar en acción el algoritmo ya visto de Slow
Start.

Van Jacobson propone mejorar el throughput si se aplica Slow Start sólo cuando se
retransmite por timeout y no por 3 ACK duplicados.

El algoritmo entiende que cuando llega el tercer ACK duplicado de un mismo segmento (por
lo cual el emisor entiende que el paquete se ha perdido), se establece el ssthresh a la mitad del
valor de la ventana de transmisión CWND, es decir:

ssthresh = máx ( current_window/2, 2 )

Sin embargo, no entra en escena el algoritmo Slow Start, sino que se retransmite el segmento
perdido como en Congestion Avoidance y se establece la ventana de congestión como:

cwnd = ssthresh + 3 * (tamaño del segmento)

Este 3 entra en escena puesto a que si han llegado 3 ACK del segmento en cuestión es porque
los segmentos consecutivos a éste han llegado a su destino, siendo entonces el motivo de
alarma que el receptor hace notar al emisor sobre la pérdida del paquete.

Igualmente, podría darse el caso de que siguiesen llegando ACK relacionados a la


retransmisión de este segmento; es decir, mientras que realizamos la operación de
retransmisión podría haber segmentos en la red pendientes de llegar a su destino y, ante esto,
se incrementa la ventana de congestión por cada uno de estos ACK, quedando cwnd como
cwnd = cwnd + 1 paquete.

Esto ocurre hasta que el emisor recibe el ACK correspondiente al segmento perdido en
cuestión y retransmitido posteriormente, igualando justo en este momento el tamaño de la
ventana de congestión cwnd al tamaño del ssthresh comentado anteriormente.

Con todo esto, podemos observar que se ha retransmitido el segmento perdido mientras que
seguíamos en Congestion Avoidance, sin tener que entrar en Slow Start como se venía
haciendo hasta ahora. Como hemos mencionado anteriormente el ssthresh se reduce a la
mitad del tamaño de la ventana cwnd en el momento en que el emisor es consciente de la
pérdida del segmento.

La siguiente figura representa este comportamiento.

El diagrama exhibe el curso del CongestionWindow y el SlowStartThreshold en el caso en


que se adopten los mecanismos de Fast Retransmit y Fast Recovery.

Evolución de la ventana de congestión del TCP con Fast Retransmit y Fast Recovery

También podría gustarte