Optimización y Aceleración TCP

BTA - Bequant TCP Acceleration

La funcionalidad BTA, parte integral del producto Bequant BQN, acelera el tráfico TCP, acelerando la subida y la bajada de datos de Intenet. TCP es el protocolo de transporte más utilizado por los servicios y aplicaciones de Internet. El buen diseño de TCP es uno de los motivos del éxito de Internet, pero aún así, TCP puede ser el cuello de botella cuando hay pérdidas de paquetes, variabilidad de latencias (jitter), latencias de red elevadas o enlaces inalámbricos, pues en todas esas condiciones tiende transmitir a una velocidad inferior a la que la red podría soportar. Bequant ha patentado una implementación de TCP (véase nuestra patente ya concedida EP3135009) que puede incrementar las velocidades del tráfico TCP por encima de un 100% en aplicaciones reales (no solamente en pruebas de laboratorio), al tiempo que previene el problema de retardos excesivos (bufferbloat) y el de pérdidas de paquetes.

El TCP de Bequant se adapta a distintas condiciones de red gracias a su algoritmo de auto-aprendizaje, pero destaca especialmente cuando hay enlaces inalámbricos (WiFi, LTE, 3G, WiMax...), superando en rendimiento a otras implementaciones de TCP, incluyendo las variantes Cubic de Linux, FastTCP de Akamai y BBR de Google.

Este vídeo detalla el funcionamiento de la funcionalidad BTA.

Proxy TCP Transparente

Siendo un proxy TCP transparente (de acuerdo con la RFC 3135, como PEP con ACKs locales), el BTA hace que los datos aparezcan más cercanos a los clientes, y más cerca significa una entrega más rápida. Este tipo de proxys han sido utilizados desde hace muchos años en redes con satélites y en grandes redes móviles celulares. Nuestro producto pone esta funcionalidad avanzada a disposición de todo tipo de redes. A diferencia de otros proxies que no son transparentes, el BTA no cambia las direcciones IP, los puertos o los números de secuencia de TCP, de forma que las conexiones TCP pueden sobrevivir incluso si el tráfico de datos es súbitamente enrutado a través de un camino directo que circunvale el BTA.

Este vídeo detalla el funcionamiento de un proxy TCP transparente.

TCP más rápido

El TCP de Bequant detecta la congestión basándose en medidas de la tasa de entrega, tal y como se describe en nuestra patente ya concedida. La implementación de TCP CUBIC, la opción por defecto en Linux y la más utilizada, detecta la congestión mediante pérdidas de paquetes y al inicio de la conexión por medio de medidas de latencia. Otras variantes en uso en Internet son el BBR de Google, que detecta la congestión con medidas de la tasa de entrega, y el FastTCP de Akamai, basado sobre todo en medidas de latencia de red. Nuestro algoritmo de detección de congestión mejorado permite que nuestro TCP sea más agresivo cuando no hay congestión y se frene en congestiones reales, todo ello en un entorno complejo, con enlaces inalámbricos, pérdida de paquetes o latencias de red elevadas.

Despliegue

El BTA se ejecuta sobre la plataforma BQN de Bequant, que se puede desplegar en servidores Intel comerciales, máquinas virtuales (sobre hipervisores KVM o VMware vSphere) o integrado en blades de equipos de red.

La solución de aceleración y optimización de TCP de Bequant ha sido probada contra dos de las variantes de TCP más ampliamente utilizadas: CUBIC, que es el TCP por defecto de Linux, y BBR, variante desarrollada por Google.

La configuración del test consiste en:

Cliente: navegador Google Chrome sobre un teléfono móvil con Android 7.1.2.

Servidor: nginx en un Linux con kernel 4.10.3, con pilas con ambas variantes de TCP Cubic y BBR.

Red de accesso: 4G LTE de Vodafone España, y WiFi 802.11ac (router Mikrotik hAP ac) a través de una fibra simétrica de 300 Mbps de Telefónica.

Router para generar la latencia del lado de Internet: basado en Linux, con netem.

El siguiente diagrama muestra una clara ventaja del TCP de Bequant frente a Cubic y BBR en redes 4G LTE. El TCP de Bequant no sufre incrementos significativos de retransmisiones y solo un pequeño incremento de bufferbloat: el RTT medio desde el BQN hacia el cliente subió hasta los 45ms, mientras que estaba en torno a los 35ms para BBR y Cubic (el RTT mínimo de una conexión era de 25ms).

Velocidad de descarga (en Mbps) para una red de acceso 4G LTE con pérdidas de paquetes mínimas, para diferentes tamaños de descarga (100 KB en la primera fila, 1 MB en la segunda fila y 5 MB en la fila de abajo), y para diferentes retardos hacia Internet (ningún retardo en la columna de la izquierda, retardo de 30ms en la columna de en medio y retardo de 100ms en la columna de la derecha).

El TCP de Bequant también es superior a las variantes Cubic y BBR en un acceso WiFi 802.11ac, a través de una fibra de acceso de 300 Mbps, tal como muestra la siguiente gráfica. En este caso, el TCP de Bequant tampoco muestra un incremento significativo de las retransmisiones y solo un ligero aumento del bufferbloat: el RTT medio desde el BQN hacia el cliente subió hasta los 16ms, mientras que estaba en torno a los 13ms para BBR y Cubic (el RTT mínimo de una conexión era de 9ms).

Velocidad de descarga (en Mbps) para una red de acceso FTTH y WiFi 802.11ac con pérdidas de paquetes mínimas, para diferentes tamaños de descarga (100 KB en la primera fila, 1 MB en la segunda fila y 5 MB en la fila de abajo), y para diferentes retardos hacia Internet (ningún retardo en la columna de la izquierda, retardo de 30ms en la columna de en medio y retardo de 100ms en la columna de la derecha).

Los resultados con 0ms de retardo hacia Internet muestran el comportamiento del TCP de Bequant como una pila (stack) de servidor, mientras los resultados de 30ms y 100ms muestran las mejoras obtenidas cuando el contenido es descargado desde servidores lejanos a través de un proxy TCP transparente.

Resultados de aceleración en redes inalámbricas con pérdidas

Las dos redes de acceso utilizadas en las pruebas mostraron mínimas pérdidas de paquetes. Se introdujeron pérdidas de paquetes del 0.5% mediante un generador aleatorio (netem en un router basado en Linux), para estudiar los efectos de las pérdidas en el rendimiento.

La configuración del test consiste en:

Cliente: navegador Google Chrome sobre un teléfono móvil con Android 7.1.2.

Servidor: nginx en un Linux con kernel 4.10.3, con pilas con ambas variantes de TCP Cubic y BBR.

Red de acceso: 4G LTE de Vodafone España, y WiFi 802.11ac (router Mikrotik hAP ac) a través de una fibra simétrica de 300 Mbps de Telefónica.

Router para generar la latencia del lado de Internet: basado en Linux, con netem.

El siguiente diagrama muestra que la ventaja del TCP de Bequant frente a Cubic y BBR se mantienen en redes 4G LTE con pérdidas. El TCP de Bequant no sufre incrementos significativos de retransmisiones respecto a las otras variantes y el RTT medio desde el nodo BQN hacia el cliente fue muy similar al obtenido en el caso sin pérdidas.

Velocidad de descarga (en Mbps) para una red de acceso 4G LTE con pérdidas de paquetes aleatorias del 0.5% , para diferentes tamaños de descarga (100 KB en la primera fila, 1 MB en la segunda fila y 5 MB en la fila de abajo), y para diferentes retardos hacia Internet (ningún retardo en la columna de la izquierda, retardo de 30ms en la columna de en medio y retardo de 100ms en la columna de la derecha).

Con pérdidas de paquetes, el TCP de Bequant también es superior a las variantes Cubic y BBR con un acceso WiFi 802.11ac a través de FTTH, como se muestra en el siguiente diagrama. Se ve que Cubic es especialmente lento con pérdidas aleatorias y descargas grandes. El TCP de Bequant no mostró un incremento significativo de retransmisiones en relación con las otras variantes y el RTT medio entre el nodo BQN y el cliente fue muy similar al medido sin pérdidas.

Velocidad de descarga (en Mbps) para una red de acceso FTTH y WiFi 802.11ac con pérdidas de paquetes aleatorias del 0.5%, para diferentes tamaños de descarga (100 KB en la primera fila, 1 MB en la segunda fila y 5 MB en la fila de abajo), y para diferentes retardos hacia Internet (ningún retardo en la columna de la izquierda, retardo de 30ms en la columna de en medio y retardo de 100ms en la columna de la derecha).