Control de congestión TCP
Técnicas para mejorar el rendimiento de la red mediante el Protocolo de Control de Transmisión

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 .

Aumento aditivo/disminución multiplicativa

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]

Ventana de congestión

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 .

Comienzo lento

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.

TCP Tahoe
Cuando ocurre una pérdida, se envía una retransmisión, la mitad del CWND actual se guarda como ssthresh y el inicio lento comienza nuevamente desde su CWND inicial.
TCP Reno
Se envía una retransmisión rápida, la mitad del CWND actual se guarda como ssthresh y como nuevo CWND, omitiendo así el inicio lento y pasando directamente al algoritmo de prevención de congestión. El algoritmo general aquí se llamarecuperación rápida

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 .

Retransmisión rápida

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.

Algoritmos

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:

  1. el tipo y la cantidad de retroalimentación recibida de la red
  2. Capacidad de implementación incremental en la Internet actual
  3. el aspecto del rendimiento que se pretende mejorar: redes de productos con retardo de ancho de banda elevado (B); enlaces con pérdidas (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 de prevención de congestión bien conocidos se clasifican según este esquema de la siguiente manera:

VarianteComentarioCambios necesariosBeneficiosJusticia
(Nuevo) RenoPérdida——Demora
Las VegasDemoraRemitenteMenos pérdidaProporcional
Alta velocidadPérdidaRemitenteAlto ancho de banda
Código de barrasPérdidaRemitenteAlto ancho de banda
CÚBICOPérdidaRemitenteAlto ancho de banda
C2TCP [11] [12]Pérdida/RetrasoRemitenteLatencia ultrabaja y gran ancho de banda
Programa Nacional de Control de Plagas [13]Señal multibitRemitenteRendimiento casi óptimo
TCP elásticoPérdida/RetrasoRemitenteGran ancho de banda/corta y larga distancia
TCP ágilPérdidaRemitenteGran ancho de banda/corta distancia
TCPHPérdidaRemitenteAlto ancho de banda
RÁPIDODemoraRemitenteAlto ancho de bandaProporcional
TCP compuestoPérdida/RetrasoRemitenteAlto ancho de bandaProporcional
WestwoodPérdida/RetrasoRemitenteEnlaces con pérdida
JerseyPérdida/RetrasoRemitenteEnlaces con pérdida
BBR [14]DemoraRemitenteBLVC, hinchazón del búfer
ABRAZADERASeñal multibitReceptor, enrutadorEnlaces de tasa variableMáximo-mínimo
TFRCPérdidaEmisor, receptorSin retransmisiónRetraso mínimo
XCPSeñal multibitEmisor, receptor, enrutadorBLFCMáximo-mínimo
PCVSeñal de 2 bitsEmisor, receptor, enrutadorBLFProporcional
MaxNetSeñal multibitEmisor, receptor, enrutadorSociedad Civil Ligera de BarbadosMáximo-mínimo
JetMaxSeñal multibitEmisor, receptor, enrutadorAlto ancho de bandaMáximo-mínimo
ROJOPérdidaEnrutadorRetraso reducido
ECNSeñal de un solo bitEmisor, receptor, enrutadorPérdida reducida

TCP Tahoe y Reno

Los algoritmos TCP Tahoe y Reno recibieron su nombre retrospectivo 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:

  • Tahoe: si se reciben tres ACK duplicados (es decir, cuatro ACK que reconocen el mismo paquete, que no se incorporan a los datos y no cambian la ventana anunciada del receptor), Tahoe realiza una retransmisión rápida, establece el umbral de inicio lento en 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. [15]
  • Reno: si se reciben tres ACK duplicados, Reno realizará una retransmisión rápida y omitirá la fase de inicio lento, dividiendo 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 entrará en una fase llamada recuperación rápida . [16]

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

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

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]

TCP Vegas

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

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]

Código de barras TCP

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 ]

TCP CÚBICO

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.

TCP de Agile-SD

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.

TCP Westwood+

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 ]

TCP compuesto

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 .

Reducción proporcional de la tasa TCP

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]

TCPBBR-es

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]

C2TCP

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]

TCP elástico

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]

Programa Nacional de Control de Activos

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]

Otros algoritmos para evitar la congestión TCP

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]

Clasificación por conocimiento de la red

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.

Caja negra

  • TCP de alta velocidad [56]
  • BIC TCP (Binary Increase Congestion Control Protocol) utiliza un aumento cóncavo de la tasa de fuentes después de cada evento de congestión hasta que la ventana es igual a la anterior al evento, con el fin de maximizar el tiempo en que la red se utiliza por completo. Después de eso, realiza sondeos agresivos.
  • TCP CUBIC : 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.
  • AIMD-FC (aumento aditivo, disminución multiplicativa con convergencia rápida), una mejora de AIMD. [57]
  • Mecanismos binomiales
  • Protocolo SIMD
  • GAIMD

Caja gris

  • TCP Vegas : calcula el retraso de la cola y aumenta o disminuye linealmente la ventana de modo que se coloque en cola en la red una cantidad constante de paquetes por flujo. Vegas implementa equidad proporcional.
  • FAST TCP : logra el mismo equilibrio que Vegas, pero utiliza un control proporcional en lugar de un aumento lineal y reduce intencionalmente la ganancia a medida que aumenta el ancho de banda con el objetivo de garantizar la estabilidad.
  • TCP BBR: calcula el retraso de la cola, pero utiliza un aumento exponencial. Reduce la velocidad de forma intencional y periódica para lograr equidad y reducir el retraso.
  • TCP-Westwood (TCPW): una pérdida hace que la ventana se restablezca a la estimación del remitente del producto de retardo de ancho de banda (el RTT medido más pequeño multiplicado por la tasa observada de recepción de ACK). [58]
  • C2TCP [12] [11]
  • TFRC [59]
  • TCP-Real
  • TCP-Jersey

Caja verde

  • Mecanismo Bimodal – Mecanismo bimodal de prevención y control de la congestión.
  • Métodos de señalización implementados por enrutadores
  • Control de congestión asistido por red
    • NATCP [13] – El 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 informar explícitamente el estado de congestión de la red. También incluye un algoritmo del lado del host final. [ cita requerida ]

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 un encabezado 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 lograr eficiencia y equidad. [60]
  • MaxNet: utiliza un único campo de encabezado que contiene el nivel máximo de congestión de cualquier enrutador en la ruta de un flujo. La tasa se establece como una función de esta congestión máxima, lo que da como resultado una equidad máxima-mínima . [61]
  • JetMax, al igual que MaxNet, responde únicamente a la señal de máxima congestión, pero también transmite otros campos aéreos.

Uso de Linux

  • BIC se utiliza de forma predeterminada en los núcleos Linux 2.6.8 a 2.6.18. (Agosto de 2004 – Septiembre de 2006)
  • CUBIC se utiliza de forma predeterminada en los núcleos de Linux desde la versión 2.6.19 (noviembre de 2006) [62]
  • PRR se ha incorporado en los núcleos de Linux para mejorar la recuperación de pérdidas desde la versión 3.2. (enero de 2012)
  • BBRv1 se ha incorporado en los núcleos de Linux para permitir el control de la congestión basado en modelos desde la versión 4.9. (diciembre de 2016)

Véase también

Notas

  1. ^ Incluso si, en realidad, el receptor puede retrasar sus ACK, enviando típicamente un ACK por cada dos segmentos que recibe [2]

Referencias

  1. ^ Jacobson y Karels 1988.
  2. ^ ab W. Stevens (enero de 1997). Algoritmos de inicio lento, prevención de congestión, retransmisión rápida y recuperación rápida de TCP. doi : 10.17487/RFC2001 . RFC 2001.
  3. ^ ab M. Allman; S. Floyd; C. Partridge (octubre de 2002). Aumento de la ventana inicial del TCP. doi : 10.17487/RFC3390 . RFC 3390.
  4. ^ "Explicación de la prevención de la congestión TCP mediante un diagrama de secuencia" (PDF) . eventhelix.com .
  5. ^ Chiu, Dah-Ming; Raj Jain (1989). "Análisis de algoritmos de aumento y disminución para evitar la congestión en redes informáticas". Redes informáticas y sistemas ISDN . 17 : 1–14. CiteSeerX 10.1.1.136.8108 . doi :10.1016/0169-7552(89)90019-6. 
  6. ^ Allman, M.; Paxson, V. (septiembre de 2009). TCP Congestion Control. Internet Engineering Task Force . sec. 3.1. doi : 10.17487/RFC5681 . RFC 5681. Consultado el 4 de marzo de 2021 .
  7. ^ Blanton, Ethan; Paxson, Vern; Allman, Mark (septiembre de 2009). "Control de congestión TCP". Grupo de trabajo de ingeniería de Internet. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  8. ^ Corbet, Jonathan. "Aumento de la ventana de congestión inicial de TCP". LWN . Consultado el 10 de octubre de 2012 .
  9. ^ Nick O'Neill. "¿Qué hace que tu sitio web funcione lento? Podría ser el botón Me gusta". AllFacebook , 10 de noviembre de 2010. Recuperado el 12 de septiembre de 2012.
  10. ^ Fall, Kevin; Sally Floyd (julio de 1996). "Comparaciones basadas en simulación de Tahoe, Reno y SACK TCP" (PDF) . Computer Communications Review . 26 (3): 5–21. CiteSeerX 10.1.1.586.2403 . doi :10.1145/235160.235162. S2CID  7459148. 
  11. ^ abcdef Abbasloo, S.; Xu, Y.; Chao, HJ (2019). "C2TCP: Un TCP celular flexible para cumplir con estrictos requisitos de retardo". Revista IEEE sobre áreas seleccionadas en comunicaciones . 37 (4): 918–932. arXiv : 1810.13241 . doi :10.1109/JSAC.2019.2898758. ISSN  0733-8716. S2CID  53107038.
  12. ^ abcd Abbasloo, S.; Li, T.; Xu, Y.; Chao, HJ (mayo de 2018). "TCP de retardo controlado celular (C2TCP)". Conferencia y talleres sobre redes IFIP de 2018 (redes IFIP) . págs. 118–126. arXiv : 1807.02689 . Código Bibliográfico :2018arXiv180702689A. doi :10.23919/IFIPNetworking.2018.8696844. ISBN 978-3-903176-08-9. Número de identificación del sujeto  49650788.
  13. ^ abcd Abbasloo y otros. 2019.
  14. ^ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van (2016). "BBR: Control de congestión basado en la congestión". Queue . 14 (5): 20–53. doi : 10.1145/3012426.3022184 .
  15. ^ Kurose y Ross 2008, pág. 284.
  16. ^ Kurose y Ross 2012, pág. 277.
  17. ^ Vasanthi N., V.; Singh M., Ajith; Kumar, Romen; Hemalatha, M. (2011). "Evaluación de protocolos y algoritmos para mejorar el rendimiento de TCP en redes inalámbricas/cableadas". En Das, Vinu V; Thankachan, Nessy (eds.). Inteligencia computacional y tecnología de la información . Comunicaciones en informática y ciencias de la información. Vol. 250. Springer. págs. 693–697. doi :10.1007/978-3-642-25734-6_120. ISBN 978-3-642-25733-9.
  18. ^ "Análisis de rendimiento de algoritmos de control de congestión TCP" (PDF) . Consultado el 26 de marzo de 2012 .
  19. ^ "Registro de cambios de DD-WRT" . Consultado el 2 de enero de 2012 .
  20. ^ "Página de inicio de Hybla". Archivado desde el original el 11 de octubre de 2007. Consultado el 4 de marzo de 2007 .
  21. ^ Caini, Carlo; Firrincieli, Rosario (2004). "TCP Hybla: una mejora de TCP para redes heterogéneas". Revista Internacional de Comunicaciones por Satélite y Redes . 22 (5): 547–566. doi :10.1002/sat.799. ISSN  1542-0973. S2CID  2360535.
  22. ^ Caini, C.; Firrincieli, R.; Lacamera, D. (2009). "Evaluación comparativa del rendimiento de variantes TCP en entornos satelitales". Conferencia internacional sobre comunicaciones del IEEE de 2009. págs. 1–5. doi :10.1109/ICC.2009.5198834. S2CID  8352762.
  23. ^ V., Jacobson; RT, Braden. Extensiones TCP para rutas de retardo largo. doi : 10.17487/RFC1072 . RFC 1072.
  24. ^ Alrshah, MA; Othman, M.; Ali, B.; Hanapi, ZM (septiembre de 2015). "Agile-SD: Un algoritmo de control de congestión TCP basado en Linux para soportar redes de alta velocidad y corta distancia". Journal of Network and Computer Applications . 55 : 181–190. arXiv : 1601.05908 . doi :10.1016/j.jnca.2015.05.011. S2CID  2645016.
  25. ^ Mathis, M.; Dukkipati, N.; Cheng, Y. (2013). Reducción de tasa proporcional para TCP. doi : 10.17487/RFC6937 . RFC 6937.
  26. ^ Corbet, Jonathan. "LPC: Hacer que la red vaya más rápido" . Consultado el 6 de junio de 2014 .
  27. ^ "Linux 3.2 – Linux Kernel Newbies" . Consultado el 6 de junio de 2014 .
  28. ^ ab "BBR: Control de congestión basado en la congestión" . Consultado el 25 de agosto de 2017 .
  29. ^ Cheng, Yuchung; Cardwell, Neal; Yeganeh, Soheil Hassas; Jacobson, Van (3 de julio de 2017). "Estimación de la tasa de entrega". Grupo de trabajo de ingeniería de Internet . Consultado el 25 de agosto de 2017 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
  30. ^ "El control de congestión TCP BBR llega a GCP: su Internet es ahora más rápida" . Consultado el 25 de agosto de 2017 .
  31. ^ "Control de congestión del BBR [LWN.net]". lwn.net .
  32. ^ "Actualización de BBR". Grupo de trabajo de ingeniería de Internet.
  33. ^ "TCP y BBR" (PDF) . Consultado el 27 de mayo de 2018 .
  34. ^ "Evaluación experimental del control de congestión de la BBR" (PDF) . Consultado el 27 de mayo de 2018 .
  35. ^ "Una evaluación del rendimiento de TCP BBRv2" . Consultado el 12 de enero de 2021 .
  36. ^ Equipo Google TCP BBR; equipo Google QUIC BBR (26 de julio de 2023). BBRv3: Corrección de errores de algoritmos e implementación en Internet pública. IETF 117: San Francisco.
  37. ^ "Retardo controlado celular TCP (C2TCP)". wp.nyu.edu . Consultado el 27 de abril de 2019 .
  38. ^ Alrshah, MA; Al-Maqri, MA; Othman, M. (junio de 2019). "Elastic-TCP: algoritmo de control de congestión flexible para adaptarse a redes de alto BDP". IEEE Systems Journal . 13 (2): 1336–1346. arXiv : 1904.13105 . Código Bibliográfico :2019ISysJ..13.1336A. doi : 10.1109/JSYST.2019.2896195 .
  39. ^ Abbasloo, Soheil (3 de junio de 2019), GitHub – Soheil-ab/natcp , consultado el 5 de agosto de 2019
  40. ^ Yuan, Cao; Tan, Liansheng; Andrew, Lachlan LH; Zhang, Wei; Zukerman, Moshe (6 de junio de 2008). "Un esquema TCP FAST generalizado". Comunicaciones informáticas . 31 (14): 3242–3249. doi :10.1016/j.comcom.2008.05.028. hdl : 1959.3/44051 . S2CID  17988768.
  41. ^ ab "Grupo Redes de Arroz".
  42. ^ "TCP Veno: Mejora de TCP para la transmisión a través de redes de acceso inalámbrico" (PDF) . Revista IEEE sobre áreas seleccionadas en comunicación.
  43. ^ "XCP en ISI".
  44. ^ "TPC de alta velocidad" (PDF) . csc.lsu.edu .
  45. ^ "Copia archivada". Archivado desde el original el 3 de abril de 2011. Consultado el 5 de marzo de 2011 .{{cite web}}: CS1 maint: archived copy as title (link)
  46. ^ Benaboud, H.; Berqia, A.; Mikou, N. (2002). "Un estudio analítico del algoritmo CANIT en el protocolo TCP". Revisión de evaluación del rendimiento de ACM SIGMETRICS . 30 (3): 20. doi :10.1145/605521.605530. S2CID  6637174.
  47. ^ Rouhani, Modjtaba (2010). "Control de congestión de redes neuronales no lineales basado en algoritmos genéticos para redes TCP/IP". 2010 2nd International Conference on Computational Intelligence, Communication Systems and Networks . págs. 1–6. doi :10.1109/CICSyN.2010.21. ISBN 978-1-4244-7837-8.S2CID 15126416  .
  48. ^ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Roy, Abhishek; Saxena, Navrati (enero de 2018). "D-TCP: algoritmo de control de congestión TCP dinámico para redes móviles de próxima generación". 2018 15.ª Conferencia anual de redes y comunicaciones para consumidores del IEEE (CCNC) . págs. 1–6. doi :10.1109/CCNC.2018.8319185. ISBN . 978-1-5386-4790-5. Número de identificación del sujeto  3991163.
  49. ^ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Kim, Hanseok; Maheshwari, Mukesh Kumar; Hwang, Jaehyun; Roy, Abhishek; Saxena, Navrati (2020). "NexGen D-TCP: algoritmo de control de congestión TCP dinámico de próxima generación". IEEE Access . 8 : 164482–164496. Bibcode :2020IEEEA...8p4482K. doi : 10.1109/ACCESS.2020.3022284 . ISSN  2169-3536. S2CID  221846931.
  50. ^ Arun, Venkat; Balakrishnan, Hari (2018). "Copa: Control práctico de la congestión basado en retardos para Internet". 15.º Simposio USENIX sobre diseño e implementación de sistemas en red (NSDI 18) : 329–342. ISBN 978-1-939133-01-4.
  51. ^ "tcp: convertir a CUBIC en el mecanismo de control de congestión predeterminado". 13 de septiembre de 2022.
  52. ^ "Resumen del proyecto de cinco nuevos algoritmos de control de congestión TCP". 8 de marzo de 2011.
  53. ^ "iTCP – Protocolo de transporte interactivo – Laboratorio Medianet, Universidad Estatal de Kent".
  54. ^ "Libro blanco: Zeta-TCP: aceleración TCP inteligente, adaptativa y asimétrica" ​​(PDF) . Consultado el 6 de diciembre de 2019 .
  55. ^ Lefteris Mamatas; Tobias Harks; Vassilis Tsaoussidis (enero de 2007). "Enfoques para el control de la congestión en redes de paquetes" (PDF) . Journal of Internet Engineering . 1 (1). Archivado desde el original (PDF) el 21 de febrero de 2014.
  56. ^ "TCP de alta velocidad". icir.org .
  57. ^ "Página de inicio de AIMD-FC". neu.edu . Archivado desde el original el 13 de enero de 2009 . Consultado el 13 de marzo de 2016 .
  58. ^ "Bienvenido al Laboratorio de Investigación en Red". cs.ucla.edu .
  59. ^ "Control de congestión basado en ecuaciones para aplicaciones unicast". icir.org .
  60. ^ Katabi, Dina; Handley, Mark; Rohrs, Charlie (2002). "Control de congestión para redes de productos con retardo de ancho de banda elevado". Actas de la conferencia de 2002 sobre aplicaciones, tecnologías, arquitecturas y protocolos para comunicaciones informáticas . Nueva York, Nueva York, EE. UU.: ACM Press. pág. 89. doi : 10.1145/633025.633035 . ISBN . 1-58113-570-X.
  61. ^ "MaxNet - Control de congestión de señalización explícita estable y justa con valores máximos y mínimos". netlab.caltech.edu .
  62. ^ "Control de congestión TCP: un enfoque de sistemas. Peterson, Brakmo y Davie" . Consultado el 17 de mayo de 2024 .

Fuentes

  • Kurose, James y Ross, Keith (2008). Redes informáticas: un enfoque descendente (4.ª ed.). Addison Wesley. ISBN 978-0-13-607967-5.
  • Kurose, James y 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". Segundo taller de USENIX sobre temas de actualidad en Edge Computing (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.
  • Enfoques para el control de la congestión en redes de paquetes
  • Documentos sobre control de la congestión
  • Allman, Mark; Paxson, Vern; Stevens, W. Richard (abril de 1999). "Retransmisión rápida/recuperación rápida". Control de congestión TCP. Grupo de trabajo de ingeniería de Internet . Sec. 3.2. doi : 10.17487/RFC2581 . RFC 2581. Consultado el 1 de mayo de 2010 .
  • Algoritmos para evitar y gestionar la congestión en TCP: la guía TCP/IP
Retrieved from "https://en.wikipedia.org/w/index.php?title=TCP_congestion_control&oldid=1254956045#TCP_New_Reno"