En esta sesión de laboratorio se propone estudiar y analizar las prestaciones de los protocolos de enlace sobre un canal punto a punto utilizando la herramienta OPNET IT Guru. En particular, se compararan las prestaciones de los protocolos de tipo parada y espera (Stop&Wait) y ventana deslizante, analizando los efectos de parámetros del enlace como el retardo, la velocidad del enlace y la tasa de error (canal libre de errores o no).
DESCRIPCIÓN
OPNET IT Guru ofrece un entorno virtual de red capaz de modelar el comportamiento de todo tipo de redes, incluyendo desde los elementos que forman parte de una red como los encaminadotes, conmutadores, concentradores, protocolos, etc., hasta las aplicaciones que corren en las estaciones de trabajo conectadas.
En esta sesión necesitamos modelar un enlace punto a punto entre dos estaciones de trabajo con el objeto de evaluar las prestaciones de protocolos de enlace. Para ello, utilizaremos el protocolo de ventana deslizante que incluye el protocolo TCP, modificando sus parámetros de configuración para definir tamaños de ventana, tamaños de paquete, temporizadores, etc. con la finalidad de sintonizar el protocolo de enlace en cada escenario ante distintos modelos del enlace punto a punto.
Los protocolos de parada y espera tienen algunas propiedades deseables en un enlace punto a punto:
�� Como el emisor no puede enviar un nuevo paquete hasta que reciba un reconocimiento del último paquete enviado, se puede decir que este protocolo está regulado por el receptor (ACK_Clocked). Estos protocolos ajustan automáticamente la velocidad de transmisión a la velocidad de la red y la que toma el receptor en enviar los reconocimientos.
Respetan un principio básico de conservación en redes de computadores: “Dado un emisor que envía paquetes a un receptor, si el sistema está en equilibrio, éste se mantendrá si se envía un nuevo paquete sólo cuando el paquete anterior ha sido procesado por el receptor”.
Sin embargo, estos protocolos son bastante ineficientes si el enlace (o ruta) entre el emisor y receptor tiene un valor del producto “ancho_de_banda x retardo” (es decir, el numero de bits en tránsito entre el origen y el destino) elevado. Una posible solución a este problema sería el permitir que el emisor pudiera enviar más de un paquete sin esperar a su reconocimiento. Si esto fuera posible, el emisor podría llenar el enlace y por lo tanto, la llegada de reconocimientos mantendría un continuo flujo de datos en el enlace maximizando su utilización. Estamos, pues, hablando de los protocolos de ventana deslizante (pipeline).
El protocolo de parada y espera podría ser considerado como un caso particular de un protocolo de ventana deslizante, en el que la ventana de transmisión (define el número de paquetes que podemos enviar sin esperar a su reconocimiento) es de tamaño 1.
En el primer escenario del proyecto se va a proceder a evaluar el rendimiento de los protocolos de enlace de ventana deslizante en función del tamaño de la ventana de transmisión. Para ello observaremos la utilización del enlace cuando tenemos una ventana de 1 (Stop&Wait), 2, 10 y 50 paquetes. Siguiendo los pasos mostrados en la práctica para asignarle al enlace los valores deseados obtenemos la gráfica de la utilización para estos cuatro casos:
Como podemos observar, la utilización del canal es muy baja para las ventanas de tamaños 1 y 2 paquetes. Con un tamaño de 10 paquetes ronda el 50% y con 50 paquetes ya obtenemos una utilización del 100%. Esto es debido a que cuanto mayor sea la ventana de transmisión más paquetes puede enviar el emisor sin necesidad de haber recibido el reconocimiento del receptor. Una utilización del 100% implica que el emisor puede enviar paquetes de forma continuada sin tener que detenerse a recibir los reconocimientos.
Calcula el tamaño de ventana más pequeño con el que utilizaríamos el canal al máximo (≈100%).
Para un valor de N >= que 1 + 2·a obtenemos una utilización del 100%. Por tanto para N= 1 + 2·a obtenemos el tamaño de ventana más pequeño para una utilización del 100%.
Utilizando la fórmula aprendida en la teoría obtenemos los siguientes resultados:
ttrama = L/R = 500·8 bits / 10·106 bps = 4·10-4 seg
a = tprop / ttrama = 4·10-3 / 4·10-4 = 10
N = 1 + 2·a = 21
Sin embargo, si utilizamos la anterior gráfica para encontrar este valor y medimos la utilización del canal para un tamaño de ventana de 1 paquete obtenemos el siguiente resultado:
U = 5,3%
U = N/1 + 2·a ; 5,3% = 1/1 + 2·a ; a = 8,93
N = 1 + 2·a = 19
Comparando un tamaño de paquete de 19 con otro de 18 observamos como el de 18 no alcanza el 100% mientras que el de 19 sí lo hace:
Influencia del retardo del enlace en un protocolo Stop&Wait.
A continuación supongamos que estamos trabajando con un protocolo Stop&Wait (ventana deslizante con tamaño de ventana igual a 1). Para ello, fijamos las propiedades “Receive Buffer (bytes)” y “Maximum Segment Size” del TCP de las estaciones de trabajo servidor y cliente al mismo valor: 1000 bytes. Esto supone ventanas de transmisión y recepción de un segmento de 1000 bytes.
En este apartado mostraremos las gráficas de la utilización del enlace punto a punto pero en esta ocasión en vez de ir variando el tamaño de ventana cambiaremos el valor del delay, es decir, del retardo del enlace, obteniendo así la siguiente gráfica:
¿ Existe una relación lineal entre la utilización y el retardo del enlace?.
Podemos observar que a mayor retardo, menor es la utilización, es decir son inversamente proporcionales.
Sin embargo, no existe una relación lineal entre la utilización y el retardo ya que podemos observar en la gráfica que no se corresponde los valores que hay en ella con los que tendrían que salir si fueran lineales, para 0.001 tenemos una utilización de 35, mas o menos, y sin embargo para 0.005 tenemos un valor de 10, aproximadamente, por lo que podemos que aunque a mayor retado menos utilización, esta relación no es lineal.
Prestaciones del protocolo Stop&Wait en un enlace con errores.
En este punto, estudiaremos el impacto de un canal con errores en el rendimiento del protocolo Stop&Wait. Para ello, configuraremos el canal punto a punto con un ancho de banda de 10 Mbps y un retardo de 0,001 segundos. Los paquetes serán de 1000 bytes.
A continuación asignaremos un valor del timeout de 0.1 segundos (para ello debemos seguir los pasos que se nos indica la práctica).
En este punto pretendemos introducir errores en el canal para estudiar el comportamiento del protocolo Stop&Wait ante errores. Como referencia simulamos también el canal sin error, para ello simularemos el proyecto para distintos valores de la propiedad BER (Bit Error Rate).
De esta manera obtenemos las siguientes gráficas:
En la primera gráfica se muestra la productividad (throughput) resultante para cada una de las simulaciones realizadas:
Lógicamente, observamos que la productividad aumenta a medida que disminuimos el número de errores, siendo la máxima productividad la simulación sin errores.
En la segunda gráfica se observan el número de retransmisiones para cada simulación:
En esta gráfica observamos que cuando tenemos más errores se transmiten mas tramas, eso es debido a que cuanto mayor sea el error más veces tendremos que enviar la misma trama hasta que llegue correctamente, por eso en el caso de no haber errores, el valor es muy bajo por que solo se envía una vez cada trama.
Prestaciones del protocolo de ventana deslizante en un canal con error.
Construye una gráfica con la productividad (throughput) resultante para cada una de las simulaciones realizadas4. Aplica el filtro “time_average” a las curvas resultantes. Explica los resultados que has obtenido. Obtiene una segunda gráfica en la que se observen el número de retransmisiones en cada simulación utilizando el filtro “sample_sum”. Relaciona ambas gráficas, explicando el comportamiento del protocolo Stop&Wait en un enlace con errores.
Analizamos el enlace con la misma velocidad que los apartados anteriores, con un retardo de 0.001 segundos y un valor de timeout de 0.1 segundos. Obtendremos la productividad entre el cliente y el servidor y el número de retransmisiones producidas debido a los errores en el enlace. En la Gráfica 3 podemos ver la productividad cliente servidor. En azul oscuro para una tasa de error de 5*10-6 y en azul claro de 0 errores.
Podemos ver como a mayor número de errores la productividad disminuye, ya que debemos reenviar más paquetes y por tanto al cabo de cierto tiempo, aquel que no tenga errores habrá realizando más envío de tramas.
En el caso del número de retransmisiones (Gráfica 4) los enlaces con mayor número de errores realizan un mayor número de retransmisiones de tramas.
Prestaciones del protocolo de ventana deslizante en un canal con error
En este punto se trata de hacer lo mismo que en el paso anterior, pero con un protocolo de ventana deslizante. Para ello, utilizando el mismo modelo de canal (ancho de banda 10 Mbps y retardo de 1 milisegundo), tamaño de paquete 1000 bytes y un tamaño de ventana que maximice la utilización del enlace5 (tal y como se hizo en el primer paso), repetiremos el experimento realizado en el paso anterior, con el fin de observar el impacto de los errores del canal en la utilización del canal.
En esta ocasión el tamaño de ventana deberá ser:
L = 1000 bytes = 8000 bits R =10 Mbps
tpropagación = 1 ms ttrama = 8000/10*106 = 4*10-4
a=1*10-3/8*10-4 = 1.25 N=1+2*1.25 = 3.5
Con este valor que hemos obtenido redondearemos el tamaño de la ventana a 4. En la Gráfica 5 representamos la productividad entre el cliente y el servidor. En azul claro tenemos el resultado para una tasa de error de 5*10-6 y 0 en azul oscuro.
Comparado con los resultados del apartado anterior obtenemos niveles superiores, se envían un mayor número de tramas. En la siguiente gráfica observamos como aumentan el número de retransmisiones.
Cuestiones
(1) Cuando se dispone de un enlace “real” con errores, las prestaciones de los protocolos Stop&Wait y ventana deslizante disminuyen en función de la tasa de error del enlace, tal y como hemos visto en los dos últimos puntos. El hecho de que se puedan perder los paquetes tanto de datos como de reconocimiento, requiere que ambos protocolos utilicen temporizadores con un valor de disparo (timeout) determinado. Analiza cual sería el valor del temporizador óptimo para ambos protocolos, suponiendo las mismas condiciones del enlace, tamaño de paquete y tamaños de ventana empleados en los puntos 5 y 6. Explica los resultados que has obtenido.
El timeout óptimo es el tiempo que tarda el emisor en enviar una trama al recetor más el tiempo que tarda el receptor en enviar el reconocimiento de que la trama ha sido recibida correctamente. El tiempo que tarda el emisor en enviar la trama y el tiempo que tarda el receptor en enviar el reconocimiento es el mismo y su valor es el valor del delay que hayamos puesto. Como el delay que tenemos es 0.001, para tener el timeout óptimo, este será dos veces ese valor, es decir 0.002.
Asignamos distintos valores de timeout y observamos en cada caso el número de retransmisiones, la utilización y el throghput:
· 0,0015
· 0,0018
· 0,0024
Como podemos observar, conforme aumentamos el valor del timeout va aumentando la productividad y disminuyendo el número de retransmisiones. Podemos ver como este cambio es significativo entre los valores de tiemout de 0,002 y 0,0024, sin embargo para el valor de 0,0028 ya no se aprecia cambio con respecto a 0,0024. Por tanto el valor del temporizador óptimo sería de 0,002.
(2) Supongamos que aumentamos la velocidad del enlace a 100 Mbps, manteniendo el resto de parámetros del enlace. En que afectaría esto al rendimiento del enlace para ambos protocolos, suponiendo que el enlace está libre de errores.
En esta cuestión se desea analizar como afecta al rendimiento del enlace un aumento de la velocidad, manteniendo los mismos valores que anteriormente y sin errores. En esta ocasión aumentamos la velocidad del enlace a 100 Mbps. Observando la Gráfica (en rojo ventana deslizante (N=4), en azul parada y espera) vemos que al aumentar la velocidad en enlace se produce un aumento de la productividad, ya que se han podido enviar mas envíos de tramas en el mismo periodo de tiempo.
¿Cómo podríamos mejorar el rendimiento del protocolo de ventana deslizante?
Una de las formas podría ser aumentando el tamaño de la ventana. En la Gráfica vemos como para ventanas superiores a 4 (líneas verde y azul claro) la productividad aumenta considerablemente con respecto parada y espera y a ventana deslizante de tamaño 4 (líneas azul y roja).
(3) Analiza y evalúa las técnicas de vuelta atrás (Goback-n) y repetición selectiva (Selective repeat) de un protocolo de ventana deslizante. Para ello, supondremos un enlace como el estudiado en el punto 5 (10 Mbps, retardo de 1 milisegundo y tasa de error de 1E-06). El tamaño de las ventanas de transmisión y recepción será de 4 paquetes (4000 bytes) y los temporizadores estarán fijados en 100 milisegundos.
Por defecto el TCP utiliza la técnica de vuelta atrás. Para que el TCP utilice la repetición selectiva se debe activar la propiedad “Selective ACK (SACK)”. Tanto el cliente como el servidor deberán activar esta propiedad en sus TCPs para que tenga efecto. Comenta los resultados que obtienes comparando ambas técnicas.
En esta cuestión se evalúan las técnicas de vuelta atrás y repetición selectiva. En la Gráfica (en rojo repetición selectiva y en azul vuelta atrás) la técnica de repetición selectiva es más productiva que la de vuelta atrás debido a que en la repetición selectiva no se pierde tiempo en retransmitir paquetes que han llegado de forma correcta al cliente.
Conclusiones
En esta práctica hemos estudiado y analizado las prestaciones de los protocolos Stop&Wait y Ventana deslizante según variaba el retardo, la velocidad de enlace, el timeout o la tasa de error. De esta forma podremos saber qué valores debemos asignar a dichos parámetros para que los protocolos que vamos a utilizar funcionen de manera adecuada. Además, podremos conocer qué respuesta tendrá la instalación ante ciertos errores y saber si podemos permitirlos o no.
Podemos determinar que el uso de uno u otro protocolo va a determinar las propiedades del sistema. Como normal general los protocolos de ventana deslizante van a tener una mayor utilización y productividad del canal. Una ventana deslizante con repetición selectiva fuerza a tener una tabla con el control de las confirmaciones, pero aumenta de forma considerable la productividad en la transmisión del enlace respecto a otras técnicas como podría ser la de vuela atrás.
Hemos comprobado como la velocidad del enlace no es el único parámetro a tener en cuenta en las transmisiones. La selección de un protocolo puede hacer que el enlace sea ineficiente o eficiente independientemente de la velocidad que tengamos. Hay que ser cuidadosos en la elección del protocolo de enlace para obtener el máximo aprovechamiento
