Control de congestión TCP

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 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á.

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 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 confirmaciones duplicadas, puede estar razonablemente seguro de que el segmento que contiene los datos que siguieron al último byte en orden especificado en la confirmación 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.

Algoritmos

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.

La siguiente es una posible clasificación según las siguientes propiedades:

1. el tipo y la cantidad de comentarios recibidos de la red
2. Capacidad de despliegue incremental en Internet actual
3. el aspecto del rendimiento que pretende mejorar: redes de productos de alta velocidad de ancho de banda (B); enlaces perdidos (L); equidad (F); ventaja a flujos cortos (S); enlaces de rango variable (V); velocidad de convergencia (C)
4. el criterio de equidad que utiliza

Este esquema clasifica algunos mecanismos conocidos para evitar la congestión de la siguiente manera:

TCP Tahoe y Reno

Los algoritmos TCP Tahoe y Reno recibieron nombres retrospectivos de las versiones o versiones del sistema operativo 4.3BSD en las 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.3BSD-Tahoe (que fue creado para admitir la minicomputadora CCI Power 6/32 "Tahoe") y luego estuvo disponible para licenciatarios que no eran de AT&T como parte del 4.3 Redes BSD Versión 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:

• Tahoe: si se reciben tres ACKs duplicados (es decir, cuatro ACKs reconociendo el mismo paquete, que no están retrocedidos en 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 se reinicia para iniciar el estado lento.
• Reno: si se reciben tres ACKs duplicados, Reno realizará una retransmisión rápida y saltará la fase de inicio lento por en lugar de reducir la ventana de congestión (en lugar de configurarlo a 1 MSS como Tahoe), estableciendo el ssthresh igual a la nueva ventana de congestión, e introducir una fase llamada recuperación rápida.

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 Nuevo Reno

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:

• Reconocimientos completos: El ACK reconoce todos los segmentos intermedios enviados, el ssthresh no se puede cambiar, cwnd se puede establecer a ssthresh
• Reconocimientos parciales: El ACK no reconoce todos los datos. Significa que puede ocurrir otra pérdida, retransmitir el primer segmento no reconocido si está permitido

Utiliza una variable llamada "recuperar" para registrar cuántos datos deben recuperarse. 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.

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 Vegas

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 CCA de TCP, TCP Vegas pareció ser el más fluido, seguido de TCP CUBIC.

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.

TCP Hybla

TCP Hybla 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.

TCP BIC

El control de la congestión de aumento binario (BIC) es una implementación TCP con un CCA optimizado para redes de alta velocidad con alta latencia, conocida como redes de grasa larga (LFNs). BIC se utiliza por defecto en núcleos Linux 2.6.8 a 2.6.18.

TCP CUBIC

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.

TCP ágil-SD

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. 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.

TCP Westwood+

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.

TCP compuesto

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.

Reducción de tarifa proporcional de TCP

La reducción de tasa proporcional (PRR) de TCP 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 %. PRR está disponible en los kernels de Linux desde la versión 3.2.

TCP BBR

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. Si bien la mayoría de los CCA se basan en pérdidas, es decir, 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.

Cuando se implementó en YouTube, BBRv1 arrojó un promedio de rendimiento de red un 4 % mayor y hasta un 14 % en algunos países. BBR ha estado disponible para Linux TCP desde Linux 4.9. También está disponible para QUIC.

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, investigadores como Geoff Huston y Hock, Bless y Zitterbart lo encontraron injusto para otras corrientes y no escalable. 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. Soheil Abbasloo et al. (autores de C2TCP) muestran que 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 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 pulgadas).

La versión 2 intenta abordar la cuestión 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 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). Si bien en ocasiones BBRv2 puede tener un rendimiento menor que BBRv1, generalmente se considera que tiene un mejor rendimiento.

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.

C2TCP

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 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 sobre 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 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.

Elástico-TCP

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.

NATCP

Soheil Abbasloo et al. propuso NATCP (TCP asistido por red) a Controvertido diseño de TCP dirigido a la informática 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.

Otros algoritmos para evitar la congestión de TCP

• FAST TCP
• TCP FAST generalizado
• H-TCP
• Centro de datos TCP
• TCP de alta velocidad
• HSTCP-LP
• TCP-Illinois
• TCP-LP
• TCP SACK
• TCP escalable
• TCP Veno
• Westwood
• XCP
• YeAH-TCP
• TCP-FIT
• Congestión Evitación con Intervalo Normalizado del Tiempo (CANIT)
• Control de congestión de red neuronal no lineal basado en algoritmo genético para redes TCP/IP
• D-TCP
• NexGen D-TCP
• Copa

TCP New Reno fue el algoritmo implementado más comúnmente, la compatibilidad con SACK es muy común 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. La versión anterior usaba New Reno. Sin embargo, FreeBSD admite otras opciones.

Cuando aumenta el producto por flujo de ancho de banda y 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) 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).

Clasificación por conocimiento de la red

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.

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 cuadro gris utilizan tiempo -instancias para obtener mediciones y estimaciones de ancho de banda, contención de flujo y otros conocimientos de 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.

Caja negra

• Highspeed-TCP
• BIC TCP (Protocolo de Control de Congestión de Incremento Bruto) utiliza un aumento de la tasa de concave después de cada evento de congestión hasta que la ventana sea igual a eso antes del evento, con el fin de maximizar el tiempo que la red es totalmente utilizada. Después de eso, sondea agresivamente.
• CUBIC TCP – 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 fijado a la ventana antes del evento.
• AIMD-FC (disminución multiplicativa de aumento aditivo con convergencia rápida), una mejora de AIMD.
• Mecanismos binomiales
• SIMD Protocol
• GAIMD

Cuadro gris

• TCP Vegas – estima el retraso de cola, y aumenta linealmente o disminuye la ventana para que un número constante de paquetes por flujo sean apagados en la red. Vegas implementa equidad proporcional.
• FAST TCP – consigue el mismo equilibrio que Las Vegas, pero utiliza el control proporcional en lugar de aumento lineal, y escala intencionalmente la ganancia a medida que el ancho de banda aumenta con el objetivo de garantizar la estabilidad.
• TCP BBR – estima el retraso de búsqueda pero utiliza un aumento exponencial. Intencionally slows down regularly for fairness and reduced delay.
• TCP-Westwood (TCPW) – una pérdida hace que la ventana se reajuste a la estimación del remitente del producto de ancho de banda (el RTT más pequeño medido multiplicado por la tasa observada de recibir ACKs).
• C2TCP
• TFRC
• TCP-Real
• TCP-Jersey

Cuadro verde

• Mecanismo Bimodal – Mecanismo de Evitación y Control de Congestión Bimodal.
• Métodos de señalización aplicados por los routers
  • Detección temprana aleatoria (RED) despliega paquetes aleatoriamente en proporción al tamaño de la cola del router, provocando una disminución multiplicativa en algunos flujos.
  • Explicit Congestion Notification (ECN)
• Control de la congestión asistido por redes
  • NATCP - TCP asistido por red utiliza retroalimentación explícita fuera de banda indicando mínimo RTT de la red y 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 anfitrión final.

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

• Protocolo de Control de Explicit (XCP) – Los paquetes XCP llevan un encabezado de congestión con un campo de retroalimentación, indicando el aumento o disminución de la ventana de congestión del remitente. Los routers XCP establecen el valor de retroalimentación explícitamente para la eficiencia y la equidad.
• MaxNet – Usa un solo campo de cabecera, que lleva el nivel máximo de congestión de cualquier router en el camino de un flujo. La tasa se establece como una función de esta congestión máxima, dando lugar a la equidad máx-min.
• JetMax, como MaxNet, responde sólo a la señal máxima de congestión, pero también lleva otros campos de arriba.

Uso de Linux

• BIC se utiliza por defecto en núcleos Linux 2.6.8 a 2.6.18. (agosto 2004 – septiembre 2006)
• CUBIC se utiliza por defecto en núcleos Linux desde la versión 2.6.19. (noviembre de 2006)
• PRR se incorpora en los núcleos Linux para mejorar la recuperación de pérdidas desde la versión 3.2. (enero de 2012)
• BBRv1 se incorpora en núcleos Linux para permitir el control de congestión basado en modelos desde la versión 4.9. (diciembre 2016)