Mediciones de direcciones IP Parte 2 – Impacto de los búfers y el rendimiento de los dispositivos en las mediciones KPI

Esta publicación es la segunda parte de una serie de artículos sobre la medición de direcciones IP en un entorno inalámbrico. ¡Revisa la primera parte aquí si ya no lo hiciste!

Medición en base al tiempo

Con las mediciones en base al tiempo, se cancela la transferencia después de un período fijo de tiempo. El rendimiento se evalúa en base a los bytes transferidos durante el período. El propósito de mediciones en base al tiempo es la saturación de la capacidad de transferencia de la red por un período corto de tiempo para calcular el rendimiento adecuadamente.

ip-4

Los estados y los tiempos de espera de la prueba (ventana de operación)

A una transferencia completada (dentro del límite del tiempo de espera) se la considera una transferencia fallida. Esto es de acuerdo a la norma, y se deriva del propósito de una medición cronometrada. El problema con este tipo de medición es poder determinar con precisión la cantidad de datos transferidos durante la ventana/estado de la transferencia.

Para poder lograr el rendimiento máximo, la aplicación de la medición debe aumentar los tamaños del búfer para los datos enviados en la interfaz de la red. Los tamaños del búfer deber ser igual e independiente a la tecnología del portador y debe optimizarse para un rendimiento máximo. En esencia, mientras más grande sea la potencia de radio del portador, mayor será la necesidad de búfer.

ip-5

Las capas esquemáticas de almacenamiento de datos en el búfer y los puntos de acceso

La estación base requerirá datos desde UE en ráfagas y su funcionamiento dependerá de la tecnología del portador. Cuando se cancela una transferencia, solamente se puede enviar una parte del búfer (el resto persisten en el búfer). Si los bytes transferidos calculados en la capa de aplicación, este error puede ser mayor (100%).

Ejemplo:
Tamaño de búfer: 256kByte
Portador: GPRS (recuerde que es el mismo tamaño sin importar de la tecnología) Tiempo de transferencia: 20 segundos

Para vaciar este búfer, en 20 segundos, debemos lograr un rendimiento mayor a 102kBit/seg, lo que no es posible para GPRS. Por lo tanto, en nuestro ejemplo, si los bytes transferidos se calculan a nivel de la aplicación, nos veríamos obligados a decir “256kByte” o “0”. Ambos están evidentemente equivocados.

Conclusión: la medición del tamaño de los datos a nivel de la aplicación es esencialmente la medición de las partes internas del sistema operativo y la eficacia con la que gestiona los datos, pero no en cómo se relaciona con el tráfico saliente en la red.

Gestión del búfer en las redes de radio

Las redes de radio están basadas en la comunicación activa con la UE. Para una red cableada (como Ethernet), la UE iniciará la comunicación, mientras que la radio en la estación base le dirá a la UE cuando se le permite enviar datos. La diferencia tiene algunas implicaciones sobre cómo se debe diseñar la aplicación para lograr la completa utilización de la infraestructura subyacente.

En LTE, la dirección MAC se programa una vez por milisegundo (TTI es 1ms). Cada TTI (en LTE) puede tomar 100kbit/seg para un Cat 3 UE. 100kbit/seg es casi 9 paquetes IP. Para LTE, se debe fijar a MTU en 1380 para su utilización completa debido al retraso del ancho de banda del producto.

En Windows, el programas principal del SO (gestiona el turno los sub-procesos y los procesos en el CPU) tiene una granularidad de 15ms en promedio. Cada 15ms, podremos básicamente enviar 9*15 paquetes de 1380 bytes, lo que es ~200kB de datos. Ya que hay muchas otras cosas más en el CPU, como tasas binarias altas, el programador fluctúa sustancialmente (casi la mayor parte del tiempo en las capas centrales del SO para la inspección profunda de paquetes). Por lo tanto, los búfers necesitan ser ligeramente mayores. Se ha encontrado que un valor de 256kb es bueno para poder lograr la utilización completa de un Cat 3 UE.

Como tal, los búfers dependen de la tecnología de radio subyacente. Se los debe optimizar para las tasas de bits más altas.

Inspección profunda de paquetes (DPI)

Para que una aplicación de medición entregue activadores compatibles con ETSI, la aplicación necesita la inspección profunda de paquetes. La inspección profunda de paquetes depende de dos requisitos principales:

  • Accesos a la secuencia IP
  • CPU para procesar la secuencia IP

En Windows/Linux/OsX basadas en PC, esto no es un problema, son plataformas muy conocidas y que han recibido soporte desde hace mucho tiempo. El poder de procesamiento del CPU es suficiente para hacer inspección profunda de paquetes.

Para el sistema operativo de los auriculares comerciales, como iOS, Android y Blackberry, esto es más complicado y a veces no es posible sin modificaciones extremas (liberación, reemplazo del firmaware, etc). Estas complicaciones hacen que la inspección profunda de paquetes no sea realista en los teléfonos promedio, sin importar que los CPU de móviles estén mejorando y que los teléfonos de gama alta estén disponibles, también se utilizará la inspección profunda de paquetes.

Cálculo de los bytes transferidos entre el cliente y el servidor

También se utiliza la inspección profunda de paquetes de secuencias de datos TCP para calcular la cantidad correcta de los datos transferidos por medio del análisis de SEQ/ACK. Cada paquete saliente está etiquetado con un número de secuencia (SEQ) que representa la posición relativa de la secuencia de datos. Como tal, el número SEQ representa la posición de lectura relativa de la secuencia de salida. Cuando el lado de receptor acepta un paquete, devuelve un paquete de acuse de recibo (ACK). ACK representa un acuse de recibo de la posición de escritura relativa en la secuencia. Por lo tanto podemos evaluar la cantidad de datos que acepta el lado receptor.

Como los números SEQ/ACK son relativos, se debe analizar la configuración TCP porque mantiene el valor cero relativo para SEQ/ACK.

También es importante para identificar la conexión y la prueba para cada paquete. Esto es una obligación para la generación confiable de KPI. De otra manera, hay una gran riesgo de mezclar datos desde la sesión paralela del mismo tipo (HTTP, FTP, etc.).

En mi tercer y última publicación sobre este tema, escarbaré en las alternativas recientes de la capacidad de medición en las redes inalámbricas que lo hacen sin la saturación de la red. Las pruebas muestran que estos métodos pueden reducir la cantidad de los datos transmitidos cuando la capacidad de medición a solo el cinco por ciento de la prueba de datos tradicional.

Puede leer la nota original en inglés aquí.

Fredrik tiene una larga trayectoria en programación basada en IP y sistemas de inspección profunda de paquetes (DPI). Anteriormente ha trabajado en arquitectura y desarrollo de sistemas de evaluación comparativa, y ahora se desempeña como Director del grupo Service Assurance en Ascom Nextwork Testing.

Recuperar contraseña

Por favor ingrese su nombre de usuario o dirección de correo electrónico. Recibirá un enlace para crear una nueva contraseña por correo electrónico.