Cómo se Mide la QoS

Existen algunos parámetros específicos de medición que pueden arrojar información fiable de cómo debería funcionar una infraestructura de red en donde se implementará un servicio en nube de acuerdo a la cacalliiddaadd qquuee pupueeddee ofofeerrttaarr p

paarraa llooss sseerrvviicciiooss yy//oo aapplliiccaacciioonneess.

Aunque estos parámetros están al alcance de todos, usuarios, fabricantes y administradores puesto que las normas, recomendaciones y estándares son internacionales; no todas deberán aplicarse a todos los servicios [3], de manera que solo tomando en cuenta algunos parámetros de acuerdo al orden del servicio, sus características y necesidades serán más que suficientes para conocer como afectarán en el desempeño de la nube que se montara.

Algunos de los parámetros que permitirán medir el desempeño y la calidad en cualquier red se enuncian a continuación.

3.7.2.1 Retardo

Se refiere al tiempo que tarda la aplicación destino en obtener los paquetes generados por la aplicación fuente al viajar de extremo a extremo en la red [2]; una subdivisión más específica del retardo es la siguiente:

a) Retardo de Procesamiento

Es el ttiieemmppoo qquuee nenecceessiittaann loloss eleleemmeennttooss dede ununaa reredd paparraa prproocceessaarr llooss ppaaqquueetteess, y que depende de la velocidad de procesamiento y complejidad de cada dispositivo en ella [3]. Un ejemplo es el tiempo que tardan en procesarse las colas de paquetes, las tablas de búsqueda, etc.

b) Retardo en Cola

Es el titieemmppoo ququee esesppeerraa eell papaqquueettee enen lalass ccoollaass ququee exexiisstteenn enen llooss cocommppoonneenntteess d

dee enenttrraaddaa//ssaalliiddaa dede lala reredd [3]. Las colas se hacen grandes (y el tiempo en cola por supuesto aumenta) cuando las redes se congestionan.

c) Retardo de Transmisión

Es el titieemmppoo nenecceessaarriioo paparraa trtraannssmmiittiirr unun papaqquueettee aa ununaa tatassaa dede trtraannssmmiissiióónn d

deetteerrmmiinnaaddaa [3]. Puede significar un retardo grande si el volumen de información es demasiado grande para la capacidad de la red o en su defecto una velocidad baja si el volumen de información es menor. Y se calcula de la siguiente manera:

. . . (3.1)

d) Retardo de Propagación

Es el titieemmppoo ququee nenecceessiittaann lalass sseeññaalleess ppaarraa viviaajjaarr a atrtraavvééss dedell mmeeddiioo [3] y puede calcularse mediante la siguiente ecuación:

. . . (3.2)

3.7.2.2 Jitter

En telecomunicaciones se denomina como jitter a la variabilidad del tiempo de ejecución de los paquetes. Éste efecto eess eessppeecciiaallmmeennttee mmoolleessttoo eenn

a

applliiccaacciioonneessmmuullttiimmeeddiia ya que a provoca que algunos paquetes lleguen demasiado pronto o tarde para poder entregarlos a tiempo [2].

El jitter o variación de retardo puede ser causado por diferentes factores como por ejemplo:

a) Diferentes paquetes pueden tener diferente plazo en las colas en el mismo dispositivo de red.

b) Diferentes paquetes pueden tener diferentes tiempo de procesamiento en un mismo dispositivo de red agregándose así diferentes tiempos de retardo. c) Diferentes paquetes pueden viajar por diferentes rutas de red y los retardos se acumularían en diferentes tiempos de cola y retardos mismos de la propagación.

Desde la perspectiva de los usuarios, el jitter o la falta de él, repercute en la coherencia o consistencia de las aplicaciones [3]. Sin embargo, mientras se trate de uunn nniivveell bbaajjoo yy ccoonnssttaannttee llaass aapplliiccaacciioonneess ppuueeddeenn rreessuullttaarr aaddaappttaattiivvaass.. El efecto puede reducirse mediante un búfer de jitter, pero a costa de un tiempo de ejecución mayor [3]. Para obtener mediciones relacionadas con el estudio del jitter se propone que sea bajo el siguiente método:

 Intervalo máximo de medición de 5 minutos.

 Separación en el intervalo de envío y recepción de paquetes 200 ms (la medida mínima se redondea a 1 ms).

 Normalmente se reporta al menos un lapso de variación en el retardo en el 99% de los casos dentro de los periodos de medición.

3.7.2.3 Pérdida de Paquetes

Es lamedida de loloss papaqquueetteess qquuee nnoo ssee hahann trtraannssmmiittiiddoo ccoonn ééxxiittoo ssoobbrree lala reredd eenn r

reellaacciióónn ccoonn ttooddooss loloss ppaaqquueetteess eennvviiaaddooss sosobbrree llaa mimissmmaa. Usualmente detectados vía métodos ARQ (Automatic Repeat-reQuest), existen cuatro causas principales de perder paquetes en la red [2]:

a) Debido a la mala calidad del medio ya sea por interferencias físicas o electromagnéticas (frecuentemente en medios inalámbricos).

b) Debido a la congestión de enlaces causando desbordamiento de buffer en los dispositivos de red usados.

c) Fallos en los dispositivos de la red.

d) Cambios en el esquema de enrutamiento o protocolos de red causando pérdidas y daños en los paquetes.

La pérdida de paquetes se ve reflejada en la calidad de presentación de las aplicaciones [3], como por ejemplo: un buen sonido en un audio o de nitidez si se trata de una imagen de video.

La pérdida de paquetes se puede calcular mediante la Ecuación 3.3:

. . . (3.3) Para medir la tasa de pérdida de paquetes se recomienda que sea bajo el siguiente método:

 Intervalo máximo de medición de 5 minutos.

 La métrica de medida para la tasa de pérdida de paquetes es mostrada como un porcentaje con precisión de 0.1%.

 Normalmente se reporta un valor de tasa de pérdida de paquete en cada intervalo de medición.

3.7.2.4 Throughput

En pocas palabras es el caudal eficaz de tráfico enviado y recibido con éxito a través de cualquier red en un tiempo determinado [2].

Estrictamente hablando, las métricas arriba mencionadas son suficientes para poder ddeetteerrmmiinnaarr elel dedesseemmppeeññoo dede lalass aapplliiccaacciioonneess ddeell ususuuaarriioo dedennttrroo dede lala rreedd;; así como también su apreciación de calidad de los servicios desde la perspectiva del usuario.

De tal manera que el ancho de banda no es un factor específico como tal; más bien a veces se debe ocupar el anancchhoo ddee babannddaa efefiiccaazz o un aanncchhoo dede babannddaa r

reesseerrvvaaddoo para garantía de algunos servicios. 3.7.3 Modelos de Implementación de QoS

Como podemos darnos cuenta la QoS es un requerimiento creciente en todas las redes actuales. Así el concepto clcloouudd cocommppuuttiinngg, cuya importancia creciente es indiscutible en nuestra sociedad requiere de la implementación de la QoS en las infraestructuras donde se implantará un modelo basado en cloud computing, a fin de asegurar una correcta prestación de cada uno de los servicios ofrecidos. Por lo tanto resulta conveniente el dedicar un momento para introducir algunos conceptos relacionados con éste tema, y en primer lugar, referirse a los diferentes modelos de implementación. En la actualidad existen tres mmooddeellooss ddee apaplliiccaacciióónn d

dee ccaalliiddaadd ddee sseerrvviicciiooss para las redes de datos que son:

a) Mejor Esfuerzo. No se discrimina ningún tipo de tráfico y se brinda el mejor soporte posible desde la infraestructura.

b) IntServ. Las aplicaciones cuyo tráfico requieren tratamiento diferencial señalizan la red para requerir y garantizar los recursos necesarios para el adecuado funcionamiento de la aplicación. Garantiza las condiciones de operación de cada una de las sesiones que se establecen.

c) DiffServ. La infraestructura de la red es la que reconoce los diferentes tipos de tráfico y aplica políticas diferenciadas para cada clase de tráfico. Es más escalable y flexible en su implementación.

3.7.3.1 Mejor Esfuerzo

Es el modelo aapplliiccaaddoo a a totoddaa reredd ququee nono ttiieennee popollííttiiccaass exexppllíícciittaammeennttee ddeeffiinniiddaass como es Internet. No garantiza ningún tratamiento o recurso específico a ningún flujo de información. Todo paquete es tratado de igual forma; no hay tratamiento preferencial [2]. Las principales características del modelo son:

 Altamente escalable.

 No requiere mecanismos o configuraciones especiales.

 No garantiza recursos ni diferencia ningún tipo de servicio. 3.7.3.2 IntServ

Modelo de implementación de servicio bajo demanda que titieennee cocommoo obobjjeettiivvoo g

gaarraannttiizzaarr rreeccuurrssooss didissppoonniibblleess a a lolo lalarrggoo dede ununaa rruuttaa paparraa ununaa apaplliiccaacciióónn e

essppeeccííffiiccaa. Antes de iniciarse propiamente la sesión de la aplicación se señaliza la ruta para verificar la disponibilidad de los recursos necesarios para un adecuado desarrollo de la misma. Permite garantizar las condiciones de operación de aplicaciones críticas [2]. Sus características más importantes son:

 Negocia condiciones específicas de calidad de servicio antes de que se inicie la comunicación propiamente dicha.

 Una vez hecha la reserva, la aplicación cuenta con los recursos reservados más allá de la situación de tráfico de la red.

 Puede adecuarse a demandas específicas y diferentes de cada tipo de tráfico o aplicación.

 La reservación de recursos se realiza para cada flujo de información en particular.

 No se reservan recursos en función de la aplicación genéricamente.

 Cuando se asocia a desarrollos de telefonía IP, da una aproximación orientada a la conexión para éste tipo de servicios. Cada dispositivo a lo largo de la ruta configura y mantiene la operación de cada comunicación individualmente.

 Utiliza los servicios de Resource Reservation Protocol (RSVP).

3.7.3.3 DiffServ

Es un modelo de imimpplleemmeennttaacciióónn ddee rreeccuurrssooss ggaarraannttiizzaaddooss ddee mmooddoo ggeennéérriiccoo yy nnoo p

poorr fflluujjooss o o sseessiioonneess. Permite garantizar diferentes condiciones de servicio para diferentes tipos de tráfico, de un modo mucho más escalable y efectivo, a través de toda la red [2].

 No requiere señalización previa.

 No permite garantizar condiciones de tráfico extremo a extremo.

 Es muy flexible y escalable.

 Divide el tráfico en clases en función de los requerimientos de la organización.

 Cada paquete recibe el tratamiento que se ha definido para la clase a la cual ese paquete pertenece.

 A cada clase se le puede asignar un diferente nivel de servicio y con ello diferentes recursos.

La aassiiggnnaacciióónnddeerreeccuurrssoossse hace salto por salto en cada dispositivo de la red y no para una ruta específica. Sin embrago el mecanismo de implementación resulta ser relativamente complejo.