Calidad de servicio en CVoIP

Los servicios de VoIP imponen restricciones estrictas y tienen factores más sensibles. El procesamiento y la entrega de las llamadas determinan la QoS. El procesamiento de llamadas incluye factores como el tiempo para inicializar y finalizar la llamada, y el tiempo para convertir la parte de voz de

las llamadas en paquetes transportados a través de la red. La calidad de voz es el aspecto más importante del procesamiento de llamadas y muchos factores en el cómputo en la nube pueden afectarlo.

3.2.1 Utilización del CPU

La calidad de la voz es percibida subjetivamente por el oyente. Un punto de referencia común utilizado para determinar la calidad de la voz es MOS. Esta medida evalúa la calidad del habla proporcionado por un códec. Cada códec proporciona cierta calidad de voz solo si la utilización del procesador es lo suficientemente baja. Teóricamente, la utilización del 100% del procesador proporciona el mejor rendimiento esperado. Sin embargo, Eleftheriou (2010) mostró que el CPU no puede manejar el estrés cuando la utilización supera el 85%, a partir de este nivel de utilización comienzan a aparecer jitter y audio cortado. Adicionalmente, el trabajo no analiza la influencia de la memoria en la reducción de la calidad de la voz.

Durante el procesamiento de una llamada, el códec incrementa el ancho de banda utilizado pero la utilización que aporta el mismo códec al CPU es más significativa. Montazerolghaem et al. (2016) indican que el ancho de banda consumido por 6,500 llamadas no supera los 100 Mbps, y 10,000 llamadas no alcanzan los 400 Mbps.

La Tabla 4 muestra el ancho de banda utilizado por diferentes códecs. Las llamadas de VoIP usan dos flujos de audio, uno por cada punto final, por lo tanto, una llamada emplea el doble de ancho de banda. El número de llamadas admitidas en una conexión de 100 Mbps está entre 6,000 y 25,000, dependiendo del códec usado por las llamadas.

Tabla 4. Ancho de banda de diferentes códecs.

Códec Bit Rate (kbps) MOS Ancho de banda (kbps)

G.711 64 4.1 87.2 G.729 8 3.92 31.2 G.723.1 6.3 3.9 21.9 G.723.1 5.3 3.8 20.8 G.726 32 3.85 55.2 G.726 24 - 47.2 G.728 16 3.61 31.5 G722_64k 64 4.13 87.2 ilbc_mode_20 15.2 NA 38.4 ilbc_mode_30 13.33 NA 28.8

Sin embargo, la cantidad de llamadas manejadas por el CPU es menor a la soportada por una conexión de 100 Mbps. Por lo tanto, el procesamiento de llamadas es una característica clave para garantizar la QoS. En este trabajo, se propone limitar la utilización del procesador para garantizar la QoS.

Las llamadas tienen diferente impacto en la utilización del procesador en función de las operaciones realizadas por Asterisk. La utilización del procesador es más baja cuando no se realizan operaciones de transcodificación, para este caso, Asterisk solo se encarga de enrutar la llamada. Sin embargo, el enrutamiento influye en la carga del procesador independientemente del tipo de códec. La Tabla 5 muestra la utilización del procesador para la llamada sin transcodificación presentada por Montoro y Casilari (2009).

Tabla 5. Utilización de llamadas sin transcodificación. Protocolo Códec 10 llamadas (%) 1 llamada (%)

SIP/RTP G.711 2.36 0.236

SIP/RTP G.726 2.13 0.213

SIP/RTP GSM 2.58 0.258

SIP/RTP LPC10 1.92 0.192

El rendimiento de los procesadores ATOM se analiza para VoIP (Eleftheriou, 2010) teniendo en cuenta las llamadas, la utilización, el consumo de energía, los mensajes de la base de datos, el registro y el rendimiento de las llamadas. El autor concluye que el CPU puede procesar de 70 a 500 llamadas con un 100% de utilización.

Además de la utilización del CPU, los proveedores deben considerar otros elementos inherentes a la infraestructura nube, uno de los más importantes es el despliegue de la infraestructura. La elasticidad del sistema CVoIP es un factor vital para garantizar la QoS y depende del tiempo despliegue de las VMs.

3.2.2 Retardo de inicio

La elasticidad es la capacidad de adquirir o liberar recursos de cómputo bajo demanda de forma dinámica. Algunas ventajas de la elasticidad en la nube abarcan: evitar la práctica de aprovisionamiento excesivo, adaptar la capacidad del sistema a las cargas de trabajo y disminuir el consumo de energía. Sin embargo, si las VMs tardan mucho tiempo en desplegarse pueden generar el problema de bajo aprovisionamiento que afecta el rendimiento de las aplicaciones.

El tiempo de retardos de inicio (StUp) de una VM es el tiempo requerido para inicializar la VM. Un StUp inesperado provoca reducción de la QoS y aprovisionamiento escaso de recursos. Para reducir los factores que afectan la ejecución de aplicaciones de tiempo crítico, es necesario estudiar los efectos de los retrasos de inicio de las VMs en la administración de sistemas CVoIP.

Mao y Humphrey (2012) estudian los StUPs de VMs en nubes y analizan la relación entre StUp y diferentes factores: tamaño de la imagen del SO, tipo de instancia, ubicación del centro de datos y cantidad

de instancias adquiridas al mismo tiempo. El StUp es el período de tiempo que los proveedores de la nube necesitan para encontrar un lugar en los centros de datos para aprovisionar VMs, asignar recursos (por ejemplo, direcciones IP) a las VMs y copiar / iniciar / configurar la imagen del SO.

Razavi et al. (2013) analizan la dependencia entre el tiempo de inicio de la VM, el tamaño del disco y el contenido. Los autores desarrollan y evalúan un enfoque para consolidar instancias de VMs y reducir el tamaño y contenido del disco. El objetivo es seleccionar un conjunto deseado de servicios para crear imágenes de VMs con tamaño mínimo requerido. Los autores aplican este enfoque a las imágenes de las VMs donde el usuario define paquetes de software necesarios para obtener la funcionalidad deseada.

Hoffman (2015) mide la velocidad de creación de la VM y el tiempo de acceso mediante SSH entre proveedores de nube ubicados en diferentes regiones del mundo. El análisis considera información recopilada durante un año y cubre diferentes regiones del mundo (Europa, Asia y EUA). Los resultados muestran que el mejor proveedor es aproximadamente cuatro veces más rápido que el peor, al considerar ambos procesos.

La Tabla 6 resume el StUp para varios SO y proveedores. La Tabla 7 presenta los tiempos promedio de creación de la VM y el tiempo de acceso al servicio SSH entre proveedores nube.

Tabla 6. Tiempo promedio de retardo de inicio para VMs. Nube SO StUp (seg.)

EC2 Linux 96.9 Windows 810.2 Azure WebRole 374.8 WorkedRole 406.2 VMRole 356.6 Rackspace Linux 44.2 Windows 429.2

Tabla 7. Tiempo promedio de retardo de inicio para VMs con acceso SSH. Nube StUp (seg.)

Google Cloud Platform 31 Amazon Web Services 47

Vexxhost 47

Linode 57

DigitalOcean 89

Rackspace 128

Azure 138

En esta investigación se estudian los efectos de los retardos en el despliegue de la infraestructura (StUp) para el procesamiento de llamadas en sistema VoIP basado en la nube computacional.