Hay algoritmos de TCP diferentes para satisfacer las conexiones de ancho de banda cada vez mayor: de hecho, los primeros algoritmos históricamente utilizados serían incapaces de aumentar la velocidad lo suficientemente rápido como para saturar un enlace de red de 100 Mbit / s. Redes locales de flujo típico en la década de 2000.
Los distintos algoritmos TCP se encuentran, entre los más conocidos:
Debe entenderse que el algoritmo TCP nunca conoce la velocidad óptima a utilizar para un enlace: además, es difícil de estimar. IP , que lleva TCP, no garantiza que la ruta sea estable en el tiempo a través de la red, lo que hace imposible predecir la velocidad a utilizar. Además, la velocidad también está condicionada por otros factores como la existencia de streams concurrentes en parte de la ruta (por ejemplo puedes tener varias descargas simultáneas en servidores con distintos niveles de rendimiento).
Así es como TCP intentará adivinar el mejor rendimiento a utilizar, siempre tratando de aumentar el rendimiento hasta que se produzca la pérdida de paquetes porque la red no puede manejar todo el rendimiento. De hecho, las redes de computadoras están diseñadas para ser lo más simples posible y es la única posibilidad que tiene una red para advertir a los usuarios que está saturada.
Los algoritmos TCP se distinguen por la forma de inicio lento y la forma en que utilizan el ancho de banda disponible. A veces hablamos de la agresividad del protocolo.
Antes de comenzar, algo de terminología:
Todos los algoritmos que se presentan más adelante se basan en estas técnicas, o en una parte. El principio básico para evitar la congestión es reaccionar reduciendo la velocidad de la conexión. Los protocolos miden la importancia del problema observando diversos fenómenos como el aumento del tiempo de respuesta o la duplicación de mensajes de tipo ACK que significan una pérdida de paquete por ejemplo. Si el protocolo no responde a la congestión, el número de retransmisiones puede seguir aumentando y agravar así la congestión. Esta es la razón por la que un algoritmo de control reduce el flujo en caso de congestión.
Los diferentes algoritmos que se presentan a continuación deben implementarse en cada dispositivo que desee utilizarlo. No existe un sistema central para evitar la congestión, cada elemento de la red debe adaptar su flujo de transmisión.
Al iniciar una conexión, no conocemos el enlace entre nosotros y el destinatario, por lo que poco a poco iremos aumentando la cantidad de paquetes que enviamos. Por tanto, el objetivo es encontrar el ancho de banda disponible y utilizar todos los recursos disponibles. Luego usaremos una ventana de transmisión (swnd), que representa una cantidad de paquetes que se enviarán sin esperar el reconocimiento. Esta ventana crecerá a medida que recibamos reconocimientos por los paquetes enviados (cada ACK aumentará esta ventana en 1, en otras palabras, después de cada RTT el tamaño de la ventana se duplicará, siempre que no haya congestión).
Más allá de un cierto límite de valor de cwnd (umbral de inicio lento, ssthresh), TCP entra en modo para evitar la congestión. A partir de ahí, el valor de cwnd aumenta linealmente y, por lo tanto, mucho más lentamente que en el inicio lento: cwnd se incrementa en un MSS (= un paquete) en cada RTT. En este modo de funcionamiento, el algoritmo detecta la pérdida de un paquete lo más rápido posible: si recibimos el ACK del mismo paquete tres veces, no esperamos a que finalice un timeout para reaccionar. Como reacción a esta pérdida, reducimos el valor de ssthresh y cwnd (posiblemente volvamos al modo de inicio lento). La técnica de retransmisión rápida se utiliza para reenviar rápidamente los paquetes perdidos.
Como se explicó anteriormente, pasamos por este algoritmo en caso de detección de pérdida de segmento (s) cuando estamos en el modo de "Evitación de congestión". Un ACK duplicado se explica por la forma en que se procesan los segmentos en la recepción. De hecho, si recibimos un segmento TCP que no está en el orden esperado, debemos enviar un ACK con un valor igual al número de segmento que se esperaba. Si hay una pérdida de segmento, el destinatario solo enviará ACK con el número del segmento perdido. Por lo tanto, podemos compensar esta pérdida rápidamente (después de 3 ACK duplicados generalmente), sin esperar el tiempo de espera.
En lugar de volver al modo de inicio lento al duplicar ACK (y después de pasar por el modo de retransmisión rápida), reenviamos el segmento perdido y esperamos un ACK para toda la ventana transmitida previamente antes de volver al modo de prevención de congestión. Si llegamos al tiempo de espera, volvemos al modo Slow Start. Gracias a esta técnica evitamos bajar el caudal de forma demasiado brusca.
Algoritmos que se han utilizado (o no), pero que ahora están obsoletos.
La primera implementación del algoritmo para evitar la congestión de TCP es TCP Tahoe. Apareció por primera vez en el sistema BSD4.3. Es el más simple y el menos efectivo (todos los tipos de problemas combinados). Esta versión utiliza un sistema de inicio lento, con un valor de cwnd inicial de 1 y un valor de cwnd máximo de ssthresh (con un valor predeterminado de 65535). La primera vez que iniciamos lentamente llegamos a una pérdida de paquetes, en este caso el valor actual de cwnd será nuestro nuevo ssthresh, luego restablecemos el valor de cwnd a 1.
Una vez que se alcanza ssthresh, ingresa Evitación de congestión. A partir de ahí, el valor de cwnd aumenta linealmente y, por lo tanto, más lentamente que en Slow Start. Cuando recibimos el mismo ACK tres veces, hay congestión, no esperamos el tiempo de espera antes de reenviar el paquete perdido (retransmisión rápida). No hay recuperación rápida, pasamos el valor de ssthresh a la mitad del cwnd actual, cwnd pasa a 1 MSS y volvemos a Slow Start. En la figura se ilustra un ejemplo del comportamiento de este algoritmo.
La diferencia con Tahoe es que usa Fast Recovery. Una vez recibidos los tres ACK duplicados reducimos a la mitad el valor de cwnd, establecemos el umbral ssthresh al tamaño de cwnd, hacemos una retransmisión rápida y pasamos a Fast Recovery. Si tenemos un tiempo de espera, volvemos a Inicio lento como con Tahoe, con la ventana de congestión en 1 MSS.
Reno, por lo tanto, hace posible no volver a Inicio lento (y con un cwnd en 1) tan pronto como haya congestión. Por tanto, los caudales son más estables.
Este algoritmo se llama "NewReno" porque es sólo una modificación leve (pero significativa) del algoritmo de Reno. De hecho, la modificación tiene lugar a nivel de la fase de recuperación rápida: permanecemos en este modo mientras no hayamos recibido los ACK de todos los paquetes perdidos. Cuando hay una pérdida de varios segmentos de la misma "ráfaga" enviada, al recibir un acuse de recibo parcial, el siguiente segmento perdido se envía de vuelta, sin salir del modo de recuperación rápida, a diferencia de Reno que sale de este modo lo antes posible. ACK no duplicado.
En lugar de esperar a que se pierda un paquete, Vegas tiene en cuenta el tiempo de respuesta del destinatario (RTT) para obtener la proporción a la que enviar los paquetes. Dependiendo del tiempo de respuesta, podemos asumir el estado de los búferes de los enrutadores intermedios. Vegas está modificando varios algoritmos vistos hasta ahora para esto (inicio lento, evitación de congestión, retransmisión rápida).
Gracias a esta técnica, Vegas tiene mejores velocidades y menos pérdida de paquetes que Reno. Este algoritmo permite lograr un reparto equitativo de recursos. Asimismo, hay relativamente pocas pérdidas con Vegas, ya que en estado estable el rendimiento coincide con la capacidad del enlace \ cite {VEGAS}.
Debido a que Vegas puede adaptarse más rápidamente a los cambios en la disponibilidad del enlace, el rendimiento se degrada cuando se usa con otros protocolos que no tienen en cuenta el estado del enlace * antes * de la pérdida de un paquete.
Sin embargo, un inconveniente es que requiere una modificación de la pila de TCP tanto para el emisor como para el receptor.
Westwood es una reescritura de New Reno en el lado del transmisor para tener una mejor gestión de LFN (Long Fat Network). Cambia los valores de ssthresh y cwnd según las estimaciones que realiza sobre el ancho de banda disponible. La primera versión con malas estimaciones, se corrigió más tarde, de ahí el nombre Westwood +. Al igual que en Vegas, estas estimaciones se basan en el tiempo de respuesta del receptor (RTT), pero estas estimaciones se utilizan de manera diferente.
Tiene un mecanismo para detectar que no hay congestión (Detección Persistente de No Congestión, PNCD), lo que le permite utilizar rápidamente el ancho de banda disponible. Westwood modifica el inicio lento (se vuelve menos agresivo) agregando una fase: "Sondeo ágil", que le permite (con estimaciones a través del RTT) tener una fase de aumento de cwnd \ cite {UCLA} casi exponencial y luego estabilizar aumentar, luego estabilizar, etc.
El algoritmo gana mucho en eficiencia, pero nosotros perdemos en equidad ya que en caso de pérdida de paquetes no se adapta repentinamente dividiendo su cwnd por dos. Esto también lo hace adecuado para redes inalámbricas, que tienen pérdidas aleatorias (y no necesariamente debido a la congestión).
Los algoritmos para el inicio lento y la prevención de la congestión son los mismos que para TCP Reno. El ACK TCP selectivo permite, durante una pérdida, decir que los paquetes se han recibido hasta el número de secuencia N, pero también especificar al remitente que se han recibido algunos de los siguientes paquetes. El remitente ya no tiene que reenviar segmentos que ya se han recibido. SACK es una opción que se negocia con la conexión. Esta opción permite ganar un poco de rendimiento, durante la pérdida de segmentos, pero es necesario tener ambas partes (emisor y receptor) que lo implementen.
Dos algoritmos para evitar la congestión se utilizan ampliamente en los sistemas operativos comunes: CUBIC (Linux) y CTCP (Microsoft Windows). Antes de ver sus diferencias, veremos el algoritmo del que se hereda CUBIC, BIC. El objetivo de estos algoritmos es mantener un rendimiento lo más cercano posible al ancho de banda disponible.
Los algoritmos anteriores no son adecuados para redes rápidas con un gran ancho de banda (varios gigabits por segundo). Dejan parte del ancho de banda sin utilizar. BIC mantiene un buen rendimiento y una buena equidad incluso con otros algoritmos de prevención de congestión de TCP.
Una versión algo simplificada del algoritmo podría ser: cuando hay una pérdida, BIC reduce cwnd en un cierto coeficiente. Antes de reducir guardaremos en memoria el valor de cwnd que será nuestro máximo (Wmax), y el nuevo valor será nuestro valor mínimo (Wmin). A partir de estos dos valores encontraremos el valor intermedio para el que no tenemos pérdidas (búsqueda dicotómica).
El algoritmo tiene cuidado de no aumentar cwnd demasiado, por lo que si durante nuestra búsqueda hacemos saltos demasiado grandes (definidos por un cierto umbral), preferiremos aumentar cwnd logarítmicamente. Una vez reducida la diferencia, podemos volver a la búsqueda dicotómica hasta llegar a Wmax. A partir de ahí buscamos un nuevo máximo, con crecimiento lineal: buscamos ver si hay un máximo cercano. Si después de cierto período no tenemos pérdida, entonces nos decimos a nosotros mismos que el máximo está mucho más lejos y nuevamente aumentamos el tamaño de la ventana exponencialmente.
BIC proporciona una buena equidad, es estable mientras mantiene un alto rendimiento y permite un buen escalado. A pesar de sus cualidades, sigue siendo demasiado agresivo durante su fase ascendente. Pero sobre todo provoca una desigualdad con los flujos que tienen RTT largos.
Este algoritmo se ha utilizado en Linux, ya que preferimos su variante más elaborada: CUBIC.
CUBIC tiene un enlace ascendente más fluido que BIC, lo que lo hace más "amigable" para otras versiones de TCP. CUBIC es más simple porque tiene un solo algoritmo para su fase ascendente y no usa reconocimientos para aumentar el tamaño de la ventana, preferimos hablar de un evento de congestión. Esto es lo que hace que CUBIC sea más eficiente en redes de baja velocidad o con un RTT corto.
Una de las grandes peculiaridades de CTCP es que mantiene dos ventanas de congestión. La primera es la ventana que aumenta linealmente pero disminuye en caso de pérdida a través de un cierto coeficiente. La segunda ventana está vinculada al tiempo de respuesta del destinatario. Por lo tanto, combinamos métodos relacionados con la pérdida de paquetes (como TCP Reno) y la adaptación preventiva a la congestión (como TCP Vegas), de ahí el nombre “Compuesto”.
El tamaño de la ventana realmente utilizada es la suma de estas dos ventanas. Si el RTT es bajo, entonces la ventana basada en retardo aumentará rápidamente. Si se produce una pérdida de segmento, la ventana basada en la pérdida de paquetes disminuirá rápidamente para compensar el aumento de la ventana basada en el retardo. Con este sistema intentaremos mantener un valor constante de la ventana de emisión efectiva, cercano al estimado.
El propósito de este protocolo es mantener un buen rendimiento en redes de alta velocidad y con un gran RTT.
Estos diferentes criterios son:
No es fácil hablar de una mejor versión de TCP: hay versiones aptas para redes de muy alta velocidad, hay versiones aptas para velocidades bajas, hay versiones aptas para redes que cometen muchos errores.
Finalmente, observamos que los algoritmos TCP son todos compatibles entre sí (ya que no hay modificación del segmento TCP sino solo una variación en su velocidad de llegada). Por ejemplo, Windows Vista usa Compound TCP mientras que los kernels de Linux usan CUBIC TCP desde la versión 2.6.19.