Reno TCP
# Reno TCP

TCP RENO surge en el año 1990 e inicialmente se implementó sobre el sistema operativo BSD. Se conoce también por el nombre de BSD Network Release 2.0 (BNR2). Es la versión más utilizada en nuestros días.

TCP Reno continuó usando las mejoras incorporadas en el TCP Tahoe, así mismo modificó la retransmisión rápida para adicionar el Fast Recovery (recuperación rápida). Esta nueva implementación previene que se vacíe el caño (“pipe”) después de la retransmisión rápida, por lo que evita la necesidad de llenarlo con el algoritmo Slow-Start luego de haber sufrido la pérdida de un solo paquete.

Fast Recovery asume que por cada dup-ACK recibido éste representa un paquete que sale del caño. Por lo que mientras Fast Recovery el transmisor TCP puede hacer una estimación de la cantidad de información en la red. Se entra en Fast Recovery una vez que el transmisor de datos recibe una cantidad de dup-ACKs (ACK's duplicados) que supera cierto valor de umbral. Una vez que se llega al umbral, el transmisor retransmite un paquete y reduce su ventana de congestión a la mitad. En lugar de empezar con Slow-Start (como lo hace el transmisor TCP Tahoe), el transmisor Reno utiliza dup-ACKs adicionales para poner en agenda la salida de paquetes.

Durante la retransmisión rápida el transmisor incrementa su ventana por el número de dup-ACKs que ha recibido, haciendo la suposición de que cada dup-ACK que le llega es una indicación de que un paquete salió de la red y fue recibido por el receptor. Después de entrar en Fast Recovery y retransmitir un solo paquete, el transmisor efectivamente espera hasta recibir una cantidad de dup-ACKs igual a la mitad del tamaño de ventana, y luego envía un nuevo paquete por cada dup-ACK recibido. Luego de la recepción de un ACK correspondiente a datos nuevos, el transmisor sale de la fase de Fast Recovery.

El algoritmo de Fast Recovery de Reno está optimizado para el caso en que hay pérdida de un solo paquete de una ventana de datos. El transmisor Reno transmite a lo sumo un paquete perdido por RTT. Reno mejora significativamente con respecto a Tahoe cuando un paquete de datos se pierde de una ventana de datos, pero puede sufrir problemas de rendimiento cuando múltiples paquetes se pierden de una ventana de datos.

La ventaja más destacable es el hecho de no pasar a la fase de slow start, cada vez que se produce la pérdida de un segmento, haciéndolo más recomendable en los enlaces de banda ancha.

## Alternativas

* Fast TCP
* Eiffel TCP
* TCP Santa Cruz
* Datos: Q11702745
