Nombre: Paco Nina Norman Ormando ci: 4818721 LP.
Materia: Telematica – inf 273 Docente: Lic. Ramiro Gallardo
infografia
Evolución de los algoritmos de control de congestión
La evolución del control de congestión de TCP comienza a mediados de los años 80.
Hasta ese momento el control de flujo de transmisión basado en ventanas deslizantes había
funcionado bastante bien, pero con la popularización de Internet la congestión pasó a ser un
problema.
Entre 1986 y 1988, Van Jacobson propuso el esquema básico de control de congestión y desarrolló
el primer protocolo de implementación, que se conoce como TCP Tahoe.
Aquí se propone que el ratio de transmisión debe considerar el valor de las ventanas de recepción
y de congestión, quedando el emisor restringido a un ratio de transmisión cuyo valor mínimo es
rwnd y su máximo es cwnd.
En 1990 con TCP Reno se introdujo la aplicación del algoritmo AIMD (additive increase /
multiplicative decrease) según el cual:
1. Se incrementará de forma paulatina el ratio de transmisión hasta que alguna
pérdida de paquetes ocurra.
2. El incremento se hará aumentando de forma lineal la ventana de congestión, es
decir, sumando un valor.
3. En caso de que se infiera congestión, se disminuirá el ratio de transmisión, pero en
este caso se hará una disminución multiplicando por un valor.
Luego de TCP Reno aparecieron otros algoritmos y versiones de TCP que procuraban tomar los
preceptos del control de congestión y refinarlo, experimentándose una gran diversificación de
versiones y alcances.
Así tenemos que TCP Vegas plantea prestar atención a los valores de retardo para inferir
congestión o el caso de ECN (Explicit Congestion Notification) que introduce la posibilidad de que
los enrutadores de la red notifiquen condiciones de congestión a los equipos emisores.
También se ha promovido el desarrollo de una buena cantidad de mecanismos que permiten la
implementación de AIMD, tales como Slow Start, Fast Retransmission, Fast recovery, Adaptive
timeout o ACK clocking.
En todo caso, es interesante precisar la situación que teníamos hasta hace poco.
El mundo Linux se había decantado por TCP CUBIC, el cual es un heredero de TCP Reno y BIC TCP,
por lo que se basa en pérdida de paquetes y no en valores de retardo para determinar congestión.
En tanto que el mundo Windows utilizaba un algoritmo llamado TCP Compound, que proviene de
TCP Fast, el cual a su vez es heredero de TCP Vegas, por lo que se basan en retardos para inferir
congestión.
Tal como mencionamos al comienzo de este artículo, esta situación cambió en el momento en el
que Microsoft apostó por introducir TCP CUBIC en sus nuevos productos.
TCP CUBIC
TCP CUBIC es un algoritmo de control de congestión que surge con la idea de tomar ventaja del
hecho de que actualmente los enlaces de comunicaciones suelen disponer de niveles de ancho de
banda cada vez mayores.
En una red compuesta por enlaces de amplios anchos de banda un algoritmo de control de
congestión que lentamente incrementa el ratio de transmisión puede terminar por desperdiciar la
capacidad los enlaces.
La intención es disponer de un algoritmo que trabaje con ventanas de congestión cuyos procesos
de incremento sean más agresivos, pero que se restrinjan de sobrecargar la red.
Para lograr esto se propone que el esquema de incremento y disminución del ratio de transmisión
se establezca de acuerdo a una función cúbica. Veamos la siguiente figura:
Descripción: Función cúbica que regula la ventana de congestión según el algoritmo Cubic
Fuente: IEEE Xplore Digital Library:
[Link]
El procedimiento que sigue el algoritmo es, de forma resumida, el siguiente:
1. En el momento de experimentar un evento de congestión se registrará el tamaño de la
ventana para ese instante como Wmax o el tamaño máximo de ventana.
2. Se fijará el valor Wmax como el punto de inflexión de la función cúbica que regirá el
crecimiento de la ventana de congestión.
3. Luego se recomenzará la transmisión con un valor de ventana menor y, de no
experimentarse congestión, este valor se incrementará según la porción cóncava de la
función cúbica.
4. A medida que la ventana se aproxime al Wmax los incrementos irán ralentizándose.
5. Una vez alcanzado el punto de inflexión -es decir, Wmax- se seguirá aumentando
discretamente el valor de la ventana.
6. Finalmente, si la red sigue sin experimentar congestión alguna, se seguirá aumentando
el tamaño de la ventana según la porción convexa de la función.
Como vemos, CUBIC implementa un esquema de incrementos grandes al principio, los cuales
disminuyen alrededor del tamaño de ventana que causó la última congestión, para luego seguir
aumentado con incrementos grandes.
El control de congestión y las herramientas de monitorización
Un punto interesante del control de congestión que aporta TCP es que se trata de procesos con las
siguientes características:
1. Estos procesos corren solo en los equipos emisores.
2. No generan tráfico.
3. Propician un reparto equitativo de la capacidad de transmisión de la red. Como cada
equipo decide sobre su capacidad de transmisión, atendiendo solo al comportamiento
de la red que él observa, no se favorece ni perjudica a ningún equipo emisor bajo
ninguna circunstancia.
Ahora bien, es fácil entender que no es justo comparar las capacidades de los algoritmos de control
de congestión de TCP con las capacidades de una herramienta de monitorización, porque nos
estamos moviendo en dos universos completamente distintos.
Sin embargo, les proponemos repensar el alcance de una herramienta de monitorización de
propósitos generales como Pandora FMS desde el ángulo de estos algoritmos.
Así surgen los siguientes puntos:
1. El objeto de estudio de una herramienta de monitorización es mucho más amplio: una
herramienta de monitorización debe considerar todos los protocolos presentes en la
plataforma, no solo TCP.
2. La idea de una herramienta de monitorización es incluir bajo su esquema a todos los
componentes, ofreciendo siempre una visión global de la plataforma.
3. Los mecanismos que utiliza una herramienta de monitorización, tales como los
asociados con la administración de red como SNMP o con el control de flujo de tráfico
como NetFlow, son protocolos que implican el envío de paquetes asociados con sus
funciones. Ahora bien, por supuesto las herramientas de monitorización tienen como
objetivo establecer esquema que interfiera lo justo con el rendimiento global de la
plataforma.
4. La causa raíz de la congestión: el acercamiento que logran las herramientas de
monitorización pretende llegar a la causa raíz de la congestión. Quizás la causa de un
estado de congestión esté en la configuración errada de un protocolo de
enrutamiento, lo que no se va a corregir con que los equipos emisores modifiquen su
capacidad de transmisión.
5. Para finalizar debemos decir que un objetivo de las herramientas de monitorización es
generar información que permita predecir una situación de congestión antes de que
aparezca.
