Informe Final QoS

Métodos para Asegurar la Calidad del Servicio Taller de Redes de Computadores 2010

1 de 13

Departamento de Informática

Universidad Técnica Federico Santa María

Métodos para Asegurar la Calidad del Servicio

(Quality of Service)

Taller de Redes de Computadores 2010

Profesor: Javier Cañas R.

Oscar Encina C. [email protected]

José Miguel Herrera [email protected]

Contenidos

Resumen …............................................................................................................ 1

Objetivos Propuestos ….......................................................................................... 2

Introducción …....................................................................................................... 2

Calidad de Servicio o QoS …................................................................................. 2

Arquitectura de Calidad de Servicio ...................................................................... 3

Métodos para QoS …….......................................................................................... 3

Marcado de Paquetes............................................................................................ 6

Implementación de QoS …..................................................................................... 7

Técnicas de Encolamiento ….................................................................................. 8

Pruebas y Resultados Experimentales .................................................................. 9

Conclusiones…....................................................................................................... 12

Bibliografia ………………………………………………………………………13

Resumen

Se dice que una red ofrece “Calidad de Servicio” cuando esta garantiza el valor de uno o

varios parámetros que determinan la red (Prioridad, Retraso, Ancho de banda, Jitter,

Errores). Uno de esos parámetros es la Priorización en el envío de datos la cual nos asegurará

el envío anticipado de un tipo de paquetes con respecto a otro de menor prioridad. Otro de

esos parámetros es la asignación de Banda Ancha a ciertos protocolos o aplicaciones

garantizando que en un determinado tiempo habrá más paquetes de un tipo de servicio que

de otro que le sea asignado menor porcentaje. Dichos parámetros se configuran sobre un

sistema Linux para poder implementar un sistema de Video Conferencia con Calidad de

Servicio.

mailto:[email protected]

mailto:[email protected]


2 de 13

Objetivos Propuestos

Aprender mediante la investigación y práctica acerca de los métodos de QoS.

Montar una red QoS en Linux (de tráfico privilegiado).

Generar QoS para un sistema de Video Conferencia.

Utilizar herramientas de tráfico de redes para poder medir y registrar los resultados

obtenidos.

Introducción

El protocolo IPv4 y el naciente IPv6 constituyen la base de las comunicaciones de Internet. Existen flujos

de tráfico sobre estas redes que son críticos y deben ser tratados de forma especial pues no todos los datos

que son transmitidos tienen la misma importancia. Causa de esto es que surge la necesidad de estudiar e

implementar esquemas de Calidad de Servicio que permitan otorgar una distinción en la manipulación de

estos flujos.

Además, dado que la red IP está diseñada bajo una filosofía de mejor esfuerzo, no se garantiza el envío de

un flujo por sobre otro ni un privilegio de servicios. Por esto, se hace imprescindible la utilización de

esquemas que garanticen cierto nivel de QoS.

En este informe se entregarán las pautas mediante las cuales se logró una mejora considerable e

importantísima en la calidad de servicio aplicada a las Video Conferencias.

Calidad de Servicio o QoS

Se entiende por Calidad de Servicio a la capacidad de una red para sostener un comportamiento adecuado

del tráfico que transita por ella, cumpliendo con parámetros relevantes para el usuario final.

Su objetivo es el de acotar los parámetros Ancho de Banda, Retardo, Jitter, y Porcentaje de Pérdida de los

paquetes para ciertas clases de tráfico.

Cada tipo de tráfico es asociado a una Clase de Servicio, utilizándose diversos métodos en los routers y

switches para otorgar el servicio apropiado a cada clase.

Se utilizan campos de diferenciación en los protocolos IPv4 e IPv6 para lograr el marcado de los paquetes.

Dichos campos se describirán con posterioridad en “Arquitecturas de Calidad de Servicio”.

Dentro de las consideraciones que se deben tener en cuenta para proporcionar una Calidad de Servicio, es

preocuparse por los siguientes elementos (problemas) de las redes:

Retardos:

Puede que los paquetes tomen un largo tiempo en alcanzar su destino, esto principalmente es


3 de 13

debido a que permanecen en largas colas y toman alguna ruta menos directa al destino (en su

intento de prevenir la congestión). En la mayoría de los casos, los retardos excesivos son un gran

problema cuando uno se quiere comunicar con sistemas VoIP o sistemas de Video Conferencia.

Jitter:

Se define como la variación en el tiempo en la llegada de los paquetes. Puede ser causada por

congestión de red (su principal causa), la pérdida de sincronización por las diferentes rutas

seguidas por los paquetes para llegar al destino.

Para compensar el jitter se utilizan jitter buffers. En ellos se almacenan los paquetes recibidos

con “adelanto”y se van sirviendo con un pequeño retraso. Los paquetes con “retraso” se

descartan. Si el jitter buffer es muy pequeño, se descartarán muchos paquetes; si es muy grande,

se agregará mucho retardo a la comunicación.

Entrega fuera de Orden:

Si se tiene un conjunto de paquetes relacionados entre si y éstos son encaminados por una red

(como Internet), los paquetes pueden tomar diferentes rutas, resultando en diferentes retardos y

ocasionando que lleguen en diferente orden de cómo fueron enviados. Para los sistemas de

Video Conferencia es vital que los paquetes lleguen en orden, por lo tanto se debe asegurar ese

punto (y no así que todos los paquetes lleguen, es decir, admite pérdidas).

Arquitecturas de QoS

Mejor Esfuerzo, servicio tradicional de transporte de datos, donde no hay garantía de la entrega

del paquete. TCP/IP fue diseñado para dar un servicio „best effort‟ o de mejor esfuerzo, sin

embargo existen aplicaciones que no pueden funcionar en una red congestionada con “best effort”

(por ejemplo, la Video Conferencia o VoIP, etc). Se han hecho modificaciones a IP para que

pueda funcionar como una red con QoS.

Servicios Integrados, provee un servicio garantizado, negociando parámetros de red de extremo a

extremo mediante RSVP. Cada dispositivo a lo largo de la ruta necesita comprender RSVP y

señalizar la QoS requerida. Cada reservación debe ser actualizada periódicamente lo que se añade

tráfico a la red. Además, cada reservación debe ser mantenida por cada uno de los dispositivos a lo

largo de la ruta.

Figura 1: Cabecera IPv4 antes de DiffServ, se marca el campo “Type Of Service”


4 de 13

Figura 2: campo “Type Of Service” (obsoleto)

Servicios Diferenciados, mediante la clasificación de paquetes utiliza mecanismos de

encolamiento para dar prioridad a los paquetes. Se definen varias clases de servicio, donde se

agrupan los tráficos. La clasificación y marcado ocurre sólo en los bordes de la red. En base a esta

clasificación se implementa en cada salto el comportamiento deseado.

Figura 3: Cabecera IPv4 con DiffServ (RFC2474, 1998), se marca el campo “DS”

En definitiva, IntServ (o Servicios Integrados) fue desarrollado con anterioridad a DiffServ, sin embargo

DiffServ (o Servicios Diferenciados) se ha extendido más que IntServ, DiffServ permite agregar flujos, el

modelo es escalable. Debido a estas diferencias muchos fabricantes de routers implementan versiones

eficientes de DiffServ, pero no de IntServ. Actualmente muchos ISP implementan DiffServ.

La única (hasta el momento) arquitectura que es capaz de proveernos una real Calidad de Servicio es la

arquitectura de Servicios Integrados, sin embargo los costos en los que se debería incurrir para poder

implementar una solución como ésta escapan de lo óptimo.


5 de 13

Si se deseara implementar esta solución (Servicios Integrados) habría que adquirir equipos de última

generación o que soporten IPv6. Estas implementaciones se pueden encontrar en los Routers Cisco,

capaces de leer el campo DS (en IPv4). IPv6 también cuenta con un campo para Calidad de Servicio

incorporado “DS” (ver Figura 4).

Figura 4: Cabecera IPv6 con DiffServ (RFC2474, 1998)

Por otro lado, se consiguió a un costo cero una implementación de arquitectura de Servicios Diferenciados

para una red que desea transmitir Video Conferencia asegurando o garantizando ciertos parámetros

(Prioridad y Ancho de Banda).

Métodos para QoS

La implementación de Políticas de Calidad de Servicio se puede enfocar en varios puntos según los

requerimientos de la red, los principales son:

Asignar ancho de banda en forma diferenciada

Evitar y/o administrar la congestión en la red

Manejar prioridades de acuerdo al tipo de tráfico

Modelar el tráfico de la red

Para esta implementación en particular se optó por realizar la combinación de dos requerimientos de red,

controlando la Prioridad de acuerdo al tipo de tráfico y también asignando un Ancho de Banda de forma

diferenciada. De esta manera, podremos tener un sistema de Video Conferencia que privilegia el tipo de

tráfico UDP y que se le es asignada una cantidad de banda ancha superior al resto.


6 de 13

Marcado de Paquetes

Para realizar el marcado de paquetes se utiliza iptables, en especial la tabla “mangle”:

La tabla Mangle:

En esta tabla podremos modificar parámetros de los paquetes como el TOS (Type Of Service) de

IPv4. Esta será la tabla que utilizaremos para el marcado de paquetes y posterior priorización para

aplicar QoS. De las cuales se podrá marcar un campo TOS o MARK (modificar el campo TOS o

marcar el paquete aparte).

MARK: Se utiliza para el marcado de paquetes. Este será el objetivo que se urilizará junto con tc

(programa Trafic Control) para definir las reglas de QoS. Destacar que cuando marcamos un paquete no

estamos cambiando ningún valor de la cabecera IP, sino el valor del paquete de cara al kernel. El valor que

tomará MARK será un entero entre 0 y 65535.

Para modificar la cabecera IP, podemos cambiar el valor del Type Of Service con el objetivo TOS.

Por ejemplo:

labds:~# iptables -t mangle -A PREROUTING -p tcp --dport 21 -j MARK --set-mark 2

Le indicamos a la tabla mangle que todo paquete FTP ( -p tcp --dport 21) que reciba la máquina deberá ser

marcado (-j MARK --set-mark 2) para su posterior clasificación y envio (-A PREROUTING).

TOS: Lo utilizaremos para cambiar el valor de 8 bits del campo TOS dentro de la cabecera IPv4. Este

campo indica la prioridad del tráfico, y se aplicará en routers que tengan soporte para QoS.

Los valores son:

• Minimize-Delay - 0x10

• Maximize-Throughput - 0x08

• Maximize-Reliability - 0x04

• Minimize-Cost 2 - 0x02

• Normal-Service 0 - 0x00

Por ejemplo:


7 de 13

labds:~# iptables -t mangle -A PREROUTING -p icmp -j TOS --set-tos Minimize-Delay

Marcamos todos los paquetes ICMP con el TOS Minimize-Delay. También los podríamos haber marcado

con 0x10. Podemos comprobar que ha cambiado el valor del TOS haciendo un ping y capturando el

paquete con un sniffer como Ethereal (también pudo haberse utilizado el sniffer Wireshark):

Implementación de QoS

Para lograr implementar QoS en nuestro sistema, en primera instancia fue necesario recompilar el kernel

de Linux para poder agregar los módulos QoS correspondientes.

Los módulos del kernel de Linux para proporcionar QoS son:

Networking Options: Network packet filtering

P: Netfilter configuration:

○ Netfilter MARK match support

○ Connection state match support

○ Packet filtering


8 de 13

○ Packet mangling

○ MARK target support

○ Connection tracking

○ Layer7 match support

Gracias a esto, fue posible utilizar el comado tc (Traffic Control) el cual facilita el marcado de paquetes

(para una priorización de tráfico) y la creación de colas de prioridad.

Técnicas de Encolamiento

Existen 2 técnicas posibles:

1) Disciplinas de colas simple :

Simplemente se limitan a aceptar, reordenar, descartar o retrasar los datos.

Podemos utilizar:

• pfifo_fast: First In Fisrst Out, con especial tratamiento al campo TOS.

• TBF: Deja pasar paquetes que no se excedan de una tasa impuesta por nosotros.

• RED: Únicamente indicado para routers de backbone, en donde el envio de tráfico debe ser lo

más rápido posible.

• SFQ: Envia datos de forma equitativa, evitando que nadie se apodere del ancho de banda.

2) Disciplinas de colas con clase:

Estas a diferencia de las simples, tienen nivel de profundidad. Es decir, se puede tener una qdisc raíz

de la que cuelguen ciertas subdivisiones, en las cuales se podrá agrupar diferentes tipos de paquetes

(clases) para luego darle prioridades. A su vez, las clases pueden tener otras qdisc con o sin clases.

Por defecto, cuando se crea una clase, se le adjunta una qdisc FIFO (se puede cambiar por otra),

salvo que de esa clase tenga clases hijas. El esquema se puede visualizar en la siguiente imagen:


9 de 13

Para identificar las clases, utilizaremos una notación de dos números separados por dos puntos :

major:minor. El major, se utiliza para referenciar la raíz de una clase, en cambio el minor se refiere a

cualquiera de las clases que descienden de la raíz padre.

Por último, para tratar a los paquetes en las diferentes clases, se debe utilizar un filtro, que de la misma

manera que hacían las reglas del firewall, en caso de cumplir unas determinadas características, irán a unas

clases o a otras. Las principales qdisc con clases:

• CBQ: Algoritmo que basándose en prioridades, envía paquetes. Útil para enviar paquetes a

clases hijas.

• HTB: Igual que CBQ pero un poco más eficiente.

Filtros: Los filtros serán los que nos permitirán clasificar los paquetes en diferentes clases.

• fw: Clasificará el tráfico basándose en la marca del paquete que le colocaremos con el “objetivo”

MARK de iptables.

• u32: Se basará en características de la cabecera IP para hacer las clasificaciones.

Pruebas y Resultados experimentales

FTP – SSH – Sin Calidad de Servicio:

Se enviaron dos archivos en igualdad de condiciones, sin ningún tipo de regla de calidad de servicio, estos

archivos eran exactamente iguales y se transfirieron de manera concurrente, uno utilizando FTP y otro

utilizando un cliente de copia de archivos vía SSH.

De la figura que se encuentra abajo se puede concluir que el ancho de banda se reparte en igual proporción

por los servicios, la cantidad de paquetes enviados es la misma en casi todo instante.


10 de 13

Figura 5: FTP – SSH – Sin Calidad de Servicio (concurrente)

FTP – SSH con Calidad de Servicio:

En esta segunda prueba, se aplicaron las siguientes reglas de calidad de servicio:

SSH tiene prioridad 2 mayor a FTP que tiene prioridad 3 y el Ancho de banda es igual para ambos tipos

de transferencias. Se repite el experimento realizado anteriormente, transfirieron dos archivos iguales de

80Mb cada uno vía SSH y FTP. Nuevamente para este experimento se igualó y asignó la misma cantidad

de Ancho de Banda.

En la segunda imagen se puede observar con claridad lo que sucede al terminar primero la transferencia

del archivo por SSH. Al finalizar, el ancho de banda es utilizado por la conexión FTP y rápidamente envía

el resto del archivo. Esto ocurrió pues no se escribieron reglas para controlar de manera especial el ancho

de banda para cada uno, por lo tanto, éste se pudo sumar a la única transferencia en curso.

Figura 6 y 7: FTP – SSH – Con Calidad de Servicio (concurrente)


11 de 13

FTP – SSH – Skype Sin Calidad de Servicio:

En este experimento se agregó el servicio VoIP Skype. Este escenario consiste en la transferencia de 160

Mb repartidos entre transferencias SSH y FTP. A este carga, se le debe sumar la cantidad de paquetes que

Skype es capaz de enviar pese a la enorme transferencia de información.

La prueba se realizó de manera concurrente para los tres servicios. Ninguna regla de Calidad de Servicio

fue aplicada.

Como se puede ver en los gráficos obtenidos, la conexión SSH y FTP agotan todo el ancho de banda no

permitiéndole a Skype una correcta comunicación, no es capaz de enviar todos los paquetes y la calidad de

la video conferencia es bastante deficiente.

Figura 8: FTP – SSH – Skype Sin Calidad de Servicio (concurrente)

FTP – SSH – Skype con Calidad de Servicio:

En este escenario, se le aplicaron las reglas de Calidad de Servicio, dejando Skype con la mayor prioridad

de 1, luego SSH con una prioridad 2 y finalmente FTP con una prioridad de 3.

Junto con esto, también controlamos el Ancho de banda para cada servicio, repartimos un total de 2Mb de

ancho de banda de la siguiente manera, Skype utilizará el 50%, mientras que SSH utilizará un 30% y

finalmente FTP el 20% restante.

Los resultados son concluyentes, se aprecia una muy buena calidad en la transferencia de la información

de la Video Conferencia, en ningún momento se produce una caída del servicio pese a que

simultáneamente se produce una transferencia de 160Mb.

En los gráficos se puede apreciar que la conexión de Skype (tráfico UDP), envía una mayor cantidad de

paquetes por intervalo de tiempo comparado con SSH y FTP. Esto se debe a que Skype, tiene una

prioridad en las colas de salida y también en la colas de entrada. A esto, se le debe agregar que tiene un

Ancho de banda reservado del 50% del total disponible.


12 de 13

Sin duda el objetivo principal se cumplió de manera satisfactoria. La Video Conferencia se realiza sin

problemas, los retardos son mínimos y la calidad aumenta pues llegan una mayor cantidad de paquetes que

hacen de la experiencia algo mucho mas fluido y natural.

A continuación se muestran los gráficos que describen el escenario anterior.

Figura 9 y 10: FTP – SSH – Skype con Calidad de Servicio (concurrente)

Los gráficos anteriores corresponden a la misma situación testeada dos veces en tiempos distintos. Los

resultados son similares como era de esperarse.

Conclusiones

Existen muchas maneras y combinaciones para lograr una Calidad de Servicio, la implementación de

arquitecturas de Servicios Diferenciados por sobre los Servicios Integrales constituyó algo fundamental,

pues no solo no se incurrió en gastos especiales de Routers capaces de manejar campos especiales, si no

que la implementación fue muy rápida, precisa y económica.

Es absolutamente necesario configurar cada enrutador con políticas y reglas de calidad de servicio si se

desea asegurar en un cien porciento la calidad del servicio, sin embargo, realizar una distribución y

modelación del tráfico de una LAN es perfectamente viable implementando Servicios Diferenciados, y sus

resultados son satisfacen totalmente las expectativas.

Las redes universitarias y también en las empresas se deberían preocupar de configurar e

implementar soluciones de Calidad de Servicio, pues no solo es económico (en el caso de los

Servicios Diferenciados) si no que también es muy útil, pues se podría tener un control total del

tipo de tráfico que se desea privilegiar.

Con el auge de las aplicaciones online, en las empresas se está migrando todas las aplicaciones de

gestión a la red debiéndose conectar a servidores externos; En situaciones como éstas, si se


13 de 13

implementara de manera correcta la Calidad de Servicio, se podría controlar y privilegiar el

tráfico hacia ese servidor y asegurarle un ancho de banda; Esto traería como consecuencia un

inmediato aumento en la satisfacción de la experiencia de uso de los clientes con su sistema de

administración remoto (como los sistemas integrados de gestión, por ejemplo).

En los laboratorios también se podrían aplicar ciertas reglas de Calidad de Servicio para que los

alumnos que realicen cierto tipo de transferencias, o deseen realizar actividades no académicas

tengan un porcentaje menor de Banda Ancha que aquellos que desean visitar páginas de docentes.

La cantidad de aplicaciones que tiene la Calidad de Servicio es grandísima, más aún, con el auge

de las redes, controlar el tipo y la cantidad de tráfico asignado para sus ellas es crucial, siempre se

debería privilegiar aquél servicio para el cual existe la red. Si la red se creó para realizar Video

Conferencias, éstas deben tener el privilegio y asignadas una mayor cantidad de garantías. Por

otro lado, si la red es educativa, los sitios distractivos deben tener menos privilegios que aquellos

educacionales o de investigación.

Bibliografía

• „Quality of Service-Fact or Fiction?‟ Geoff Huston, Internet Protocol Journal Vol. 3 Nº 1.

http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_qos.html

• Intserv: http://www.ietf.org/html.charters/intserv-charter.html

• RSVP: http://www.ietf.org/html.charters/rsvp-charter.html

• Diffserv: http://www.ietf.org/html.charters/diffserv-charter.html

• Grupo de Trabajo QoS Internet2: http://www.internet2.edu/qos/wg

• B. Teitelbaum: „Internet 2 Qbone: A Test Bed for Differentiated Services‟,

www.isoc.org/inet99/proceedings/4f/4f_1.htm

Informe Final QoS

Documents

Transcript of Informe Final QoS