Home Artículos técnicos Mejora del rendimiento de la red con el ajuste dinámico de control de congestión
Applications

Mejora del rendimiento de la red con el ajuste dinámico de control de congestión

About The Author

Outline

El algoritmo de control de congestión (CCA) del protocolo de control de transmisión (TCP) regula la cantidad de datos que deben enviarse entre los clientes y los servidores para maximizar la utilización del ancho de banda disponible y evitar la congestión. Desde su creación se han desarrollado otros CCA desde su creación, 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 el rendimiento de BBR para flujos con tiempo de ida y vuelta bajo (RTT) y retransmisiones bajas fue peor que CÚBICO. Por último, los beneficios de BBR solo se vieron para el tráfico orientado al cliente, mientras que las conexiones de back-office (RTT bajo y retransmisiones insignificantes) funcionaron mejor con CUBIC.

Edgecast, ahora Edgio, es una CDN global multi-tenant que entrega tráfico web para muchos clientes grandes (VOD y en vivo) de transmisión de video. Dado que las afinaciones de control de congestión que utilizan BBR para un cliente pueden afectar negativamente el rendimiento de otro cliente, y una habilitación general puede resultar en la 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 y dinámica función de ajuste de control de congestión que hemos puesto a disposición de todos nuestros clientes.

Insights sobre la metodología

Tal vez la entrada más importante para un sistema tan dinámico son los datos que lo alimentan. Nuestro mecanismo dinámico de ajuste de control de congestión 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 kernel Linux a través de NetLink y la transmite a través de Kafka en 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, hace poco activamos nuestra ventana de congestión inicial IPv6 y supervisamos el rendimiento de las ganancias 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 administrar el gran número de sockets vistos por nuestros caches de borde (en comparación con los servidores M-Lab) y la capacidad de exportar los datos en formato de protobuf. Manténgase atento, planeamos abrir el código xTCP pronto.

En la siguiente figura, mostramos la visión general de nuestro sistema. Los datos xTCP se recopilan a escala de todos nuestros caché de borde transmitidos a Kafka. Los datos xTCP se recopilan en un clúster de ClickHouse, que alimenta nuestro análisis de datos de red, incluido el controlador BBR, que detecta los prefijos de bajo rendimiento en cada ventana 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 consistentemente de bajo rendimiento en cada punto de borde de presencia (POP) para evitar chancadas entre CÚBICOS y BBR en duraciones cortas. Y, como se señaló anteriormente, activamos selectivamente BBR para solicitudes donde el tamaño del archivo es mayor de 100KB. Un flujo CÚBICO ajustado 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 consistentemente prefijos de peor rendimiento en las últimas horas. Esta detección funciona cada 5 minutos. Si bien el número total de prefijos seleccionados por cada borde pop 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 pop de Chicago) son muy pocas.

Gráfico 2. El número de prefijos nuevos seleccionados por ronda de generación de configuración es bajo.

Si hay alguno, 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 a nivel mundial.

Mejora de la actuación profesional

Nos complace informar de que la habilitación de BBR a través de nuestro perímetro en todo el mundo ha mostrado considerables mejoras de rendimiento. 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 la BBR para los prefijos de menor rendimiento, esperamos que nuestra tasa de entrega de percentiles más baja (el peor de los casos) mejore.

La siguiente figura muestra la mejora en la tasa de entrega de percentiles 5 y 10 en nuestro pop de Los Ángeles tan pronto como se activó el cambio de BBR.

Gráfico 3. Se observaron mejoras en las tasas de entrega de los percentiles 5 y 10 después del cambio de BBR.

Del mismo modo, en la siguiente figura, mostramos una mejora considerable (~2x) en la tasa de entrega de percentiles más bajo para un ISP residencial grande en los EE.UU. Tan pronto como activamos dinámicamente BBR en todos nuestros POP norteamericanos.

Gráfico 4. Se observaron mejoras para un ISP residencial grande después de habilitar dinámicamente 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 se tradujo en un aumento de la buena posición. En general, el 10mo percentil goodput aumentó un 12%.

Gráfico 5. El décimo percentil goodput 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 a 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 del 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 en los rebuffers para la transmisión de video.