El Protocolo de control de transmisión (TCP) utiliza un algoritmo para evitar la congestión de la red que incluye varios aspectos de un esquema de aumento aditivo / disminución multiplicativa (AIMD), junto con otros esquemas que incluyen un inicio lento y una ventana de congestión , para lograr evitar la congestión. El algoritmo TCP para evitar la congestión es la base principal para el control de la congestión en Internet. [1] [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 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 .
Operación
Para evitar el colapso congestivo , TCP utiliza una estrategia de control de la congestión multifacética. Para cada conexión, TCP mantiene una ventana de congestión , lo que limita el número total de paquetes no reconocidos que pueden estar en tránsito de un extremo a otro. Esto es algo análogo a la ventana deslizante de TCP utilizada para el control de flujo . TCP utiliza un mecanismo llamado inicio lento [1] para aumentar la ventana de congestión después de que se inicializa una conexión o después de un tiempo de espera . Comienza con una ventana, un pequeño múltiplo del tamaño máximo del segmento (MSS). Aunque la tasa inicial es baja, la tasa de aumento es muy rápida; por cada paquete reconocido, la ventana de congestión aumenta en 1 MSS de modo que la ventana de congestión efectivamente se duplica para cada tiempo de ida y vuelta (RTT).
Cuando la ventana de congestión excede el umbral de inicio lento, ssthresh , [a] el algoritmo entra en un nuevo estado, llamado prevención de congestión. En el estado de evitación de la congestión, siempre que se reciban ACK no duplicados [b], la ventana de congestión aumenta de forma aditiva en un SMS cada tiempo de ida y vuelta. Esto corresponde al algoritmo AIMD que se describe a continuación .
Ventana de congestión
En TCP, la ventana de congestión es uno de los factores que determina la cantidad de bytes que se pueden enviar en cualquier momento. El remitente mantiene la ventana de congestión y es un medio para evitar que un enlace entre el remitente y el receptor se sobrecargue con demasiado tráfico. Esto no debe confundirse con la ventana deslizante mantenida por el remitente que existe para evitar que el receptor se sobrecargue. La ventana de congestión se calcula estimando cuánta congestión hay en el enlace.
Cuando se establece una conexión, la ventana de congestión, un valor que se mantiene independientemente en cada host, se establece en un pequeño múltiplo del MSS permitido en esa conexión. La variación adicional en la ventana de congestión viene dictada por un enfoque de aumento aditivo / disminución multiplicativa (AIMD). Esto significa que si se reciben todos los segmentos y los reconocimientos llegan al remitente a tiempo, se agrega alguna constante al tamaño de la ventana. Cuando la ventana alcanza ssthresh , la ventana de congestión aumenta linealmente a la tasa de 1 / (ventana de congestión) segmento en cada nuevo acuse de recibo recibido. La ventana sigue creciendo hasta que se agota el tiempo de espera. En tiempo de espera:
- La ventana de congestión se restablece a 1 MSS.
- ssthresh se establece en la mitad del tamaño de la ventana de congestión antes del tiempo de espera.
- se inicia el arranque lento .
Un administrador del sistema puede ajustar el límite máximo de 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. Al comparar su propia ventana de congestión con la ventana de recepción , un remitente puede determinar cuántos datos puede enviar en un momento dado.
Comienzo lento
El inicio lento 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 algoritmo está especificado por RFC 5681 .
Aunque la estrategia se conoce como inicio lento, el crecimiento de su ventana de congestión es bastante agresivo, más agresivo que la fase de evitación de la congestión. [1] Antes de que se introdujera el inicio lento en TCP, la fase inicial de prevención de la congestión era incluso más rápida.
El inicio lento comienza inicialmente con un tamaño de ventana de congestión (CWND) de 1, 2, 4 o 10 MSS. [5] [3] : 1 El valor para el tamaño de la ventana de congestión aumentará en uno con cada acuse de recibo (ACK) recibido, duplicando efectivamente el tamaño de la ventana en cada tiempo de ida y vuelta. [c] El algoritmo de inicio lento aumentará la velocidad de transmisión hasta que se detecte una pérdida, o la ventana anunciada del receptor (rwnd) sea el factor limitante, o se alcance ssthresh . Si ocurre un evento de pérdida, TCP asume que se debe a la congestión de la red y toma medidas para reducir la carga ofrecida en la red. Estas medidas dependen del algoritmo exacto de prevención de congestión de TCP utilizado.
- TCP Tahoe
- Cuando ocurre una pérdida, se envía una retransmisión rápida , la mitad de la CWND actual se guarda como ssthresh y el inicio lento comienza de nuevo desde su CWND inicial. Una vez que la CWND llega a ssthresh , TCP cambia al algoritmo para evitar la congestión donde cada nuevo ACK aumenta la CWND por MSS / CWND. Esto da como resultado un aumento lineal de la CWND.
- TCP Reno
- Se envía una retransmisión rápida, la mitad de la CWND actual se guarda como ssthresh y como nueva CWND, omitiendo así el inicio lento y yendo directamente al algoritmo para evitar la congestión. El algoritmo general aquí se llama recuperación rápida.
Una vez que se alcanza ssthresh , TCP cambia del algoritmo de inicio lento al algoritmo de crecimiento lineal (evitación de la congestión). En este punto, la ventana aumenta en 1 segmento por cada tiempo de retardo de ida y vuelta (RTT).
El inicio lento supone que los segmentos no reconocidos se deben a la congestión de la red. Si bien esta es una suposición aceptable para muchas redes, 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 funcionar mal en situaciones con mala recepción, como redes inalámbricas .
El protocolo de inicio lento también funciona mal para conexiones de corta duración. Los navegadores web más antiguos crearían muchas conexiones consecutivas de corta duración al servidor web y abrirían y cerrarían la conexión para cada archivo solicitado. Esto mantuvo la mayoría de las conexiones en el modo de inicio lento, lo que resultó en un tiempo de respuesta deficiente. Para evitar este problema, los navegadores modernos abren múltiples conexiones simultáneamente o reutilizan una conexión para todos los archivos solicitados desde un servidor web en particular. Conexiones, sin embargo, no pueden ser reutilizados para los servidores múltiples de terceros utilizados por los sitios web para implementar publicidad en la web , compartiendo características de los servicios de redes sociales , [6] y el contador de secuencias de comandos de análisis web .
Aumento aditivo / disminución multiplicativa
El algoritmo de aumento aditivo / disminución multiplicativa (AIMD) es un algoritmo de control de circuito cerrado . AIMD combina el crecimiento lineal de la ventana de congestión con una reducción exponencial cuando se produce una congestión. Múltiples flujos que usan el control de congestión AIMD eventualmente convergerán para usar cantidades iguales de un enlace en disputa. [7]
Este es el algoritmo que se describe en RFC 5681 para el estado de "prevención de congestión". [8]
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 usa un temporizador simple para reconocer segmentos perdidos. Si no se recibe un acuse de recibo para un segmento en particular dentro de un tiempo específico (una función del tiempo de retardo de ida y vuelta estimado ), el remitente asumirá que el segmento se perdió en la red y retransmitirá el segmento.
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 en orden de datos recibidos. Para un paquete en orden, este 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, el receptor solo 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 quinto paquete. Nuevamente, falta el segundo paquete en la secuencia, por lo que el último byte en orden no ha cambiado. Se envían confirmaciones duplicadas para ambos paquetes.
Cuando un remitente recibe tres acuses de recibo duplicados, puede estar razonablemente seguro de que se perdió el segmento que contenía los datos que siguieron al último byte en orden especificado en el acuse de recibo. Un remitente con retransmisión rápida retransmitirá este paquete inmediatamente sin esperar su 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 reconocería 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. [9] [ verificación fallida ]
La siguiente es una clasificación posible según las siguientes propiedades:
- el tipo y la cantidad de comentarios recibidos de la red
- implementabilidad incremental en la Internet actual
- el aspecto del rendimiento que pretende mejorar: redes de productos con alto retardo de ancho de banda (B); enlaces con pérdida (L); equidad (F); ventaja de los flujos cortos (S); enlaces de tasa variable (V); velocidad de convergencia (C)
- el criterio de equidad que utiliza
Este esquema clasifica algunos mecanismos conocidos para evitar la congestión de la siguiente manera:
Variante | Realimentación | Cambios requeridos | Beneficios | Justicia |
---|---|---|---|---|
(Nuevo) Reno | Pérdida | - | - | Demora |
Vegas | Demora | Remitente | Menos perdida | Proporcional |
Alta velocidad | Pérdida | Remitente | Alto ancho de banda | |
BIC | Pérdida | Remitente | Alto ancho de banda | |
CÚBICO | Pérdida | Remitente | Alto ancho de banda | |
C2TCP [10] [11] | Pérdida / Retraso | Remitente | Latencia ultrabaja y ancho de banda alto | |
NATCP [12] | Señal de varios bits | Remitente | Rendimiento casi óptimo | |
TCP elástico | Pérdida / Retraso | Remitente | Alto ancho de banda / corta y larga distancia | |
Ágil-TCP | Pérdida | Remitente | Alto ancho de banda / corta distancia | |
H-TCP | Pérdida | Remitente | Alto ancho de banda | |
RÁPIDO | Demora | Remitente | Alto ancho de banda | Proporcional |
TCP compuesto | Pérdida / Retraso | Remitente | Alto ancho de banda | Proporcional |
Westwood | Pérdida / Retraso | Remitente | L | |
Jersey | Pérdida / Retraso | Remitente | L | |
BBR [13] | Demora | Remitente | BLVC, Bufferbloat | |
ABRAZADERA | Señal de varios bits | Receptor, enrutador | V | Máximo minimo |
TFRC | Pérdida | Enviador recibidor | Sin retransmisión | Retraso mínimo |
XCP | Señal de varios bits | Remitente, receptor, enrutador | BLFC | Máximo minimo |
VCP | Señal de 2 bits | Remitente, receptor, enrutador | BLF | Proporcional |
MaxNet | Señal de varios bits | Remitente, receptor, enrutador | BLFSC | Máximo minimo |
JetMax | Señal de varios bits | Remitente, receptor, enrutador | Alto ancho de banda | Máximo minimo |
ROJO | Pérdida | Enrutador | Retraso reducido | |
ECN | Señal de un solo bit | Remitente, receptor, enrutador | Pérdida reducida |
TCP Tahoe y Reno
Los algoritmos TCP Tahoe y Reno fueron nombrados retrospectivamente según las versiones o sabores del sistema operativo 4.3BSD en el que aparecieron por primera vez (que a su vez recibieron el nombre de Lake Tahoe y la cercana ciudad de Reno, Nevada ). El algoritmo Tahoe apareció por primera vez en 4.3BSD-Tahoe (que se hizo para admitir la minicomputadora CCI Power 6/32 "Tahoe" ), y más tarde se puso a disposición de los titulares de licencias que no eran de AT&T como parte de 4.3BSD Networking Release 1; esto aseguró su amplia distribución e implementación. Se realizaron mejoras en 4.3BSD-Reno y posteriormente se lanzaron al público como Networking Release 2 y más tarde 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 están respaldados por 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 congestión actual ventana, reduce la ventana de congestión a 1 MSS y se restablece al estado de inicio lento. [14]
- 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 umbral de inicio lento igual a la nueva ventana de congestión y entrar en una fase llamada recuperación rápida . [15]
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 Vegas
Hasta mediados de la década de 1990, todos los tiempos de espera establecidos de 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 (llamado así por 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 de TCP , TCP Vegas pareció ser el más fluido seguido de TCP CUBIC. [dieciséis]
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 DD-WRT v24 SP2. [17]
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. 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 siempre que hay progreso en el búfer de transmisión, New Reno puede llenar huecos grandes, o múltiples huecos, en el espacio de secuencia, al igual que TCP SACK . 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 huecos, incluso cuando hay varios huecos, de varios paquetes cada uno. Cuando TCP entra en recuperación rápida, registra el número de secuencia de paquete no reconocido más alto pendiente. Cuando se reconoce este número de secuencia, TCP vuelve al estado de evitación de congestión.
Se produce un problema con New Reno cuando no hay pérdidas de paquetes, sino que los paquetes se reordenan por más de 3 números de secuencia de paquetes. En este caso, New Reno ingresa por error en una recuperación rápida. Cuando se entrega el paquete reordenado, ocurre 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 ACK inmediatamente. [ aclaración necesaria ]
New Reno se desempeña tan bien como SACK con bajas tasas de error de paquetes y supera sustancialmente a Reno con altas tasas de error. [18]
TCP Hybla
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. [19]
TCP BIC
El control binario de aumento de congestión (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 . [20] BIC se utiliza de forma predeterminada en los kernels de Linux 2.6.8 a 2.6.18. [ cita requerida ]
TCP CUBIC
CUBIC 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 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 entre las versiones 2.6.19 y 3.2.
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 de corta distancia (redes de baja BDP), como redes de área local o redes de fibra óptica, especialmente cuando el tamaño del búfer aplicado es pequeño. [21] Se evaluó comparando su rendimiento con el Compound TCP (el CCA predeterminado en MS Windows) y CUBIC (el predeterminado de Linux) usando 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 de solo 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 divide ciegamente a la mitad la ventana de congestión después de tres ACK duplicados, TCP Westwood + establece de forma adaptativa un umbral de inicio lento y una ventana de congestión que tiene en cuenta una estimación del ancho de banda disponible en el momento en que se experimenta la congestión. En comparación con Reno y New Reno, Westwood + aumenta significativamente el rendimiento de los enlaces inalámbricos y mejora la equidad en las redes cableadas. [ cita requerida ]
TCP compuesto
El 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 los LFN sin afectar 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 de la tasa proporcional de TCP
La Reducción de Tasa Proporcional de TCP (PRR) [22] es un algoritmo diseñado para mejorar la precisión de los datos enviados durante la recuperación. El algoritmo asegura 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 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%. [23] PRR está disponible en kernels de Linux desde la versión 3.2. [24]
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. [25] Si bien la mayoría de los CCA se basan en pérdidas, en el sentido de que dependen de la pérdida de paquetes para detectar la 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 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 acuse de recibo de ese paquete. [26] A medida que los controladores de interfaz de red evolucionan de megabits por segundo a gigabits por segundo, la latencia asociada con el bloque de búfer en lugar de la pérdida de paquetes se convierte en un marcador más confiable del rendimiento máximo, lo que hace que los CCA basados en modelos proporcionen un mayor rendimiento y una menor latencia. 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. [27] También está disponible para QUIC . [28]
La versión 1 de BBR (BBRv1) es eficiente y rápida, pero se disputa su imparcialidad con las transmisiones que no son de BBR. Cuando se implementó en YouTube , BBRv1 arrojó un rendimiento de red un promedio de 4% más alto y hasta un 14% en algunos países. [29] Si bien la presentación de Google muestra que BBRv1 coexiste bien con CUBIC, [25] investigadores como Geoff Huston y Hock, Bless y Zitterbart lo encuentran injusto para otras corrientes y no escalable. [30] Hock et al también encontraron "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. [31]
Soheil Abbasloo y col. (autores de C2TCP) muestran que BBRv1 no funciona bien en entornos dinámicos como las redes celulares. [10] [11] 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 (ver figura 16 en [10] ).
La versión 2 intenta abordar el problema de la injusticia cuando se opera junto con la gestión de congestión basada en pérdidas como CUBIC. [32] 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 BBRv2 a veces puede tener un rendimiento más bajo que BBRv1, generalmente se considera que tiene un mejor rendimiento .
C2TCP
El retardo controlado por celular TCP (C2TCP) [10] [11] 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 LTE actual y 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 hace que el retraso promedio de los paquetes se limite a los retrasos deseados establecidos por las aplicaciones.
Los investigadores de la NYU [33] demostraron que C2TCP supera el rendimiento de retardo y variación de retardo de varios esquemas de TCP de última generación. Por ejemplo, demostraron 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 redes celulares. [10]
TCP elástico
Elastic-TCP se propuso en febrero de 2019 para aumentar la utilización del ancho de banda en redes de alta 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 retardo de 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 sintonía humana. Ha sido evaluado comparando su rendimiento con el Compound TCP (el CCA predeterminado en MS Windows), CUBIC (el predeterminado para Linux) y TCP-BBR (el predeterminado de Linux 4.9 usado por Google) usando el simulador y banco de pruebas NS-2. Elastic-TCP mejora significativamente el rendimiento total en términos de rendimiento promedio, índice de pérdidas y retraso. [34]
NATCP
Soheil Abbasloo et. Alabama. propuso NATCP (TCP asistido por red) [12], un 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 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 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 tasas de envío. Como muestran los resultados preliminares, NATCP supera a los esquemas TCP de última generación. [12] [35]
Otros algoritmos de prevención de congestión de TCP
- TCP RÁPIDO
- FAST TCP generalizado [36]
- H-TCP
- Centro de datos TCP
- TCP de alta velocidad
- HSTCP-LP [37]
- TCP-Illinois
- TCP-LP [37]
- SACO TCP
- TCP escalable
- TCP Veno [38]
- Westwood
- XCP [39]
- YeAH-TCP [40]
- TCP-FIT [41]
- Evitación de la congestión con intervalo de tiempo normalizado (CANIT) [42]
- Control de congestión de redes neuronales no lineales basado en algoritmos genéticos para redes TCP / IP [43]
TCP New Reno fue el algoritmo más comúnmente implementado, el soporte 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 usa New Reno como algoritmo predeterminado. Sin embargo, admite otras opciones. [44]
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 ancho de banda muy alto.
TCP Interactive (iTCP) [45] permite que las aplicaciones se suscriban a eventos de TCP y respondan en consecuencia habilitando varias extensiones funcionales de TCP desde fuera de la capa de TCP. La mayoría de los esquemas de congestión de TCP funcionan internamente. Además, el iTCP 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 de las medidas de latencia y tasa de pérdida, y aplica diferentes estrategias de retroceso de la ventana de congestión en función de la probabilidad de congestión para maximizar el buen rendimiento . También tiene un par de otras mejoras para detectar con precisión las pérdidas de paquetes, evitando la retransmisión del tiempo de espera de retransmisión; y acelerar / controlar el tráfico entrante (descarga). [46]
Clasificación por conocimiento de la red
Los CCA se clasifican en relación con la conciencia de la red, es decir, el grado en que estos algoritmos conocen el estado de la red, y constan de tres categorías principales: caja negra, caja gris y caja verde. [47]
Los algoritmos de caja negra ofrecen métodos ciegos de control de la congestión. Operan solo con la retroalimentación binaria recibida en caso de congestión y no asumen ningún conocimiento sobre el estado de las redes que administran.
Los algoritmos de caja gris utilizan instancias de tiempo 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 la 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
- TCP de alta velocidad [48]
- 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 sea 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, investiga agresivamente.
- CUBIC TCP : una derivada menos agresiva y más sistemática de BIC, en la 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. [49]
- Mecanismos binomiales
- Protocolo SIMD
- GAIMD
Caja gris
- TCP Vegas : estima el retraso de la cola y aumenta o disminuye linealmente la ventana para que un número constante de paquetes por flujo se coloquen en la cola de la red. Vegas implementa la equidad proporcional.
- FAST TCP : logra el mismo equilibrio que Vegas, pero usa control proporcional en lugar de aumento lineal e intencionalmente reduce la ganancia a medida que aumenta el ancho de banda con el objetivo de garantizar la estabilidad.
- TCP BBR: estima el retraso de la cola, pero utiliza un aumento exponencial. Intencionalmente se ralentiza periódicamente por justicia y disminución de la demora.
- 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, que es el RTT medido más pequeño multiplicado por la tasa observada de recibir ACK. [50]
- C2TCP [11] [10]
- TFRC [51]
- TCP-Real
- TCP-Jersey
Caja verde
- Bimodal Mecanismo - Congestion Avoidance Bimodal y Control mecanismo.
- Métodos de señalización implementados por enrutadores
- La Detección Temprana Aleatoria (RED) descarta paquetes al azar en proporción al tamaño de la cola del enrutador, lo que desencadena una disminución multiplicativa en algunos flujos.
- Notificación explícita de congestión (ECN)
- Control de congestión asistido por red
- NATCP [12] : 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.
- VCP : 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 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 por eficiencia y equidad. [52]
- MaxNet : MaxNet utiliza un solo campo de encabezado, que lleva el nivel de congestión máximo de cualquier enrutador en la ruta de un flujo. La tasa se establece en función de esta congestión máxima, lo que da como resultado una equidad máxima-mínima . [53]
- JetMax : JetMax , como MaxNet, también responde solo a la señal de congestión máxima, pero también transporta otros campos generales
Uso de Linux
- BIC se utiliza de forma predeterminada en los kernels de Linux 2.6.8 a 2.6.18. (Agosto de 2004 - septiembre de 2006)
- CUBIC se utiliza de forma predeterminada en los kernels de Linux desde la versión 2.6.19. (Noviembre de 2006)
- PRR está incorporado en los kernels de Linux para mejorar la recuperación de pérdidas desde la versión 3.2. (Enero de 2012)
- BBR está incorporado en los kernels de Linux para permitir el control de la congestión basado en modelos desde la versión 4.9. (Diciembre de 2016)
Ver también
- Protocolo de control de transmisión §§ Control y desarrollo de congestión
- Congestión de la red § Mitigación
- Transporte en segundo plano con retardo extra bajo (LEDBAT)
Notas
- ^ En algunas implementaciones (por ejemplo, Linux), el ssthresh iniciales grande, por lo que el primer inicio lento generalmente termina después de una pérdida. Sin embargo, ssthresh se actualiza al final de cada inicio lento y, a menudo, afectará los inicios lentos posteriores provocados por tiempos de espera.
- ^ Cuando se pierde un paquete, la probabilidad de que se reciban ACK duplicados es muy alta. También es posible en este caso, aunque improbable, que la secuencia se haya sometido a un reordenamiento extremo de paquetes, lo que también provocaría ACK duplicados.
- ^ Incluso si, en realidad, el receptor puede retrasar sus ACK, normalmente enviando un ACK por cada dos segmentos que recibe [2]
Referencias
- ^ a b c Jacobson y Karels, 1988 .
- ^ a b W. Stevens (enero de 1997). Algoritmos TCP de inicio lento, prevención de congestión, retransmisión rápida y recuperación rápida . doi : 10.17487 / RFC2001 . RFC 2001 .
- ^ a b M. Allman; S. Floyd; C. Partridge (octubre de 2002). Aumento de la ventana inicial de TCP . doi : 10.17487 / RFC3390 . RFC 3390 .
- ^ "Evitación de la congestión de TCP explicada mediante un diagrama de secuencia" (PDF) . eventhelix.com .
- ^ Corbet, Jonathan. "Incrementando la ventana de congestión inicial de TCP" . LWN . Consultado el 10 de octubre de 2012 .
- ^ Nick O'Neill. " ¿Qué hace que su sitio vaya lento? Podría ser el botón Me gusta ". AllFacebook , 10 de noviembre de 2010. Recuperado el 12 de septiembre de 2012.
- ^ 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 RDSI . 17 : 1-14. CiteSeerX 10.1.1.136.8108 . doi : 10.1016 / 0169-7552 (89) 90019-6 .
- ^ Allman, M .; Paxson, V. (septiembre de 2009). Control de congestión de TCP . IETF . segundo. 3.1. doi : 10.17487 / RFC5681 . RFC 5681 . Consultado el 4 de marzo de 2021 .
- ^ Fall, Kevin; Sally Floyd (julio de 1996). "Comparaciones basadas en simulación de Tahoe, Reno y SACK TCP" (PDF) . Revisión de comunicaciones informáticas . 26 (3): 5-21. CiteSeerX 10.1.1.586.2403 . doi : 10.1145 / 235160.235162 . S2CID 7459148 .
- ^ a b c d e f Abbasloo, S .; Xu, Y .; Chao, HJ (2019). "C2TCP: un TCP celular flexible para cumplir con los 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 .
- ^ a b c d Abbasloo, S .; Iluminado.; Xu, Y .; Chao, HJ (mayo de 2018). "TCP de retardo controlado celular (C2TCP)". Conferencia y talleres de trabajo en red de la IFIP 2018 : 118–126. arXiv : 1807.02689 . Código bibliográfico : 2018arXiv180702689A . doi : 10.23919 / IFIPNetworking.2018.8696844 . ISBN 978-3-903176-08-9. S2CID 49650788 .
- ^ a b c d Abbasloo y col. 2019 .
- ^ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van (2016). "BBR: Control de congestión basado en la congestión" . Cola . 14 (5): 20–53. doi : 10.1145 / 3012426.3022184 . Consultado el 6 de diciembre de 2016 .
- ^ Kurose y Ross , 2008 , p. 284.
- ^ Kurose y Ross 2012 , p. 277.
- ^ "Análisis de rendimiento de los algoritmos de control de congestión de TCP" (PDF) . Consultado el 26 de marzo de 2012 .
- ^ "Registro de cambios de DD-WRT" . Consultado el 2 de enero de 2012 .
- ^ VasanthiN., V .; SinghM., Ajith; Kumar, Romen; Hemalatha, M. (2011). Das, Vinu V; Thankachan, Nessy (eds.). "Evaluación de protocolos y algoritmos para mejorar el rendimiento de TCP sobre redes inalámbricas / cableadas". Congreso Internacional de Inteligencia Computacional y Tecnología de la Información . Comunicaciones en Informática y Ciencias de la Información. Saltador. 250 : 693–697. doi : 10.1007 / 978-3-642-25734-6_120 . ISBN 978-3-642-25733-9.
- ^ "Copia archivada" . Archivado desde el original el 11 de octubre de 2007 . Consultado el 4 de marzo de 2007 .CS1 maint: copia archivada como título ( enlace )
- ^ V., Jacobson; RT, Braden. Extensiones de TCP para rutas de retardo largo . doi : 10.17487 / RFC1072 . RFC 1072 .
- ^ 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 de corta distancia". Revista de aplicaciones informáticas y de red . 55 : 181-190. doi : 10.1016 / j.jnca.2015.05.011 . S2CID 2645016 .
- ^ "Reducción de tasa proporcional para TCP" . Consultado el 6 de junio de 2014 .
- ^ Corbet, Jonathan. "LPC: Hacer que la red sea más rápida" . Consultado el 6 de junio de 2014 .
- ^ "Linux 3.2 - principiantes del kernel de Linux" . Consultado el 6 de junio de 2014 .
- ^ a b "BBR: Control de congestión basado en la congestión" . Consultado el 25 de agosto de 2017 .
- ^ "Estimación de la tasa de entrega" . Consultado el 25 de agosto de 2017 .
- ^ "Control de congestión BBR [LWN.net]" . lwn.net .
- ^ "Actualización BBR" . datatracker.ietf.org .
- ^ "El control de congestión de TCP BBR llega a GCP: su Internet se ha vuelto más rápido" . Consultado el 25 de agosto de 2017 .
- ^ "TCP y BBR" (PDF) . Consultado el 27 de mayo de 2018 .
- ^ "Evaluación experimental del control de congestión BBR" (PDF) . Consultado el 27 de mayo de 2018 .
- ^ "Una evaluación del rendimiento de TCP BBRv2" . Consultado el 12 de enero de 2021 .
- ^ "TCP de retardo controlado celular (C2TCP)" . wp.nyu.edu . Consultado el 27 de abril de 2019 .
- ^ Alrshah, MA; Al-Maqri, MA; Othman, M. (junio de 2019). "Elastic-TCP: Algoritmo de control de congestión flexible para adaptarse a redes de alta BDP" . Revista de sistemas IEEE . 13 (2): 1336-1346. arXiv : 1904.13105 . Código bibliográfico : 2019ISysJ..13.1336A . doi : 10.1109 / JSYST.2019.2896195 .
- ^ Abbasloo, Soheil (3 de junio de 2019), GitHub - Soheil-ab / natcp , consultado el 5 de agosto de 2019
- ^ Yuan, Cao; Tan, Liansheng; Andrew, Lachlan LH; Zhang, Wei; Zukerman, Moshe (5 de septiembre de 2008). "Un esquema FAST TCP generalizado" . Comunicaciones informáticas . 31 (14): 3242–3249. doi : 10.1016 / j.comcom.2008.05.028 . hdl : 1959,3 / 44051 .
- ^ a b "Grupo de redes de arroz" .
- ^ "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.
- ^ "XCP @ ISI" .
- ^ "TPC de alta velocidad" (PDF) . www.csc.lsu.edu .
- ^ "Copia archivada" . Archivado desde el original el 3 de abril de 2011 . Consultado el 5 de marzo de 2011 .CS1 maint: copia archivada como título ( enlace )
- ^ Benaboud, H .; Berqia, A .; Mikou, N. (2002). "Un estudio analítico del algoritmo CANIT en protocolo TCP". Revisión de la evaluación del desempeño de ACM SIGMETRICS . 30 (3): 20. doi : 10.1145 / 605521.605530 . S2CID 6637174 .
- ^ Rouhani, Modjtaba (2010). "Control de congestión de red neuronal no lineal basado en algoritmo genético para redes TCP / IP". 2010 2º Congreso Internacional de Inteligencia Computacional, Sistemas y Redes de Comunicaciones . págs. 1–6. doi : 10.1109 / CICSyN.2010.21 . ISBN 978-1-4244-7837-8. S2CID 15126416 .
- ^ "Resumen del proyecto de cinco nuevos algoritmos de control de congestión de TCP" .
- ^ "iTCP - Protocolo de transporte interactivo - Medianet Lab, Universidad Estatal de Kent" .
- ^ "Documento técnico: Zeta-TCP - Aceleración TCP inteligente, adaptativa y asimétrica" (PDF) . Consultado el 6 de diciembre de 2019 .
- ^ Lefteris Mamatas; Tobias Harks; Vassilis Tsaoussidis (enero de 2007). "Enfoques para el control de la congestión en redes de paquetes" (PDF) . Revista de Ingeniería de Internet . 1 (1). Archivado desde el original (PDF) el 21 de febrero de 2014.
- ^ "TCP de alta velocidad" . www.icir.org .
- ^ "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 .
- ^ "Bienvenido a Network Research Lab" . www.cs.ucla.edu .
- ^ "Control de congestión basado en ecuaciones para aplicaciones de unidifusión" . www.icir.org .
- ^ Katabi, Dina; Handley, Mark; Rohrs, Charlie (2002). "Control de congestión para redes de productos con alto retardo de ancho de banda" . Actas de la Conferencia de 2002 sobre aplicaciones, tecnologías, arquitecturas y protocolos para comunicaciones informáticas - SIGCOMM '02 . Nueva York, Nueva York, EE.UU .: ACM Press: 89. doi : 10.1145 / 633025.633035 . ISBN 1-58113-570-X.
- ^ "MaxNet - Control de congestión de señalización explícita estable y máxima justa y mínima" . netlab.caltech.edu .
Fuentes
- Kurose, James ; Ross, Keith (2008). Redes de computadoras: un enfoque de arriba hacia abajo (4ª ed.). Addison Wesley. ISBN 978-0-13-607967-5.
- Kurose, James ; Ross, Keith (2012). Redes de computadoras: un enfoque de arriba hacia abajo (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 Mobile Edge" . Renton, WA: Asociación USENIX. Parámetro desconocido
|book-title=
ignorado ( ayuda );Cite journal requiere|journal=
( ayuda ) - Afanasyev, A .; N. Tilley; P. Reiher; L. Kleinrock (2010). "Control de congestión de host a host para TCP" (PDF) . Encuestas y tutoriales de comunicaciones de IEEE . 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) . Revisión de comunicación informática ACM SIGCOMM . 18 (4): 314–329. doi : 10.1145 / 52325.52356 .
enlaces externos
- Enfoques para el control de la congestión en redes de paquetes (PDF) , archivado desde el original (PDF) el 21 de febrero de 2014
- Papeles en control de congestión
- Página de inicio de TCP Vegas
- Allman, Mark; Paxson, Vern; Stevens, W. Richard (abril de 1999). "Retransmisión rápida / Recuperación rápida" . Control de congestión de TCP . IETF . segundo. 3.2. doi : 10.17487 / RFC2581 . RFC 2581 . Consultado el 1 de mayo de 2010 .
- Algoritmos de manejo y prevención de congestión de TCP: la guía de TCP / IP