El Protocolo de Control de Transmisión (TCP) utiliza un algoritmo de control de congestión que incluye varios aspectos de un esquema de aumento aditivo/disminución multiplicativa (AIMD), junto con otros esquemas que incluyen un inicio lento [1] y una ventana de congestión (CWND), para lograr evitar la congestión. El algoritmo de evitación de congestión TCP es la base principal para el control de la congestión en Internet. [2] [3] [4] Según el principio de extremo a extremo , el control de la congestión es en gran medida una función de los hosts de Internet , no de la red en sí. Hay varias variaciones y versiones del algoritmo implementadas en pilas de protocolos de sistemas operativos de computadoras que se conectan a Internet .
Para evitar el colapso por congestión , TCP utiliza una estrategia de control de congestión multifacética. Para cada conexión, TCP mantiene un CWND, que limita la cantidad total de paquetes no reconocidos que pueden estar en tránsito de extremo a extremo. Esto es algo similar a la ventana deslizante de TCP utilizada para el control de flujo .
El algoritmo de aumento aditivo/disminución multiplicativa (AIMD) es un algoritmo de control de bucle cerrado . El AIMD combina el crecimiento lineal de la ventana de congestión con una reducción exponencial cuando se produce una congestión. Los flujos múltiples que utilizan el control de congestión AIMD eventualmente convergerán para utilizar cantidades iguales de un enlace en disputa. [5]
Este es el algoritmo que se describe en RFC 5681 para el estado de "evitación de congestión". [6]
En TCP, la ventana de congestión (CWND) es uno de los factores que determina la cantidad de bytes que se pueden enviar en cualquier momento. La ventana de congestión la mantiene el emisor y es un medio para evitar que un enlace entre el emisor y el receptor se sobrecargue con demasiado tráfico. Esto no debe confundirse con la ventana deslizante que mantiene el emisor y que existe para evitar que el receptor se sobrecargue. La ventana de congestión se calcula estimando cuánta congestión hay en el enlace.
Cuando se establece una conexión, la ventana de congestión, un valor que se mantiene de forma independiente en cada host, se establece en un pequeño múltiplo del tamaño máximo de segmento ( MSS ) permitido en esa conexión. Una mayor variación en la ventana de congestión está determinada por un enfoque de aumento aditivo/disminución multiplicativa (AIMD). Esto significa que si se reciben todos los segmentos y los acuses de recibo llegan al remitente a tiempo, se agrega alguna constante al tamaño de la ventana. Seguirá diferentes algoritmos.
Un administrador del sistema puede ajustar el límite máximo del tamaño de la ventana o ajustar la constante agregada durante el aumento aditivo, como parte del ajuste de TCP .
El flujo de datos a través de una conexión TCP también se controla mediante el uso de la ventana de recepción anunciada por el receptor. Un remitente puede enviar datos en un tiempo menor que su propia ventana de congestión y la ventana de recepción .
El inicio lento, definido por RFC 5681. [7] es parte de la estrategia de control de congestión utilizada por TCP junto con otros algoritmos para evitar enviar más datos de los que la red es capaz de reenviar, es decir, para evitar causar congestión en la red.
El inicio lento comienza inicialmente con un tamaño de ventana de congestión (CWND) de 1, 2, 4 o 10 MSS. [8] [3] : 1 El valor del tamaño de la ventana de congestión se puede aumentar en 1 MSS con cada reconocimiento (ACK) recibido, duplicando efectivamente el tamaño de la ventana en cada RTT . [a]
La velocidad de transmisión aumentará mediante el algoritmo de inicio lento hasta que se detecte una pérdida de paquetes, la ventana anunciada del receptor (rwnd) se convierta en el factor limitante o se alcance el umbral de inicio lento (ssthresh) , que se utiliza para determinar si se utiliza el algoritmo de inicio lento o el de evitación de congestión, un valor establecido para limitar el inicio lento.
Si el CWND alcanza ssthresh , TCP cambia al algoritmo de prevención de congestión. Debe incrementarse en hasta 1 MSS por cada RTT. Una fórmula común es que cada nuevo ACK incrementa el CWND en MSS * MSS / CWND. Aumenta casi linealmente y proporciona una aproximación aceptable.
Si se produce un evento de pérdida, TCP supone que se debe a una congestión de la red y toma medidas para reducir la carga ofrecida en la red. Estas medidas dependen del algoritmo de prevención de congestión TCP exacto que se utilice.
Cuando un remitente TCP detecta la pérdida de un segmento utilizando el temporizador de retransmisión y el segmento dado aún no se ha reenviado, el valor de ssthresh se debe establecer en no más de la mitad de la cantidad de datos que se han enviado pero que aún no se han reconocido acumulativamente o 2 * MSS , el que sea mayor.
El inicio lento presupone que los segmentos no reconocidos se deben a la congestión de la red. Si bien esta es una suposición aceptable para muchas redes, los segmentos pueden perderse por otras razones, como una mala calidad de transmisión de la capa de enlace de datos . Por lo tanto, el inicio lento puede tener un rendimiento deficiente en situaciones con mala recepción, como en las redes inalámbricas .
El protocolo de inicio lento también funciona mal para conexiones de corta duración. Los navegadores web más antiguos creaban muchas conexiones consecutivas de corta duración con el servidor web y abrían y cerraban la conexión para cada archivo solicitado. Esto mantenía la mayoría de las conexiones en el modo de inicio lento, lo que daba como resultado un tiempo de respuesta deficiente. Para evitar este problema, los navegadores modernos abren múltiples conexiones simultáneamente o reutilizan una conexión para todos los archivos solicitados desde un servidor web en particular. Sin embargo, las conexiones no se pueden reutilizar para los múltiples servidores de terceros que utilizan los sitios web para implementar publicidad web , funciones de uso compartido de servicios de redes sociales [9] y scripts de contador de análisis web .
La retransmisión rápida es una mejora de TCP que reduce el tiempo que un remitente espera antes de retransmitir un segmento perdido. Un remitente TCP normalmente utiliza un temporizador simple para reconocer los segmentos perdidos. Si no se recibe un acuse de recibo para un segmento en particular dentro de un tiempo especificado (una función del tiempo de retardo de ida y vuelta estimado ), el remitente asumirá que el segmento se perdió en la red y lo retransmitirá.
El acuse de recibo duplicado es la base del mecanismo de retransmisión rápida. Después de recibir un paquete, se envía un acuse de recibo para el último byte de datos en orden recibido. Para un paquete en orden, esto es efectivamente el número de secuencia del último paquete más la longitud de carga útil del paquete actual. Si se pierde el siguiente paquete de la secuencia pero se recibe un tercer paquete de la secuencia, entonces el receptor solo puede acusar recibo del último byte de datos en orden, que es el mismo valor que se acusó recibo para el primer paquete. El segundo paquete se pierde y el tercer paquete no está en orden, por lo que el último byte de datos en orden sigue siendo el mismo que antes. Por lo tanto, se produce un acuse de recibo duplicado . El remitente continúa enviando paquetes y el receptor recibe un cuarto y un quinto paquete. Nuevamente, el segundo paquete falta en la secuencia, por lo que el último byte en orden no ha cambiado. Se envían acuses de recibo duplicados para ambos paquetes.
Cuando un remitente recibe tres acuses de recibo duplicados, puede estar razonablemente seguro de que se perdió el segmento que transportaba los datos que seguían al último byte en orden especificado en el acuse de recibo. Un remitente con retransmisión rápida retransmitirá entonces este paquete inmediatamente sin esperar a que se agote el tiempo de espera. Al recibir el segmento retransmitido, el receptor puede acusar recibo del último byte en orden de los datos recibidos. En el ejemplo anterior, esto acusaría recibo hasta el final de la carga útil del quinto paquete. No es necesario acusar recibo de los paquetes intermedios, ya que TCP utiliza acuses de recibo acumulativos de forma predeterminada.
La convención de nombres para los algoritmos de control de congestión (CCA) puede haberse originado en un artículo de 1996 de Kevin Fall y Sally Floyd. [10] [ verificación fallida ]
La siguiente es una posible clasificación según las siguientes propiedades:
Algunos mecanismos de prevención de congestión bien conocidos se clasifican según este esquema de la siguiente manera:
Los algoritmos TCP Tahoe y Reno recibieron su nombre de forma retrospectiva en honor a las versiones o variantes del sistema operativo 4.3BSD en las que cada uno de ellos apareció por primera vez (que a su vez recibieron su nombre del lago Tahoe y de la cercana ciudad de Reno, Nevada ). El algoritmo Tahoe apareció por primera vez en 4.3BSD-Tahoe (que se creó para dar soporte a la minicomputadora CCI Power 6/32 "Tahoe" ), y más tarde se puso a disposición de los usuarios que no tenían licencia de AT&T como parte de la versión 1 de Networking de 4.3BSD; esto aseguró su amplia distribución e implementación. Se realizaron mejoras en 4.3BSD-Reno y posteriormente se lanzó al público como Networking Release 2 y más tarde como 4.4BSD-Lite.
Si bien ambos consideran el tiempo de espera de retransmisión (RTO) y los ACK duplicados como eventos de pérdida de paquetes, el comportamiento de Tahoe y Reno difiere principalmente en cómo reaccionan a los ACK duplicados:
Tanto en Tahoe como en Reno, si se agota el tiempo de espera de un ACK (tiempo de espera RTO), se utiliza un inicio lento y ambos algoritmos reducen la ventana de congestión a 1 MSS. [ cita requerida ]
TCP New Reno, definido por RFC 6582 (que deja obsoletas las definiciones anteriores en RFC 3782 y RFC 2582), mejora la retransmisión durante la fase de recuperación rápida de TCP Reno.
Durante la recuperación rápida, para mantener llena la ventana de transmisión, por cada ACK duplicado que se devuelve, se envía un nuevo paquete no enviado desde el final de la ventana de congestión.
La diferencia con Reno es que New Reno no reduce a la mitad ssthresh inmediatamente, lo que puede reducir demasiado la ventana si se producen múltiples pérdidas de paquetes. No sale de la recuperación rápida ni reinicia ssthresh hasta que reconoce todos los datos.
Después de la retransmisión, los datos recién reconocidos tienen dos casos:
Utiliza una variable denominada "recover" para registrar la cantidad de datos que se deben recuperar. Después de un tiempo de espera de retransmisión, registra el número de secuencia más alto transmitido en la variable recover y sale del procedimiento de recuperación rápida. Si se confirma este número de secuencia, TCP vuelve al estado de prevención de congestión.
Se produce un problema con New Reno cuando no hay pérdidas de paquetes, sino que los paquetes se reordenan con más de 3 números de secuencia de paquetes. En este caso, New Reno ingresa por error en la recuperación rápida. Cuando se entrega el paquete reordenado, se envían inmediatamente retransmisiones duplicadas e innecesarias.
El nuevo Reno funciona tan bien como SACK en tasas bajas de error de paquetes y supera sustancialmente a Reno en tasas altas de error. [17]
Hasta mediados de los años 1990, todos los tiempos de espera establecidos y los retrasos de ida y vuelta medidos de TCP se basaban únicamente en el último paquete transmitido en el búfer de transmisión. Los investigadores de la Universidad de Arizona Larry Peterson y Lawrence Brakmo introdujeron TCP Vegas en el que se establecían tiempos de espera y se medían los retrasos de ida y vuelta para cada paquete en el búfer de transmisión. Además, TCP Vegas utiliza incrementos aditivos en la ventana de congestión. En un estudio comparativo de varios CCA de TCP , TCP Vegas parecía ser el más uniforme, seguido de TCP CUBIC. [18]
TCP Vegas no se implementó ampliamente fuera del laboratorio de Peterson, pero fue seleccionado como el método de control de congestión predeterminado para el firmware DD-WRT v24 SP2. [19]
TCP Hybla [20] [21] tiene como objetivo eliminar las penalizaciones a las conexiones TCP que utilizan enlaces de radio terrestres o satelitales de alta latencia. Las mejoras de Hybla se basan en la evaluación analítica de la dinámica de la ventana de congestión. [22]
El control de aumento de congestión binario (BIC) es una implementación de TCP con un CCA optimizado para redes de alta velocidad con alta latencia, conocidas como redes largas y pesadas (LFN). [23] BIC se utiliza de forma predeterminada en los núcleos Linux 2.6.8 a 2.6.18. [ cita requerida ]
CUBIC es un derivado menos agresivo y más sistemático de BIC, en el que la ventana es una función cúbica del tiempo desde el último evento de congestión, con el punto de inflexión establecido en la ventana anterior al evento. CUBIC se utiliza de forma predeterminada en los núcleos de Linux desde la versión 2.6.19.
Agile-SD es un CCA basado en Linux que está diseñado para el núcleo real de Linux. Es un algoritmo del lado del receptor que emplea un enfoque basado en pérdidas utilizando un mecanismo novedoso, llamado factor de agilidad (AF). para aumentar la utilización del ancho de banda en redes de alta velocidad y corta distancia (redes de productos de bajo ancho de banda-retardo) como redes de área local o redes de fibra óptica, especialmente cuando el tamaño de búfer aplicado es pequeño. [24] Se ha evaluado comparando su rendimiento con Compound TCP (el CCA predeterminado en MS Windows) y CUBIC (el predeterminado de Linux) utilizando el simulador NS-2. Mejora el rendimiento total hasta en un 55% en términos de rendimiento promedio.
Westwood+ es una modificación de TCP Reno que solo permite el envío de mensajes y optimiza el rendimiento del control de congestión de TCP tanto en redes cableadas como inalámbricas . TCP Westwood+ se basa en una estimación del ancho de banda de extremo a extremo para establecer la ventana de congestión y el umbral de inicio lento después de un episodio de congestión, es decir, después de tres acuses de recibo duplicados o un tiempo de espera. El ancho de banda se calcula promediando la tasa de paquetes de acuse de recibo que regresan. A diferencia de TCP Reno, que reduce a la mitad ciegamente la ventana de congestión después de tres acuses de recibo duplicados, TCP Westwood+ establece de forma adaptativa un umbral de inicio lento y una ventana de congestión que tiene en cuenta una estimación del ancho de banda disponible en el momento en que se experimenta la congestión. En comparación con Reno y New Reno, Westwood+ aumenta significativamente el rendimiento en los enlaces inalámbricos y mejora la equidad en las redes cableadas. [ cita requerida ]
Compound TCP es una implementación de Microsoft de TCP que mantiene dos ventanas de congestión diferentes simultáneamente, con el objetivo de lograr un buen rendimiento en las LFN sin perjudicar la equidad . Se ha implementado ampliamente en versiones de Windows desde Microsoft Windows Vista y Windows Server 2008 y se ha adaptado a versiones anteriores de Microsoft Windows, así como a Linux .
TCP Proportional Rate Reduction (PRR) [25] es un algoritmo diseñado para mejorar la precisión de los datos enviados durante la recuperación. El algoritmo garantiza que el tamaño de la ventana después de la recuperación sea lo más cercano posible al umbral de inicio lento. En pruebas realizadas por Google , PRR resultó en una reducción del 3 al 10 % en la latencia promedio y los tiempos de espera de recuperación se redujeron en un 5 %. [26] PRR está disponible en los núcleos de Linux desde la versión 3.2. [27]
El ancho de banda de cuello de botella y el tiempo de propagación de ida y vuelta (BBR) es un CCA desarrollado en Google en 2016. [28] Si bien la mayoría de los CCA se basan en pérdidas, ya que dependen de la pérdida de paquetes para detectar la congestión y las tasas de transmisión más bajas, BBR, como TCP Vegas, se basa en modelos. El algoritmo utiliza el ancho de banda máximo y el tiempo de propagación de ida y vuelta en el que la red entregó el vuelo más reciente de paquetes de datos salientes para construir un modelo de la red. Cada reconocimiento acumulativo o selectivo de la entrega de paquetes produce una muestra de tasa que registra la cantidad de datos entregados durante el intervalo de tiempo entre la transmisión de un paquete de datos y el reconocimiento de ese paquete. [29]
Cuando se implementó en YouTube , BBRv1 produjo un rendimiento de red promedio un 4 % mayor y hasta un 14 % en algunos países. [30] BBR ha estado disponible para Linux TCP desde Linux 4.9. [31] También está disponible para QUIC . [32]
La imparcialidad de la versión 1 de BBR (BBRv1) con los flujos que no son de BBR es objeto de controversia. Si bien la presentación de Google muestra que BBRv1 coexiste bien con CUBIC, [28] investigadores como Geoff Huston y Hock, Bless y Zitterbart encontraron que no es justa con otros flujos y que no es escalable. [33] Hock et al. también encontraron "algunos problemas inherentes graves, como mayores demoras en las colas, injusticia y pérdida masiva de paquetes" en la implementación de BBR de Linux 4.9. [34] Soheil Abbasloo et al. (autores de C2TCP) muestran que BBRv1 no funciona bien en entornos dinámicos como las redes celulares. [11] [12] También han demostrado que BBR tiene un problema de injusticia. Por ejemplo, cuando un flujo CUBIC (que es la implementación TCP predeterminada en Linux, Android y MacOS) coexiste con un flujo BBR en la red, el flujo BBR puede dominar el flujo CUBIC y obtener todo el ancho de banda del enlace de este (ver figura 16 en [11] ).
La versión 2 intenta abordar el problema de la injusticia al operar junto con la gestión de congestión basada en pérdidas, como CUBIC. [35] En BBRv2, el modelo utilizado por BBRv1 se amplía para incluir información sobre la pérdida de paquetes e información de la Notificación de Congestión Explícita (ECN). [36] Si bien BBRv2 puede tener a veces un rendimiento menor que BBRv1, generalmente se considera que tiene un mejor rendimiento útil . [ cita requerida ]
La versión 3 (BBRv3) corrige dos errores de BBRv2 (final prematuro del sondeo de ancho de banda, convergencia de ancho de banda) y realiza algunos ajustes de rendimiento. También existe una variante, denominada BBR.Swift, optimizada para enlaces internos de centros de datos: utiliza network_RTT (excluyendo el retraso del receptor) como la principal señal de control de congestión. [36]
El TCP de retardo controlado celular (C2TCP) [11] [12] fue motivado por la falta de un enfoque TCP flexible de extremo a extremo que pueda satisfacer varios requisitos de QoS para diferentes aplicaciones sin requerir ningún cambio en los dispositivos de red. C2TCP tiene como objetivo satisfacer los requisitos de latencia ultrabaja y alto ancho de banda de aplicaciones como realidad virtual , videoconferencia , juegos en línea , sistemas de comunicación vehicular , etc. en un entorno altamente dinámico como las redes celulares LTE actuales y 5G futuras . C2TCP funciona como un complemento sobre TCP basado en pérdidas (por ejemplo, Reno, NewReno, CUBIC , BIC , ...), solo se requiere instalarlo en el lado del servidor y hace que el retraso promedio de los paquetes esté limitado a los retrasos deseados establecidos por las aplicaciones.
Los investigadores de la Universidad de Nueva York [37] demostraron que C2TCP supera el rendimiento en cuanto a retardo y variación de retardo de varios esquemas TCP de última generación. Por ejemplo, demostraron que, en comparación con BBR, CUBIC y Westwood, en promedio, C2TCP reduce el retardo promedio de los paquetes en aproximadamente un 250 %, 900 % y 700 % respectivamente en varios entornos de redes celulares. [11]
Elastic-TCP se propuso en febrero de 2019 para aumentar la utilización del ancho de banda en redes de alto BDP en apoyo de la computación en la nube. Es un CCA basado en Linux que está diseñado para el kernel de Linux. Es un algoritmo del lado del receptor que emplea un enfoque basado en pérdida-retardo utilizando un mecanismo novedoso llamado función de ponderación correlacionada con ventanas (WWF). Tiene un alto nivel de elasticidad para lidiar con diferentes características de red sin la necesidad de un ajuste humano. Se ha evaluado comparando su rendimiento con Compound TCP (el CCA predeterminado en MS Windows), CUBIC (el predeterminado para Linux) y TCP-BBR (el predeterminado de Linux 4.9 utilizado por Google) utilizando el simulador y banco de pruebas NS-2. Elastic-TCP mejora significativamente el rendimiento total en términos de rendimiento promedio, tasa de pérdida y retraso. [38]
Soheil Abbasloo et al. propusieron NATCP (Network-Assisted TCP) [13], un diseño de TCP controvertido [ ¿según quién? ] que apunta a la computación de borde de acceso múltiple (MEC). La idea clave de NATCP es que si las características de la red se conocieran de antemano, TCP se habría diseñado de manera diferente. Por lo tanto, NATCP emplea las características y propiedades disponibles en las arquitecturas celulares actuales basadas en MEC para impulsar el rendimiento de TCP cerca del rendimiento óptimo. NATCP utiliza retroalimentación fuera de banda de la red a los servidores ubicados cerca. La retroalimentación de la red, que incluye la capacidad del enlace de acceso celular y el RTT mínimo de la red, guía a los servidores para ajustar sus tasas de envío. Como muestran los resultados preliminares, NATCP supera a los esquemas TCP de última generación. [13] [39]
TCP New Reno fue el algoritmo más comúnmente implementado, [ cita requerida ] El soporte de SACK es muy común [ cita requerida ] y es una extensión de Reno/New Reno. La mayoría de los demás son propuestas competitivas que aún necesitan evaluación. A partir de la versión 2.6.8, el núcleo Linux cambió la implementación predeterminada de New Reno a BIC . La implementación predeterminada se cambió nuevamente a CUBIC en la versión 2.6.19. FreeBSD desde la versión 14.X en adelante también usa CUBIC como algoritmo predeterminado. [51] La versión anterior usaba New Reno. Sin embargo, FreeBSD admite varias otras opciones. [52]
Cuando el producto de ancho de banda y latencia por flujo aumenta, independientemente del esquema de colas, TCP se vuelve ineficiente y propenso a la inestabilidad. Esto adquiere cada vez mayor importancia a medida que Internet evoluciona para incorporar enlaces ópticos de muy alto ancho de banda.
TCP Interactive (iTCP) [53] permite que las aplicaciones se suscriban a eventos TCP y respondan en consecuencia, lo que permite varias extensiones funcionales a TCP desde fuera de la capa TCP. La mayoría de los esquemas de congestión TCP funcionan internamente. iTCP también permite que las aplicaciones avanzadas participen directamente en el control de la congestión, como por ejemplo para controlar la tasa de generación de la fuente.
Zeta-TCP detecta la congestión a partir de medidas de latencia y tasa de pérdida. Para maximizar el rendimiento, Zeta-TCP aplica diferentes estrategias de reducción de la ventana de congestión en función de la probabilidad de congestión. También tiene otras mejoras para detectar con precisión las pérdidas de paquetes, evitar el tiempo de espera de retransmisión y acelerar y controlar el tráfico entrante (descarga). [54]
Los CCA pueden clasificarse en función de su conocimiento de la red, es decir, en qué medida estos algoritmos conocen el estado de la red. Esto consta de tres categorías principales: caja negra, caja gris y caja verde. [55]
Los algoritmos de caja negra ofrecen métodos ciegos de control de la congestión. Operan únicamente con la retroalimentación binaria que reciben sobre la congestión y no presuponen ningún conocimiento sobre el estado de las redes que gestionan.
Los algoritmos de caja gris utilizan mediciones basadas en el tiempo, como la variación de RTT y la tasa de llegada de paquetes, para obtener mediciones y estimaciones del ancho de banda, la contención del flujo y otros conocimientos sobre las condiciones de la red.
Los algoritmos de caja verde ofrecen métodos bimodales de control de congestión que miden la parte justa del ancho de banda total que debe asignarse a cada flujo, en cualquier punto, durante la ejecución del sistema.
Los siguientes algoritmos requieren que se agreguen campos personalizados a la estructura del paquete TCP:
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite web}}: CS1 maint: archived copy as title (link)