Вы находитесь на странице: 1из 12

´

PR ACTICA DE COMUNICACIONES

INALAMBRICAS - DITG

´

´

ESCUELA POLIT ECNICA DEL EJ ERCITO

´

´

DEPARTAMENTO DE EL ECTRICA Y ELECTR ONICA

´

AREA TELECOMUNICACIONES

˜

LORENA PAZMI NO

JUAN CARLOS VILLAC IS

MARCELO MOREANO

´

´

ING. ROM AN LARA C.

´

SANGOLQU I - ECUADOR

2010

i

´

Indice

1. Abstracto:

 

1

2. Introducci´on:

1

3. Materiales:

1

4. Desarrollo:

2

4.1. Instalaci´on de Repositorios y Software: .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

2

4.2. Inyecci´on de Tr´afico Unidireccional: .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

2

 

4.2.1.

An´alisis de Gr´aficas:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

4.3. Inyecci´on de Tr´afico Bidireccional:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

 

4.3.1.

An´alisis de Gr´aficas:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

4

4.4. Inyecci´on de Tr´afico Multiflujo:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

6

 

4.4.1.

An´alisis de Gr´aficas:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

6

5. Conclusiones:

 

7

6. Recomendaciones:

7

7. Referencias:

 

8

8. Anexos:

9

 

ii

Inyecci´on De Tr´afico con DITG

1. Abstracto:

En la presente pr´actica se pretende simular la inyecci´on de tr´afico utilizando el simulador DITG, el cual nos va

a facilitar el env´ıo de paquetes de modo unidireccional, bidireccional y multiflujo; para lo cual se debera realizar las configuraciones necesarias en lo que respecta a las opciones: Definici´on de flujo, Propiedades, Analizador, Multiflujo. El inyector de tr´afico DITG que se utilizar´a en el presente laboratorio, se implementar´a sobre el sistema operativo UBUNTU, por lo que se necesita su previa instalaci´on, y se recomienda montar el sistema dentro de una partici´on del disco debido a ciertas limitaciones que presenta en m´aquina virtual. Cabe recalcar que para que los equipos se puedan comunicar entre s´ı debemos configurar las conexiones de red, asignando direcciones IP para que se encuentren dentro de la misma red.

2. Introducci´on:

La calidad de servicio denominado como QoS, es un par´ametro muy importante para el an´alisis de una red, de esto depender´a su buen funcionamiento y desempe˜no dentro del sistema a trabajar, es por eso que se han creado diversas herramientas que permiten simular comunicaciones en tiempo real.

Al utilizar herramientas de inyecci´on de tr´afico se permite generar el mismo basados en patrones lo m´as cercanos

a la realidad, y mediante el mismo se traza tanto en emisi´on como en recepci´on el movimiento de cada paquete transmitido, de manera que se pueda representar gr´aficamente los diferentes par´ametros de calidad.

DITG es particularmente interesante por varias razones: dispone de una interfaz gr´afica que puede simpli- ficar su uso, dispone de un ”manager” que permite enviar ordenes a fuentes y sumideros de tr´afico remotos, as´ı como de un servidor de logs que se puede ubicar en cualquier m´aquina que convenga (coincida o no con las fuentes o sumideros de tr´afico), permite caracterizar estad´ısticamente el tr´afico inyectado, y mide todos los par´ametros de QoS como: throughput, retardo, jitter y probabilidad de p´erdida de paquetes, adem´as dispone de una interfaz gr´afica que facilita su uso, dispone de un ”manager” que permite enviar ordenes a fuentes y sumideros de tr´afico remotos, as´ı como de un servidor de logs que se puede ubicar en cualquier m´aquina que convenga (coincida o no con las fuentes o sumideros de tr´afico), permite caracterizar estad´ısticamente el tr´afico inyectado, y mide todos los par´ametros de QoS citados.

a.Jitter.- Es la medida de variaci´on de delay entre paquetes consecutivos en un determinado flujo de tr´afico. A medida que var´ıa la tasa de delay, el jitter impacta sobre el rendimiento de la aplicaci´on. Una cantidad m´ınima de jitter puede ser aceptable. b.Packetloss.- Indica los paquetes fallados para llegar a su destino que viajan dentro de una comunicaci´on. Para una transmisi´on ´optima los paquetes perdidos no debe ser m´as del 1 % y para una prioridad m´ınima entre 5 % y 10 % de paquetes perdidos. a.Delay.- Es aquel que espec´ıfica cuan largo se le hace para un bit de datos viajar dentro de la red de un nodo

a otro.

b.Bitrate.- Es el n´umero de bits que son transportados, se lo calcula en bits por segundo (bps).[1][2]

3. Materiales:

2 Computadoras con sistema operativo Linux, distribuci´on Ubuntu 9.04 o 9.10.se lo calcula en bits por segundo (bps).[1][2] 3. Materiales: Cable cruzado de 1m. Conexi´on a

Cable cruzado de 1m.3. Materiales: 2 Computadoras con sistema operativo Linux, distribuci´on Ubuntu 9.04 o 9.10. Conexi´on a internet.

Conexi´on a internet.3. Materiales: 2 Computadoras con sistema operativo Linux, distribuci´on Ubuntu 9.04 o 9.10. Cable cruzado de

1

4.

Desarrollo:

4.1. Instalaci´on de Repositorios y Software:

Se debe descargar el inyector; DITG para el correcto funcionamiento del software previamente mencionado se deber´a instalar los siguientes repositorios: Sun-java6-jre, g++, octave3.0. Los que ser´an descargados con la ayuda del gestor de paquetes synaptic. Posteriormente se descarg´o los paquetes D-ITG-2.7.0-Beta y itggui-0911 desde:

http://www.grid.unina.it/software/ITG/

http://www.semken.com/projekte/index.html

Dentro de root creamos una carpeta con el nombre DITG, en el que descomprimimos el contenido de los paquetes. En el terminal y digitamos las siguientes l´ıneas de comando:

cd /root/DITG/srcel terminal y digitamos las siguientes l´ıneas de comando: make Una vez realizado esto copiamos todos

makelas siguientes l´ıneas de comando: cd /root/DITG/src Una vez realizado esto copiamos todos los archivos

Una vez realizado esto copiamos todos los archivos membretados ITG y lib que se encuentraron en el directorio /home/monica/DITG/bin al directorio usr/local/bin y usr/local/lib respectivamente. En el siguiente an´alisis de inyecci´on de tr´afico vamos a poder medir el rendimiento de la red, de acuerdo a su comportamiento. Cabe recalcar que cuando a traves del terminal intentamos graficar los datos obtenidos no se logr´o puesto que ITGplot no ten´ıa todos los permisos; por lo que se procedi´o a: en el terminal # chmod 777 ITGplot para obtener los permisos.

4.2. Inyecci´on de Tr´afico Unidireccional:

Transmisor:los permisos. 4.2. Inyecci´on de Tr´afico Unidireccional: Define Flow, Settings, Analizer Para esta configuraci´on

Define Flow, Settings, Analizer Para esta configuraci´on deberemos seguir los pasos indicados en la gu´ıa de laboratorio, definiendo par´ametros como:

Direcciones tanto de logs como de binen la gu´ıa de laboratorio, definiendo par´ametros como: Duraci´on de env´ıo de paquetes: 30(0.5minutes)

Duraci´on de env´ıo de paquetes: 30(0.5minutes)par´ametros como: Direcciones tanto de logs como de bin Selecci´on de archivos de texto, gr´aficos y

Selecci´on de archivos de texto, gr´aficos y los generados por octave.de bin Duraci´on de env´ıo de paquetes: 30(0.5minutes) Target Host: Aputamos a la direcci´on IP de

Target Host: Aputamos a la direcci´on IP de la maquina receptora, entre otros par´ametros para su posterior an´alisis.archivos de texto, gr´aficos y los generados por octave. Receptor: Settings y Analizer Como en el

Receptor:entre otros par´ametros para su posterior an´alisis. Settings y Analizer Como en el caso anterior se

Settings y Analizer Como en el caso anterior se mantendr´a la configuraci´on indicada en la gu´ıa. Se debe tomar en cuenta que la m´aquina receptora deber´a iniciar la transmisi´on presionando loger y receiver, posteriormente la m´aquina transmisora deber´a presionar sender para su comunicaci´on.

2

4.2.1.

An´alisis de Gr´aficas:

El an´alisis del tr´afico unidireccional est´a basado en la comunicaci´on entre una estaci´on transmisora con un solo tr´afico dirigido hacia la estaci´on receptora.

un solo tr´afico dirigido hacia la estaci´on receptora. Fig1: Gr´afica Bitrate Unidireccional Fig2: Gr´afica
un solo tr´afico dirigido hacia la estaci´on receptora. Fig1: Gr´afica Bitrate Unidireccional Fig2: Gr´afica

Fig1: Gr´afica Bitrate Unidireccional Fig2: Gr´afica Delay Unidireccional

Bitrate.-La gr´afica nos muestra la transmisi´on de bits por segundo que se obtuvo, es decir la velocidad de transferencia de datos, dado que la inyecci´on de tr´afico es Unidireccional, este posee una elevada velocidad de transferencia y ciertamente constante en el tiempo si obtenemos la media de la misma. Delay.-Podemos ver que este es un tipo de delay fijo por transmisi´on de datos (queuing delay) sobre medios de

red f´ısicos en cada salto de la red.[2], presenta un comportamiento constante y relativamente alto puesto que DITG al iniciar el env´ıo no sincroniza los relojes y en las PCs que trabajamos las horas difer´ıan considerablemente por lo que se presenta este tipo de retardo.

por lo que se presenta este tipo de retardo. Fig3: Gr´afica Jitter Unidireccional Fig4: Gr´afica
por lo que se presenta este tipo de retardo. Fig3: Gr´afica Jitter Unidireccional Fig4: Gr´afica

Fig3: Gr´afica Jitter Unidireccional Fig4: Gr´afica Packetloss Unidireccional

Jitter.-El jitter genera un efecto importante sobre aplicaciones sensibles al delay que deben recibir paquetes en una tasa relativamente contante con un delay fijo. Podemos ver que el jitter tiene cantidad y variaci´on m´ınima

lo que es bueno ya que a medida que este incrementa, la aplicaci´on puede terminar siendo in´util.

Packetloss.-Se observa que el valor fluct´ua en 0 lo que muestra que es una comunicaci´on de alta calidad ya que est´a dentro del 1 % de paquetes perdidos.

4.3. Inyecci´on de Tr´afico Bidireccional:

Para este an´alisis de tr´afico debemos tomar en cuenta que los equipos se deben configurar como emisores

y receptores a la vez, si bien es cierto esta configuraci´on no es posible mediante la interfaz grafica del la

herramienta DITG, por lo que es necesario realizar esta configuraci´on mediante el terminal de Ubuntu en el cual pondremos en modo receptor a cada PC mediante los comandos ./ITGRecv y ./ITGLog para el caso del

receptor y ./ITGSend para transmisor.

3

Fig5: Gr´afica ITGRecv en terminal Fig6: Gr´afica ITGLog en terminal 4.3.1. An´alisis de Gr´aficas: Cabe
Fig5: Gr´afica ITGRecv en terminal Fig6: Gr´afica ITGLog en terminal 4.3.1. An´alisis de Gr´aficas: Cabe

Fig5: Gr´afica ITGRecv en terminal Fig6: Gr´afica ITGLog en terminal

4.3.1. An´alisis de Gr´aficas:

Cabe recalcar que una vez configurados los relojes de las PCs existe un retardo considerable ya que el concepto que se utiliza para el trafico bidireccional en DITG no es simultaneo en las dos PCs sino que deben negociar para decidir quien env´ıa y quien recibe primero.

En las siguientes gr´aficas podemos ver los siguientes comportamientos:

Bitrate.-Vemos que la velocidad de transmisi´on de ambas PCs es constante mientras que la de recepci´on es variante y disminuye respecto a la tasa de bits transmitidos. Delay.-Vemos claramente que este par´ametro s´olo se distingue en el receptor tanto de la PC1 como PC2; en la

transmisi´on su valor es pr´acticamente nulo. As´ı como que su valor es variante del tipo Delay de ingreso para el tr´afico en un nodo de la red; pero dado que su valor es relativamente bajo la QoS no se ve comprometida.

Jitter.-Al igual que el delay ´este existe unicamente´

del delay pero dado que su valor medio es bajo la QoS no se ve comprometida. Packetloss.-Podemos ver que en todos los casos su valor es constante al rededor de 0, es decir mantiene QoS ya que est´a dentro del 1 % de paquetes perdidos.

en el lado receptor, y su fluctuaci´on depende de la variaci´on

Receptor PC1

y su fluctuaci´on depende de la variaci´on Receptor PC1 Fig7: Gr´afica Bitrate Receptor PC1 Fig8: Gr´afica
y su fluctuaci´on depende de la variaci´on Receptor PC1 Fig7: Gr´afica Bitrate Receptor PC1 Fig8: Gr´afica

Fig7: Gr´afica Bitrate Receptor PC1 Fig8: Gr´afica Delay Receptor PC1

Bitrate Receptor PC1 Fig8: Gr´afica Delay Receptor PC1 Fig9: Gr´afica Jitter Receptor PC1 Fig10: Gr´afica
Bitrate Receptor PC1 Fig8: Gr´afica Delay Receptor PC1 Fig9: Gr´afica Jitter Receptor PC1 Fig10: Gr´afica

Fig9: Gr´afica Jitter Receptor PC1 Fig10: Gr´afica Packetloss Receptor PC1

4

Transmisor PC1

Transmisor PC1 Fig11: Gr´afica Bitrate Transmisor PC1 Fig12: Gr´afica Delay Transmisor PC1 Fig13: Gr´afica
Transmisor PC1 Fig11: Gr´afica Bitrate Transmisor PC1 Fig12: Gr´afica Delay Transmisor PC1 Fig13: Gr´afica

Fig11: Gr´afica Bitrate Transmisor PC1 Fig12: Gr´afica Delay Transmisor PC1

Transmisor PC1 Fig12: Gr´afica Delay Transmisor PC1 Fig13: Gr´afica Jitter Transmisor PC1 Fig14: Gr´afica
Transmisor PC1 Fig12: Gr´afica Delay Transmisor PC1 Fig13: Gr´afica Jitter Transmisor PC1 Fig14: Gr´afica

Fig13: Gr´afica Jitter Transmisor PC1 Fig14: Gr´afica Packetloss Transmisor PC1 Receptor PC2

Fig14: Gr´afica Packetloss Transmisor PC1 Receptor PC2 Fig15: Gr´afica Bitrate Receptor PC2 Fig16: Gr´afica
Fig14: Gr´afica Packetloss Transmisor PC1 Receptor PC2 Fig15: Gr´afica Bitrate Receptor PC2 Fig16: Gr´afica

Fig15: Gr´afica Bitrate Receptor PC2 Fig16: Gr´afica Delay Receptor PC2

Bitrate Receptor PC2 Fig16: Gr´afica Delay Receptor PC2 Fig17: Gr´afica Jitter Receptor PC2 Fig18: Gr´afica
Bitrate Receptor PC2 Fig16: Gr´afica Delay Receptor PC2 Fig17: Gr´afica Jitter Receptor PC2 Fig18: Gr´afica

Fig17: Gr´afica Jitter Receptor PC2 Fig18: Gr´afica Packetloss Receptor PC2 Transmisor PC2

Delay Receptor PC2 Fig17: Gr´afica Jitter Receptor PC2 Fig18: Gr´afica Packetloss Receptor PC2 Transmisor PC2 5
Delay Receptor PC2 Fig17: Gr´afica Jitter Receptor PC2 Fig18: Gr´afica Packetloss Receptor PC2 Transmisor PC2 5

5

Fig19: Gr´afica Bitrate Transmisor PC2 Fig1:20 Gr´afica Delay Transmisor PC2

Transmisor PC2 Fig1: 20 Gr´afica Delay Transmisor PC2 Fig21: Gr´afica Jitter Transmisor PC2 Fig22: Gr´afica
Transmisor PC2 Fig1: 20 Gr´afica Delay Transmisor PC2 Fig21: Gr´afica Jitter Transmisor PC2 Fig22: Gr´afica

Fig21: Gr´afica Jitter Transmisor PC2 Fig22: Gr´afica Packetloss Transmisor PC2

4.4. Inyecci´on de Tr´afico Multiflujo:

El an´alisis del tr´afico mutiflujo est´a basado en la comunicaci´on entre una estaci´on transmisora con varios tipos de tr´aficos dirigidos hacia la estaci´on receptora, con lo cual mediante el analisis de graficos observaremos los distintos tipos de paquetes enviados, dentro de la herramienta DITG debemos configurarla modificando la pesta˜na de multiflow el f1 y f2 como se muestra en las imagenes:

de multiflow el f1 y f2 como se muestra en las imagenes: Fig23: Gr´afica Pesta˜na Multiflujo

Fig23: Gr´afica Pesta˜na Multiflujo

en las imagenes: Fig23: Gr´afica Pesta˜na Multiflujo Fig24: Gr´afica Configuraci´on F1 (Voz) Fig25:
en las imagenes: Fig23: Gr´afica Pesta˜na Multiflujo Fig24: Gr´afica Configuraci´on F1 (Voz) Fig25:

Fig24: Gr´afica Configuraci´on F1 (Voz) Fig25: Gr´afica Configuraci´on F2 (DNS)

4.4.1. An´alisis de Gr´aficas:

Bitrate.-Podemos ver que la tasa de bits es constante aunque su velocidad de transmisi´on a disminuido respecto a los otros tipos de inyecci´on de tr´afico. Delay.-En este caso se obtuvo un delay negativo ya que no hab´ıa una correcta sincronizaci´on con los relojes de

las PCs, pero visiblemente se mantiene constante lo que nos ayuda a mantener la QoS y evitar la p´erdida de paquetes.

6

Fig26: Gr´afica Bitrate Multiflujo Fig27: Gr´afica Delay Multiflujo Jitter.- Dado que el delay es constante
Fig26: Gr´afica Bitrate Multiflujo Fig27: Gr´afica Delay Multiflujo Jitter.- Dado que el delay es constante

Fig26: Gr´afica Bitrate Multiflujo Fig27: Gr´afica Delay Multiflujo

Jitter.-Dado que el delay es constante la variaci´on de ´este en valor medio tambi´en lo es, y su valor es bajo lo que ayuda para no comprometer los paquetes en la transmisi´on. Packetloss.-De acuerdo al comportamiento del Delay y del Jitter podemos ver que no existe p´erdida de paquetes.

del Jitter podemos ver que no existe p´erdida de paquetes. Fig28: Gr´afica Jitter Multiflujo Fig29: Gr´afica
del Jitter podemos ver que no existe p´erdida de paquetes. Fig28: Gr´afica Jitter Multiflujo Fig29: Gr´afica

Fig28: Gr´afica Jitter Multiflujo Fig29: Gr´afica Packetloss Multiflujo

5. Conclusiones:

En los tres tipos de tr´afico se obtuvo una ´optima comunicaci´on ya que en ninguna se obtuvo perdida de paquetes, esto se debe a que la comunicaci´on entre las PCs fue por un medio cableado y a una corta distancia, tomando en cuenta que el cable era de buena calidad y no presentaba deterioros caso contrario hubi´esemos tenido perdida de informaci´on.Fig29: Gr´afica Packetloss Multiflujo 5. Conclusiones: Nos pudimos dar cuenta que el tr´afico unidireccional

Nos pudimos dar cuenta que el tr´afico unidireccional presenta una gr´afica de delay distinta a la del tr´afico bidireccional, esto se debi´o a que el DITG no sincroniza los relojes de las PCs y es por esto que en el primer caso se obtiene un delay alto y con un comportamiento constante.caso contrario hubi´esemos tenido perdida de informaci´on. Para realizar la simulaci´on del tr´afico bidireccional

Para realizar la simulaci´on del tr´afico bidireccional fue necesario realizarlo por medio de c´odigo en el terminal de UBUNTU ya que el software DITG no nos permite configurar a ambas PCs como emisoras y transmisoras a la vez.se obtiene un delay alto y con un comportamiento constante. En el tr´afico bidireccional se present´o

En el tr´afico bidireccional se present´o retardo, puesto que este no es simult´aneo en las dos PCs, esto se debe a que en el momento de la comunicaci´on las PCs deben decidir qui´en va a enviar y quien va a recibir primero.a ambas PCs como emisoras y transmisoras a la vez. En el tr´afico bidireccional se obtuvieron

En el tr´afico bidireccional se obtuvieron diferentes gr´aficas en las dos PCs eso se refiere a la negociaci´on y sincronismo de reloj para el paso de tr´afico y dependiendo de la NIC de cada computadora establecer´a la comunicaci´on.decidir qui´en va a enviar y quien va a recibir primero. El tr´afico unidireccional es el

El tr´afico unidireccional es el menos determin´ıstico frente a los dem´as dado que presenta una curva Gausiana, mientras que los dem´as presentan su latencia en forma determin´ıstica.la NIC de cada computadora establecer´a la comunicaci´on. 6. Recomendaciones: Es necesario utilizar cable cruzado

6. Recomendaciones:

Es necesario utilizar cable cruzado para la comunicaci´on entre las PCs ya que si utilizamos un cable directo tendremos muchos errores al momento de enviar informaci´on, es decir tendremos demasiada p´erdida deuna curva Gausiana, mientras que los dem´as presentan su latencia en forma determin´ıstica. 6. Recomendaciones: 7

7

paquetes, Adem´as de esto debemos verificar que nuestras PCs est´an en red caso contario nunca se podr´a establecer la comunicaci´on

Se recomienda tambi´en configurar de manera eficiente el terminal en el que se guardara los logs, para con esta informaci´on generar las graficas que el inyector de tr´afico proporciona de acuerdo a la informaci´on enviada por el medio.caso contario nunca se podr´a establecer la comunicaci´on Es importante comprobar los permisos para ejecutar el

Es importante comprobar los permisos para ejecutar el ITGPlot caso contrario no se nos permitir´a generar ning´un tipo de tr´afico.de acuerdo a la informaci´on enviada por el medio. DITG mantien cerrado el mismo por medio

DITG mantien cerrado el mismo por medio de la interfaz gr´afica; para esto se debe ingresar al terminal y digitar el comando ps -d, donde muestra el n´umero y nombre de los procesos activos, luego se digita kill numerodelProceso . Si esto no se ejecuta este comando se puede presentar un mensaje de numerodelProceso. Si esto no se ejecuta este comando se puede presentar un mensaje de error ya que se est´a ejecutando a´un otro proceso.

7.

Referencias:

DITG, d-itg-manual.pdf,29/09/10.que se est´a ejecutando a´un otro proceso. 7. Referencias: Par´ametros para medir la QoS,

Par´ametros

paraPar´ametros

medir

la

QoS,

www.nsrc.org/workshops/2008/walc/

/performance

concepts.pdf,

01/10/10.[1]

Rendimiento de la red par´ametros que intervienen, http://www.anixtersoluciones.com/latam/cl /infor-/performance concepts.pdf, 01/10/10.[1] macion general/2078/la importancia de la calidad de servicio

macion general/2078/la importancia de la calidad de servicio qos

8

parte ii es.htm, 01/10/10.[2]

8.

Anexos:

CUESTIONARIO DIT-G

1. Es posible que el delay salga negativo, si es posible, porque? Si es posible que el Delay salga negativo ya que el programa DITG no posee ning´un tipo de sincronismo entre emisor y receptor esto debido a los relojes internos de cada m´aquina tanto emisora como receptora; por lo que esta variaci´on de tiempo acasiona ´este fen´omeno.

2. Que se debe realizar para que el delay tenga el valor correcto? Con el fin de medir correctamente paquetes de One Way Delay (OWD), los relojes de emisor y el receptor deben estar sincronizados por otros medios (mediante el uso de NTP, GPS, etc.). En caso contrario, le sugerimos utilizar el medidor de tiempo de ida y vuelta (RTT). Esta es otra caracter´ıstica de la D-ITG.

3. Porque es importante la sincronizaci´on en la comunicaci´on? Como explicamos en las preguntas anteriores es muy importante, ya que sin una correcta sincronizaci´on vamos a tener retardos muy grandes o con variacionesya que cuando esto ocurre produce p´erdida de paquetes o errores de transmisi´on como: datos err´oneos o colisiones y congesti´on en el canal.

4. En las graficas obtenidas que se debe modificar para que sean mejor apreciadas? Primero ubicamos el archivo llamado itgrecv.log, lo copiamos y pegamos en:

/root/DITG/D-ITG-2.7.0-Beta2/src/ITGDec

Posteriormente en el terminal nos ubicamos en la direcci´on anteriormente mencionada y digitamos el comando:

direcci´on anteriormente mencionada y digitamos el comando: ./ITGDec itgrecv.log -v -d 250 -b 250 -p 250

./ITGDec itgrecv.log -v -d 250 -b 250 -p 250 -j 250

Donde los valores de 250 son los que nos indican la escala en la que se va a presentar para aumentar la mismo, con este comando se generar´an 4 archivos con extensi´on .dat los cuales deber´an ser graficados por l´ınea de comandos para observar el cambio.

5. Para qu´e sirve el inyector de tr´afico? Como pudimos observar en la pr´actica realizada un inyector de trafico nos permite saber cu´anto es lo m´aximo que nos podr´ıa resistir un canal respecto a velocidad as´ı tambi´en como ver retardos que ocurren en la conexi´on, ver si algunos paquetes se est´an perdiendo, verificar la tasa de error entre otras carac- ter´ısticas tanto del canal como de la transmisi´on y as´ı aprovechar al m´aximo nuestro enlace.

6. Que tipo de trafico podr´ıa enviar?, se puede enviar video? Los tipos que env´ıa DITG son muy completos ya que logra soportar envi´o de voz, video y datos; espec´ıfi- camente udp, tcp, icmp, dccp y sctp. Para el caso de udp al ser este no orientado a la conexi´on se puede enviar: Gaming, Voice y DNS, Custom. Para tr´afico TCP, se puede enviar: Telnet, DNS y Custom, para el resto se puede enviar tr´afico personalizado (Custom). En cuesti´on de video cabe recalcar que el trafico debe ser en nivel medio de (1000 paquetes de 50 bytes c/u) y en un nivel alto de (1000 paquetes de 100 bytes c/u).

7. Qu´e se puede observar con la gr´afica obtenida del Jitter? Dado que es la medida de variaci´on de delay entre paquetes consecutivos en un determinado flujo de tr´afico. Genera un efecto importante sobre las aplicaciones sensibles al delay en tiempo real, como voz y video. A medida que var´ıa la tasa de delay, el jitter impacta sobre el rendimiento de la aplicaci´on. En base a esto el valor promedio de todas las gr´aficas del Jitter fue bajo, lo que indica que su transmisi´on

9

fu´e ´optima ya que si este posee variaciones la comunicaci´on ser´ıa in´util.

8. Que diferencia se encuentra entre las graficas obtenidas de tr´afico, unidireccional y bidireccional? Primero como todos debemos recordar el modo de transmisi´on es muy diferente en las 2 inyecciones de trafico ya que en la unidireccional un PC recibe y otro transmite pero en el caso de la bidireccional las dos PCs env´ıan y reciben, por lo tanto las diferencias que podemos resaltar en las graficas son:

Bitrate: Podemos observar que existe una mayor tasa en la unidireccional respecto a la bidireccional ya que utiliza todo el canal para el envi´o lo que en la bidireccional utiliza el canal para envi´o y recepci´on al mismo tiempo

utiliza el canal para envi´o y recepci´on al mismo tiempo Delay: En esta grafica por motivos

Delay: En esta grafica por motivos de sincronismo observamos un mayor retardo en la unidireccionalutiliza el canal para envi´o y recepci´on al mismo tiempo respecto a la bidireccional Jitter: Como

respecto a la bidireccional

Jitter: Como podemos observar no existe mucha diferencia el uno del otro y esto es

Jitter: Como podemos observar no existe mucha diferencia el uno del otro y esto es bueno porque sabemos que este si tiene muchas variaciones la inyecci´on de trafico se volver´a in´util.

Packetloss: En relacion de la unidireccional y bidireccional podemos decir que no existen diferencias los

Packetloss: En relacion de la unidireccional y bidireccional podemos decir que no existen diferencias los 2 envios fueron exitosos ya que no poseen paquetes perdidos. Cabe recalcar que todas estas diferencias las realizamos con respecto a las gr´aficas de transmisi´on del tipo de inyecci´on de tr´afico Bidireccional.

9. Con las graficas del trafico multiflujo que se puede concluir?

Claramente podemos observar que en este tipo de inyecci´on de tr´afico la tasa de bits disminuye respecto

a las otras, ya que a trav´es de este canal se est´a enviando 2 tipos de tr´afico diferente por lo que el ancho de banda para cada tipo de tr´afico se ve comprometido, es decir disminuye y la cantidad de bits por segundo transmitidos es menor. Referente a las otras gr´aficas vemos que tienen un comportamiento adecuado para evitar la p´erdida de paquetes.

10. Que indica la grafica del paquetloss?

Como sabemos paquetloss significa paquetes perdidos por lo cual las graficas presentadas de packetloss

lo que nos indica es la cantidad de paquetes que se perdieron durante la transmisi´on en un total de 30

paquetes los cuales fueron enviados en nuestro caso.

10