Control de congestión TCP

Los algoritmos TCP Tahoe y Reno recibieron su nombre retrospectivamente de las versiones o variantes del sistema operativo 4.3BSD en las que aparecieron por primera vez (las cuales, 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 (creado para dar soporte al miniordenador CCI Power 6/32 "Tahoe" ) y posteriormente se puso a disposición de usuarios que no eran licenciatarios de AT&T como parte de 4.3BSD Networking Release 1; esto garantizó 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:

• Tahoe: si se reciben tres ACK duplicados (es decir, cuatro ACK que confirman el mismo paquete, que no se adjuntan a los datos y no cambian la ventana anunciada del receptor), Tahoe realiza una retransmisión rápida, establece el umbral de inicio lento a la mitad de la ventana de congestión actual, reduce la ventana de congestión a 1 MSS y vuelve al estado de inicio lento. ^{[ 17 ]}
• Reno: si se reciben tres ACK duplicados, Reno realizará una retransmisión rápida y omitirá la fase de inicio lento reduciendo a la mitad la ventana de congestión (en lugar de establecerla en 1 MSS como Tahoe), estableciendo el ssthresh igual a la nueva ventana de congestión y entrando en una fase llamada recuperación rápida . ^{[ 18 ]}

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.

TCP New Reno, definido por el RFC 6582 (que deja obsoletas las definiciones anteriores en los 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 recibe, se envía un nuevo paquete no enviado del final de la ventana de congestión.

La diferencia con Reno radica en que New Reno no reduce a la mitad el umbral ssthresh inmediatamente, lo que podría disminuir demasiado la ventana si se producen múltiples pérdidas de paquetes. No finaliza la recuperación rápida ni restablece el umbral ssthresh hasta que reconoce todos los datos.

Tras la retransmisión, los datos recién confirmados presentan dos casos:

• Acuses de recibo completos: El ACK confirma todos los segmentos intermedios enviados; el ssthresh no se puede cambiar y el cwnd se puede establecer en ssthresh.
• Acuses de recibo parciales: El ACK no confirma la recepción de todos los datos. Esto significa que puede producirse otra pérdida; si está permitido, se retransmitirá el primer segmento no confirmado.

Utiliza una variable llamada `recover` para registrar la cantidad de datos que deben recuperarse. Tras un tiempo de espera de retransmisión, registra el número de secuencia más alto transmitido en la variable `recover` y finaliza el 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érdida de paquetes, sino que estos se reordenan en más de tres posiciones. En este caso, New Reno entra erróneamente en modo de recuperación rápida. Al recibirse el paquete reordenado, se envían inmediatamente retransmisiones duplicadas e innecesarias.

El nuevo Reno funciona tan bien como SACK con bajas tasas de error de paquetes y supera sustancialmente a Reno con altas tasas de error. ^{[ 19 ]}

Hasta mediados de la década de 1990, todos los tiempos de espera y las demoras de ida y vuelta 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 los tiempos de espera se configuraban y las demoras de ida y vuelta se medían 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 2012 de varios TCP CCA , TCP Vegas resultó ser el más fluido, seguido de TCP CUBIC. ^{[ 20 ]}

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. ^{[ 21 ]}

TCP Hybla ^{[ 22 ] [ 23 ]} 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. ^{[ 24 ]}

El control de congestión de incremento 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 gordas (LFN). ^{[ 25 ]} BIC se utiliza por defecto en los núcleos de Linux de la versión 2.6.8 a la 2.6.18.

CUBIC es una variante menos agresiva y más sistemática de BIC, en la que la ventana es una función cúbica del tiempo transcurrido desde el último evento de congestión, con el punto de inflexión establecido en la ventana anterior al evento. CUBIC se utiliza por defecto en los núcleos de Linux desde la versión 2.6.19.

Agile-SD es un CCA basado en Linux diseñado para el kernel de Linux real. Es un algoritmo del lado del receptor que emplea un enfoque basado en pérdidas mediante 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 con bajo producto ancho de banda-retardo), como redes de área local o redes de fibra óptica, especialmente cuando el tamaño del búfer aplicado es pequeño. ^{[ 26 ]} 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 afecta al remitente y que optimiza el rendimiento del control de congestión TCP tanto en redes cableadas como inalámbricas . TCP Westwood+ se basa en la estimación del ancho de banda de extremo a extremo para establecer la ventana de congestión y el umbral de inicio lento tras un episodio de congestión, es decir, tras tres acuses de recibo duplicados o un tiempo de espera agotado. El ancho de banda se estima promediando la tasa de paquetes de acuse de recibo devueltos. A diferencia de TCP Reno, que reduce a la mitad la ventana de congestión automáticamente tras 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 produce la congestión. En comparación con Reno y New Reno, Westwood+ aumenta significativamente el rendimiento en enlaces inalámbricos y mejora la equidad en redes cableadas.

El TCP compuesto es una implementación de Microsoft del TCP que mantiene dos ventanas de congestión diferentes simultáneamente, con el objetivo de lograr un buen rendimiento en LFN sin comprometer la equidad . Se ha implementado ampliamente en versiones de Windows desde Microsoft Windows Vista y Windows Server 2008 , y también se ha adaptado a versiones anteriores de Microsoft Windows y Linux .

La reducción proporcional de la tasa TCP (PRR) ^{[ 27 ]} 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 %. ^{[ 28 ]} PRR está disponible en los núcleos de Linux desde la versión 3.2. ^{[ 29 ]}

El algoritmo de detección de cuello de botella de ancho de banda y tiempo de propagación de ida y vuelta (BBR) es un CCA desarrollado en Google en 2016. ^{[ 30 ]} Si bien la mayoría de los CCA se basan en la pérdida, ya que dependen de la pérdida de paquetes para detectar la congestión y las tasas de transmisión más bajas, BBR, al igual que TCP Vegas , se basa en un modelo. El algoritmo utiliza el ancho de banda máximo y el tiempo de ida y vuelta en el que la red entregó el último vuelo de paquetes de datos salientes para construir un modelo de la red. Cada acuse de recibo 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 acuse de recibo de ese paquete. ^{[ 31 ]}

Cuando se implementó en YouTube , BBRv1 produjo un rendimiento de red promedio un 4 % mayor y hasta un 14 % en algunos países. ^{[ 32 ]} BBR ha estado disponible para Linux TCP desde Linux 4.9. ^{[ 33 ]} También está disponible para QUIC . ^{[ 34 ]}

La equidad de BBR versión 1 (BBRv1) para flujos que no son BBR es cuestionada. Si bien la presentación de Google muestra que BBRv1 coexiste bien con CUBIC, ^{[ 30 ]} investigadores como Geoff Huston y Hock, Bless y Zitterbart encontraron que era injusto para otros flujos y no escalable. ^{[ 35 ]} Hock et al. también encontraron "algunos problemas inherentes graves, como mayores retrasos en la cola, inequidad y pérdida masiva de paquetes" en la implementación de BBR de Linux 4.9. ^{[ 36 ]} 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 inequidad. 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 al flujo CUBIC y obtener todo el ancho de banda del enlace (ver figura 18 en ^{[ 11 ]} ).

La versión 2 intenta abordar el problema de la injusticia cuando opera junto con la administración de congestión basada en pérdidas como CUBIC. ^{[ 37 ]} 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 Explícita de Congestión (ECN). ^{[ 38 ]} Si bien BBRv2 puede tener a veces un rendimiento menor que BBRv1, generalmente se considera que tiene un mejor rendimiento efectivo . Windows 11, versión 24H2 y Windows Server 2025 tenían soporte para BBRv2, pero es posible que no lo habiliten de forma predeterminada.

La versión 3 (BBRv3) corrige dos errores de BBRv2 (fin 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 retardo del receptor) como señal principal de control de congestión. ^{[ 38 ]}

El protocolo TCP de retardo controlado celular (C2TCP) ^{[ 11 ] [ 12 ]} surgió debido a la falta de un enfoque TCP flexible de extremo a extremo que pudiera satisfacer diversos requisitos de QoS para diferentes aplicaciones sin requerir cambios en los dispositivos de red. C2TCP busca satisfacer los requisitos de latencia ultrabaja y ancho de banda alto 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 las futuras redes celulares 5G . 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 retardo promedio de los paquetes se ajuste a los retardos deseados establecidos por las aplicaciones.

Investigadores de la NYU ^{[ 39 ]} 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, C2TCP reduce el retardo promedio de los paquetes en aproximadamente un 250 %, un 900 % y un 700 %, respectivamente, en diversos 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 diseñado para el kernel de Linux. Es un algoritmo del lado del receptor que emplea un enfoque basado en pérdida-retardo mediante un mecanismo novedoso llamado función de ponderación correlacionada con ventana (WWF). Posee un alto nivel de elasticidad para gestionar diferentes características de red sin necesidad de ajuste manual. 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) mediante el simulador y banco de pruebas NS-2. Elastic-TCP mejora significativamente el rendimiento total en términos de rendimiento promedio, relación de pérdida y retardo. ^{[ 40 ]}

Soheil Abbasloo et al. propusieron NATCP (Network-Assisted TCP), ^{[ 13 ]} un diseño de TCP controvertido 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 llevar 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 ] [ 41 ]}

• TCP rápido
• TCP FAST generalizado ^{[ 42 ]}
• H-TCP
• Centro de datos TCP
• TCP de alta velocidad
• HSTCP-LP ^{[ 43 ]}
• LEDBAT
• TCP-Illinois
• TCP-LP ^{[ 43 ]}
• TCP SACK
• TCP escalable
• TCP Veno ^{[ 44 ]}
• Westwood
• XCP ^{[ 45 ]}
• YeAH-TCP ^{[ 46 ]}
• TCP-FIT ^{[ 47 ]}
• Prevención de la congestión con intervalo de tiempo normalizado (CANIT) ^{[ 48 ]}
• Control de congestión de redes neuronales no lineales basado en algoritmo genético para redes TCP/IP ^{[ 49 ]}
• D-TCP ^{[ 50 ]}
• NexGen D-TCP ^{[ 51 ]}
• Copa ^{[ 52 ]}

TCP New Reno fue el algoritmo más comúnmente implementado, el soporte para SACK es muy común y es una extensión de Reno/New Reno. La mayoría de los demás son propuestas competidoras que aún necesitan evaluación. A partir de la versión 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, a partir de la versión 14.X, también utiliza CUBIC como algoritmo predeterminado. ^{[ 53 ]} Las versiones anteriores utilizaban New Reno. Sin embargo, FreeBSD admite varias otras opciones. ^{[ 54 ]}

Cuando el producto del ancho de banda y la latencia por flujo aumenta, independientemente del esquema de colas, TCP se vuelve ineficiente y propenso a la inestabilidad. Esto cobra cada vez más importancia a medida que Internet evoluciona para incorporar enlaces ópticos de muy alto ancho de banda.

TCP Interactive (iTCP) ^{[ 55 ]} permite que las aplicaciones se suscriban a eventos TCP y respondan en consecuencia, lo que posibilita diversas extensiones funcionales de TCP desde fuera de la capa TCP. La mayoría de los esquemas de congestión de TCP funcionan internamente. iTCP también permite que las aplicaciones avanzadas participen directamente en el control de la congestión, por ejemplo, para controlar la tasa de generación de fuentes.

Zeta-TCP detecta la congestión a partir de medidas de latencia y tasa de pérdida. Para maximizar el rendimiento útil , Zeta-TCP aplica diferentes estrategias de retroceso de ventana de congestión según la probabilidad de congestión. También cuenta con 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 (de descarga). ^{[ 56 ]}

• TCP de alta velocidad ^{[ 58 ]}
• El protocolo BIC TCP (Binary Increase Congestion Control Protocol) utiliza un incremento cóncavo de la tasa de la fuente después de cada evento de congestión hasta que la ventana sea igual a la anterior al evento, con el fin de maximizar el tiempo de uso completo de la red. Posteriormente, realiza sondeos de forma agresiva.
• TCP CUBIC : una variante menos agresiva y más sistemática de BIC, en la que la ventana es una función cúbica del tiempo transcurrido desde el último evento de congestión, con el punto de inflexión establecido en la ventana anterior al evento.
• AIMD-FC (aumento aditivo, disminución multiplicativa con convergencia rápida), una mejora de AIMD. ^{[ 59 ]}
• Mecanismos binomiales
• Protocolo SIMD
• GAIMD

• TCP Vegas estima el retardo de cola y aumenta o disminuye linealmente la ventana para que se ponga en cola un número constante de paquetes por flujo en la red. Vegas implementa la equidad proporcional.
• FAST TCP logra el mismo equilibrio que Vegas, pero utiliza un control proporcional en lugar de un aumento lineal, y reduce intencionadamente la ganancia a medida que aumenta el ancho de banda con el objetivo de garantizar la estabilidad.
• TCP BBR: estima el retardo de la cola, pero utiliza un incremento exponencial. Ralentiza intencionadamente de forma periódica para garantizar la equidad y reducir el retardo.
• TCP-Westwood (TCPW): una pérdida provoca que la ventana se restablezca a la estimación del remitente del producto ancho de banda-retardo (el RTT medido más pequeño multiplicado por la tasa observada de recepción de ACKs). ^{[ 60 ]}
• C2TCP ^{[ 12 ] [ 11 ]}
• TFRC ^{[ 61 ]}
• TCP-Real
• TCP-Jersey

• Mecanismo bimodal : Mecanismo bimodal para evitar y controlar la congestión .
• Métodos de señalización implementados por los enrutadores
  • La detección temprana aleatoria (RED) descarta paquetes al azar en proporción al tamaño de la cola del enrutador, lo que provoca una disminución multiplicativa en algunos flujos.
  • Notificación explícita de congestión (ECN)
• Control de congestión asistido por la red
  • NATCP ^{[ 13 ]} – TCP asistido por red utiliza retroalimentación explícita fuera de banda que indica el RTT mínimo de la red y la capacidad del enlace de acceso celular.
  • El protocolo de control de congestión de estructura variable (VCP) utiliza dos bits ECN para retroalimentar explícitamente el estado de congestión de la red. También incluye un algoritmo del lado del host final.

Los siguientes algoritmos requieren que se agreguen campos personalizados a la estructura del paquete TCP:

• Protocolo de Control Explícito (XCP): los paquetes XCP llevan una cabecera de congestión con un campo de retroalimentación que indica el aumento o la disminución de la ventana de congestión del remitente. Los enrutadores XCP establecen el valor de retroalimentación explícitamente para mayor eficiencia y equidad. ^{[ 62 ]}
• MaxNet : utiliza un único campo de encabezado que contiene el nivel máximo de congestión de cualquier enrutador en la ruta del flujo. La tasa se establece en función de esta congestión máxima, lo que resulta en una equidad máxima-mínima . ^{[ 63 ]}
• JetMax , al igual que MaxNet, responde únicamente a la señal de congestión máxima, pero también transporta otros campos de sobrecarga.

• Kurose, James ; Ross, Keith (2008). Redes informáticas: Un enfoque descendente (4.ª  ed.). Addison Wesley. ISBN 978-0-13-607967-5.
• Kurose, James ; Ross, Keith (2012). Redes informáticas: Un enfoque descendente (6.ª  ed.). Pearson. ISBN 978-0-13-285620-1.
• Abbasloo, Soheil; Xu, Yang; Chao, H. Jonathon; Shi, Hang; Kozat, Ulas C.; Ye, Yinghua (2019). "Hacia un rendimiento óptimo con TCP asistido por red en el borde móvil" . 2.º Taller USENIX sobre temas candentes en computación de borde (HotEdge 19) . Renton, WA: Asociación USENIX.
• Afanasyev, A.; N. Tilley; P. Reiher; L. Kleinrock (2010). "Control de congestión de host a host para TCP" (PDF) . IEEE Communications Surveys and Tutorials . 12 (3): 304– 342. CiteSeerX 10.1.1.228.3080 . doi : 10.1109/SURV.2010.042710.00114 . S2CID 8638824 .  
• Jacobson, Van ; Karels, Michael J. (noviembre de 1988). "Evitación y control de la congestión" (PDF) . ACM SIGCOMM Computer Communication Review . 18 (4): 314–329 . doi : 10.1145/52325.52356 .