La convención de nomenclatura para algoritmos de control de congestión (CCAs) puede haberse originado en un artículo de 1996 de Kevin Fall y Sally Floyd.

La siguiente es una clasificación posible de acuerdo con las siguientes propiedades:

1. el tipo y la cantidad de retroalimentación recibida de la red
2. capacidad de despliegue incremental en el Internet actual
3. el aspecto de rendimiento que pretende mejorar: redes de productos con retardo de ancho de banda alto (B); enlaces con pérdida (L); equidad (F); ventaja para flujos cortos (S); enlaces de velocidad variable (V); velocidad de convergencia (C)
4. el criterio de equidad que utiliza

Algunos mecanismos conocidos para evitar la congestión se clasifican según este esquema de la siguiente manera:

Variant	Feedback	Required changes	Benefits	Fairness
(New) Reno	Loss	—	—	Delay
Vegas	Delay	Sender	Less loss	Proportional
High Speed	Loss	Sender	High bandwidth
BIC	Loss	Sender	High bandwidth
CUBIC	Loss	Sender	High bandwidth
C2TCP	Loss/Delay	Sender	Ultra-low latency and high bandwidth
NATCP	Multi-bit signal	Sender	Near Optimal Performance
Elastic-TCP	Loss/Delay	Sender	High bandwidth/short & long-distance
Agile-TCP	Loss	Sender	High bandwidth/short-distance
H-TCP	Loss	Sender	High bandwidth
FAST	Delay	Sender	High bandwidth	Proportional
Compound TCP	Loss/Delay	Sender	High bandwidth	Proportional
Westwood	Loss/Delay	Sender	L
Jersey	Loss/Delay	Sender	L
BBR	Delay	Sender	BLVC, Bufferbloat
CLAMP	Multi-bit signal	Receiver, Router	V	Max-min
TFRC	Loss	Sender, Receiver	No Retransmission	Minimum delay
XCP	Multi-bit signal	Sender, Receiver, Router	BLFC	Max-min
VCP	2-bit signal	Sender, Receiver, Router	BLF	Proportional
MaxNet	Multi-bit signal	Sender, Receiver, Router	BLFSC	Max-min
JetMax	Multi-bit signal	Sender, Receiver, Router	High ancho de banda	Max-min
ROJO	Pérdida	Router	Retraso reducido
ECN	Señal de un solo bit	Remitente, receptor, Router	Pérdida reducida

TCP Tahoe y RenoEdit

Los algoritmos TCP Tahoe y Reno recibieron el nombre retrospectivamente de las versiones o sabores del sistema operativo 4.3 BSD en el que aparecieron por primera vez (que a su vez recibieron el nombre del Lago Tahoe y la cercana ciudad de Reno, Nevada). El algoritmo Tahoe apareció por primera vez en 4.3 BSD-Tahoe (que se hizo para soportar la minicomputadora CCI Power 6/32 «Tahoe»), y más tarde se puso a disposición de los licenciatarios no AT&T como parte de la versión 1 de red 4.3 BSD; esto aseguró su amplia distribución e implementación. Se hicieron mejoras en 4.3 BSD-Reno y posteriormente se lanzaron al público como Networking Release 2 y más tarde 4.4 BSD-Lite.

Mientras que ambos consideran el tiempo de espera de retransmisión (RTO) y los ACKs duplicados como eventos de pérdida de paquetes, el comportamiento de Tahoe y Reno difiere principalmente en cómo reaccionan a los ACKs duplicados:

• Tahoe: si se reciben tres ACKs duplicados (es decir, cuatro ACKs que reconocen el mismo paquete, que no están empaquetados en 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 se restablece al estado de inicio lento.
• Reno: si se reciben tres ACKs duplicados, Reno realizará una retransmisión rápida y saltará la fase de inicio lento al reducir a la mitad la ventana de congestión (en lugar de configurarla a 1 MSS como Tahoe), establecer el umbral de inicio lento igual a la nueva ventana de congestión y entrar en una fase llamada recuperación rápida.

Tanto en Tahoe como en Reno, si un ACK se agota (tiempo de espera de RTO), se usa inicio lento y ambos algoritmos reducen la ventana de congestión a 1 MSS.

TCP VegasEdit

Hasta mediados de la década de 1990, todos los tiempos de espera establecidos por TCP y los retrasos medidos de ida y vuelta 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 (el nombre de Las Vegas, la ciudad más grande de Nevada) en el que se establecieron tiempos de espera y se midieron los retrasos de ida y vuelta para cada paquete en el búfer de transmisión. Además, TCP Vegas utiliza aumentos aditivos en la ventana de congestión. En un estudio comparativo de varios CCA TCP, TCP Vegas parecía ser el más suave seguido por TCP CÚBICO.

TCP Vegas no se implementó ampliamente fuera del laboratorio de Peterson, pero se seleccionó como el método de control de congestión predeterminado para el firmware v24 SP2 de DD-WRT.

TCP New RenoEdit

TCP New Reno, definido por RFC 6582 (que desactiva 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. Por cada ACK que progresa parcialmente en el espacio de secuencia, el remitente asume que el ACK apunta a un nuevo agujero, y se envía el siguiente paquete más allá del número de secuencia ACKed.

Debido a que el tiempo de espera se restablece cada vez que hay progreso en el búfer de transmisión, el Nuevo Reno puede llenar agujeros grandes, o múltiples agujeros, en el espacio de secuencia, al igual que el SACO TCP. Debido a que New Reno puede enviar nuevos paquetes al final de la ventana de congestión durante la recuperación rápida, se mantiene un alto rendimiento durante el proceso de llenado de orificios, incluso cuando hay varios orificios, de varios paquetes cada uno. Cuando TCP entra en recuperación rápida, registra el número de secuencia de paquetes no reconocidos más alto pendiente. Cuando se reconoce este número de secuencia, TCP vuelve al estado de evitación de congestión.

Un problema ocurre 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 entra por error en una recuperación rápida. Cuando se entrega el paquete reordenado, se produce el progreso del número de secuencia ACK y desde allí hasta el final de la recuperación rápida, todo el progreso del número de secuencia produce una retransmisión duplicada e innecesaria que se activa inmediatamente.

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.

TCP HyblaEdit

TCP Hybla tiene como objetivo eliminar las penalizaciones a las conexiones TCP que incorporan 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.

TCP BICEdit

El control de congestión de aumento binario (BIC) es una implementación TCP con un CCA optimizado para redes de alta velocidad con alta latencia, conocidas como redes long fat. BIC se usa por defecto en los núcleos de Linux 2.6.8 a 2.6.18.

TCP Cubiceditar

CÚBICO es una derivada 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 usa por defecto en los núcleos de Linux entre las versiones 2.6.19 y 3.2.

TCPEdit Agile-SD

Agile-SD es un CCA basado en Linux que está diseñado para el núcleo 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 de corta distancia (redes de bajo BDP), como redes de área local o redes de fibra óptica, especialmente cuando el tamaño del búfer aplicado es pequeño. 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 promedio.

TCP Westwood + Edit

Westwood + es una modificación de TCP Reno solo para el remitente que optimiza el rendimiento del control de congestión TCP en redes cableadas e inalámbricas. TCP Westwood + se basa en una estimación de 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 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. En contraste con TCP Reno, que reduce a la mitad a ciegas la ventana de congestión después de tres ACKs duplicados, TCP Westwood+ establece adaptativamente 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 a través de enlaces inalámbricos y mejora la equidad en las redes cableadas.

TCPEdit compuesto

TCP compuesto 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 LFN sin perjudicar la equidad. Se ha implementado ampliamente en versiones de Windows desde Microsoft Windows Vista y Windows Server 2008 y se ha portado a versiones anteriores de Microsoft Windows, así como a Linux.

Reducción de velocidad proporcionaleditar

La reducción de velocidad proporcional TCP (PRR) 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, el PRR resultó en una reducción del 3-10% en la latencia promedio y los tiempos de espera de recuperación se redujeron en un 5%. PRR está disponible en los núcleos de Linux desde la versión 3.2.

BREDIT TCP

Ancho de banda de cuello de botella y tiempo de propagación de ida y vuelta (BBR) es un CCA desarrollado en Google en 2016. Si bien la mayoría de las 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, al igual que TCP Vegas, se basa 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 reconocimiento acumulativo o selectivo de la 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 reconocimiento de ese paquete. A medida que los controladores de interfaz de red evolucionan de un rendimiento de megabits por segundo a gigabits por segundo, la latencia asociada con bufferbloat en lugar de la pérdida de paquetes se convierte en un marcador más confiable del rendimiento máximo, haciendo que las CCA basadas en modelos que proporcionan un rendimiento más alto y una latencia más baja, como BBR, una alternativa más confiable a los algoritmos basados en pérdidas más populares como TCP CUBIC.

BBR ha estado disponible para Linux TCP desde Linux 4.9. También está disponible para QUIC.

La versión 1 de BBR (BBRv1) es eficiente y rápida, pero su imparcialidad para transmisiones que no son de BBR está en disputa. Cuando se implementó en YouTube, BBRv1 produjo un promedio de un 4% más de rendimiento de red y hasta un 14% en algunos países. Si bien la presentación de Google muestra que BBRv1 coexiste bien con CUBIC, investigadores como Geoff Huston y Hock, Bless y Zitterbart lo encuentran injusto para otras transmisiones y no escalable. Hock et al también encontraron «algunos problemas inherentes graves, como el aumento de los retrasos en las colas, la injusticia y la pérdida masiva de paquetes» en la implementación de BBR de Linux 4.9.

Soheil Abbasloo et al. (autores de C2TCP) muestran que el BBRv1 no funciona bien en entornos dinámicos como las redes celulares. También han demostrado que BBR tiene un problema de injusticia. Por ejemplo, cuando un flujo CÚBICO (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 CÚBICO y obtener todo el ancho de banda del enlace (consulte la figura 18 en ).

La versión 2 intenta abordar el problema de la injusticia cuando se opera junto con la gestión de la congestión basada en pérdidas, como CUBIC. En BBRv2, el modelo utilizado por BBRv1 se ha ampliado para incluir información sobre la pérdida de paquetes e información de la Notificación Explícita de Congestión (ECN). Mientras que el BBRv2 a veces puede tener un rendimiento menor que el BBRv1, generalmente se considera que tiene un mejor rendimiento.

C2TCPEdit

Cellular Controlled Delay TCP (C2TCP) fue motivado por la falta de un enfoque TCP flexible de extremo a extremo que pueda satisfacer varios requisitos de QoS de diferentes aplicaciones sin requerir cambios en los dispositivos de red. El objetivo de C2TCP es satisfacer los requisitos de latencia ultrabaja y ancho de banda elevado de aplicaciones como la realidad virtual, las videoconferencias, los juegos en línea, los sistemas de comunicación vehicular, etc. en un entorno altamente dinámico, como las redes 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,…) y hace que el retraso promedio de los paquetes esté limitado a los retrasos deseados establecidos por las aplicaciones.

Los investigadores de la NYU mostraron que C2TCP supera el rendimiento de retardo/fluctuación de varios esquemas TCP de última generación. Por ejemplo, mostraron que en comparación con BBR, CUBIC y Westwood en promedio, C2TCP disminuye el retraso promedio de los paquetes en aproximadamente un 250%, 900% y 700%, respectivamente, en varios entornos de red celular.

Solo es necesario instalar C2TCP en el lado del servidor.

Elastic-tcpeditar

Elastic-TCP fue propuesto en febrero de 2019 por Mohamed A. Alrshah et al. aumentar la utilización del ancho de banda en redes de alta BDP para admitir aplicaciones recientes como computación en la nube, transferencia de big data, IoT, etc. Es un CCA basado en Linux que está diseñado para el núcleo Linux. Es un algoritmo del lado del receptor que emplea un enfoque basado en la Pérdida y el retraso utilizando un mecanismo novedoso, llamado Función de Ponderación correlacionada con Ventanas (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 de Linux) y TCP-BBR (el predeterminado de Linux 4.9 de Google) utilizando 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érdidas y retardo.

NATCP / NACubicEdit

Recientemente, Soheil Abbasloo et. al. propuesta de NATCP (TCP asistido por red) un controvertido diseño TCP dirigido a redes móviles perimetrales como 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 una mejor manera. Por lo tanto, NATCP emplea las características y propiedades disponibles en las arquitecturas celulares basadas en MEC actuales para acercar el rendimiento de TCP al rendimiento óptimo. NATCP utiliza una 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 tarifas de envío. Como muestran los resultados preliminares, NATCP supera a los esquemas TCP de última generación al lograr al menos 2 veces más potencia (definida como Rendimiento/Retardo). NATCP reemplaza el esquema TCP tradicional en el remitente.

Para lidiar con el problema de compatibilidad con versiones anteriores, propusieron otra versión llamada NACubic. NACubic es un diseño compatible con versiones anteriores, que no requiere ningún cambio en TCP en los nodos conectados. NACubic emplea la retroalimentación recibida e impone un límite en la ventana de congestión (CWND) y la tasa de estimulación según sea necesario.

Otras TCP para evitar la congestión algorithmsEdit

• TCP RÁPIDO
• Generalizada TCP RÁPIDO
• H-TCP
• Centro de Datos TCP
• Alta Velocidad TCP
• HSTCP-LP
• TCP-Illinois
• TCP-LP
• TCP SACK
• Escalable TCP
• TCP Veno
• Westwood
• XCP
• Sí-TCP
• TCP-FIT
• control de Congestión con Normalizado Intervalo de Tiempo (CANIT)
• No-lineal de la red neuronal de control de congestión basado en un algoritmo genético para redes TCP/IP

TCP New Reno fue el más frecuentemente aplicado algoritmo, el soporte de SACK es muy común y es una extensión de Reno / New Reno. La mayoría de las demás son propuestas que compiten entre sí y 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ó de nuevo a CÚBICA en la versión 2.6.19. FreeBSD usa New Reno como algoritmo predeterminado. Sin embargo, es compatible con una serie de otras opciones.

Cuando el producto por flujo de ancho de banda y latencia aumenta, 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) permite a las aplicaciones suscribirse a eventos TCP y responder en consecuencia, habilitando varias extensiones funcionales a TCP desde la capa TCP externa. La mayoría de los esquemas de congestión TCP funcionan internamente. iTCP, además, 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 las congestiones a partir de las medidas de latencia y tasa de pérdida, y aplica diferentes estrategias de retroceso de la ventana de congestión basadas en la probabilidad de las congestiones para maximizar el rendimiento. También tiene un par de otras mejoras para detectar con precisión las pérdidas de paquetes, evitar la retransmisión de tiempo de espera de retransmisión y acelerar/controlar el tráfico de entrada (descarga).