Cuando se opera una red global grande, garantizar una buena conectividad y rendimiento entre los sistemas que se comunican a través de Internet pública es clave para garantizar una experiencia de usuario positiva. Dada la naturaleza compleja y de mejor esfuerzo de Internet, incluso los enlaces más bien provisionados en los proveedores más confiables a veces tienen problemas.
Existen varias estrategias para el seguimiento de estos enlaces, entre ellas la medición activa, que genera tráfico específico para la medición, y la medición pasiva, que monitorea el tráfico existente. En este artículo, describimos un enfoque pasivo que hace uso de nuestro sistema de muestreo de socket xTCP para monitorear pasivamente muchos de estos enlaces de los que depende nuestra red.
Para aprovechar al máximo los datos de xTCP, hemos desarrollado un enfoque para el procesamiento de estos datos que aborda algunos de los desafíos asociados con el monitoreo de Internet. En particular, introducimos un concepto que llamamos la relación de retransmisión , que proporciona una medida relativa de la gravedad de las retransmisiones observadas entre sitios de red de entrega de contenido (CDN). Demostramos que la relación de retransmisión por encima de ciertos niveles corresponde a degradaciones en el rendimiento, impactando directamente en el rendimiento percibido por el usuario, por lo que es una excelente base para la automatización de la red que nos permite trabajar en torno a las degradaciones del rendimiento de la red.
Antecedentes
Un flujo de trabajo común en la CDN, implica un punto de presencia (POP) que se dirige a otro para algún pedazo de contenido, por ejemplo, para recuperar un pedazo de contenido para almacenar en caché. Con frecuencia, estas interacciones se realizan en respuesta directa a una solicitud del cliente, lo que significa que la solicitud posterior puede estar esperando a que se complete esta transferencia. Generalmente, las solicitudes en sí pueden ser bastante pequeñas, del orden de unos pocos kilobytes. Las respuestas pueden ser muy variables en tamaño, desde kilobytes a muchos megabytes.
Figura 1: El flujo de solicitud envía peticiones pequeñas (KBS de orden) y recibe respuestas potencialmente grandes (potencialmente megabytes).
Con el fin de monitorear el estado de las conexiones entre los puntos de presencia, podemos utilizar nuestra herramienta de monitoreo de sockets, xTCP, para muestrear el estado actual de todos los sockets abiertos en nuestros servidores perimetrales. Si bien esto proporciona visibilidad crítica en nuestros sockets orientados al cliente, estos datos de socket también nos dan una visión de los datos entre POP.
Sin embargo, la medición de estos datos no está exenta de algunos desafíos. En primer lugar, xTCP proporciona una muestra de punto en tiempo de diferentes conexiones. Eso significa que podríamos atrapar muchas conexiones en muchos puntos diferentes de la transmisión. Por lo tanto, cualquier evaluación que hagamos tendrá que considerar la distribución más amplia de los comportamientos, en lugar de cualquier valor individual.
A continuación, tenemos que asegurarnos de que estamos vigilando la dirección correcta. Mientras tanto el POP que generó la solicitud (POP A en el diagrama anterior) como el POP que recibió la solicitud y debe responder a ella (POP B arriba) tienen información de socket, sus cargas de trabajo asimétricas significan que esperamos ver un comportamiento diferente: La mayoría de los paquetes enviados por el cliente serán paquetes de control (la solicitud inicial, paquetes de confirmación posteriores), mientras que la mayoría de los paquetes enviados por el servidor serán paquetes de datos, que son más propensos a contener volúmenes significativos de datos.
Como resultado, si hay congestión u otros problemas a lo largo de la ruta, los paquetes que transportan datos, y por lo tanto ocupan más espacio en la cola, son más propensos a encontrar pérdida de paquetes y sufrir retransmisiones, por ejemplo, como resultado de caídas de colas en un router ocupado. Para demostrar esto, consideramos la distribución de las velocidades de retransmisión de paquetes (calculadas como la relación de paquetes retransmitidos totales divididos por el número total de segmentos de datos enviados, menos retransmisiones) observadas en los flujos de solicitud y respuesta entre un par de POP durante un período de 10 minutos.
Figura 2: El tráfico de respuesta encuentra más retransmisiones, probablemente debido a su mayor tamaño.
Aquí, vemos que los sockets de solicitud del cliente no experimentan casi ninguna retransmisión durante este período de tiempo. Por otro lado, las respuestas muestran que casi el 85% de los sockets tienen retransmisiones distintas de cero, sin embargo, observamos que la tasa de retransmisión está muy por debajo del 1% para la gran mayoría de las conexiones. Como era de esperar, observamos un comportamiento similar en casi todos los pares de estallidos con retransmisiones distintas de cero durante el período de prueba. Por lo tanto, nos centramos en los flujos de respuesta cargados de datos. Dado que nos preocupa atender las solicitudes a los POPS solicitantes originales, nos referimos a estos como flujos “entrantes”.
Nuestro desafío final proviene de algunas complejidades generales en torno a las retransmisiones, y la dificultad de usarlas como señal de degradación del rendimiento. De hecho, las retransmisiones pueden ocurrir regularmente sin indicar un problema en particular, ya que simplemente reflejan el estado del remitente y el número de veces que un paquete fue reenviado. Estos pueden ser en última instancia el resultado de otro comportamiento complejo del protocolo además de la pérdida (por ejemplo, sondeo de pérdida de cola ). Añadiendo a la complejidad, observamos que muchos sockets nunca observan retransmisiones. Esto significa que los resúmenes ingenuos (por ejemplo, tomando la mediana) pueden resultar en resúmenes muy conservadores de la tasa de retransmisión, y los resúmenes sesgados (por ejemplo, el percentil 95 o 99) pueden capturar en gran medida comportamientos que no son perjudiciales para la población en general.
Relación de retransmisión
Con el fin de ayudar a simplificar los impactos de estos desafíos, consideramos una métrica compuesta que llamamos el ratio de retransmisión. Inspirada en el ratio HD de Meta , que tiene como objetivo cuantificar la fracción de clientes que son capaces de transmitir video HD, esta medida se esfuerza por describir la fracción de sockets que están experimentando un nivel poco saludable de retransmisiones. Dado que a veces se esperan retransmisiones distintas de cero, definimos la relación de retransmisión de la siguiente manera:
Críticamente, este valor es particularmente fácil de calcular con datos disponibles a través de xTCP. En nuestra experiencia operativa, hemos encontrado que los valores de la relación de retransmisión son generalmente pequeños en enlaces saludables, al tiempo que evitan los desafíos casi siempre cero presentes en las mediciones de la tasa de retransmisión bruta.
También hemos encontrado que la medición es sensible, a menudo generando alertas antes de otros sistemas de monitoreo del rendimiento. Esto hace que sea especialmente valioso cuando se diagnostica rápidamente degradaciones de la red, que a menudo comienzan con pequeños problemas que eventualmente se convierten en problemas más grandes.
Validación de la métrica
Con el fin de demostrar que la relación de retransmisión está directamente correlacionada con el rendimiento de la aplicación, demostramos su efectividad considerando dos mediciones. En primer lugar, mostramos que durante los tiempos de alta relación de retransmisión, la aplicación cliente (el solicitante) experimenta un rendimiento menor que durante los tiempos con baja o cero relación de retransmisión. En segundo lugar, mostramos que la alta relación de retransmisión a menudo se corresponde con degradaciones en otras señales de red, en particular, sondas ICMP entre COP.
Para explorar los impactos en el rendimiento de la aplicación, recurrimos a mediciones tomadas explícitamente desde la capa de aplicación. En particular, consideramos los rendimientos medidos en el POP del cliente, ya que representan la tasa de entrega funcional alcanzada en el proceso de envío de datos. Con el fin de comprender el impacto de los eventos de retransmisión, realizamos el siguiente estudio en un par de estallidos en el transcurso de una semana, durante el cual ocurrió un problema significativo con el proveedor.
En primer lugar, consideramos todos los períodos en los que ocurrió un evento de retransmisión. Definimos un evento de retransmisión como cualquier período de tiempo en el que la relación de retransmisión entre un par de POP se encuentra dentro de un cierto rango durante al menos diez minutos consecutivos. Si bien observamos que esto excluye los eventos de corta duración, proporciona una visión del comportamiento de los eventos más largos. Para cada evento de retransmisión, recopilamos los valores de rendimiento correspondientes durante el evento. Como control, recopilamos datos durante el mismo tiempo que el evento, pero tres horas antes. Esto nos da dos conjuntos de mediciones de rendimiento: Los eventos de retransmisión “Durante” y “Normal”, tomados durante tiempos de no retransmisiones. Luego normalizamos las mediciones “durante” por el rendimiento medio alcanzado entre los COP durante el tiempo normal. Para nuestros umbrales, consideramos cuatro rangos: Mayor que 0 pero menor que 25%, mayor que 25 pero menor que 50%, mayor que 50 pero menor que 75%, y finalmente mayor que 75%.
Fig 3: El rendimiento relativo en comparación con los períodos de no retransmisión, observado durante cada evento de retransmisión.
La figura anterior muestra la distribución de los rendimientos relativos observados durante el período de medición. En primer lugar, vemos que incluso en el rango más bajo, el 60% de las transacciones lograron un rendimiento inferior a la mediana. A medida que consideramos relaciones de retransmisión más altas, el rendimiento continúa disminuyendo, con una mayor relación de retransmisión correspondiente a un menor rendimiento, y el peor de los casos resultando en una disminución mediana relativa de más de un orden de magnitud. Estas mediciones dejan claro que la relación de retransmisión captura con éxito el bajo rendimiento de los flujos impactados.
A continuación, pasamos a cómo estos eventos se correlacionan con nuestras mediciones ICMP activas entre POP. Aquí, consideramos el comportamiento de algunos de nuestros monitores activos, que realizan sondeos ICMP regulares entre COP, para medir cualquier pérdida o cambio en los patrones de retardo. Para este análisis, utilizamos nuevamente los eventos extraídos de nuestra comparación de rendimiento. Esta vez, sin embargo, nos fijamos en la pérdida medida por ICMP para períodos de tiempo de cada umbral, donde normal en este caso no se observó ninguna pérdida. Observamos que las limitaciones en nuestro sondeo ICMP resultan en una granularidad de pérdida del 2% para estas mediciones particulares.
Fig 4: La pérdida observada por ICMP durante cada período de tiempo. Mayor ratio de retransmisión corresponde con mayor pérdida.
Aquí, vemos que los umbrales más bajos rara vez muestran ninguna pérdida, con el 90% de las mediciones no detectando ninguna. En contraste, en el umbral de .75, el 80% de las mediciones observaron pérdida, y observaron pérdida mediana relativamente alta del 4%. Críticamente, observamos los niveles donde la relación de retransmisión se correspondía con impactos significativos de rendimiento (por ejemplo, 0,25) dan como resultado poca pérdida en las métricas ICMP. Estos hallazgos reiteran la importancia de medir el rendimiento de la trayectoria más allá de las sondas ICMP simples, y destacan la capacidad de la relación de retransmisión para ofrecer una visión matizada del rendimiento de los flujos reales a través de Internet.
Conclusiones y más allá
En esta publicación, demostramos el valor de la relación de retransmisión, una métrica de resumen conveniente que se puede calcular fácilmente con los datos disponibles de los datos del socket xTCP también. Además, demostramos que proporciona una visión clara de los casos en los que el rendimiento de las aplicaciones se ve afectado y las intervenciones de red son necesarias.
La relación de retransmisión se ha convertido en una parte clave de nuestro proceso de monitoreo, proporcionando una visión clara del rendimiento del sistema, sin la necesidad de procesar registros de aplicaciones más grandes y difíciles de manejar o confiar en sondas ICMP que no logran capturar algunos impactos.
Nuestro trabajo en curso está explorando cómo la métrica puede ser lo más sensible posible para proporcionar una alerta temprana de degradaciones, al tiempo que proporciona una entrada adecuada a sistemas de automatización más complejos.
¡Agradecemos especialmente a los equipos de Arquitectura y Confiabilidad de Redes por su apoyo en este trabajo!
Para los investigadores interesados en aprender más sobre Edgio Labs & Proyectos Avanzados, o interesados en explorar trabajos colaborativos en cualquiera de los temas descritos anteriormente, por favor comuníquese con el equipo en research@edg.io.
