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 inicio lento [1] y ventana de congestión (CWND), para lograr evitar la congestión. El algoritmo TCP para evitar la congestión 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 servidores de Internet , no de la red en sí. Existen varias variaciones y versiones del algoritmo implementado en pilas de protocolos de sistemas operativos de computadoras que se conectan a Internet .
Para evitar el colapso congestivo , TCP utiliza una estrategia de control de congestión multifacética. Para cada conexión, TCP mantiene un CWND, lo que limita la cantidad total de paquetes no reconocidos que pueden estar en tránsito de un extremo a otro. Esto es algo análogo 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 . AIMD combina un crecimiento lineal de la ventana de congestión con una reducción exponencial cuando se produce una congestión. Múltiples flujos que utilizan el control de congestión AIMD eventualmente convergerán para usar cantidades iguales de un enlace en competencia. [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. El remitente mantiene la ventana de congestión y es un medio para evitar que un enlace entre el remitente y el receptor se sobrecargue con demasiado tráfico. Esto no debe confundirse con la ventana deslizante mantenida por el remitente 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 configura 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 viene dictada 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 de tamaño de 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 menos datos 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 en conjunto 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 para el tamaño de la ventana de congestión se puede aumentar en 1 MSS con cada confirmación (ACK) recibida, 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 paquete, la ventana anunciada por el receptor (rwnd) se convierta en el factor limitante o se alcance el umbral de inicio lento (ssthresh) , que se utiliza para determinar si el algoritmo de inicio lento Se utiliza un algoritmo de inicio o evitación de congestión, un valor establecido para limitar el inicio lento.
Si CWND alcanza ssthresh , TCP cambia al algoritmo para evitar la congestión. Debe aumentarse hasta en 1 MSS por cada RTT. Una fórmula común es que cada nuevo ACK aumenta el CWND en MSS * MSS/CWND. Aumenta casi linealmente y proporciona una aproximación aceptable.
Si ocurre un evento de pérdida, TCP asume que se debe a la congestión de la red y toma medidas para reducir la carga ofrecida en la red. Estas medidas dependen del algoritmo exacto para evitar la congestión de TCP utilizado.
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 debe establecerse en no más de la mitad de la cantidad de datos que se han enviado pero que aún no se han reconocido de forma acumulativa o 2 * MSS , el valor que sea mayor.
El inicio lento supone 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, se pueden perder segmentos por otras razones, como una mala calidad de transmisión de la capa de enlace de datos . Así, un inicio lento puede funcionar mal en situaciones con mala recepción, como en redes inalámbricas .
El protocolo de inicio lento también funciona mal para conexiones de corta duración. Los navegadores web más antiguos crearían muchas conexiones consecutivas de corta duración con el servidor web y abrirían y cerrarían la conexión para cada archivo solicitado. Esto mantuvo a la mayoría de las conexiones en el modo de inicio lento, lo que resultó en un tiempo de respuesta deficiente. Para evitar este problema, los navegadores modernos abren varias 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 utilizados por los sitios web para implementar publicidad web , compartir funciones de servicios de redes sociales , [9] y contraguiones de análisis web .
La retransmisión rápida es una mejora de TCP que reduce el tiempo que espera un remitente antes de retransmitir un segmento perdido. Un remitente TCP normalmente utiliza un temporizador simple para reconocer segmentos perdidos. Si no se recibe un acuse de recibo para un segmento en particular dentro de un tiempo específico (una función del tiempo de demora estimado de ida y vuelta ), 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 del último byte de datos recibidos en orden. Para un paquete en orden, este es efectivamente el número de secuencia del último paquete más la longitud de la 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 sólo puede reconocer el último byte de datos en orden, que es el mismo valor que se reconoció 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 tanto, se produce un reconocimiento 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 el segmento que contiene los datos que siguieron al último byte en orden especificado en el acuse de recibo se perdió. Un remitente con retransmisión rápida retransmitirá este paquete inmediatamente sin esperar a que expire el tiempo de espera. Al recibir el segmento retransmitido, el receptor puede acusar recibo del último byte en orden de datos recibidos. En el ejemplo anterior, esto reconocería hasta el final de la carga útil del quinto paquete. No es necesario reconocer los paquetes intermedios ya que TCP utiliza reconocimientos acumulativos de forma predeterminada.
La convención de nomenclatura 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:
Este esquema clasifica algunos mecanismos bien conocidos para evitar la congestión de la siguiente manera:
Los algoritmos TCP Tahoe y Reno recibieron nombres retrospectivos de las versiones o sabores del sistema operativo 4.3BSD en el que aparecieron por primera vez (que a su vez recibieron el nombre de Lake Tahoe y la cercana ciudad de Reno, Nevada ). El algoritmo Tahoe apareció por primera vez en 4.3BSD-Tahoe (que fue creado para admitir la minicomputadora CCI Power 6/32 "Tahoe" ) y luego estuvo disponible para licenciatarios que no son de AT&T como parte de 4.3BSD Networking Release 1; esto aseguró su amplia distribución e implementación. Se realizaron mejoras en 4.3BSD-Reno y posteriormente se lanzaron al público como Networking Release 2 y posteriormente 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 ante los ACK duplicados:
Tanto en Tahoe como en Reno, si se agota el tiempo de espera de un ACK (tiempo de espera de RTO), se utiliza un inicio lento y ambos algoritmos reducen la ventana de congestión a 1 MSS. [ cita necesaria ]
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 la ventana de transmisión llena, 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 restablece ssthresh hasta que reconoce todos los datos.
Después de la retransmisión, los datos recién reconocidos tienen dos casos:
Utiliza una variable llamada "recuperar" 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 de recuperación y sale del procedimiento de recuperación rápida. Si se reconoce este número de secuencia, TCP vuelve al estado para evitar la congestión.
Se produce un problema con New Reno cuando no hay pérdidas de paquetes, sino que los paquetes se reordenan según más de 3 números de secuencia de paquetes. En este caso, New Reno entra por error en recuperación rápida. Cuando se entrega el paquete reordenado, se envían inmediatamente retransmisiones duplicadas e innecesarias.
New Reno funciona tan bien como SACK con bajas tasas de error de paquetes y supera sustancialmente a Reno con altas tasas de error. [17]
Hasta mediados de la década de 1990, todos los tiempos de espera establecidos por TCP y los retrasos de ida y vuelta medidos 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 establecieron tiempos de espera y se midieron retrasos de ida y vuelta para cada paquete en el buffer de transmisión. Además, TCP Vegas utiliza aumentos aditivos en la ventana de congestión. En un estudio comparativo de varios TCP CCA , TCP Vegas pareció ser el más fluido, seguido de TCP CUBIC. [18]
TCP Vegas no se implementó ampliamente fuera del laboratorio de Peterson, pero se seleccionó como 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 congestión de aumento 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 gruesas (LFN). [23] BIC se utiliza de forma predeterminada en los kernels de Linux 2.6.8 a 2.6.18. [ cita necesaria ]
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 kernels de Linux desde la versión 2.6.19.
Agile-SD es un CCA basado en Linux que está diseñado para el kernel de Linux real. 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 con bajo retardo de ancho de banda), como redes de área local o redes de fibra óptica, especialmente cuando el tamaño del 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 un 55% en términos de rendimiento medio.
Westwood+ es una modificación de TCP Reno exclusiva para el remitente que optimiza el rendimiento del control de congestión de TCP en redes cableadas e inalámbricas . TCP Westwood+ se basa en la estimación del ancho de banda de un extremo a otro 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 confirmaciones duplicadas o un tiempo de espera. El ancho de banda se estima promediando la tasa de devolución de paquetes de acuse de recibo. A diferencia de TCP Reno, que reduce ciegamente a la mitad la ventana de congestión después de tres ACK 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 de los enlaces inalámbricos y mejora la equidad en las redes cableadas. [ cita necesaria ]
TCP compuesto es una implementación de TCP de Microsoft que mantiene dos ventanas de congestión diferentes simultáneamente, con el objetivo de lograr un buen rendimiento en 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 y Linux .
La reducción de velocidad proporcional de TCP (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 esté lo más cerca posible del umbral de inicio lento. En las pruebas realizadas por Google , PRR dio como resultado 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 kernels 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 congestión y tasas de transmisión más bajas, BBR, como TCP Vegas, está basado en modelos. El algoritmo utiliza el ancho de banda máximo y el tiempo 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 acuse de recibo acumulativo o selectivo de entrega de paquetes produce una muestra de velocidad que registra la cantidad de datos entregados durante el intervalo de tiempo entre la transmisión de un paquete de datos y el acuse de recibo de ese paquete. [29]
Cuando se implementó en YouTube , BBRv1 arrojó un promedio de un 4% más de rendimiento de red 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]
Se cuestiona la equidad de BBR versión 1 (BBRv1) con las transmisiones que no son de BBR. Si bien la presentación de Google muestra que BBRv1 coexiste bien con CUBIC, [28] investigadores como Geoff Huston y Hock, Bless y Zitterbart lo encontraron injusto para otras corrientes y no escalable. [33] Hock et al. También encontró "algunos problemas inherentes graves, como mayores retrasos en las colas, injusticia y pérdida masiva de paquetes" en la implementación 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 (consulte la figura). 16 en [11] ).
La versión 2 intenta abordar la cuestión de la injusticia cuando se opera junto con una gestión de congestión basada en pérdidas como CUBIC. [35] En BBRv2, el modelo utilizado por BBRv1 se aumenta 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 en ocasiones tener un rendimiento menor que BBRv1, generalmente se considera que tiene un mejor rendimiento . [ cita necesaria ]
La versión 3 (BBRv3) corrige dos errores en BBRv2 (fin prematuro del sondeo del ancho de banda, convergencia del ancho de banda) y realiza algunos ajustes del rendimiento. También existe una variante, denominada BBR.Swift, optimizada para enlaces internos del centro de datos: utiliza network_RTT (excluyendo el retardo del receptor) como principal señal de control de congestión. [36]
Cellular Controlled Delay TCP (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 , videoconferencias , juegos en línea , sistemas de comunicación vehicular , etc. en un entorno altamente dinámico como el LTE actual y las futuras redes celulares 5G . C2TCP funciona como un complemento además de TCP basado en pérdidas (por ejemplo, Reno, NewReno, CUBIC , BIC , ...), solo es necesario instalarlo en el lado del servidor y limita el retraso promedio de los paquetes a los retrasos deseados establecidos por las aplicaciones.
Investigadores de la Universidad de Nueva York [37] demostraron que C2TCP supera el rendimiento de 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 retraso 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 con 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 el retraso de la pérdida utilizando un mecanismo novedoso llamado función de ponderación correlacionada con la ventana (WWF). Tiene un alto nivel de elasticidad para hacer frente a diferentes características de la red sin necesidad de 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 el banco de pruebas NS-2. Elastic-TCP mejora significativamente el rendimiento total en términos de rendimiento promedio, índice de pérdidas y retraso. [38]
Soheil Abbasloo et al. propuso NATCP (TCP asistido por red) [13] un controvertido [ ¿según quién? ] Diseño TCP dirigido a la computación de borde de acceso múltiple (MEC). La idea clave de NATCP es que si se conocieran de antemano las características de la red, 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 acercar el rendimiento de TCP al 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 implementado más comúnmente, [ cita necesaria ] La compatibilidad con SACK es muy común [ cita necesaria ] y es una extensión de Reno/New Reno. La mayoría de las demás son propuestas en competencia que aún necesitan evaluación. A partir de 2.6.8, el kernel de 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 utiliza CUBIC como algoritmo predeterminado. [51] La versión anterior usaba New Reno. Sin embargo, FreeBSD admite otras opciones. [52]
Cuando aumenta el producto por flujo del ancho de banda y la latencia, independientemente del esquema de cola, TCP se vuelve ineficiente y propenso a la inestabilidad. Esto se vuelve cada vez más importante 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 de TCP desde fuera de la capa TCP. La mayoría de los esquemas de congestión de TCP funcionan internamente. Además, iTCP 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 buen 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 cuenta con otras mejoras para detectar con precisión la pérdida de paquetes, evitando el tiempo de espera de retransmisión; y acelerar y controlar el tráfico entrante (descarga). [54]
Los CCA pueden clasificarse en relación con el conocimiento de la red, es decir, el grado en que estos algoritmos son conscientes del estado de la red. Consta de tres categorías principales: cuadro negro, cuadro gris y cuadro verde. [55]
Los algoritmos de caja negra ofrecen métodos ciegos de control de la congestión. Operan únicamente con la retroalimentación binaria recibida en caso de congestión y no asumen ningún conocimiento sobre el estado de las redes que administran.
Los algoritmos de caja gris utilizan instancias de tiempo [ se necesita aclaración ] para obtener mediciones y estimaciones de ancho de banda, contención de 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 para 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 web}}: CS1 maint: archived copy as title (link)