La calidad de la transmisión de vídeo depende de que millones de cosas vayan bien, como gestionar una carga de trabajo que fluctúa constantemente o lidiar con “multitudes flash” cuando un gran número de espectadores ingresan a una transmisión al mismo tiempo. Es por eso que ofrecer una transmisión de video confiable y de alta calidad como parte de un servicio de pago, donde los espectadores esperan una experiencia similar a la de la televisión, requiere herramientas y métricas para articular con precisión los desafíos de rendimiento para que pueda saber dónde y cómo solucionar los problemas.
Las CDN son una solución indispensable en streaming de vídeo porque proporcionan escalabilidad de baja latencia bajo demanda en todo el mundo. Además de las optimizaciones que mejoran el camino, la CDN equilibra el crecimiento caótico de la audiencia que puede acompañar a una transmisión en vivo, ofreciendo un gran rendimiento al usuario final requiere una capa adicional de visibilidad, métricas, herramientas y automatización.
En esta publicación, revisaremos ejemplos de optimizaciones de rendimiento recientes que hemos realizado para un gran servicio de streaming vMVPD norteamericano, incluyendo:
- Métricas que utilizamos para mejorar/solucionar problemas de rendimiento
- Cómo definir el rendimiento y cómo medirlo
- Optimizaciones continuas que tomamos para mejorar el rendimiento de vídeo
Números del sistema autónomo: La complejidad detrás de la cortina
La web moderna se construye alrededor de múltiples capas interconectadas de redes conocidas como ASN (números de sistema autónomo), cada una de las cuales consiste en grandes grupos de direcciones IP junto con CDN (redes de entrega de contenido ) que reducen la congestión al hacer que el contenido esté disponible en el borde. Esencialmente, como se muestra a continuación, Internet consiste en una red de redes, cada una con su modelo de negocio y prioridades únicas.
Fuente: Puerta de Investigación
Junto con la complejidad inherente de los ASN que interactúan entre sí está su alcance y escala. La herramienta vizAS intenta visualizar las interconexiones entre los muchos ASN en una base país por país. Por ejemplo, solo en los EE.UU., hay 16.979 ASN y 24.905 relaciones de peering en todas las redes. A nivel mundial, hay más de 90.000 ASN.
https://stats.apnic.net/vizas/index.html
Desde nuestra perspectiva como proveedor de CDN, la complejidad involucrada con la conexión a miles de ASN se ve agravada por la necesidad de adaptarse a los requisitos de rendimiento de cada cliente, perfil de uso, tipo de tráfico y muchos otros factores. Por ejemplo, un servicio como Twitter tendrá un perfil de uso o huella muy diferente al de una empresa de juegos que está lanzando una actualización importante. Del mismo modo, una emisora que transmite un evento deportivo en vivo tiene un perfil diferente al de un servicio de streaming bajo demanda. Incluso dos servicios de streaming en vivo probablemente tengan perfiles diferentes, cada uno de los cuales requiere una optimización de rendimiento personalizada.
Entre bastidores, tenemos una gran cantidad de configuraciones que podemos ajustar y ajustar para ayudar a los clientes a alcanzar sus objetivos y requisitos de rendimiento. Para algunos, el rendimiento puede ser lo que esperaban (o mejor) desde el principio, y no necesitamos cambiar nada. Otros pueden tener objetivos específicos, como TTFB más rápido (Time to First Byte), una métrica importante para los servicios de streaming, que debe abordarse.
Dada la complejidad y el tamaño de Internet, es imposible ofrecer mejoras de rendimiento útiles y consistentes a través de enfoques «whack-a-mole» o scattershot. Las ganancias reales vienen a través de la recopilación de datos exhaustiva y el análisis intensivo de datos para identificar la causa raíz de un problema o obtener información proactiva sobre los cambios de configuración de la red que beneficiarán más a un cliente.
Entregando insights RTT con Stargazer
Una de las métricas más importantes para determinar la latencia de la red y el estado general del rendimiento es RTT (tiempo de ida y vuelta). Esto se define como la duración, medida en milisegundos, toma un paquete para viajar de origen a destino y una respuesta para ser enviada de vuelta a la fuente. Se puede utilizar para diagnosticar y mejorar el rendimiento de la red en varios vectores, incluyendo congestión, problemas de hardware, configuraciones erróneas y problemas de enrutamiento.
Dada la importancia de esta métrica, hemos construido un sistema interno llamado Stargazer que utilizamos para agregar datos RTT de varias fuentes, incluidos nuestros sensores, datos que importamos de clientes y terceros que también monitorean la información RTT. Stargazer monitorea los tiempos de respuesta salientes que van al cliente. Otras fuentes de datos pueden incluir tablas BGP (Border Gateway Protocol) de routers, mapeo de routers a ubicaciones geográficas, registros RTT para conexiones de clientes e información sobre el volumen de tráfico. Además, el sistema puede realizar sondas activas como traceroutes y pings cuando sea necesario.
Detrás de la actividad de monitorización, Stargazer, junto con otras herramientas que hemos desarrollado, nos permite consultar todos los datos que hemos recopilado y realizar análisis en profundidad que abre la puerta a mejoras continuas. Nuestros administradores de red pueden usar esta información para aislar problemas e identificar rutas o configuraciones de red para optimizar el rendimiento para los objetivos y requisitos específicos del cliente. Y, como se discutirá más adelante, también es útil para comprender el efecto que las nuevas tecnologías, como el protocolo BBR (Bottleneck Bandwidth y Round-Trip Propagation Time), tienen sobre el rendimiento.
Optimización de un servidor de origen
Para proporcionar más información sobre cómo funciona la optimización del rendimiento en la práctica, veamos un ejemplo que involucra a un cliente de streaming de video en vivo recientemente agregado que necesitaba optimizar para una arquitectura multi-CDN. En una arquitectura de cliente CDN tradicional, el cliente hace una solicitud a uno de nuestros POP, y la caché POP se llena desde el origen, como se muestra a continuación.
Sin embargo, este cliente eligió aprovechar una arquitectura multi-CDN para aumentar la redundancia y la resiliencia y potencialmente aumentar el rendimiento. Esto está habilitado por nuestra arquitectura Origin Shield que se muestra en la Figura 4. Origin Shield ofrece más control sobre cómo se puede enrutar el tráfico de varios clientes para obtener el mejor rendimiento.
A diferencia de una relación CDN tradicional, todo el tráfico, incluido el servido por la segunda CDN, fluye de vuelta a uno de nuestros POP (AGA) ubicados en Atlanta para el relleno de caché. El AGA POP sirve entonces como origen, o más específicamente, lo que se conoce como el escudo de origen, aliviando la considerable carga del servidor de origen del cliente. El AGA POP fue elegido como la ubicación del escudo de origen debido a su mayor relación de aciertos de caché y rendimiento que el segundo CDN. Una preocupación importante, sin embargo, fue la optimización del rendimiento entre las dos CDN.
El primer paso en el proceso fue buscar la optimización de las rutas tomadas por la segunda CDN a AGA, actuando como el escudo de origen. Un problema inmediatamente aparente fue el bajo rendimiento entre las CDN y un alto número de tiempos de espera de conexión que afectaron a TTFB. Para profundizar en los problemas de rendimiento, utilizamos Stargazer para enviar un traceroute desde AGA al destino previsto y capturar los ASN utilizados para cada salto.
Como se muestra en el resumen a continuación, se envió un traceroute desde AGA a una dirección IP en la segunda CDN, simulando la ruta del cliente.
Nos dimos cuenta de que varios lúpulos estaban dentro de la ASN 7018, que no era la ruta preferida porque implicaba más lúpulos y tenía más congestión. Usando Stargazer, confirmamos rápidamente el problema e hicimos los cambios de red apropiados. Como muestra el resumen de traceroute a continuación, después de hacer el cambio de red, disminuimos el número de saltos y mejoramos el RTT cambiando a ASN 7922, que también resolvió el problema con los tiempos de espera de TTFB.
En un ejemplo diferente, utilizamos la herramienta Stargazer para determinar la mejor ruta de escudo de origen al servidor de origen de un cliente ubicado en la costa este. Para reducir eficazmente la carga en el origen de un cliente y mejorar el rendimiento de entrega, el escudo de origen POP debe estar cerca del origen. A veces, no es necesariamente el pop físico más cercano que funciona mejor. Es una combinación de la menor cantidad de ASN, la menor cantidad de congestión y los tiempos de RTT bajos. Como se puede ver en el antes y después de la tabla de abajo, un traceroute de Stargazer mostró que el pasar del pop DE NYA (Nueva York) al pop de DCC (Washington, D.C.) redujo el conteo de saltos a tres, lo que resultó en una mejora general en el rendimiento de RTT.
Análisis más profundo con Sweeper Fish
Con más de 7.000 interconexiones y más de 300 POP en nuestra CDN a nivel mundial, hay mucho trabajo de optimización en curso. Para evitar hacer girar nuestras ruedas en tareas que pueden no marcar mucha diferencia, necesitábamos una manera eficiente de priorizar las acciones tomadas por nuestros equipos operativos. Esta necesidad llevó al desarrollo de una herramienta complementaria para Stargazer llamada Sweeper Fish que marca los lugares donde existen problemas y nos permite burbujearlos de una manera priorizada.
El pescado barrendero también es útil para determinar si una ruta está congestionada y si es probable que cause problemas. Volviendo al ejemplo multi-CDN, usamos Sweeper Fish para descubrir qué rutas tenían congestión. Para ello, Sweeper Fish midió el delta entre el percentil 25 y 75 para los datos de RON (Medición del Usuario Real) para todos los clientes en todos los caminos hacia el POP AGA, centrándose en el segundo camino de CDN hacia nosotros, ASN7922. La desviación estándar para todo el tráfico sobre este ASN se muestra a continuación.
También confirmamos que la configuración anterior a través de ASN7018 no era el camino a seguir. El análisis de Sweeper Fish mostró que el IQR (rango intercuartílico) aumentó a 20-60 a milisegundos (ver Figura 9) debido a la congestión en esta ruta. IQR, también llamado midspread o medio 50%, proporciona una forma útil de analizar una ruta y señalar problemas rápidamente. Cuanto menor sea el IQR, mejor.
En contraste, el AGA POP fue consistentemente entre 10-22 milisegundos en la ruta que terminamos usando, ASN7922, como se muestra a continuación. Al comparar diferentes ASN, Sweeper Fish nos permite elegir la mejor ruta, menos congestionada y / o identificar problemas para remediar.
Sintonización TCP
La congestión también causa que los paquetes se dejen caer y se retransmitan. Esto ocurre cuando las rutas entre los POP están distantes y el algoritmo TCP no está optimizado. Dado que AGA fue el origen de nuestro ejemplo, era posible que los COP distantes que llegaron a AGA tuvieran este problema. Aunque se distribuyeron en muchos COP, los registros de CDN agregados a continuación nos permitieron identificar áreas problemáticas como se indica en las casillas.
Gráfico 11. Los registros agregados del servidor identifican rápidamente las áreas problemáticas donde los paquetes se están eliminando y retransmitiendo.
Evaluación de BBR
El ancho de banda del cuello de botella y el tiempo de propagación de ida y vuelta (BBR) es un algoritmo alternativo de control de congestión TCP desarrollado por Google que ha comenzado a ganar algo de tracción. Difiere de los algoritmos de control de congestión basados en pérdidas, como el ubicuo TCP-Cubic, e introduce un paradigma de operación diferente. Actualiza continuamente la cantidad de datos que pueden estar en vuelo en función del RTT mínimo que la sesión ha visto hasta ahora para evitar la hinchazón del búfer.
Nuestro análisis encontró que la BBR es útil para mejorar el rendimiento de RTT, pero no llega a ser una solución universal. Hay algunas veces en las que quieres usarlo y otras veces en las que no lo haces. Stargazer nos ayuda a determinar cuándo queremos usarlo mediante el seguimiento del perfil consistente de RTT a destinos durante períodos. Esto nos permite determinar los mejores lugares para aplicar BBR para ayudar a reducir las retransmisiones y mejorar el control del flujo.
Con base en el análisis mostrado en los gráficos a continuación, concluimos que el cambio a BBR mejoraría ligeramente el rendimiento para el POP AGA a la segunda CDN y origen del cliente. El primer conjunto de gráficos muestra que el cambio de TCP-Cubic a TCP BBR resultó en una disminución en las retransmisiones, mientras que el segundo conjunto de gráficos indica que el cambio a BBR proporcionó un ligero aumento en el rendimiento promedio.
Gráfico 12. En este ejemplo, el cambio de TCP-Cubic a TCP BBR resultó en una disminución en las retransmisiones
Gráfico 13. En este ejemplo, el cambio a BBR para el control de flujo desde TCP-Cubic para el AGA POP redujo las retransmisiones y mejoró ligeramente el rendimiento promedio.
Conclusión
Internet es vasta y compleja – es esencialmente una red de redes. Para Edgecast, ahora Edgio, optimizar el rendimiento para los casos de uso de los clientes sería casi imposible sin un análisis en profundidad para obtener información sobre las áreas problemáticas y probar posibles cambios de configuración. Para mejorar el rendimiento de nuestros clientes, hemos desarrollado un sólido conjunto de herramientas para monitorear los RTT continuamente para que podamos realizar mejoras de forma rápida y eficiente en toda nuestra red. Para un servicio de streaming de video en vivo, encontramos maneras de optimizar el rendimiento para sus requisitos únicos, al tiempo que evaluamos el uso de BBR para su aplicación. El resultado fue una solución de streaming de alto rendimiento que aprovechó dos CDN. Y aún no hemos terminado. A medida que la congestión de la red continúa aumentando, nunca dejaremos de optimizar nuestra red para garantizar que nuestros clientes y sus clientes tengan la mejor experiencia en línea posible.
