El algoritmo de control de congestión (CCA) del protocolo de control de transmisión (TCP) rige la cantidad de datos que se deben enviar entre clientes y servidores para maximizar la utilización del ancho de banda disponible y evitar la congestión. Desde sus inicios se han desarrollado otros CCA desde sus inicios, como el ancho de banda de cuello de botella, el tiempo de propagación de ida y vuelta (TCP BBR) y EL CÚBICO. Mientras que TCP BBR y CUBIC tienen como objetivo evitar la congestión, entender su efectividad ha sido una misión continua para nuestros equipos de ingeniería e investigación.
TCP BBR tiene como objetivo lograr un mayor rendimiento mediante el uso de retardo de paquetes como un indicador en lugar de pérdida de paquetes. Sin embargo, nuestra investigación anterior informó que la BBR funciona mal en todos los casos. Específicamente, nuestra evaluación concluyó que había poco o ningún beneficio en el rendimiento de archivos pequeños (<100KB). Además, observamos que el rendimiento de la RBBR para los flujos con tiempo de ida y vuelta (RTT) bajo y retransmisiones bajas fue peor que CÚBICO. Finalmente, los beneficios de BBR solo se vieron para el tráfico orientado al cliente, mientras que las conexiones de back-office (baja RTT y retransmisiones insignificantes) se desempeñaron mejor con CUBIC.
Edgecast, ahora Edgio, es una CDN global multi-inquilino que ofrece tráfico web para muchos grandes clientes de transmisión de video (VOD y en vivo). Dado que los ajustes de control de congestión que utilizan BBR para un cliente pueden afectar negativamente el rendimiento de otro cliente, y una habilitación general podría resultar en una degradación del rendimiento en algunos escenarios, implementamos un mecanismo para detectar casos en los que BBR proporciona un rendimiento mejorado y puede habilitarlo dinámicamente para todos los clientes de CDN. El resultado es una nueva función de ajuste de control de congestión dinámica que hemos puesto a disposición de todos nuestros clientes.
Insights sobre la metodología
Tal vez la entrada más importante a un sistema tan dinámico son los datos que lo impulsan. Nuestro mecanismo de ajuste de control de congestión dinámico se encuentra en la parte superior de nuestra recopilación de datos de socket a gran escala, que exporta datos de rendimiento de socket TCP (xTCP) de todas las cachés de borde. Específicamente, extrae información de la estructura tcp_INFO del núcleo Linux a través de NetLink y la transmite a través de Kafka a un clúster de Clickhouse. Tener estos datos de rendimiento de socket a escala nos permite monitorear el rendimiento de las conexiones a nuestros servidores de caché con una granularidad muy alta. XTCP ha demostrado ser una herramienta poderosa para muchas optimizaciones de CDN. Por ejemplo, recientemente cambiamos nuestra ventana de congestión inicial IPv6 y supervisamos las ganancias de rendimiento usando xTCP.
XTCP es similar al trabajo realizado por la herramienta tcp-INFO de Google Measurement Lab (M-Lab), con diferencias significativas provenientes de las optimizaciones necesarias para gestionar el gran número de sockets vistos por nuestros cachés perimetrales (en comparación con los servidores M-Lab) y la capacidad de exportar los datos en formato protobuf. Manténgase atento, planeamos abrir xTCP de código abierto pronto.
En la siguiente figura, mostramos la visión general de nuestro sistema. Los datos xTCP se recopilan a escala de todos nuestros cachés de borde transmitidos a Kafka. Los datos xTCP se recopilan en un clúster de Clickhouse, que impulsa el análisis de datos de red, incluido el controlador BBR, que detecta los prefijos de bajo rendimiento en cada pop de borde.
Gráfico 1. Descripción general de la recopilación de datos mediante un push de configuración xTCP y BBR.
Si bien queremos mantener la naturaleza dinámica de nuestro flujo de trabajo, también necesitamos seleccionar prefijos de bajo rendimiento consistentemente en cada punto de presencia (POP) para evitar flip-flopping entre CÚBICO y BBR en duraciones cortas. Y, como se señaló anteriormente, activamos selectivamente BBR para las solicitudes donde el tamaño del archivo es mayor de 100KB. Un flujo CÚBICO afinado funciona mejor para archivos pequeños.
El controlador BBR utiliza dos métricas para evaluar el estado de cada prefijo de cliente observado:
- Ciclo de trabajo: ¿Cuánto tiempo duró un prefijo (/24 o /56) en el grupo de rendimiento del percentil 20 inferior?
- Tasa de solapa: ¿Con qué frecuencia aparece y desaparece el prefijo del grupo de rendimiento del percentil 20 inferior, es decir, cambio de estado?
El algoritmo entonces detecta constantemente prefijos de peor rendimiento en las últimas horas. Esta detección se ejecuta cada 5 minutos. Mientras que el número total de prefijos seleccionados por pop de borde podría ser de cientos, observamos que el rendimiento del prefijo sigue siendo relativamente consistente. Los mismos prefijos se seleccionan regularmente, y las nuevas adiciones en cada ronda (como se muestra en la siguiente figura del Chicago POP) son muy pocas.
Gráfico 2. El número de nuevos prefijos seleccionados por ronda de generación de configuración es bajo.
Si los hay, se seleccionan nuevos prefijos para habilitar BBR, y se genera una configuración, se pasa a través de un paso de validación y se envía a nuestras cachés de borde globalmente.
Aumento del rendimiento
Nos complace informar que habilitar BBR en todo el mundo ha mostrado mejoras de rendimiento considerables. Una métrica clave que rastreamos desde los datos del socket xTCP es la tasa de entrega reportada en tcp_INFO. Dado que activamos dinámicamente el BBR para los prefijos de menor rendimiento, esperamos que nuestra tasa de entrega de percentil más bajo (en el peor de los casos) mejore.
La siguiente figura muestra la mejora en la tasa de entrega de percentil 5 y 10 en nuestro POP de Los Ángeles tan pronto como el cambio de BBR fue activado.
Gráfico 3. Se observaron mejoras en las tasas de parto de los percentiles 5 y 10 después del cambio de la RBG.
Del mismo modo, en la siguiente figura, mostramos una mejora considerable (~2x) en la tasa de entrega de percentil más baja para un ISP residencial grande en los EE.UU. Tan pronto como activamos dinámicamente el BBR en todos nuestros COP norteamericanos.
Gráfico 4. Se observaron mejoras para un ISP residencial grande después de habilitar dinámicamente el BBR.
La tasa de entrega extraída de TCP-INFO proporciona una buena estimación del rendimiento visto por el cliente. Sin embargo, el indicador de rendimiento más preciso es el rendimiento visto en los registros de acceso HTTP para la conexión del cliente, es decir, goodput.
Medimos el goodput desde un servidor de caché de borde. Como se muestra en el gráfico siguiente, el cambio dio lugar a un aumento de los ingresos. En general, el valor del percentil 10 aumentó un 12%.
Gráfico 5. El valor del percentil 10 aumentó un 12%.
Un agradecimiento especial al equipo de desarrollo de BBR en Google por su increíble trabajo en BBRv1 y su continuo esfuerzo en BBRv2. Esperamos con interés BBRv2 y continuaremos impulsando cambios relevantes en nuestra plataforma en breve. Felicitaciones a Sergio Ruiz, Joseph Korkames, Joe Lahoud, Juan Bran, Daniel Lockhart, Ben Lovett, Colin Rasor, Mohnish Lad, Muhammad Bashir, Zach Jones y Dave Andrews en Edgecast por apoyar este cambio durante el desarrollo, las pruebas y el despliegue. El equipo de ingeniería de Edgio desea agradecer especialmente a Dave Seddon por contribuir al desarrollo de la herramienta xTCP que impulsó gran parte del análisis.
Con el ajuste dinámico de control de congestión, los clientes de Edgio ahora obtienen automáticamente mejoras de rendimiento para sus clientes de bajo rendimiento y mejoran su rendimiento final, lo que resulta en una entrega web más rápida y una reducción de los rebuffers para la transmisión de vídeo.
