Sesión de Laboratorio: protocolos de enlace, stop & wait

Sesión de Laboratorio 4: Stop & Wait y Protocolos con Ventanas

Objetivo del laboratorio: Hacer una comparación y una evaluación de la eficiencia de los protocolos stop&wait y con ventanas.

Duración: 2 horas

Lugar: Laboratorio de Redes y Sistemas (E10)

Breve descripción: Se maneja un simulador del libro de la bibliografía de Tanenbaum para comprobar el comportamiento de estos algoritmos al aparecer errores.

Primera parte: Toma de contacto con el simulador

El programa se encuentra en la sisd00.si.ehu.es, en el directorio /users/alumnos/soft/acaz/lab4

· algunas cuentas necesitan un source /usr/logio/.gcc_login

· se compila todo con la utilidad make. Es necesario explicar su uso a los alumnos, no conocen la utilidad ni lo que es un Makefile

· existe un script llamado run2 para ejecutar el simulador

· Utilizamos los protocolos 4 (stop&wait sin piggybacking) y 5 (con ventanas de tamaño 7 con piggybacking.

· Fichero README del Tanenbaum:

If you want to use gcc instead of cc, change the line

CC=cc

to

CC=gcc

in Makefile.

It is executed by giving a command line containing the simulation parameters.

The command line has six decimal parameters, as follows:

sim protocol events timeout pct_loss pct_cksum debug_flags

where

protocol tells which protocol to run, e.g. 5

events tells how long to run the simulation

timeout gives the timeout interval in ticks

pct_loss gives the percentage of frames that are lost (0-99)

pct_cksum gives the percentage of arriving frames that are bad (0-99)

debug_flags enables various tracing flags:

1 frames sent

2 frames received

4 timeouts

8 periodic printout for use with long runs

For example

sim 6 100000 40 20 10 3

will run protocol 6 for 100,000 events with a timeout interval of 40 ticks,

a 20% packet loss rate, a 10% rate of checksum errors (of the 80% that get through), and will print a line for each frame sent or received. Because each peer process is represented by a different UNIX process, there is (quasi)parallel processing going on. This means that successive runs will not give the same results due to timing fluctuations.

A set of possible student exercises is given in the file exercises.

Primeras pruebas

· sim 4 10000 40 0 0 0

· sim 5 10000 40 0 0 0

· Explicar eficiencia 1 (original de Tanenbaum)

· Problema de eficiencia 1: aumenta al haber errores!!! (sim 4 10000 40 2 0 0)

· Mejor: eficiencia 2, lo podemos usar para hacer una gráfica después del comportamiento de los protocolos

· Que vean el efecto de introducir errores en el sistema, y que comprueben la influencia de los parámetros en todos los valores de salida que se presentan.

Segunda parte: Comparación empírica de la eficiencia y la influencia de errores

Medición del rendimiento

Se hará una primera gráfica, con eje x = errores de CRC 0...20, eje y = payloads accepted 0...2000, en todos los casos con 0% de tramas perdidas. Se puede utilizar la eficiencia 2 en vez del payloads accepted, ya que son proporcionales.

Se hará otra gráfica con un 5% de tramas perdidas sobre la misma gráfica.

De poder ser, debería instalarse Excel en los ordenadores y realizar las gráficas directamente en Excel en el laboratorio.

Conclusiones

Conclusiones que se obtienen a la vista de los resultados

En caso de errores el protocolo 5 es más crítico, incluso teniendo piggybacking, ya que hay que retransmitir todos los frames de la ventana. En algunos algoritmos solo se retransmite a partir del frame erroneo, pero aún así en un momento seguiría siendo peor que stop&wait.

Esto último es aún más critico cuando la ventana es de mayor tamaño.

En caso de no haber errores la eficiencia máxima del stop & wait es del 50%, y del protocolo con ventanas es del 100%

Un administrador de red debe hacer experimentos de este tipo para saber cuál es la mejor configuración de la red.

Este tipo de técticas también se utilizan en otros niveles de red, no están sólo a nivel de enlace.

Anexo: notas preparadas por Jose para sus alumnos.

Notas

1. En ausencia de errores, el protocolo P4 siempre envía un ACK (con el número de la última trama de datos bien recibida). Por lo tanto, en estas condiciones la eficiencia no puede pasar del 50%: la mitad de las tramas transmitidas no contienen información. Los ACKs no aparecen contados como tales, porque el protocolo sólo utiliza un tipo de tramas, en las que SIEMPRE hay un campo para ACK.
2. El protocolo P5 tampoco usa tramas sólo con ACK. Sin embargo, realiza realmente piggybacking: se aprovechan tramas con datos de verdad para, además, enviar ACKs. En estas condiciones, se puede llegar una una eficiencia total.
3. Nos podemos encontrar resultados aparentemente contradictorios con el simulador. Por ejemplo, estas ejecuciones:
sim 4 10000 40 0 0 0 à 49% de eficiencia
sim 4 10000 40 10 0 0 à 52% de eficiencia

¿Cómo es posible que el protocolo P4 sea más eficiente con errores que sin ellos? Mirando con más atención, vemos que en el primer caso cada proceso ha entregado al nivel de red aprox. 1140 tramas útiles, mientras que el segundo sólo se han enviado 363.
El problema es la definición de la palabra eficiencia. Tanenbaum la ha definido como (tramas útiles/ tramas totales)*100. Bajo esta definición, los datos de eficiencia entregados por el simulador son correctos. Sin embargo, no son demasiado útiles. Es más útil saber cuanta información real se puede enviar, en el mismo intervalo de tiempo, con un protocolo u otro.
Teniendo en cuenta estas consideraciones, he realizado una colección de ejecuciones, poco extensa, representada en estas gráficas.

Gráfica 1. Comparación de los protocolos P4 y P5. Ejecución durante 10000 ciclos. Estudio de cómo afecta el % de tramas dañadas al rendimiento de ambos protocolos, cuando no hay tramas perdidas.

Gráfica 2. Estudio de cómo afecta el % de tramas dañadas al rendimiento del protocolo, para diferentes valores de % de tramas perdidas.