Control de la calidad del servicio en redes en tiempo real

Control de la calidad del servicio en redes en tiempo real

Comparación de esquemas de establecimiento de canales en Redes en Tiempo Real

Uno de los componentes más importantes para un protocolo para redes en tiempo real es el control de la calidad del servicio. Toda red en tiempo real tiene que asegurar que en todos los canales que sirve se cumple el nivel de calidad requerido.

Casi todos los protocolos definen una primera fase de aceptación de canales en la que se decide si se puede dar el servicio requerido por el canal. La diferencia entre los distintos protocolos reside en la forma de especificar los canales y los test que se realizan para asegurar esta calidad.

Este trabajo compara de forma determinista varios criterios de aceptación de canales, y la utilización que hacen de la red. Además se establece un modelo para poder determinar la carga y poder hacer comparaciones.

Trabajo doctorado 6 créditos.

Preparado por ________________________________ Enrique Hernández Orallo Dirigido por _______________________________________ Joan Vila i Carbó

1.- INTRODUCCIÓN...3

2.- ANÁLISIS DE LOS SISTEMAS DE COMUNICACIONES ...4

2.1.- MODELO DEL TRÁFICO O FLUJO...5

2.2.- MODELO DE LOS ELEMENTOS...6

2.3.- TESTS DE ADMISIÓN...7

3.- BREVE DESCRIPCIÓN DE DOS PROTOCOLOS BÁSICOS ...8

3.1.- RSVP (RESOURCE RESERVATION PROTOCOL)...8

3.1.1.- Servicio garantizado ...8

3.1.2.- Test en el receptor ...10

3.1.3.- Término slack...11

3.2.- TENET SUITE...11

3.2.1.- Establecimiento y control de canales...12

3.2.2.- Transmisión y planificación de paquetes...12

3.2.3.- Test en los nodos...13

3.2.4.- Tests en el receptor ...15

3.2.5.- Tests adicionales...15

4.- COMPARACIÓN...16

4.1.- MODELOS DE TRÁFICO O FLUJO: ...16

4.2.- MODELOS DE LOS NODOS/ ELEMENTOS...17

4.3.- TEST DE PLANIFICABILIDAD...18

5.- DESCRIPCIÓN DE LA CARGA ...19

5.1.- FLUJO 1: VBR...19

5.2.- FLUJO 2: HVBR ...20

5.3.- FLUJO 3: CBR ...21

6.- ANÁLISIS PARA UN NODO ...22

6.1.- FLUJO 1: VBR ...24

6.2.- FLUJO 2 : HVBR ...25

6.3.- FLUJO 3 : CBR ...26

7.- ANÁLISIS PARA VARIOS NODOS ...28

7.1.- FLUJO 1 : VBR ...29

7.2.- FLUJO 2 : HVBR ...31

7.3.- FLUJO 3 : CBR ...32

8.- COMENTARIOS SOBRE LAS COMPARACIONES ...33

9.- CONCLUSIONES Y FUTUROS TRABAJOS...34

APÉNDICE 1 : BIBLIOGRAFÍA ...35

1.- Introducción

El incremento de la velocidad de transmisión en las redes de datos ha permitido empezar a utilizar nuevos tipos de aplicaciones como la videoconferencia, visualización científica y médica, telecontrol, etc. , no siempre con los resultados deseados. Estas aplicaciones tienen unos requerimientos elevados en términos de ancho de banda, retraso de transmisión permitido y tasa de errores. El esquema de servicio ofrecido por las actuales redes es totalmente inadecuado, por lo que se requieren nuevos servicios que permitan una transmisión en tiempo real.

Para la transmisión de información en tiempo real se requiere un sistema de comunicaciones que proporcione a las aplicaciones los servicios y el control necesarios para la gestión de la calidad del servicio. En particular la comunicación de audio o vídeo requiere la provisión de cierto nivel de calidad (QoS), garantizándolo durante el tiempo de la transmisión. Este nivel de calidad lo tienen que establecer las aplicaciones a la hora de comunicarse.

Por lo tanto se tiene que proveer mecanismos para el:

• establecimiento y corte de los canales,

• negociación de los niveles de calidad entre emisor – receptor, sistemas intermedios y control de red, y

• control del nivel de calidad acordado.

En general el medio (físico o virtual) por el que se realizan estas comunicaciones se suele denominar canal. Estos canales son definidos con unos parámetros típicos como pueden ser el ancho de banda, retraso, variación del retraso (delay jitter) y fiabilidad.

La implementación de estos sistemas incluye el desarrollo de nuevos routers que soporten este tipo de transmisión. Cada router solo debe admitir nuevas comunicaciones si permiten obtener la calidad requerida.

Las redes basadas en paquetes como IP, tienen como objetivo maximizar la utilización de la red por medio de la multiplexación de los canales. Además, pueden proporcionar comunicación multipunto, y proporcionar robustez adaptándose a la dinámica de la red. Sin embargo este funcionamiento hace que el comportamiento sea difícilmente predecible. En cambio las redes basadas en conexión proporcionan un servicio garantizado, pero sin embargo, hacen un uso no eficiente de los recursos de la red, no se adaptan a los fallos de la red y no soportan comunicaciones multipunto.

Se puede hablar de una Red de paquetes de servicios integrados (RPSI) en la que se mezclan estos dos paradigmas de comunicación; combinando la comunicación multipunto y multiplexada y la robustez de la red de paquetes conmutadas y la garantía de servicio del modelo de conexión.

El desarrollo de este tipo de redes requiere distintos componentes, que incluyen :

1. Especificación del flujo : Una especificación del flujo definiendo el tipo del tráfico, los requerimientos del receptor y la calidad de servicio que se va a proporcionar al flujo,

2. Encaminamiento : La red debe decidir como transportar los paquetes desde la fuente al destino. Por ello se requiere un protocolo de encaminamiento que soporte calidad de servicio y rutas unicast y multicast,

3. Reserva de recursos : Para mantener un flujo con una calidad de servicio se requiere un protocolo de reserva para crear y mantener las reservas de recursos, como el ancho de banda o número de buffers.

4. Control de admisión : Un algoritmo de control de admisión para mantener la carga de la red a un determinado nivel,

5. Planificador de paquetes : Un algoritmo de servicio de paquetes para planificar la transmisión de los paquetes con el objetivo de mantener el servicio garantizado para cada flujo.

Se ha denominado protocolo de RPSI a los diseñados con el objetivo de servir como soporte a una red de servicios integrados. Los protocolos que se van a ver implementan solamente algunos de los componentes vistos, dando la posibilidad de integrarlos con otros componentes.

2.- Análisis de los sistemas de comunicaciones

En el análisis de los sistemas en tiempo real se asume normalmente un entorno con un único servidor, tareas periódicas y el retraso acotado por su periodo [Stankovic88]. Sin embargo, el tráfico de red es a ráfagas (“bursty” ), y el retraso para cada conexión es independiente de los requerimientos de ancho de banda. Además se necesita garantizar las prestaciones entres emisor y receptor en un entorno de red, donde la dinámica del tráfico es mucho más compleja. Los métodos analíticos con redes de colas de espera son a menudo inviables para modelos de tráfico realistas. Además, este análisis normalmente estudia las prestaciones medias del conjunto de conexiones, mientras aquí es necesario conocer los límites de las prestaciones para cada tipo de conexión.

Por lo tanto, se tiene que establecer otra metodología para la comparación de estos sistemas. Se establecen los siguientes criterios:

1. Modelo del tráfico o flujo . Una descripción de la carga que va a tener el sistema.

2. Modelos de los elementos. Descripción de los elementos que tiene la red.

3. Mecanismos de admisión de canales. Como se admiten o deniegan nuevos canales.

Existen otros métodos para analizar estos tipos de sistema, como la basada en la teoría de flujos de Cobb [Cobb97].

2.1.- Modelo del tráfico o flujo

Describe el flujo que va a tener el canal. En este sentido todo transmisión por parte de un emisor debe seguir estas características para asegurar que se cumplen la calidad requerida. Además, asociado a cada canal están los parámetros de calidad requeridos. Estos parámetros son equivalentes a todos los protocolos y suelen ser el retraso máximo, ancho de banda necesario y tasa de error.

Para poder determinar el máximo retraso de un paquete, se necesita una descripción determinista del tráfico. Se podría utilizar la tasa pico de transmisión pero esto provocaría una utilización no eficiente de la red. Contra más se acerque el modelo de la carga a la real, más información dispondrá la red para planificar de forma adecuada los paquetes. De esta forma, aunque la suma de las tasas pico de todas las conexiones sea mayor que la velocidad del enlace, todavía se podrá proporcionar límites al retraso.

Se define la función A(t) como el número de bits transmitidos para un tiempo t.

Esta función nos da una visión de los bits transmitido pero dependiente del tiempo. Sin embargo, para algunos test de admisión sería necesario calcular todas las posibilidades en función del valor de t. Como en la práctica es inviable calcular todos los casos para cada realización del tráfico de entrada, es mejor encontrar el peor caso del tráfico de entrada, y comprobar que se puede planificar.

Se puede determinar el peor caso, por medio de una función límite del tráfico A^*_j(t) que denota el máximo número de bits que puede transmitir el canal j en un intervalo de tiempo t. Si el tráfico de un canal está determinado por la función A tal que A[τ,τ+t] representa la transmisión en un intervalo de tiempo [τ,τ+t] , la función A^*(t) será un límite superior de A para todos los valores de τ ≥ 0 y todos los intervalos de tiempo t si se cumple:

[

]

Aτ τ + ≤

Cualquier función A^*(t) que satisface la propiedad se denomina “función de tráfico limitado”. Esta función proporciona un límite independiente del tiempo de A, por lo que el flujo está acotado para cada intervalo de longitud t.

Además, se define la función “envolvente empírica” E^*(t) , que es la función de tráfico constante más exacta para una función A:

^{( )}

[

]

0

* = + ∀ >

> A t t

max t

E τ τ

τ

donde se cumple siempre que:

0 )

( )

( ^*

* t ≥E t ∀t >

A

Si la tasa de transmisión de un flujo está descrita por el siguiente gráfico:

0 0,2 0,4 0,6 0,8 1

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

tasa (Mb/s)

la función A(t) , la envolvente empírica E^*(t) y una función A^*(t) sería:

0 0,2 0,4 0,6 0,8 1 1,2 1,4

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

Mb

E*(t) A*(t) A(t)

En la práctica, una fuente especifica el flujo por medio de un modelo parametrizado. Este modelo define una función que limita el tráfico. En el ejemplo A^*(t) está definida por la siguiente función interpolada:







≤

<

− +

≤

<

− +

≤

<

=

3 2

2 . 0

* ) 2 ( 25 . 1

2 5

. 0 5 . 0

* ) 5 . 0 ( 5 . 0

5 . 0 0

)

*(

t t

t t

t t

t A

2.2.- Modelo de los elementos

Se tiene que describir como afectan los distintos elementos de la red al tránsito de los flujos. Esto dependerá del tipo de elemento, algoritmo de planificación, etc.

En general, se distinguen dos tipos de disciplinas de servicio en los nodos : “non work-conserving”, en el que los nodos intentan mantener el modelo del tráfico, aunque

esto implique que en determinados periodos no se transmita nada, o las disciplinas

“work-conserving” en el que si existen paquetes en el nodo por transmitir se envían. A las primeras pertenecen las disciplinas de tasa controlada (“rate-controlled”) como son las RCSP [Zhang94] , Jitter-EDD [Verma91], “Stop-and-go” [Golestani90] y

“Hierarchical Round Robin” [Kalmanek90] donde se puede determinar el tiempo de retraso de un paquete. Al segundo grupo pertenecen Virtual Clock [Zhang90], Weighted Fair Queueing y GPS (General Processor Sharing) [Parekh92] . Virtual Clock no proporciona funciones para calculo del retraso máximo mientras que en GPS se puede determinar un retraso emisor - receptor dada una topología de red [Parekh93].

Aunque en este trabajo no se va a tener en cuenta, hay que determinar el coste de los algoritmos de planificación para su implementación en redes de alta velocidad. Por ejemplo, un planificador FCFS tiene un coste de implementación bajo, pero sólo puede soportar un límite de retraso para todas las conexiones. En el otro extremo, el algoritmo EDD es complejo ya que involucra una operación de búsqueda del paquete con el deadline más corto.

2.3.- Tests de admisión

Con los modelos del tráfico y de los elementos se pueden desarrollar unos tests que nos indiquen si se puede admitir un nuevo flujo con tales características.

Estos tests pueden ser a nivel de nodo o a nivel de red. A nivel de nodo se chequea con la información disponible del nodo y del flujo si el canal se puede admitir.

En el caso de que no se pueda admitir se rechaza directamente la conexión. A nivel de red, el receptor chequea con toda la información de los nodos por los que ha pasado el mensaje de conexión si se cumplen los requerimientos pedidos. En el caso de ser así, se envía al emisor un mensaje de vuelta de establecimiento de canal. En caso contrario se rechaza el canal y se envía un mensaje de rechazo.

Emisor

Receptor Connect

Accept/

Refuse

Los tests van a depender del modelo de los nodos y del tráfico. Cuando más exactos sean los tests se hará un uso más eficiente de los recurso de la red y se podrán admitir más canales.

3.- Breve descripción de dos protocolos básicos

Los dos protocolos actualmente más difundidos responden a dos formas diferentes de modelar el flujo y con diferentes mecanismos de admisión. RSVP basa su funcionamiento en modelo de flujo continuo mientras que en Tenet Suite la descripción está basada en la características de transmisión de los paquetes. RSVP realiza los test de admisión en el receptor, mientras que Tenet realiza los tests tanto el receptor como en los nodos.

Por lo demás, el funcionamiento de estos protocolos es muy parecido a la hora de asignar los recursos del sistema y establecer la conexión.

3.1.- RSVP (Resource ReSerVation Protocol)

RSVP se ha diseñado [White97][Zhang93] para permitir a los emisores, receptores y routers de las sesiones de comunicación (tanto multicast como unicast) comunicarse con el resto para establecer una ruta que pueda soportar la calidad de servicio requerida. La calidad de servicio viene especificado en un flowspec.

RSVP identifica una sesión por medio de una dirección de destino, un tipo de protocolo de transporte y un número de puerto de destino. RSVP no es un protocolo de encaminamiento, se usa meramente para reservar recursos a través de la ruta que se establezca por cualquiera de los protocolos de niveles inferiores.

Existe un draft del protocolo del IETF [IETF97] . Además existe un proyecto para una nueva versión del protocolo RSVP2 de la University of Southern California/Information Sciences Institute.[RSVP296]

Aunque RSVP en principio sólo era un protocolo de reserva de recursos se describe las especificaciones de flujos utilizada en una implementación[19] de este protocolo así como su control de admisión.

IETF ha considerado varias clases de QoS aunque sólo dos han sido formalmente especificados para RSVP: Servicio Garantizado (Guaranteed Service) [Schenker96] y Servicio de carga controlada (Controlled-Load Service ) [ Wroclawski96] . Nos vamos a limitar al servicio garantizado.

3.1.1.- Servicio garantizado

Esta calidad de servicio está destinada para aplicaciones con requerimientos exigentes de tiempo real. Esta calidad asegura un ancho de banda, un límite en el retraso y ninguna perdida en las colas.

Como introducción, un flujo es descrito usando un esquema “token bucket¹” y dada esta descripción, cualquier elemento de la red (un router, una subred, etc.) calcula varios parámetros describiendo como va a manejar los datos del flujo. Combinando los parámetros de los distintos elementos que recorre el flujo es posible calcular el retraso máximo que se producirá en el flujo.

Cada router caracteriza el servicio garantizado para un flujo determinado, asignando un ancho de banda, R, y un espacio de memoria (buffer space), B, que representa los recursos que el flujo puede consumir. Esto representa que existe un ancho de banda R entre emisor y receptor. Así para un flujo que siga las características de

”token bucket” [Tanembaum96] con un cubo de capacidad b y tasa r se puede calcular el límite del retraso como b/R siempre que R sea mayor r. Para permitir desviaciones para este modelo perfecto se añaden dos términos de error C y D; con lo que el límite del retraso se convierte en b/R +C/R + D. El termino C es el error dependiente de la tasa. Representa el retraso que un datagrama en el flujo puede experimentar debido a la tasa de los parámetros en el flujo. El termino de error D es el error independiente de la tasa y representa el peor caso de variación de tiempo de tránsito a través del router.

Sin embargo se impone una tasa pico del flujo p, que reduce los límites del retraso. Además se tienen que tener en cuenta los efectos de la partición en paquetes en el flujo considerando el tamaño máximo del paquete, M. Esto nos permite disponer de un limite más preciso para el retraso de cola en el router:

) ) (

( ) (

) )(

( D caso p R r

R C M r

p R

R p M

Q_delay b + + ^tot + _tot > ≥

−

−

= − (1)

) ) (

( D casoR p r

R C

Q_delay = M + ^tot + _tot ≥ ≥ (2)

donde Ctot y Dtot representan el sumatorio de los términos de error C y D de cada router de la ruta.

Cada router necesita ser informado de las características del tráfico, Tspec, y del flujo con las características de las reservas realizadas, Rspec. Además necesita los términos C_sum y D_sum que representan la suma de los términos de error C y D, de cada router desde el origen del mensaje. Los parámetros Tspec y Rspec son los siguientes:

1“Token Bucket es una forma particular de especificación del flujo que consiste en una tasa de tokens r y un tamaño de cubo b. Esencialmente, el parámetro r especifica la tasa de datos sostenible continuamente, mientras que b especifica en cuanto se puede exceder esta tasa para cortos periodos de tiempo. Más específicamente, el tráfico debe obedecer la regla de que para cualquier periodo de tiempo, la cantidad de datos enviados no puede ser superior a rT+b, donde T es la longitud del periodo de tiempo ”. Ver descripción en el [Tanenbaum96] Pags 380-386.

Parámetro Tspec Descripción Unidad

p Tasa pico del flujo Bytes/s.

b (bucket depth) Tamaño del cubo Bytes.

r (token bucket rate)Tasa de transmisión del cubo Bytes/s

m Tamaño mínimo del paquete Bytes

M Tamaño máximo de paquete Bytes

Parámetros Rspec

R Ancho de banda Bytes/s

S Slack term. Diferencia entre el retraso deseado y el obtenido usando una reserva de ancho de banda R.

µs

Para utilizar este esquema los routers tienen que aproximarse al modelo de flujo.

Existen varios algoritmos de planificación como el WFQ (Weighted Fair Queueing) [Demers89] , Jitter-EDD [Verma91] y Virtual Clock [Zhang90], que se aproximan a este modelo.

3.1.2.- Test en el receptor

Cuando el receptor recibe un mensaje Path extrae los siguientes parámetros del Sender Tspec: r, b, p, m. Además también extrae del objeto Adspec los siguientes parámetros : latencia mínima de la ruta, Ctot, Dtot, PathMTU y ancho de banda de la ruta.

El límite requerido para el retraso de cola, Qdelreq se calcula restando la latencia mínima de la ruta, del valor del retraso de emisor a receptor requerido por la aplicación receptora. El receptor realizará un chequeo inicial evaluando la ecuación 2 para R igual a la tasa pico p. Si el resultado es mayor o igual que Qdelreq se utilizará esta formula para calcular el mínimo valor de R necesario para satisfacer Q_delreq; sino se utilizará la ecuación 1 para este propósito. Este mínimo valor de R se obtiene insertando Qdelreq en la ecuación 1 o 2 con los valores determinados de Ctot, Dtot ,r, b, p, M. Si el valor R excede el ancho de banda obtenido del Adspec recibido se reducirá. El receptor entonces puede crear una especificación de la reserva, Rspec, que contiene el valor R de ancho de banda que se reservará en cada router y un término slack que será inicialmente cero.

Este mensaje se envía de vuelta por la ruta que ha recorrido. Por cada router que pasa de vuelta, los mensajes se pueden fusionar con otros mensajes Resv con el mismo interfaz, de acuerdo a una serie de reglas que dependen del estilo de reserva, obteniendo un nuevo Flowspec y FilterSpec. Cada router realiza además las siguientes acciones :

• El Flowspec se pasa al módulo de control del tráfico que aplica el control de admisión para determinar si la reserva se acepta.

• Si la reserva es denegada, se envía un mensaje ResvErr.

• Si la reserva es aceptada, el estado de las reservas se actualiza de acuerdo con los parámetros FilterSpec y FlowSpec. La reserva puede ser mezclada con otras reservas de acuerdo con el estilo de reserva, y con esto se creará un nuevo mensaje Resv.

3.1.3.- Término slack

Cuando el receptor genera un Rspec en el mensaje Rserv se incluye un termino slack, S(ms) que inicialmente es cero. S representa la cantidad por la que el límite del retraso estará por debajo del retraso requerido por la aplicación, asumiendo que cada router de la ruta reserva un ancho de banda R. Este término permite una mayor flexibilidad a los router al hacer sus reservas locales.

Cualquier router que use el termino S para reducir su nivel de reserva debe seguir las reglas en la ecuación 3 para asegurar que el límite del retraso de emisor a receptor se satisface.

in out in

i tot in in out

i tot out

out r R R

R C R S b R C R

S + b + ≤ + + ≤ ≤ (3)

donde C_{tot i} es la suma acumulativa de los términos de error, C para todos los routers hasta el emisor e incluyendo el actual elemento i . (R_in, S_in) es la petición de reserva recibida por el router, i. (Rout, Sout) es la petición de reserva modificada unicast del anterior router en dirección al emisor.

En otras palabras este elemento consume Sin- Sout del término slack y puede usarla para reducir su nivel de reserva asegurando que se cumple la ecuación 3.

3.2.- Tenet suite

El Tenet Group de la University of California at Berkeley ha diseñado, simulado e implementado un conjunto de protocolos para soportar canales en tiempo real[Banerjea94][Ferrari89]. Intenta ser una solución completa y está más orientado a la investigación y solución de los problemas existentes en este tipo de redes. Los protocolos Tenet están diseñados para coexistir con los protocolos Internet.

Los canales en tiempo real son establecidos en la fase de conexión que precede a la transferencia de datos. Un mensaje es enviado desde el origen del canal y viaja al destino, provocando que en cada nodo se ejecuten unos test de admisión para comprobar si se puede obtener la calidad de servicio requerida. Cuando llega el mensaje al destino este envía un mensaje de aceptación de canal que llegará al origen estableciéndose el canal.

El grupo tenet tiene también modelos matemáticos y simulaciones de los protocolos utilizados [Ferrari91][Ferrari92][Ferrari93][Widyono94] .

Actualmente tienen en fase de desarrollo una nueva versión del sistema denominada Tenet Suite II.

3.2.1.- Establecimiento y control de canales

El establecimiento de un canal se realiza en una sola pasada. Un mensaje se envía desde el origen al destino del canal. Cada nodo mantiene una tabla de rutas para calcular el próximo salto para el establecimiento del canal. Si el canal puede ser soportado por este nodo (mediante la realización de un test de control de admisión) se reservan de forma provisional los recursos necesarios y el mensaje se envía al siguiente nodo. Si el nodo determina que no puede soportar este canal se envía un mensaje de rechazo de vuelta al origen. Este mensaje libera los recursos reservados por cada nodo por el que pasa de vuelta. Cuando el mensaje de establecimiento de canal alcanza el destino, este toma la última decisión de aceptar o rechazar el canal. Si se acepta el canal se envía de vuelta al origen un mensaje de aceptación. Cuando este mensaje llega a cada nodo intermedio se puede reducir la asignación de recursos realizada en la ida. Cuando la asignación definitiva de recursos se realiza se envía el mensaje al nodo siguiente de vuelta. Cuando este mensaje llega al origen la transmisión sobre el canal puede comenzar.

El cliente debe establecer los requerimientos de calidad de servicio y una descripción del tráfico que va a transmitir en la red. Los parámetros son los siguientes:

Parámetros de QoS Descripción

Dmáx Limite superior de retraso del mensaje de emisor a receptor Zmin Límite inferior de retraso del mensaje de emisor a receptor Jmáx Límite superior de la variación del retraso (delay jitter)

Wmin Límite inferior en la probabilidad de no perdida debido a una sobrecarga de los buffers.

Parámetros del tráfico

Xmin Tiempo mínimo entre mensajes Xave Tiempo medio entre mensajes I Intervalo medio para Xave

Smax Tamaño máximo del mensaje

La implementación de este agente es a través de un daemon. Para la transmisión de mensajes el RCAP utiliza TCP/IP para asegurar que los mensajes llegan a su destino correctamente. Esto implica que los tiempos de conexión no son determinados.

3.2.2.- Transmisión y planificación de paquetes

La entidad RTIP en cada nodo tiene el objetivo de asegurar que todos los paquetes son transportados para que cumplan sus requerimientos de calidad. Cuando se establece una conexión RTIP es informado del máximo retraso d que puede tener un paquete en ese nodo. RTIP asegura que un paquete llegado al nodo en un tiempo T es transmitido al siguiente nodo antes de T + d. RCAP informa además de la cantidad de espacio de buffer asignado a la nueva conexión y del tiempo mínimo y medio entre mensajes. (Xmin, Xave y I).

La planificación en los nodos se basa en una modificación del EDD (Earliest Due Date), en el que en caso de conflicto, se da más prioridad a los canales deterministas que a los estadísticos.

3.2.3.- Test en los nodos

El objetivo de los test en los nodos es asegurar que se puede dar servicio al canal sin afectar a la calidad de servicio del resto de canales.

Cuando un nodo recibe una petición de establecimiento de canal se realizan dos o tres test en los nodos:

Test determinista verifica que hay suficiente poder de proceso para acomodar el nuevo canal sin perturbar el resto. Como la máxima utilización de un nodo por el canal i, cuyo paquetes tienen un tiempo de servicio máximo de ti, es ti/xmin,i. Así, la condición es:

1

,

∑

j minj j

x

t (4)

donde la suma se extiende para todos los canales deterministas, incluido el que se establece.

Test estadístico tiene dos propósitos:

i. determinar si para cada canal estadístico j en el nodo la probabilidad de un retraso mayor que el límite d_j está por debajo del máximo tolerable, 1 – zj;

ii. proporcionar al nodo de destino la información que es necesaria para calcular z_i para el nuevo canal si éste es estadístico.

Los dos propósitos se pueden obtener calculando la probabilidad de sobrecarga del límite Pdo. Un paquete puede ser retrasado más allá de su límite en un nodo por dos causas: una saturación temporal de la capacidad de proceso del nodo (saturación del nodo), o bien, por la saturación del planificador. Este último se evita con el test del retraso límite, mientras el primero se evalúa con este test estadístico.

Una medida de la probabilidad de que el canal j este activo durante un intervalo I es:

j ave

j min

j x

p x

,

= , (5)

Dado m canales independientes 1,2, ... m pasando por el nodo, la probabilidad de que miembros de un subconjunto C de ellos estén simultáneamente activos es dada por:

∏

∏

−

=

C j

j C

j

i p

p

C) (1 )

Pr( (6)

Para calcular Pdo, se empieza listando todas la combinaciones de sobrecarga.

Una combinación de sobrecarga es un conjunto de canales que, cuando está activos simultáneamente durante un periodo de tiempo suficiente, causa que los paquetes incumplan sus limites. En otras palabras, una combinación de sobrecarga es aquella en la que no se cumple la condición (4).

Sea H el conjunto de todas las combinaciones de sobrecarga de un nodo, h un miembro de H, y P(h) la probabilidad de la ocurrencia de la combinación h calculada de acuerdo a (6). Entonces:

∑

=

h

do P h

P ( ) (7)

se puede comprobar si la siguiente desigualdades se satisfacen:

P_do ≤1−z_j (8)

para cada canal estadístico j que exista en el nodo. Para ver si se satisface (8) , es suficiente verificar que:

j do

j

do min z o P maxz

P ≤ (1− ), 1− ≥ (9)

Si este test tiene éxito, entonces el valor de Pdo es enviado al host de destino para que calcule el valor zi final. El uso de este valor por el nodo final se comenta más adelante.

Test del retraso límite determina si se puede evitar la saturación del planificador en el nodo, y, si es así, el mínimo retraso a asignar al canal que se va a establecer para que el objetivo se cumpla.

Para determinar si la saturación del planificador en el nodo es posible se dividen los m canales del nodo en dos conjuntos : A el conjunto de canales cuyo retraso límite en el nodo es menor que la suma de los tiempo de servicio de todos los canales, y B el conjunto de aquellos canales cuyo retraso límite es el nodo es mayor o igual que esa suma:

},

; ,...

1

| {

∑

=

<

=

= ^m

j j

i t

d a i

i

A (10)

},

; ,...

1

| {

∑

=

≥ +

=

= ^m

j j

i t

d m a

i i

B (11)

Se numeran los a canales en A de acuerdo al orden en que se van a planificar.

Asumiendo que

∑

=

≥ ^m

j j l

min t l m

x

1

, ( 1,K ) (12)

que es lo mismo que decir que no llegarán más paquetes a un nodo que puedan interferir con la transmisión de aquellos que estamos considerando.

Entonces la saturación del planificador es imposible si y solo si:

∑

≥ ⁱ

j

m k k j i

i t maxt i a

d

1

) , 1 (

, K (13)

Si la (12) condición no se cumple, se aplicará el siguiente formula al conjunto de canales que incluyen paquetes seguidos. Considerando que estos paquetes incrementa el

∑t, se calcula el nuevo valor de esta suma (∑t)´ , con la siguiente definición recursiva:

∑

∑

( t _o t

⁽

∑

∑

∑

Con la ecuación (13) podemos calcular el mínimo valor d_i con el que se cumple la condición de no saturable. Este valor se enviará al nodo receptor.

3.2.4.- Tests en el receptor

Cuando llega al receptor el mensaje de establecimiento de canal se realizan dos tests. El test del retraso comprueba si no se sobrepasa el retraso total:

∑

∑

≥

n n i n

n i

i mind l

D _{, ,} (15)

En el caso de canales estadísticos, cuando el receptor recibe el mensaje de petición de establecimiento de canal, debe determinar si el valor total Zi puede ser factorizado entre las contribuciones de los nodos z_k (k = 1, 2, .. n):

⁼

∏

k k i

i z

Z _, (16)

Esto se determina comprobando si:

∏

k

k

do Z

P ) 1

( _, (17)

Si se pasan todos los tests en los nodos, el receptor subdivide el retraso D ( y la probabilidad Z) entre los nodos atravesados por el canal, después de restar el retraso total en los enlaces de la ruta. Sea di,n el mínimo retraso asignado al canal i en el nodo n, y z_i,n la mínima probabilidad de que d_i,n no se excediera en ese nodo. Un paquete viajando en este canal y llegando al nodo en el tiempo t se le asignará un retraso máximo de t+ di,n . Para satisfacer el retraso total, es suficiente satisfacer el límite d (o d, z) en cada nodo a través de la ruta.

Los valores Di y Zi se pueden redistribuir utilizando las siguientes formulas:

k i n

n i n

n i i

k

i mind

n

l d

min D

d _,

, ,

, +



 



 − −

=

∑ ∑

( ) (

)

n

n

n do i k

i P

P

z Z _,

1

,

, 1

1 −

















= −

∏

3.2.5.- Tests adicionales

Tenet Suite ha desarrollado otros test más exactos para distintos planificadores.

Para este trabajo se va a comparar el test del algoritmo FCFS. Este algoritmo tiene el gran inconveniente de que el retraso tiene que se común a todos los nodos, aunque tiene la ventaja de ser muy simple de implementar. Existen otros tests como el del algoritmo EDF y de prioridad estática tal como se exponen en [Wregle96].

Para calcula el límite del retraso se utilizará el siguiente test:

= ^*( )− + ∀ ≥0

∈ ∈

∑

d _k

N N k

j

j (18)

4.- Comparación

4.1.- Modelos de tráfico o flujo:

Los parámetros que definen los distintos esquemas son:

RSVP-IETF:

Parámetros Descripción Unidad

p Tasa pico del flujo Bytes/s

b (bucket depth) Tamaño del cubo Bytes

r (token bucket rate)Tasa de transmisión del cubo Bytes/s

m Tamaño mínimo del paquete Bytes

M Tamaño máximo de paquete Bytes

Tenet Suite :

Parámetros Descripción Unidad

Xmin Tiempo mínimo entre mensajes s

Xave Tiempo medio entre mensajes s

I Intervalo medio para Xave s

Smax Tamaño máximo del mensaje Bytes

Flujo constante (CBR):

Parámetros Descripción Unidad

Xmin Tiempo mínimo entre mensajes s

Smax Tamaño máximo del mensaje Bytes

Existen otros modelos que se acercan más a E^*(t) , como puedan ser el D-BIND [Knightly95] y el (σ,ρ) [Wregel96].

Cada modelo en realidad está definiendo una función de tráfico limitado l(t) que indica el número máximo de bytes que se puede enviar en cada intervalo de tiempo t.

Función de tráfico limitado RSVP-IETF l(t)=b+rt

Tenet Suite

I t x I

t S x min S S

t l

ave max min max

max ≤



 +

= ,

) (

CBR t

x S S t l

min max max +

= ) (

Gráficamente:

intervalo longitud t l(t) máximo bits

RSVP Tenet CBR p

Xmin I I Smax

Xave

Smax

Para esta comparación se van a distinguir tres tipos de tráfico:

• CBR : “Delay Sensitive Constant bit-rate” : Tráfico en tiempo real con una tasa de transmisión constante. Por ejemplo, audio con muestreo fijo sin comprimir.

• VBR : “Delay Sensitive Variable bit-rate” : Tráfico en tiempo real con una tasa de transmisión variable. El ejemplo más claro de este tipo de tráfico es la transmisión de vídeo comprimido por ejemplo en formato MPEG, en el que cada imagen puede tener una tasa compresión bastante variable.

• ABR : “Available Bit Rate” : Es tráfico que no es sensible al retraso.

4.2.- Modelos de los nodos/ elementos

El modelo a utilizar en los nodos dependerá del algoritmo de planificación de los paquetes. Un nodo vendrá definido por un ancho de banda de salida Li, y una capacidad de memoria B_i.

RSVP-IETF:

Hay que calcular los valores Ci y Di para cada elemento de la red.

Para una planificación en los nodos WFQ (Weighted Fair Queueing) los valores C_i Y D_i se calculan así (Ver [Wroclawski96] págs 16-17)

• Di es igual al valor del MTU del enlace dividido por el ancho de banda del enlace. Así se tiene en cuenta la posibilidad de que un paquete llegue justo cuando se empieza a transmitir el paquete más grande.

• El valor Ci se asume que es M para tener en cuenta los efectos de la división en paquetes.

Tenet Suite:

Se utiliza un algoritmo de planificación determinista como el Earliest Due Date.

Los valores a calcular en los nodos serán:

• ti : tiempo máximo de transmisión en los nodos. Este valor dependerá del ancho de banda de salida L_i y el máximo tamaño de un paquete del flujo S_max. En este valor puede influir la capacidad de proceso del nodo. En principio asumimos que su valor es Smax /Li

• di : Deadline en el nodo del flujo. Se calculará el menor valor que el nodo permita.

FCFS:

En los nodos se utilizará un algoritmo FCFS para planificar los paquetes.

4.3.- Test de planificabilidad

Los test a pasar son en resumen los siguientes:

Esquema Test en los nodos Test en el receptor

RSVP-IETF 0 1

Tenet Suite 2 1

FCFS 1 1

5.- Descripción de la carga

Para todos los flujos se va utilizar un valor de I = 3s y Smax=M=10000 bits.

5.1.- Flujo 1: VBR

Este flujo describe una carga con una tasa de transmisión con pequeñas variaciones, como podría ser una transmisión de videoconferencia. Un ejemplo de este tipo de flujo sería descrito por el siguiente gráfico:

0 0,2 0,4 0,6 0,8 1

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

tasa (Mb/s)

A partir de aquí se pueden calcular las distintas funciones de tráfico limitado, así como las funciones A(t) y E*(t) .

0 0,25 0,5 0,75 1 1,25 1,5

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

Mb

A(t) E*(t) RSVP Tenet CR 1,06

Los valores resultantes para cada descripción del flujo son los siguientes:

RSVP Tenet Suite CBR

b = 0,3 Mb r = 0,36 Mb/s p = 1 Mb/s Xave = 0,0286s Xmin = 0,01s Xmin = 0,01s

5.2.- Flujo 2: HVBR

Se va a denominar HVBR (High Variable Bit Rate) al flujo con una gran variación de la tasa de transmisión. Este flujo representa una transmisión de información a ráfagas y poco determinista. Un ejemplo de este flujo podría ser el telecontrol o una transmisión de una conversación.

0 0,5 1 1,5 2 2,5 3

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

tasa (Mb/s)

Se puede calcular las distintas funciones de tráfico limitado así como la envolvente :

0 0,25 0,5 0,75 1 1,25 1,5 1,75

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

Mb

A(t) E*(t) RSVP Tenet CR 0,98

Los valores resultantes para cada descripción del flujo son los siguientes:

RSVP Tenet Suite CBR

b = 0,71 Mb r = 0,33 Mb/s p = 3 Mb/s Xave = 0,03s Xmin = 0,0033s Xmin = 0,0033s

5.3.- Flujo 3: CBR

Este flujo tiene una tasa de transmisión constante o con mínimas variaciones.

0 0,25 0,5 0,75 1

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

tasa (Mb/s)

En este caso las funciones de tráfico limitado son equivalentes

0 0,25 0,5 0,75 1 1,25 1,5

0 0,2 0,4 0,6 0,8 1

1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

t (s)

Mb

E*(t) RSVP Tenet CR

Los valores de cada flujo son los siguientes:

RSVP Tenet Suite CBR

b = 0 Mb r = 0,5 Mb/s p = 0,5 Mb/s Xave = Xmin = 0,02s Xmin = 0,02s

6.- Análisis para un nodo

Primero se va a realizar la comparación de los distintos esquemas en un sólo nodo. El nodo a utilizar en las comparaciones va a tener un enlace de salida L de 10 Mb/s con un MTU (Minimal Transmision Unit) de 2000 bits.

La comparación más útil es el número máximo de canales n que admite para un retraso determinado. De esta forma se pueden comparar la eficiencia de los distintos esquemas.

Con esto valores, se puede calcular los valores C_i y D_i para RSVP que son:

Di = MTU/L = 0,0002 y Ci= M = 0,01

Sustituyendo estos valores y los del flujo en las ecuaciones (1) y (2) obtenemos dos funciones que devuelve el retraso de cola² en función del ancho de banda R a reservar en el nodo. Con este valor dividido por el ancho de banda del enlace nos da el número de canales admitidos. Sustituyendo por tanto R por L/n tenemos el retraso en función del número de canales.

Para Tenet Suite se utilizará el test determinista (4) que para todos los canales iguales se queda:

≤1 L X n S

min

max (20)

Para el test de retraso límite como todos los canales son iguales resulta el conjunto A o está compuesto por todos los canales o bien está vacío. Si A está lleno significa que los canales no son planificables. Con lo que simplemente hay que tener en cuenta la siguiente condición:

L

nS

d ≤ ^max (21)

Para FCFS se utiliza la siguiente ecuación simplificada para el caso en que todos los canales sean iguales (Ver [Zhang94]) :

( )









>

∧

≤

 +

 

 −

+ + ≤

=

X L n S X L

nS L si

I S X X L X n S X

X L n S L si

n S d

min max ave

max max

sve min ave

max min

min max

max 1

(22)

Como valores de referencia se puede comparar con los valores Xave y Xmin, para ver cuales son el número medio de canales a usar y el máximo:

2 Para calcular el retraso máximo de transmisión habría que sumarle la latencia mínima de la ruta (ver

min max min

X S

n = L y

ave max max

X S n = L

6.1.- Flujo 1 : VBR

Para RSVP sustituyendo en (1) y (2) nos queda:

d = 0,002n + 0,0002 ⇒ n = 500d – 0,1 para n ≤ 10

d = 0,0047n – 0,45 ⇒ n = 21,28d + 9,57 para 27,7 > n > 10

Para Tenet Suite sustituyendo en (20) nos da un máximo de 10 canales.

Sustituyendo en (21) queda:

d = 0,001n ⇒ n = 1000d para n ≤ 10

Las ecuaciones del retraso para FCFS se calculan sustituyendo los valores en (22) :

d = 0,001(n+1) ⇒ n = 1000d – 1 para n ≤ 10 d = 0,105n – 1,039 ⇒ n = 9,52d + 9,9 para n > 10

Los valores medio y máximo de canales son n_med= 10 y n_max=28,6. Gráficamente el número de canales admitidos es el siguiente³:

0 5 10 15 20 25 30

0,000 0,500 1,000 1,500 2,000 2,500 3,000

d (s)

Canales

RSVP FCFS Tenet Xave

Utilizando una escala logarítmica se ven mejor las diferencias:

3 Aunque el número de canales admitidos n es siempre un valor entero, se ha preferido representar este

0 5 10 15 20 25 30

0,001 0,010 0,100 1,000 10,000

d (s)

Canales

RSVP FCFS Tenet Xave

De los resultados se desprende que RSVP resulta el más eficiente para un retraso entre 0,05 s y 1s. Para retrasos menores a 0,05 Tenet y FCFS admite más canales, quizá debido a la simplicidad de su algoritmo. Tenet tiene la limitación de no poder utilizar más de 10 canales al basarse en los valores de tasa mínimo. FCFS aumenta los canales permitidos de forma lineal aunque de una forma más lenta que RSVP.

6.2.- Flujo 2 : HVBR

Para RSVP sustituyendo en (1) y (2) nos queda:

d = 0,002n + 0,0002 ⇒ n = 500d – 0,1 para n ≤ 3,3 d = 0,0798n – 0,2458 ⇒ n = 12,53d + 3,08 para 30 > n > 3,3

Para Tenet Suite sustituyendo en (20) nos da un máximo de 3,3 canales.

Sustituyendo en (21) queda:

d = 0,001n ⇒ n = 1000d para n ≤ 3,3

Las ecuaciones del retraso para FCFS se calculan sustituyendo los valores en (22) :

d = 0,001(n+1) ⇒ n = 1000d – 1 para n ≤ 3,3 d = 0,1n – 0,3257 ⇒ n = 10d + 3,257 para n > 3,3

Los valores de n_min y n_max serán respectivamente 3,3 y 30.

0 5 10 15 20 25 30 35

0,0 0,5 1,0 1,5 2,0 2,5 3,0

d (s)

Canales

RSVP FCFS Tenet Xave

0 5 10 15 20 25 30

0,001 0,010 0,100 1,000 10,000

d (s)

Canales

RSVP FCFS Tenet Xave

En este caso no se ve que hay mucha diferencia entre RSVP y FCFS en la admisión de canales. Esto es quizá debido a que la descripción del flujo de Tenet Suite se acerca más al flujo 2 que RSVP.

6.3.- Flujo 3 : CBR

Para RSVP como r = p la ecuación (1) no es válida con lo que el retraso vendrá dada por la (2) que es:

d = 0,002n + 0,0002 ⇒ n = 500d – 0,1 para n ≤ 20

Para Tenet Suite sustituyendo en (20) nos da un máximo de 20 canales.

Sustituyendo en (21) queda:

d = 0,001n ⇒ n = 1000d para n ≤ 20

Las ecuaciones del retraso para FCFS se calculan sustituyendo los valores en (22) :

d = 0,001(n+1) ⇒ n = 1000d – 1 para n ≤ 20

Los valores de nmin y nmax serán iguales a 20.

0 5 10 15 20 25

0,000 0,010 0,020 0,030 0,040 0,050

d (s)

Canales

RSVP FCFS Tenet Xave

En este caso RSVP no es muy eficiente, en el caso de pequeños retrasos, donde Tenet Suite y FCFS se comportan mejor.

7.- Análisis para varios nodos

Para poder calcular el retraso total en una red con varios nodos, en principio habrá que sumar el retraso producido en cada nodo más el tiempo de transmisión de los paquetes en los enlaces. Esto, en general, no es tan simple debido a que la dinámica de la red puede modificar las características del flujo.

En este sentido existen dos tipos de planificadores, los que son independiente del tipo de flujo que entre y los que asumen que el flujo sigue los parámetros determinados.

Paro los primeros se puede calcular el retraso sumando los retraso en los nodos y en los enlaces, para los segundos habrá que asegurar que el tráfico no sobrepase los parámetros determinados en el flujo. Para ello se añade un nuevo elemento en los nodos que es el controlador de tasa (rate-controller) [Zhang94] .

Regulador n Regulador 2 Regulador 1

Tráfico entrada (Tiempo real)

Tráfico

regulado Cola de paquetes de tiempo-real

Tráfico de entrada (no tiempo-real)

Controlador de tasa Planificador

Este elemento es un regulador de tráfico que a grandes rasgos mantiene las características del flujo por medio de un buffer interno. Según Zhang [Zhang93b] la permanencia de los paquetes en estos reguladores no afecta a los límites del retraso. Por lo tanto el retraso de emisor – receptor puede ser calculado sumando los retrasos en cada nodo.

La comparación se va a realizar en una red con un emisor, tres nodos y un receptor, como sigue:

n1

n2

Emisor n3

Receptor l1

l2

l3

l4

donde las características de los nodos y los enlaces son:

Enlace Ancho Banda (Mbits) MTU

l1 10 0,002

l2 15 0,001

l3 20 0,003

l4 10 0,002

Para RSVP se pueden calcular los valores Ci y Di que son

∑

∑

= 0,000617

i i i

sum AB

D MTU

D y ^{Csum =}

∑

∑

y se calcularán las funciones del retraso en función de los canales de la misma forma que para un sólo nodo. En estos cálculos se asume que la latencia tendrá un valor no significativo con respecto al retraso de cola y no se tiene en cuenta (La latencia mínima será menor de 0,03 ms).

Para Tenet Suite y FCFS se calcula el retraso total en función de los retrasos en los nodos. El retraso total por lo tanto es:

3 2 1 4 3 2

1 d d d 2d d d

d d

d_total ≤

∑

Donde d1 es el retraso en el enlace 1 de 10Mbits, d2 es el retraso en el enlace 2 de 15Mbits y d₃ es el retraso en el enlace 3. Como d₄ es igual a d₁ se suman.

7.1.- Flujo 1 : VBR

Para RSVP sustituyendo en (1) y (2) nos queda:

d = 0,005n + 0,0006 ⇒ n = 200d – 0,12 para n ≤ 10

d = 0,05n – 0,45 ⇒ n = 20d + 9 para 27,7 > n > 10

Para Tenet Suite calculando los retrasos en cada nodo y calculando el máximo de canales para cada nodo resulta:

d₁ = 0,001n para n < 10