El ancho de banda de cuello de botella y el tiempo de propagación de ida y vuelta (BBR) es un algoritmo de control de congestión TCP que ha ganado una atención significativa del mercado debido a su capacidad de ofrecer un mayor rendimiento según lo informado por muchos proveedores de contenido. En esta publicación, evaluamos BBR (versión 1) en el contexto de las cargas de trabajo de la red de entrega de contenido (CDN) de Verizon Media, ahora Edgio, que ofrece volúmenes significativos (múltiples Tbps) de actualizaciones de software y streaming de video, y cuantifica los beneficios y el impacto en el tráfico. Esperamos que tal evaluación en una CDN grande ayude a otros proveedores de contenido a elegir el protocolo de control de congestión adecuado para su tráfico.
Antecedentes
Muchos proveedores de contenido e investigadores académicos han descubierto que BBR proporciona mayor rendimiento que otros protocolos como TCP-Cubic. A diferencia de los algoritmos de control de congestión basados en pérdidas, como el ubicuo TCP-Cubic, BBR tiene un paradigma de operación diferente: Actualiza continuamente la cantidad de datos que pueden estar en vuelo basándose en el RTT mínimo que la sesión ha visto hasta ahora para evitar el búferbloat. Para obtener más información sobre el funcionamiento de BBR, eche un vistazo a la publicación original de Google aquí.
Mediciones y Análisis
Con el fin de entender el potencial de BBR en nuestra CDN, evaluamos BBR en múltiples etapas, midiendo el impacto en los flujos de TCP desde unos pocos puntos de presencia (POP). Los POP representan una concentración de servidores de almacenamiento en caché ubicados en grandes áreas metropolitanas. Inicialmente, realizamos una prueba BBR a pequeña escala en un POP y también realizamos una prueba POP completa, con todos los flujos hacia los clientes que ejecutan BBR. Para identificar los beneficios que los clientes experimentarían, medimos el rendimiento de nuestros registros de servidor web proxying internos durante la prueba, así como el análisis de nivel de socket.
Métricas a evaluar
Nuestra CDN multi-inquilino ve una gran variedad de tráfico de clientes. Muchos clientes tienen muchos objetos pequeños, mientras que otros tienen objetos multi-gigabytes mucho más grandes. Por lo tanto, es crucial identificar métricas de éxito que capturen ganancias reales de rendimiento en diferentes patrones de tráfico. En particular, para esta evaluación, identificamos el rendimiento y los tiempos de finalización del flujo TCP como los parámetros de éxito. En la Figura 1, mostramos un mapa de calor de los tamaños de objeto comunes solicitados a la CDN vs. El tiempo necesario para servirlos. El gradiente de color indica el número de solicitudes en cada categoría. Estos son números representativos de un pequeño conjunto de servidores, suficientes para capturar solo el comportamiento común.
Gráfico 1 Mapa de calor que muestra tamaños de objetos comunes.
El mapa de calor nos da una comprensión de los diferentes patrones de solicitud. En general, obtener un mayor rendimiento es el mejor indicador de la ganancia de rendimiento. Sin embargo, el rendimiento como medida puede ser muy ruidoso, especialmente para los casos en los que el tamaño del objeto es pequeño (menos de unos pocos MBs). Por lo tanto, en base a una evaluación separada de qué tamaños proporcionan la evaluación más confiable del rendimiento, utilizamos solo el tamaño de objeto mayor a 3 MB para las evaluaciones del rendimiento. Para tamaños de objetos inferiores a 3 MB, los tiempos de finalización del flujo de seguimiento son una mejor métrica.
Como primer paso en nuestra evaluación, habilitamos BBR en algunos servidores en un POP en Los Ángeles y monitoreamos el rendimiento y los tiempos de finalización del flujo para todos los flujos TCP. Los siguientes resultados examinan algunos estudios de casos específicos de proveedores de servicios de Internet.
Un gran proveedor inalámbrico
La Figura 2 muestra la diferencia una vez que se activó el BBR.
Gráfico 2 Impacto en el rendimiento para los clientes de un gran proveedor inalámbrico cuando BBR se activó (prueba) en comparación con los flujos cúbicos (control). Izquierda: Mediciones de rendimiento durante dos días. La línea azul vertical indica cuándo se activó BBR. Aquí vemos una mejora general de alrededor de 6-8% con BBR. Derecha: Un CDF del rendimiento del 5to percentil. Los flujos de BBR muestran una mejora significativa.
Para este proveedor inalámbrico, tan pronto como habilitamos BBR, en promedio, vimos una mejora del rendimiento del 6-8%. También vimos tiempos de finalización de flujo TCP más bajos en general. Este hallazgo está de acuerdo con otros informes de Spotify, Dropbox y YouTube, donde se observa una clara ganancia en el rendimiento en las redes inalámbricas donde la pérdida de paquetes es común, pero eso no es necesariamente un indicador de congestión.
Un gran proveedor de línea fija
A continuación, examinamos el rendimiento de un gran proveedor de línea fija. Aquí también vimos tanto el rendimiento (para objetos grandes) como el tiempo de finalización del flujo (mostrado en la Figura 3) mejoras usando BBR.
Gráfico 3 El tiempo promedio que se tarda en completar un flujo para un proveedor de línea fija grande. Los flujos BBR (test) muestran menos fluctuaciones y tardaron menos tiempo en finalizar la transferencia de datos. Los beneficios son más impactantes para objetos más grandes. Sin embargo, vemos jitter similar para tamaños de archivo grandes para Cubic y BBR.
Las ganancias reportadas por estas pruebas muestran resultados muy prometedores para el tráfico del lado del cliente.
Dado que estas ganancias están en una vista agregada, decidimos profundizar un poco más para comprobar si todos los flujos TCP en el POP vieron el beneficio de usar BBR; o si algunos flujos TCP sufrieron, y cuáles?
En el borde de CDN, realizamos cuatro tipos diferentes de sesiones TCP:
- Pop-to-Client (como se muestra arriba)
- Pop-to-pop (entre centros de datos)
- Comunicación intra-pop (entre los cachés del mismo pop)
- Pop-to-Origin (POP al centro de datos de origen del cliente)
Para este estudio, consideramos los flujos POP-to-Client, POP-POP e Intra-POP, ya que el borde-to-origen no es tan alto como los otros tres.
Tráfico pop-to-pop e intra-pop
También es importante evaluar el impacto en estos flujos TCP, ya que en muchos casos estos flujos son bloqueadores para la entrega de clientes, como para el contenido dinámico.
Para el rendimiento del tráfico pop-to-pop e intra-pop, vimos una gran regresión en el rendimiento. La Figura 4 muestra el impacto en el tráfico intra-pop y pop-to-pop durante el mismo período de tiempo:
Gráfico 4 Impacto de rendimiento para el tráfico intra-pop y Pop-to-pop cuando BBR se activó (prueba) en comparación con los flujos cúbicos (control). Mediciones de rendimiento durante dos días. La línea azul vertical indica cuándo se activó BBR. El rendimiento disminuyó aproximadamente a la mitad con BBR.
Tales diferencias claras de rendimiento entre los flujos a los usuarios finales y entre centros de datos no se han informado en hallazgos anteriores. Tenemos que evaluar por qué estos flujos TCP particulares sufrieron; si se trata de un artefacto de hardware o configuraciones en nuestra CDN; y si es así, qué afinaciones necesitarían ser cambiadas.
A partir de investigaciones posteriores que utilizaron registros de acceso al servidor web y evaluaciones a partir de datos de socket del lado del servidor, se observó que, en presencia de flujos de RTT altos y bajos, los flujos de TCP que tienen RTT muy bajos sufrieron el uso de BBR. Además, evaluamos los casos en los que se transfirieron menos de 0.5KB de datos y encontramos que en la mayoría de los casos, la RBM se desempeñó de manera similar a Cubic.
Con base en estos hallazgos, concluimos que para nuestros patrones de tráfico, es mejor usar Cubic para comunicaciones intra-pop y pop-a-pop donde los RTT y las pérdidas son bajas. Para el tráfico del lado del cliente, vale la pena usar BBR.
Prueba completa POP
Para evaluar el beneficio de rendimiento de BBR a gran escala, realizamos una prueba POP completa en un POP en Río de Janeiro para todo el tráfico orientado al cliente de nuestra red en ese POP. Este POP hizo un estudio de caso interesante, ya que las limitaciones de ubicación y peering en la región resultan en RTT medianas más altas experimentadas por los clientes que en otras regiones.
Gráfico 5 Mejora del rendimiento utilizando BBR para el cliente, YA QUE muestra altas retransmisiones (ASN1).
Implementamos el cambio en el algoritmo de control de congestión y monitoreamos el rendimiento. Se muestra una CDF de rendimiento observado usando BBR vs. Cubic para los dos primeros ASES (Sistemas Autónomos) en Río. Como se ve en la Figura 5, un AS, en general, vio el beneficio de la BBR mientras que otro no lo hizo.
Para investigar el razonamiento detrás de él, buscamos otras métricas TCP recopiladas durante la prueba utilizando la utilidad ss. Se observa una clara distinción en la tasa de retransmisión entre estos dos ASES. Incluso para ASES con RTT más altas, BBR funciona bien solo para casos que tienen un alto número de retransmisiones, es decir, para ASES con menos pérdida Cubic no tiene razón para retroceder y funciona mejor que BBR. Sin embargo, es importante tener en cuenta que muchos de los parámetros de TCP Cubic han sido cuidadosamente afinados en nuestra CDN.
A continuación, investigamos si todas las conexiones del ASN1 mostradas en la Figura 5, mostraron una mejora en el rendimiento. La Figura 6 es un gráfico de tiempo tomado (menor implica mejor rendimiento) por BBR y conexiones cúbicas para diferentes tamaños de objeto. Aquí vemos que BBR solo comenzó a mostrar beneficios notables para objetos más grandes, en el orden de MBs. Vimos una instancia anómala usando BBR, pero no pudimos atribuirla a ningún problema particular relacionado con el protocolo de control de congestión.
Gráfico 6 Para ASES que muestran mejoras, el beneficio de BBR se ve para flujos de larga duración con archivos grandes.
¿Por qué sucede esto?
Hay dos dimensiones en estos resultados: Cúbico vs. BBR y BBR vs. BBR.
Cúbico vs. BBR
BBR es altamente reactivo a tamaños de búfer y RTT cuando estima el ancho de banda del cuello de botella. En el caso de los búferes grandes, donde las cajas intermedias podrían acumular una cola, el RTT estimado de BBR aumenta. Dado que no hay pérdida de paquetes, Cubic no retrocede en tales casos, en otras palabras, el tráfico estilo pop-to-pop, y por lo tanto Cubic logra un mayor rendimiento. En el caso de búferes pequeños, como los clientes inalámbricos, el búfer se llena rápidamente y resulta en una pérdida, por lo tanto, los flujos cúbicos retroceden y los flujos BBR funcionan mejor.
BBR vs. BBR
En este escenario, ningún flujo retrocede cuando hay una pérdida. Sin embargo, cuando dos flujos con diferentes RTT compiten por una parte del ancho de banda, el flujo que tiene un RTT más alto también tiene un RTT mínimo más grande y, por lo tanto, un producto de mayor retraso de ancho de banda. Así, ese flujo aumenta sus datos de vuelo a una velocidad mucho más rápida que el flujo que tiene un RTT más bajo. Esto conduce a la reasignación del ancho de banda a los flujos en orden descendente de RTT y los flujos con RTT más altos llenan los búferes más rápido que los flujos con RTT pequeños.
Reproduciendo resultados en un entorno de laboratorio
Para desarrollar una mayor comprensión de las interacciones entre los flujos, creamos un entorno de prueba en máquinas virtuales que captan el comportamiento que vimos en la producción. Identificamos formas de simular diferentes clases de tráfico en un servidor de borde de la siguiente manera:
El retraso del tráfico del cliente se estableció en ~50ms con pérdidas que van de 0,001 a 0,1 y el ancho de banda del cuello de botella de 50Mbps. Del mismo modo, para pop-to-pop solo la pérdida y el retraso se establecieron en ~15ms y 0,0001 a 0,01. Para el tráfico intra-pop, dejamos que las VM maximicen la capacidad disponible. Finalmente, las simulaciones se ejecutaron utilizando varios tamaños de objeto para capturar la naturaleza multi-inquilino de nuestro tráfico. Ejecutamos los tres patrones de tráfico en paralelo con una llegada exponencial de flujos para capturar una distribución de llegada de flujo al estilo poisson. La Figura 7 muestra la configuración de testbed.
El objetivo de esta prueba era reproducir los problemas que vemos en la prueba de producción, específicamente la caída en el rendimiento para pequeños flujos de RTT para tráfico intra-pop y pop-to-pop.
Gráfico 7 Configuración de laboratorio usando las utilidades KVM, iperf, netem y tc.
Usando esta configuración, ejecutamos la simulación cientos de veces con tráfico de fondo simulado, tanto cúbico como BBR, y medimos el tiempo necesario para completar los flujos. El objetivo del tráfico de fondo es simular un entorno similar a la producción. Muchos estudios existentes se centraron en ejecutar algunos flujos de cúbicos y BBR y evaluar sus comportamientos. Mientras que en esos casos es útil entender el comportamiento por flujo, representa mal las complejidades de una CDN grande y de alto volumen. Utilizamos el tiempo de finalización del flujo del lado del cliente como un indicador confiable ya que para tamaños de archivo pequeños el rendimiento puede ser ruidoso.
Gráfico 8 El tiempo toma los flujos de iperf. Izquierda: Flujos de clientes. Derecha: Flujos pop-to-pop. Tamaño del objeto: 3MB. BBR se desempeñó mejor que Cubic para flujos de clientes simulados.
Vimos el patrón reapareciendo en nuestro banco de pruebas también. En la Figura 8, mostramos un CDF del tiempo tomado por los flujos BBR y Cubic iperf en dos escenarios: Tráfico de cliente y tráfico pop-to-pop para archivos de 3MB (tamaño medio). Los flujos BBR no alcanzan a Cubic en una configuración de ancho de banda alto y baja pérdida. El tráfico de clientes (bajo ancho de banda) vio una mejora, es decir, el tiempo tomado por los flujos BBR fue menor. Sin embargo, la mejora para archivos pequeños es marginal. La reproducción de estos comportamientos en el entorno de prueba nos da la confianza de que son el resultado de la interacción entre diferentes tipos de flujo. Como resultado, cualquier implementación de BBR en la CDN debe ser consciente del impacto más amplio que puede tener en una mezcla de tipos de flujo.
Conclusión
De nuestra evaluación, observamos que los flujos de BBR no funcionan bien en todos los escenarios. Específicamente, el tráfico dentro de un centro de datos/punto de presencia (POP) y el tráfico entre centros de datos (POP-to-POP) sufrieron al usar BBR. En algunos casos extremos, el rendimiento se reduce a la mitad. Sin embargo, vimos una mejora del 6-8% en el rendimiento del tráfico Pop-to-Client.
En este post, describimos la evaluación de BBR (versión 1) en el contexto de nuestra CDN. Comenzamos con una pequeña prueba de unos pocos servidores en un solo pop y evaluamos diferentes variables que nos interesan como gran proveedor de contenidos. En una prueba POP completa a gran escala, nos dimos cuenta de que BBR ayudaría más en casos para ASES donde las retransmisiones son altas y sugieren que vale la pena usar BBR para archivos grandes.
¿A dónde vamos desde aquí?
Si habilitamos BBR a nivel del sistema (todos los flujos), corremos el riesgo de que el tráfico intra-pop y pop-to-pop sufra una disminución en el rendimiento.
Sin embargo, BBR ha mostrado potencial y está funcionando bien para el tráfico del lado del cliente. Esto nos motiva a habilitar selectivamente BBR para los clientes, potencialmente comenzando con los proveedores inalámbricos. Además, estos caminos tienen búferes poco profundos y pérdida inalámbrica, una situación ideal para que BBR funcione mejor que otros flujos cúbicos.
Esperamos que este esquema aporte cierta claridad en torno al uso de BBR en los grandes proveedores de contenido y sus implicaciones en los diferentes tipos de tráfico que pueden compartir cuellos de botella. La versión alfa de BBRv2 ya está disponible, que debería abordar algunos de estos problemas. Planeamos continuar evaluando las nuevas versiones de BBR y usar un controlador de transporte inteligente que elija el control de congestión correcto para el tipo correcto de flujo. Compartiremos más detalles al respecto en el futuro.
¡Gracias a la contribución de varios equipos de toda la organización que hicieron posible este análisis!
