CUBIC es un protocolo de control de congestión para TCP (protocolo de control de transmisión) y

el algoritmo TCP predeterminado actual en Linux. El protocolo modifica la función de crecimiento

de ventana lineal de los estándares TCP existentes para que sea una función cúbica con el fin de
mejorar la escalabilidad de TCP en redes rápidas y de larga distancia. También logra asignaciones
de ancho de banda más equitativas entre flujos con diferentes RTT (tiempos de ida y vuelta) al
hacer que el crecimiento de la ventana sea independiente del RTT, por lo que esos flujos
aumentan su ventana de congestión al mismo ritmo. Durante el estado estacionario, CUBIC
aumenta el tamaño de la ventana de manera agresiva cuando la ventana está lejos del punto de
saturación, y lentamente cuando está cerca del punto de saturación. Esta característica permite
que CUBIC sea muy escalable cuando el ancho de banda y el producto de retardo de la red son
grandes y, al mismo tiempo, son altamente estables y también de flujos TCP de justos a estándar.
La implementación de CUBIC en Linux ha pasado por varias actualizaciones. Este documento
documenta su diseño, implementación, rendimiento y evolución como el algoritmo TCP
predeterminado de Linux.

¡El internet es diferente ahora!

Los enfoques de Tahoe y Reno se desarrollaron a finales de los años 80 y 90, y funcionaron
entonces, pero internet ha cambiado mucho desde entonces. Cabe destacar que ahora existen
redes de ancho de banda más largas y más altas (redes largas y pesadas). Para aprovechar al
máximo estas redes, los remitentes de TCP deben enviar ventanas de congestión mucho más altas.

Como Tahoe y Reno crecen linealmente después de cruzar el umbral de inicio lento, si un ancho de
banda mucho más disponible en un enlace, estos algoritmos tardarán mucho tiempo en
"descubrir" el ancho de banda disponible.

¿Por qué es esto útil en el control de la congestión?

Resulta que puede aprovechar esta propiedad al diseñar un algoritmo de control de
congestión:

Si la ventana de congestión crece como una función cúbica de tiempo desde la última
caída del paquete, y el punto de inflexión se configura para que sea el tamaño de la
ventana de congestión en la última caída, la ventana tiene el siguiente comportamiento:

Empieza a crecer muy rápido

A medida que el algoritmo se acerca a la ventana en la última gota, la ventana de

congestión comienza a crecer más lentamente
Si la ventana de congestión llega al punto en el que se produjeron las caídas la última vez y
no experimenta una caída, comience a crecer lentamente nuevamente, pero aumente
más rápidamente.
La parte cóncava de esto, donde la ventana comienza a crecer rápidamente pero luego se
ralentiza, y la parte convexa de esto se puede pensar en dos fases diferentes. Durante la
fase cóncava, la ventana de congestión se está acercando al lugar donde se perdió un
paquete la última vez, y ralentiza su crecimiento para ser justo para los remitentes
tradicionales de TCP. Si el algoritmo llega allí sin experimentar caídas, puede pasar a una
fase "exploratoria", en la que crece rápidamente para descubrir el nuevo ancho de banda
disponible. http://squidarth.com/rc/programming/networking/2018/08/01/congestion-
cubic.html

On a simulated 15 Mbps fixed-rate link with eight senders contending and an RTT of 150 ms, a
computer-generated congestioncontrol algorithm achieved the following improvements in median
throughput and reductions in median queueing delay over these existing protocols: