PONTIFICIA UNIVERSIDAD CATÓLICA DEL

ECUADOR

INFORME FINAL PROYECTO

TITULO:

“Estudio de la factibilidad de utilizar herramientas de Vídeo-Teléfono

con soporte de Calidad de Servicio (QoS) en la Intranet de la PUCE “

Preparado por: Gustavo Chafla Ph.D.

 CONTENIDO

1 INTRODUCCION..........................................................................................................3
2 METODOLOGÍA...........................................................................................................3
3 DESCRIPCIÓN DEL AMBIENTE DE PRUEBAS .....................................................4
4 ELECCIÓN DE LA APLICACIÓN DE VIDEO-TELEFONO.....................................5
5 ELECCIÓN DEL MANEJO DE QoS ...........................................................................7
5.1 QoS bajo Windows XP............................................................................................7
5.2 Netmeeting y el modelo de QoS..............................................................................9
6 CONFIGURACIÓN DE LOS DISPOSITIVOS DE RED...........................................10
6.1 Creación del Clasificador......................................................................................11
6.2 Creación del perfil.................................................................................................12
6.3 Niveles de servicio del conmutador.......................................................................14
7 PRUEBAS DE RENDIMIENTO.................................................................................15
7.1 Configuración de la tasa de cuadros por segundo.................................................15
7.2 Pruebas de estrés del conjunto ya configurado......................................................17
8 CONCLUSIONES........................................................................................................18
1 INTRODUCCION

Durante los últimos años se ha observado una creciente tendencia de la tecnología de las
telecomunicaciones hacia la utilización de las redes de datos IP como una plataforma
multi-servicio, es decir, utilizar las redes de datos no solamente para el intercambio de
información digital, sino que estas redes de datos sirvan como medio para transmitir
voz y vídeo en tiempo real, lo que se conoce como voz sobre IP (VoIP) y
videoconferencia por Internet.

Esta tendencia ha sido claramente identificada también por los grandes proveedores de
hardware y software, por lo que se observan en el mercado equipos especializados para
la transmisión de voz y vídeo en diferentes modelos y rangos de precios. Sin embargo,
la tecnología subyacente es sujeto de estudio detallado antes de tomar una decisión de
adquirirlos.

Las redes de datos actuales, como la red interna de la PUCE, dada su capacidad de
transmisión, estaría en teoría en la posibilidad de integrar dentro de sus servicios un
sistema de video teléfono, por lo que es necesario identificar los estándares adecuados
para la transmisión de audio y vídeo, el ancho de banda mínimo indispensable y la
forma de brindar calidad de servicio (QoS) en una red TCP/IP, que en esencia es del
tipo mejor esfuerzo (Best Effort), donde todas las aplicaciones en red compiten en
igualdad de condiciones por el ancho de banda.

De esta forma el objetivo del proyecto es identificar los estándares más adecuados para
la utilización de una aplicación de vídeo-teléfono en la Intranet de la PUCE. Es también
objetivo determinar el manejo y configuración de los parámetros de calidad de servicio
de los equipos conmutadores de la Intranet de la PUCE.

Las pruebas de rendimiento y configuración se realizarán en un ambiente controlado de

pruebas. Este ambiente permitirá la generación de tráfico con QoS y tráfico BE que
permita evaluar los parámetros elegidos en la configuración de los equipos de
comunicaciones y estaciones de trabajo.

2 METODOLOGÍA

Para la elaboración de la investigación se han seguido los siguientes pasos:

- Recopilación de información relevante al tema. Determinación del estado

del arte en la transmisión de audio y vídeo en una red de datos y sobre la
configuración de QoS en los equipos de red. Se ha realizado una búsqueda
bibliográfica y de artículos relacionados con la investigación, además de contar con
la información que el Internet provee respecto al tema.

- Determinación del ambiente de pruebas. Una vez identificada la tendencia

tecnológica de hardware y software se procedió a determinar el equipamiento
necesario para la realización de las pruebas.
 - Configuración de los parámetros de QoS en los equipos de red. Una vez
determinados los equipos de red se realizó un estudio del tipo de configuración y
parámetros de QoS a configurar.

- Identificación del software y pruebas de funcionalidad, rendimiento y

calidad. Determinada la aplicación a utilizar se realizaron la instalación y pruebas
de funcionalidad y compatibilidad con el esquema de QoS.

- Análisis de los resultados de las pruebas de rendimiento y de configuración

de QoS en los equipos de red. Se verificó que las aplicaciones y los equipos de red
se ajustan de forma correcta a la configuración establecida.

- Generación de conclusiones.

3 DESCRIPCIÓN DEL AMBIENTE DE PRUEBAS

Para la realización de las pruebas de evaluación y rendimiento se utilizó un

equipamiento hardware que incluía los siguientes equipos:

• 1 Ordenador portátil Toshiba Intel Dual Core 1.8Ghz, 1Gb RAM, NIC Ethernet
100/1000 Mbps. Sistema Operativo Windows XP.
• 1 Ordenador portátil HP, Intel 1.73 Ghz, NIC Ethernet 100 Mbps. Sistema
Operativo Windows XP.
• 3 Conmutadores 3COM 4400, Interfaces Ethernet LAN de 100 Mbps. Manejo de
QoS con Perfiles DSCP
• 1 Cámara de captura de video Genios 30 fps

Camera

Windows XP
Dual Core 3
Laptop

Figura 2.1 Esquema general del ambiente de pruebas

El ambiente de pruebas está compuesto por una red privada Ethernet de 100 Mbps.
Como equipos de comunicaciones únicamente se han utilizado únicamente switches y
no concentradores (Hubs). Los concentradores al ser dispositivos de nivel 1 no permiten
realizar ningún tipo de configuración respecto al manejo de la calidad de servicio. Las
condiciones de red no tienen influencia de tráfico externo al generado en las pruebas,
por lo tanto el emisor como receptor disponen de un máximo de 100 Mbps duplex. El
esquema general de las pruebas se muestra en la figura 2.1

Respecto a los equipos portátiles utilizados en el ambiente de pruebas estos fueron

entregados al proyecto pre-configurados con el sistema operativo Windows XP.
Entendemos que este sistema operativo es el de mayor utilización en los equipos de
usuario de la red de la PUCE. Independientemente de aquello, consideramos que en
cualquier caso Windows XP se puede considerar como un representante válido de la
tendencia de Microsoft respecto del manejo de Calidad de Servicio (QoS). En efecto
esta tendencia fue identificada y descrita en la sección

4 ELECCIÓN DE LA APLICACIÓN DE VIDEO-TELEFONO

Un requisito del proyecto de investigación era la utilización de herramientas estándar, es

decir, tanto en el aspecto de aplicativos como de equipos de comunicaciones la
investigación siempre debía estar encaminada a la utilización de herramientas que ya se
encuentran disponibles en la configuración actual de la red de la PUCE.

Si bien es cierto que el requisito anterior no cierra las puertas a la instalación de

aplicaciones de vídeo-teléfono de libre distribución, es también cierto que Microsoft
provee por omisión del ejecutable que permite realizar una instalación del aplicativo
Microsoft Netmeeting sin tener que incurrir en el pago de licencias adicionales por la
utilización de este software.

Para instalar Netmeeting bajo el sistema Windows XP es necesario ejecutar el archivo

conf.exe. Si el programa no ha sido ejecutado antes este archivo presenta el instalador
de la aplicación donde se ajustan por ejemplo la captura del vídeo y audio. Una vez
instalado Netmeeting se puede observar la ventana principal de la aplicación tal como se
muestra en la figura 4.1

Netmeeting es una herramienta que permite el trabajo cooperativo tanto dentro de una
red local como una red de área extendida. Este trabajo cooperativo se habilita mediante
herramientas como por ejemplo, el intercambio de archivos, un pizarrón virtual,
videoconferencia y audio-conferencia, entre otras características.

Precisamente son estas utilidades de vídeo y audio conferencia las que hacen a
Netmeeting como la herramienta escogida en este estudio, ya que por una lado nos
permite utilizarla como una aplicación de vídeo-teléfono y por otro lado es una
herramienta que se encuentra incluida en la distribución de los sistemas operativos
Windows.
 Figura 4.1 Netmeeting

En efecto, y como se podrá observar más adelante en la sección de pruebas de

rendimiento, Netmeeting sí hace uso de la capacidad de manejo de QoS que ofrece
Windows XP y de forma automática, es decir, los datagramas de audio y vídeo
generados por la aplicación sí incluyen información para el manejo de QoS.

Microsoft Windows hace hincapié que las aplicaciones que necesiten incorporan el
manejo de QoS en el envío de sus datagramas deberán incluir el API de QoS,
desafortunadamente la información existente sobre este API es muy escueta y poco
documentada. Este es un problema menor si consideramos que Netmeeting incorpora la
interfaz y se encuentra previamente configurada. Mayor información respecto a este
punto puede obtenerse de la siguiente dirección web
//support.microsoft.com/kb/316666/es.

Una vez que el audio y vídeo han sido ajustados en Netmeeting son pocas las variantes
que Netmeeting permite hacer a estos dos flujos. Básicamente permite configurar la
calidad del audio e incluso cambiar el codificador, pero respecto al vídeo únicamente
permite configurar la calidad y el tamaño del mismo. No permite ajustar por ejemplo el
tipo de codificador peor aún la tasa de cuadros por segundo fps. Podría pensarse que la
calidad del vídeo esta directamente relacionada con los fps pero como se verá más
adelante esta relación no se cumple en su totalidad.
5 ELECCIÓN DEL MANEJO DE QoS
Se realizó una recopilación de información del estado del arte en provisión de QoS en
los sistemas operativos Windows con especial atención a los mecanismos que provee
Microsoft Windows XP.

A la hora de diferenciar el tráfico que necesita granarías de calidad (p.e: voz y vídeo)
del que no lo necesita y con el que se realiza el mejor esfuerzo (p.e: navegación web,
correo electrónico) existen básicamente dos enfoques: Realizar un control de admisión
de los nuevos flujos de datos que generan las aplicaciones o realizar un control del
tráfico generado por las aplicaciones.

El método de control de admisión se basa en algún tipo de protocolo de señalización

con el que las aplicaciones especifican sus parámetros de calidad de servicio (ancho de
banda, picos de velocidad, tasa de error admitida, retardo admitido) a una entidad de
control antes de físicamente enviar los datos. Esta entidad decide si el flujo con las
características indicadas puede o no ser admitido por el sistema en base a los flujos que
se encuentran activos y que requieren de garantías de calidad.

El método de control de tráfico por otra parte no necesita un protocolo de señalización

más sí la especificación explícita en los routers de qué tratamiento se dará a un
determinado tipo de flujo. Es decir, ahora los flujos deben diferenciarse unos de otros en
base a alguna característica del datagrama. Es un método más sencillo que el anterior
pero esta simplicidad se paga con la especificación o aprovisionamiento manual a
realizarse en los routers.

5.1 QoS bajo Windows XP

El principal método de control de admisión utilizado en los sistemas operativos

Windows estaba representado por el protocolo RSVP (Resource Reservation Protocol)
que implica la señalización específica de los parámetros de QoS de las aplicaciones.
Windows había puesto a disposición de los usuarios una serie de herramientas que
permitían la configuración de estos parámetros, como por ejemplo la utilidad TCMON
disponible en las versiones Windows 2000 o Server.

Desafortunadamente a partir de Windows XP, Microsoft decide eliminar el soporte de

QoS utilizando un control de admisión, es decir, elimina el soporte al protocolo RSVP.
Justifica esta decisión considerando que para las aplicaciones resulta extremadamente
complicado especificar sus parámetros de QoS. De esta forma para Windows XP
únicamente es posible realizar un control de tráfico mediante la configuración de
códigos DSCP utilizando el modelo propuesto por los servicios diferenciados DiffServ.

Dado que el soporte a RSVP fue eliminado del sistema Windows XP y únicamente se
cuenta con la especificación del modelo DiffServ, es muy probable que esta
configuración se mantenga en las nuevas versiones de los sistemas operativos de
Microsoft, como por ejemplo, Windows Vista.
Para el manejo de ciertos parámetros de QoS Windows XP provee de la herramienta
group policy editor para presentarla es necesario ejecutar gpedit.msc. A continuación se
muestra la ventana de configuración de QoS de Windows.

Figura 5.1 Editor de políticas de grupo

Importante en este punto verificar que es efectivamente el modelo DiffServ el que

utiliza Windows XP, puede notarse la especificación de los valores del código DiffServ
DSCP. El manejo de los códigos diferenciados de servicios DSCP de la capa 3 del
modelo ISO/OSI se lo realiza utilizando el programador de paquetes QoS. Si la versión
del sistema no lo trae preinstalado, su instalación se lo realiza en la interfaz en la que se
desee realizar un control de los paquetes de QoS, para el caso de estas pruebas esta
instalación se la realizó en la interfaz de red de área local ethernet.

El programador de paquetes usa el valor predeterminado de DSCP igual a 24 (0x18)

para el servicio de carga controlada. Para el servicio garantizado el programador usará
el valor predeterminado de DSCP igual a 40 (0x28). Es posible cambiar estos valores de
omisión en caso de que por ejemplo la administración de los códigos en los equipos de
red así lo determine. Como se verá más adelante son estos códigos los que utiliza la
aplicación de vídeo-teléfono seleccionada.

Como dato curioso en este punto está la reserva de ancho de banda que Windows XP
define para el manejo de QoS. El sistema reserva el 20% del total del ancho de banda
para tráfico con garantías de calidad, esto en teoría, debería aplicar cuando
efectivamente existe tráfico de este tipo generado por la estación. Sin embargo, existen
muchas personas que señalan que esta configuración aplica de forma permanente a
todas las conexiones de red por lo que recomiendan encerar este valor a fin de utilizar el
100% del ancho de banda disponible, dicho en otras palabras, una interfaz de red
únicamente utiliza el 80% de su capacidad. Microsoft desmiente este comportamiento
del sistema cuando no existe tráfico QoS en el sistema.

5.2 Netmeeting y el modelo de QoS

Una vez elegida la aplicación de vídeo-teléfono a utilizar, la principal preocupación que

surgió era determinar si esta aplicación se ajusta al modelo de QoS que implanta el
sistema operativo. Esta era otra razón que reforzaba en el momento la idea de instalar
una aplicación hecha por Microsoft.

Netmeeting no muestra en su configuración ninguna forma de especificar los

parámetros de QoS por lo que la duda era razonable sobre si la aplicación implanta o no
un modelo de QoS y de forma más específica el modelo DiffServ.

No quedaba en este punto otra opción que realizar una captura de tramas y constatar de
la existencia o no del manejo de QoS de la aplicación. Mostramos de esta forma dos
pantallas de la captura de datos hecha con Ethereal para los datos de audio y vídeo.

Figura 5.2 Captura trama de audio

De la captura realizada puede notarse que el audio utiliza lo que el programado de

paquetes identifica como servicio garantizado con el código DSCP 40 (0x28
hexadecimal). Por otro lado, el vídeo es enviado utilizando el código DSCP 24 (0x18
hexadecimal) que corresponde al servicio de carga controlada del programador de
paquetes como puede observarse en la figura 5.3.
 Figura 5.3 Captura trama de vídeo

En este punto entonces se ha determinado que efectivamente la aplicación se ajusta al

modelo propuesto por el sistema operativo queda por configurar el comportamiento de
los equipos de comunicaciones que forman parte de la red de pruebas.

6 CONFIGURACIÓN DE LOS DISPOSITIVOS DE RED

Tomando en cuenta que en una red de área local básicamente se utilizan como
dispositivos de conexión a los conmutadores o switches. Dentro de estos dispositivos y
de buena utilización dentro de la LAN de la PUCE se encuentran los switches 3COM.

Para la realización de estas pruebas se han escogido, por lo antes expresado, switches
del fabricante 3COM modelo SuperStack 4400. Estos switches son administrables
mediante una interfaz de línea de comando (CLI) indispensable para configurar los
parámetros de calidad de servicio del modelo que implementen.

Habiendo avanzado ya en la investigación y determinado que el modelo escogido por

los hosts de la red de pruebas era el de servicios diferenciados que utiliza los códigos
DSCP para la diferenciación de los flujos de red, quedaba por identificar si el modelo
adoptado por los switches era compatible con el primero.

Efectivamente se observó que los switches 3COM permiten manejar distintos niveles de
QoS y mas concretamente son capaces de manejar estos niveles mediante el uso de
códigos DSCP configurables mediante la línea de comandos.
Para entrar en el proceso de configuración de QoS de los switches es necesario ingresar
a la sección de qos dentro de la sección de control de tráfico trafficManagement tal
como se muestra en la figura 6.1

Figura 6.1. CLI para manejo de QoS

Realizadas las pruebas de configuración correspondientes se determinó que la

configuración que requiere el switch 3COM incluye la creación de un perfil que cuenta
con clasificador al que se la asigna uno de los niveles de servicio previamente
configurados en el conmutador (desde best effort hasta network control) para finalmente
asignar el perfil a los puertos correspondientes del conmutador. Cabe aclarar en este
punto que son necesarios dos perfiles, uno para el tráfico de audio y otro para el tráfico
de vídeo.

En otras palabras, mediante un clasificador filtramos los paquetes que cumplen la

especificación de QoS, en este caso el DSCP. Una vez filtrados los paquetes se les da un
nivel de servicio distinto de los demás paquetes que no cumplen la especificación.

El proceso quedaría entonces estructurado de la siguiente forma:

• Creación de un clasificador por cada tipo de tráfico

• Crear un perfil
• Asociar los clasificadores al perfil
• Definir un nivel de servicio para los clasificadores
• Asociar el perfil a los puertos del conmutador a utilizar

6.1 Creación del Clasificador

Para crear el clasificador se utiliza la opción create dentro del menú

trafficManagement/qos/classifier. En la figura 6.2 podemos ver los pasos para crear el
clasificador del flujo de audio que genera la aplicación Netmeeting (código DSCP 24).
Este mismo procedimiento aplicamos para la creación del clasificador de vídeo.

Figura 6.2. CLI para creación del clasificador

6.2 Creación del perfil

La creación del perfil se realiza en la sección profile dentro del menú

trafficManagement/qos escogiendo la opción create, tal como se muestra en la figura
6.3

Figura 6.3. CLI para creación del perfil

Una vez creados los dos perfiles es posible comprobar esta información con la opción
summary.

En este punto es necesario asociar los clasificadores al perfil que acabamos crear,
cuando se hace esta asociación el proceso de configuración preguntará el nivel de
servicio que se asignará a esta asociación. En la siguiente sección hará una descripción
más en detalle de estos niveles y su significado.

Para asociar un clasificador a un perfil se utiliza la instrucción addClassifier. Un

ejemplo completado de la configuración de perfil con los dos clasificadores se muestra
en el resumen de la figura 6.4

Figura 6.4. Resumen de configuración del perfil y clasificador

Puede notarse en esta configuración el perfil creado video_phone y asociados los

clasificadores 102 y 101 con los niveles de servicio 4 y 5 respectivamente.

El trabajo únicamente quedará completo cuando podamos asociar estos perfiles a los
puertos del conmutador que vayamos a utilizar en las pruebas de la aplicación de vídeo
teléfono. En el caso de la prueba utilizamos los puertos 1 y 2 con capacidad de manejo
de tráfico QoS, en otras palabras, añadimos los perfiles de audio y vídeo a los puertos
tanto al puerto 1 como al 2.

Para añadir a un puerto los perfiles creados utilizamos la opción assign dentro del menú
trafficManagement/qos/profile. Una vez realizado este procedimiento se debería ver la
información de resumen de los puertos (opción listport) tal como se muestra en la figura
6.5.

Puede notarse en la figura 6.5 la asociación de los puertos 1 y 2 al perfil video_phone.

Adicionalmente puede verse que el resto de los puertos están asociados al perfil de
omisión con un nivel de servicio de 2. Esta asociación de omisión de alguna forma
sugiere que posiblemente el nivel 2 corresponde al más bajo y para el tráfico con el que
el conmutador hará su mejor esfuerzo.

Figura 6.5. Asociación del perfil a los puertos

6.3 Niveles de servicio del conmutador

Los conmutadores 3COM utilizados en el proyecto cuentan con 6 niveles de servicio tal
como se muestra en la figura 6.6. Cabe recalcar en este punto que no es posible crear
niveles de servicio, el conmutador viene preconfigurado con estos niveles. En cualquier
caso, 6 niveles de servicio son más que suficientes para las pruebas del proyecto.

Los niveles de servicio del conmutador van desde el más bajo, nivel 2 al más alto nivel
7. Esta conclusión la podemos inferir considerando que el nivel 2 esta asociado al
tráfico Best Effort que corresponde al tráfico con el que el conmutador hará su mejor
esfuerzo. En contraposición el tráfico de control de red tendrá el nivel más alto de
servicio.

El investigador deja abierta la posibilidad de que no necesariamente el nivel de servicio

sea mejor cuanto más alto es el número asociado al nivel de servicio debido
principalmente a que el tráfico crítico del negocio (Business Critical) tiene un nivel
igual a 3. En cualquier caso lo importante en este punto es diferenciar el tráfico de audio
y vídeo del tráfico del mejor esfuerzo.

Dentro de los niveles de servicio con los que cuenta el conmutador podemos observar
que existen niveles de servicio diferenciados para aplicaciones de audio (4) y vídeo (5).
Efectivamente el lector puede inferir que fueron precisamente estos niveles los que se
utilizaron para nuestros perfiles de audio y vídeo respectivamente.
 Figura 6.6. Niveles de servicio del conmutador

7 PRUEBAS DE RENDIMIENTO

Se realizan pruebas de rendimiento del sistema en un ambiente poco cargado se observa

una calidad bastante aceptable del audio pero el comportamiento del vídeo no parece ser
el más óptimo a pesar de que las condiciones de saturación de red son mínimas.

La calidad de imagen del vídeo es buena pero su tasa de trama es inferior a la

especificación de la cámara utilizada, es decir, 30 tramas por segundo. Una tasa de
muestreo de 30 tramas por segundo es suficiente para que el ojo humano no detecte la
superposición de tramas y en su defecto las imágenes se perciben en movimiento
continuo. Estudios muestran que una tasa de muestreo en Video-Teléfono superior a las
8 tramas por segundo podría ser suficiente considerando que los interlocutores no tienen
mayor movimiento y la mayoría de conversaciones consisten en busto-parlantes.

7.1 Configuración de la tasa de cuadros por segundo

Se ha identificado que la tasa de cuadros por segundo (fps) ésta es determinada por el
sistema operativo y el equipo de captura involucrado. Las pruebas realizadas muestran
un tasa máxima de 4 a 5 fps para el vídeo.

A continuación incluye una pantalla de la captura de trazas de uno de los experimentos

que se ha realizado. Esta captura utiliza un filtro DSCP 0x18 utilizado por las tramas
que transportan el vídeo, la columna tiempo muestra el instante en que la trama es
generada por lo que es sencillo determinar el número de tramas por segundo que se han
enviado en el experimento, nótese que las tramas capturadas que tienen un tiempo de
generación muy similar se puede considerar como correspondientes al mismo cuadro.

Adicionalmente la captura permite identificar que no existen problemas de rendimiento

de TCP/IP del emisor y tampoco del receptor. Si es de su interés puedo facilitarle la
captura completa de este experimento para su análisis.

Figura 7.1. Captura de tramas de vídeo de la aplicación

Para el caso del audio la tasa de muestreo supera las 70 unidades por segundo según la
captura realizada por lo que la calidad del audio es bastante aceptable. Una captura de la
información de audio puede observarse en la figura 7.2
 Figura 7.2. Captura de tramas de audio de la aplicación

7.2 Pruebas de estrés del conjunto ya configurado

Finalmente se procedió con la pruebas de estrés en las que someteremos a tráfico

importante tanto a las estaciones de trabajo como a los conmutadores. De esta forma
sería posible observar si el modelo de QoS de las estaciones y de los equipos de
comunicaciones era el adecuado y correctamente procesado por ambas partes.

La prueba consistió básicamente de dos generadores de tráfico activados de forma

simultánea:

1. Generador de paquetes de la aplicación de vídeo-teléfono desde una de las

estaciones de usuario con especificación de QoS mediante el uso de 2 códigos
DSCP distintos para audio y vídeo.
2. Generador de paquetes en una transferencia de archivos sin código DSCP, es
decir, tráfico best effort.

De esta forma el punto 1 generaría tráfico siguiendo el modelo DiffServ de QoS, los
datagramas estarían marcados con el código DSCP asignado por la aplicación (0x28 y
0x18 para audio y vídeo). La parte 2 generaría tráfico best effort, es decir con un código
DSCP de omisión (0x00) que no es diferenciado en las estaciones de usuario o los
equipos de comunicaciones en cuanto a otorgarle un tratamiento distinto.

Se pudo observar en la prueba que la aplicación de vídeo teléfono mantuvo una calidad
de audio bastante aceptable. La tasa de generación de cuadros para el vídeo llego a una
máxima de 6 cuadros por segundo y no se notaron cambios en la calidad de la imagen
respecto a pruebas anteriores.

Puede notarse en la figura 7.2 que la utilización de la interfaz de red del equipo que
genera el audio y vídeo llegaba a picos que superaban el 80 % de utilización, valor que
es bastante elevado considerando una actividad promedio de la interfaz durante el día.
Es decir, se ha generado una situación de utilización máxima de la interfaz de red sin
observar un deterioro significado de la calidad del audio y vídeo.

Figura 7.2. Utilización de la NIC durante la prueba de estrés

8 CONCLUSIONES

A continuación se exponen las principales conclusiones que se pudieron obtener de toda

la investigación realizada dentro del proyecto:

• Sí es posible configurar parámetros de QoS tanto en los hosts como en los

equipos de red (conmutadores en el caso de la prueba) dentro de una red de área
local. El requisito en este último caso es que los conmutadores sean
administrables y dispongan de la utilidad de manejo de tráfico.
• Definitivamente el modelo más sencillo y de mayor utilización por la comunidad
científica es el de servicios diferenciados con sus códigos DSCP. No podemos
 concluir que los conmutadores utilizados en la prueba son de nivel 3 debido en
especial por su incapacidad de encaminar paquetes. Sin embargo, tampoco son
categóricamente dispositivos de nivel 2 ya que son capaces de interpretar y dar
un servicio diferente utilizando un código DSCP que se encuentra en el nivel 3
de la torre ISO/OSI.
• Existe una tendencia evidente de adoptar en los sistemas operativos un modelo
sencillo de manejo de QoS. Microsoft ha dejado de utilizar el enfoque de
modelos integrados precisamente por su compleja utilización y ha preferido que
las aplicaciones utilicen un código DSCP previamente establecido. En
contraparte, el aprovisionamiento de los recursos deber ser hecho de forma
manual, desventaja con la que no se cuenta en el modelo de servicios integrados.
• Si bien es cierto que se ha utilizado un modelo específico de un fabricante de
conmutadores como es el caso de 3COM, si podemos extrapolar la información
en otros modelos superiores del mismo fabricante como es el caso del
encaminador 5500. En general no es aventurado pensar que los conceptos
manejados de clasificador, perfil y asociación de puertos son procesos
inevitables al momento de manejar QoS en cualquier switch independientemente
fabricante.
• Es importante anotar que el manejo de QoS expuesto en esta investigación no es
restrictivo para otras aplicaciones que no sean de vídeo teléfono, sino más bien
se ha especificado un método de tratar con prioridad un tráfico de cualquier
aplicación de la red que sea capaz de marcar un código DSCP.
• Un problema en este punto con este modelo es: ¿qué pasa si alguien
maliciosamente genera un tráfico con una especificación DSCP que no le
corresponde?, es posible controlar que esto no suceda dentro una red LAN. Si
hubiera un proceso de aceptación previa a un flujo es lo ideal en esta
circunstancia pero eso implica una mayor complejidad y mantenimiento de
estados que precisamente es una de las razones que no ha permitido una
adopción mayoritaria del modelo de servicios integrados.