Mediciones de direcciones IP Parte 1 – Los motivos por los que las transferencias de archivos completos para la medición de rendimiento no funcionará en la HetNet

En esta serie de artículos, estudiaré el tema de las mediciones de direcciones IP, y en particular el rendimiento. A lo largo de las tres publicaciones podrá leer acerca de:

  • Dos enfoques diferentes para medir el rendimiento, de los cuales uno, por lo general falla en el entorno HetNet
  • El modo en el que el cliente guarda en el búfer y el impacto que tiene el desempeño en las mediciones de red
  • Sobre cómo el desarrollo de HetNets y de la tecnología nos obligará a encontrar alternativas para la medición de la capacidad y el rendimiento

Las mediciones de rendimiento son la piedra angular en cualquier red para el análisis del cuadro de herramientas, diseñadas para tensar la capacidad del ancho de banda de la red. Es importante recordar que para que el rendimiento conlleve valor real, se debería minimizar la ruta de la red (número de saltos por paquete IP).

Cuando se desea analizar la velocidad de su red y solamente su red es importante que los paquetes nunca salgan de la red para que la medición no sea influenciada por un tercero, como un operador o proveedor de contenidos.

 

ip-1

Figura 1, esquema del diseño de la red, desde UE hasta el servicio

Este caso ilustra uno de los desafíos que enfrenta las MNO (operadores de red móvil) cuando se trata de las aplicaciones OTT. Ya que el servicio se puede originar o terminar fuera de la parte controlada de la red, es casi imposible garantizar el rendimiento y el control sobre la prueba de calidad. El almacenamiento en caché y la compresión de contenidos son técnicas comunes para mejorar la recuperación rápida de objetos comunes afuera la red central.

ETSI tiene mediciones de rendimiento normalizadas para servicios bien conocidos (HTTP/FTP). Es esencial que estos KPI sean usados en la creación de informes para permitir la comparación de KPI a través de las herramientas y los puntos de captura.

Hay dos opciones principales cuando se realizan mediciones de rendimiento por medio de transferencias de archivos y contenido.

  • Transferencias completas (se transfiere todo el archivo con éxito)
  • Mediciones basadas en el tiempo (transferencia abortada después de un tiempo predefinido, incluso si hay datos por transferir)

Recomendaría las mediciones basadas en el tiempo debido a las siguientes razones:

  • Hace que el tiempo de transferencia sea el mismo sin importar la tecnología de red subyacente
  • El tiempo total de ejecución de la medición es más predecible debido al “1”
  • Evite los cambios de tecnología de red para influenciar una sola muestra de medición, es decir cambiar de GSM a LTE
  • No agota la red al mismo grado que una descarga completa

Sin importar que la medición sea completa o en base al tiempo, ETSI define una serie de activadores usados para realizar el cálculo de KPI. Para las mediciones en base a la dirección IP, estos activadores están definidos a nivel del paquete. Para poder tener una completa compatibilidad con la norma, se debe evaluar a los activadores con una inspección profunda.

Activadores ETSI KPI

Al disectar una prueba en base a direcciones IP (en este caso una descarga HTTP) obtenemos la siguiente imagen.

Nota: Los marcadores de activadores ETSI están en negrita debajo de la columna UE/Cliente.

ip-2

Figura 2. Ejemplo de activadores ETSI KPI para un prueba de descarga HTTP

Ventana de medición y criterios para cancelar

Cada servicio pasa por varias etapas/estados como:

  • Conexión: configuración de la conexión (implementación TCP, incluyendo DNS)
  • Autenticación/Negociación
    • Autenticación con el servicio (inicio de sesión, de ser necesario)
    • Negociación (selección del archivo a descargar a través de FTP)
  • Transferencia: la transferencia del contenido
  • Cierre: terminar la conexión

Las diferentes etapas no son requeridas para todos los servicios y pueden ser opcionales, por ejemplo la descarga HTTP no suele requerir autenticación. Es posible que haya pasos adicionales requeridos para otros servicios, la negociación para correo electrónico es muy diferente a FTP.

Cada etapa puede estar sujeta a la gestión del tiempo de espera. Esto se ha simplificado en muchas soluciones de medición a dos ventanas de operación, ambas están sujetas a la gestión del tiempo de espera:

  • Tiempo de espera de la sesión (o actividad)
  • Tiempo de espera de la transferencia (si las mediciones en base al tiempo están habilitadas)
ip-3

Figura 3, el estado y el tiempo de espera de la prueba (ventana de operación)

El tiempo de espera de la sesión controla toda la actividad (descarga HTTP/FTP, etc). Mientras que el tiempo de espera de la transferencia se activa solamente durante la fase de transferencia de datos. Se fija esta simplificación para imitar el comportamiento del usuario. La mayoría de las aplicaciones usarán estos valores predeterminados del SO del host para esto. Como tal, una actividad cancelada debido al tiempo de expiración por lo tanto es una indicación de que algo no está bien en la red. En caso de que el tiempo de expiración de la actividad es posible hacer el seguimiento en el estado en que se canceló el servicio, se hace seguimiento del estado como un KPI adicional.

En el caso de las transferencias completas, estas permiten que la prueba complete la transferencia. Esto facilita mucho la estimación del rendimiento. Es tan simple como dividir el tamaño de archivo por el tiempo que llevó la transferencia del archivo. ¡Listo! También es posible cumplir con ETSI incluso sin la inspección profunda de paquetes. Los activadores de ETSI pueden transformar el llamado de la función a nivel de API y por lo tanto se puede cuantificar el retraso introducido.

Como tal, las transferencias completas son el modo preferido de medir hosts que no permiten la inspección profunda de paquetes. Sin embargo, como se mencionó anteriormente, las transferencias completas no son adecuadas para las mediciones de rendimiento.

Imagina que analizas una red LTE, un caudal de 60-80 MB/s, lo que requiere un archivo bastante grande como para que la red logre su rendimiento potencial máximo. Si el archivo es demasiado chico, la prueba terminará antes de que se alcance el rendimiento máximo y los datos de la prueba tendrán principalmente a los valores de rendimiento que suben pero que no son representativos del rendimiento de la red. Así que si se configura su transferencia con un archivo del tamaño adecuada, ¿qué sucederá si debe bajarse a GSM o EDGE? Tendrá que esperar para que la transferencia termine, por los siglos de los siglos…

En mi siguiente publicación me pondré a escarbar en las mediciones basadas en el tiempo, el impacto de los búfers y el rendimiento de los dispositivos en las mediciones KPI.

¡Hasta la próxima!

Puede leer la versión 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.