Home Blogs Medición del medio con relación de retransmisión
Applications

Medición del medio con relación de retransmisión

About The Author

Outline

Al operar una gran red global, 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. Dado el carácter complejo y de mayor esfuerzo de Internet, incluso los enlaces mejor provistos en los proveedores más fiables a veces tienen problemas.

Existen varias estrategias para el seguimiento de estos enlaces, entre ellas la medición activa, que genera tráfico específicamente para la medición, y la medición pasiva, que supervisa 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 procesar estos datos que aborda algunos de los desafíos asociados con la supervisión 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 degradaciones del rendimiento de la red.

Antecedentes

Un flujo de trabajo común en la CDN, implica un punto de presencia (POP) que llega a otro para algún contenido, por ejemplo, para obtener una pieza de contenido 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 peticiones en sí pueden ser bastante pequeñas, en el orden de unos pocos kilobytes. Las respuestas pueden ser muy variables en tamaño, desde kilobytes hasta muchos megabytes.

Figura 1: El flujo de solicitud envía solicitudes pequeñas (orden KBs) y recibe respuestas potencialmente grandes (potencialmente megabytes).

Con el fin de supervisar el estado de las conexiones entre 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 de borde. Si bien esto proporciona visibilidad crítica en nuestros sockets orientados al cliente, estos datos de socket también nos dan una vista de los datos entre pops.

Sin embargo, la medición de estos datos no está exenta de algunos desafíos. En primer lugar, xTCP proporciona una muestra puntual 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 único.

A continuación, debemos asegurarnos de que estamos supervisando la dirección correcta. Mientras que 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, los paquetes de reconocimiento 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 de cola, son más propensos a encontrar la pérdida de paquetes y sufrir retransmisiones, por ejemplo como resultado de caídas de cola en un enrutador ocupado. Para demostrar esto, consideramos la distribución de las tasas 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) vista en los flujos de solicitud y respuesta entre un par de Pops durante un período de 10 minutos.

Fig 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 no cero, sin embargo, notamos que la tasa de retransmisión es muy inferior al 1% para la gran mayoría de las conexiones. Como era de esperar, observamos un comportamiento similar en casi todos los pares de pops con retransmisiones no cero durante el período de prueba. Por lo tanto, nos centramos en los flujos de respuesta cargados de datos. Dado que estamos preocupados por 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 una 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. En última instancia, estos pueden ser el resultado de otro comportamiento de protocolo complejo además de la pérdida (por ejemplo, sondeo de pérdida de cola). Sumado a la complejidad, observamos que muchos enchufes 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, 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 la relación de retransmisión. Inspirada en la relación 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 conectores que están experimentando un nivel poco saludable de retransmisiones. Dado que a veces se esperan retransmisiones no cero, definimos la relación de retransmisión de la siguiente manera:

Críticamente, este valor es particularmente fácil de calcular con los 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 sanos, evitando los desafíos casi siempre cero presentes en las mediciones de la tasa de retransmisión cruda.

También hemos encontrado que la medición es sensible, generando a menudo alertas antes de otros sistemas de monitoreo de rendimiento. Esto lo hace especialmente valioso al diagnosticar rápidamente las 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 eficacia 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 más bajo 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, las sondas ICMP entre POPs.

Para explorar los impactos en el rendimiento de la aplicación, recurrimos a las 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 lograda en el proceso de envío de datos. Con el fin de entender el impacto de los eventos de retransmisión, realizamos el siguiente estudio sobre un par de Pops 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 Pops 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 retransmisión. Luego normalizamos las mediciones “durante” por el rendimiento medio alcanzado entre los pops durante el tiempo normal. Para nuestros umbrales, consideramos cuatro rangos: Mayor de 0 pero menor de 25%, mayor de 25 pero menor de 50%, mayor de 50 pero menor de 75%, y finalmente mayor de 75%.

Fig 3: El rendimiento relativo en comparación con los períodos de no retransmisión, observados 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 alcanzaron un rendimiento inferior a la mediana. A medida que consideramos mayores ratios de retransmisión, el rendimiento continúa disminuyendo, con una mayor relación de retransmisión correspondiente a menor rendimiento, y el peor de los casos resulta en una disminución relativa mediana de más de un orden de magnitud. Estas mediciones dejan claro que la relación de retransmisión captura con éxito el mal rendimiento de los flujos impactados.

A continuación, nos referimos a cómo estos eventos se correlacionan con nuestras mediciones activas de ICMP entre Pops. Aquí, consideramos el comportamiento de algunos de nuestros monitores activos, que realizan sondeos ICMP regulares entre pops, para medir cualquier pérdida o cambio en los patrones de retardo. Para este análisis, nuevamente usamos los eventos extraídos de nuestra comparación de rendimiento. Esta vez, sin embargo, nos fijamos en la pérdida medida ICMP para los períodos de tiempo de cada umbral, donde lo normal en este caso no observó pérdida. Observamos que las limitaciones en nuestro sondeo ICMP resultan en una granularidad de pérdida del 2% para estas mediciones particulares.

Figura 4: La pérdida observada de ICMP durante cada período de tiempo. Una mayor relación de retransmisión corresponde a una mayor pérdida.

Aquí, vemos que los umbrales más bajos rara vez muestran alguna pérdida, con el 90% de las mediciones fallando en detectar ninguna. En contraste, en el umbral de .75, el 80% de las mediciones observó pérdida, y observó una pérdida mediana relativamente alta del 4%. De manera crítica, observamos niveles en los que la relación de retransmisión se correspondió con impactos significativos en el rendimiento (por ejemplo, 0,25) que dan lugar a pocas pérdidas en las métricas de ICMP. Estos hallazgos reiteran la importancia de medir el rendimiento de la ruta más allá de las simples sondas ICMP, 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 la aplicación se ve afectado y las intervenciones de la 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 depender de sondas ICMP que no captan algunos impactos.

Nuestro trabajo en curso está explorando cómo la métrica se puede hacer lo más sensible posible para proporcionar una alerta temprana a las degradaciones, al tiempo que proporciona una entrada adecuada a los sistemas de automatización más complejos.

¡Un agradecimiento especial a los equipos de Ingeniería de Arquitectura y Confiabilidad de Red por su apoyo en este trabajo!

Para los investigadores interesados en aprender más sobre Edgio Labs & Advanced Projects, o interesados en explorar trabajos colaborativos sobre cualquiera de los temas descritos anteriormente, por favor póngase en contacto con el equipo en research@edg.io.