Introducción 1) Principio de transferencia de datos Confiable Un canal confiable implica un canal donde los datos de entrada no sufren alteraciones a la salida (0 1, ó 1 0, etc.). La idea es que la capa de transporte pueda ofrecerle un canal confiable de comunicación a la capa de aplicación, de forma que los datos lleguen al destino sin errores ni problemas. Implementar esta abstracción de servicio es responsabilidad de un protocolo de transferencia de datos confiable (RDT: Reliable Data Transfer). Nota : TCP (Transmission Control Protocol) ofrece este modelo de servicio confiable. Problema Implementar un protocolo RDT sobre una capa no confiable. Por ejemplo: TCP es un protocolo RDT que está implementado sobre la capa de red (IP) que no es confiable. Generalizando el problema La capa sobre la que se realiza la comunicación punto a punto puede ser la capa de enlace, dado por un link (Link-Level Data Transfer Protocol), o una internetwork global (Transport-Level Protocol). Como la teoría desarrollada en esta sección se aplica a las redes en general y no solo a la capa de transporte, se va a utilizar la terminología Paquete en vez de Segmento. 2) Esquema de un protocolo RDT La implementación del Sender y del Receiver van a depender del modelo del canal que está por debajo y su complejidad. Si bien vamos a considerar solo el caso de transferencia de datos unidireccional, el Receiver y el Sender van a necesitar intercambiar paquetes de control para poder enviar los paquetes de datos. 1
3) Construyendo un RDTP a) RDT 1.0 : Se asume que el canal que está por debajo es confiable, no hay errores de bits y no se pierden paquetes. Sender : rdt_send es una llamada procedural capa superior. de la Receiver : rdt_rcv es una llamada procedural de la inferior. capa b) RDT 2.0 : Conclusión : Nada puede salir mal, no hay necesidad para que el receiver envíe paquetes de control al sender. Desventajas : Este esquema sirve para presentar el problema de RDT con su estructura, no sirve a la práctica. Asumiendo que todos los paquetes se reciben y en orden en que fueron enviados. Pero durante la transmisión pueden ocurrir errores de bits. Protocolo ARQ (Automatic Repeat request) Protocolo simple que utiliza mensajes Acknowledgements. El receiver provee feedback : Si el mensaje llega correctamente, el receiver envía ACK al sender. Si el mensaje no llega correctamente, el receiver envía NACK al sender para que reenvíe el paquete. Detección de errores : Se utiliza checksum. 2
Sender : Receiver : Es un protocolo Stop-and-Wait, es decir, mientras espera por paquetes ACK o NACK no puede recibir llamadas de la capa superior y por lo tanto no envía nuevos datos hasta asegurarse de que el paquete llegó correctamente. Los paquetes ACK y NACK pueden estar corruptos, por lo que el emisor no tiene forma de saber si el paquete llegó correctamente. Conclusión : Ventajas : Plantea el caso de que los paquetes de datos pueden llegar corruptos. Desventajas : No plantea el caso de que los paquetes de control ( ACK y NACK ) puedan llegar corruptos. Es un protocolo Stop-and-Wait, por lo que es ineficiente. Se asume que todos los paquetes se reciben y en el orden en que fueron enviados. Es para ayudar a plantear de a poco el escenario del problema. No sirve. Soluciones planteadas por el libro: 1. Usar ACK2 / NACK2, pero si estos llegan corruptos se llega al mismo problema. 2. Checksum suficiente para poder corregir los errores de los paquetes. Pero si se corrige ya sería confiable y perdería el sentido de elaborar el protocolo RDT. 3. Duplicar paquetes de datos al momento de llegar ACK / NACK. El problema es que el receptor no distingue entre datos nuevos y duplicados. 3
c) RDT 2.1 : Se asume el mismo canal subyacente que en RDT 2.0. Solo se agrega el Nro. de Secuencia a los paquetes de datos, es una solución para determinar si el receiver recibe un paquete nuevo o retransmitido. Sender : Receiver : 4
Se envía ACK para confirmar que el paquete llegó correctamente y se reenvía ACK por llegar corrupto. Mientras que se envía NACK para indicar que el paquete llegó incorrectamente. Escenarios posibles de error : a) Error transmisión sp1. b) Error de transmisión de un ACK. 5
c) RDT 2.2 : Conclusión : Ventajas : Plantea el caso de que los paquetes de datos y de control pueden llegar corruptos. Mediante el nro. de secuencia le permite al receiver detectar duplicados de paquetes. Desventajas : No plantea el caso de que los paquetes de control ( ACK y NACK ) puedan llegar corruptos. Es un protocolo Stop-and-Wait, mientras espera por paquetes ACK o NACK, no puede recibir llamadas de la capa superior y por lo tanto no envía nuevos datos hasta asegurarse de que el paquete emitido llegó correctamente. Se asume que todos los paquetes se reciben y en el orden en que fueron enviados. Es para ayudar a plantear de a poco el escenario del problema. No sirve. Se asume el mismo canal que antes, solo que no se cuenta con respuestas de tipo NACK y se incluye un número de secuencia en el ACK. Sender : 6
Receiver : Escenarios posibles : a) Error de transmisión de SP1. 7
b) Error de transmisión de ACK1. Conclusión : Ventajas : Plantea el caso de que los paquetes de datos y control pueden llegar corruptos. Introduce la idea de nros de secuencia sobre todos los paquetes de datos y de control. Permite determinar si el receptor recibe un paquete nuevo o retransmitido, e identificar que el ACK[i] corresponde al paquete de dato SP[i]. Sin perder funcionalidad al reemplazar el mecanismo de NACK. Los resultados funcionales son prácticamente iguales que en RDT 2.1, solo que el autómata del receptor contiene 2 transiciones menos. Desventajas : Es un protocolo Stop-and-Wait, mientras espera por paquetes ACK o NACK, no puede recibir llamadas de la capa superior y por lo tanto no envía nuevos datos hasta asegurarse de que el paquete emitido llegó correctamente. Se asume que todos los paquetes se reciben y en el orden en que fueron enviados. Es para ayudar a plantear de a poco el escenario del problema. No sirve. 8
d) RDT 3.0 : El canal subyacente no es confiable, existe la posibilidad de bits corruptos y pérdidas de paquetes. Se retransmite los paquetes después de un límite de tiempo. Es difícil estimar un tiempo límite para asegurarse de que un paquete se perdió, por lo que en el peor caso, esperar mucho tiempo resulta en ralentizar mucho el protocolo. Por lo que se elige un tiempo probable de pérdida menor al peor caso. Esto implica que se puede retransmitir paquetes que no se han perdido pero que han demorado en llegar más que el promedio. Sender : Se utiliza un temporizador de cuenta atrás. Por lo que el emisor debe poder: 1. Iniciar temporizador luego de emisión. 2. Responder ante una interrupción del temporizador. 3. Detener el temporizador. 9
Receiver : El receiver del RDTP 3.0 se mantiene igual que el RDTP 2.2. No se altera. Escenarios posibles : a) Normal, sin fallas o pérdidas de paquetes. b) Con pérdida de paquetes (Timeout). 10
c) Las del libro: Conclusión : Ventajas : Primer algoritmo en plantear una solución para un canal subyacente inseguro por pérdida de paquetes o paquetes corruptos. Primero que sirve de algo. Introduce la idea del timer con un tiempo límite. El cuál debe ser calculado mediante probabilidad de pérdida. 11
Desventajas : Timers con límite de tiempo corto introducen duplicados de paquetes. Es un protocolo Stop-and-Wait. Es decir, mientras espera por paquetes ACK o NACK, no puede recibir llamadas de la capa superior y por lo tanto no envía nuevos datos hasta asegurarse de que el paquete emitido llegó correctamente. No tiene buen rendimiento. A modo de ejemplo, si entre 2 hosts existe un enlace R de 1Gbps (10^9 b/s) con un RTT de 30 milisegundos. Al transmitirse un paquete de tamaño L = 1000 bytes (8000 bits) incluyendo campos del header y datos, el tiempo que toma transmitir el paquete es: Pero, utilizando un protocolo stop-and-wait, el sender transmite su último bit a los 8 microsegundos, por lo que ese último bit es transmitido en 15 milisegundos, llegando al receiver en tiempo t=rtt/2+l/r=15.008 milisegundos. Asumiendo que el receiver puede enviar el ACK de tamaño despreciable (para no sumar el tiempo de transmisión de este) tan pronto como recibe el último bit del paquete, el ACK llega en t=rtt + L/R = 30.008 milisegundos. Definiendo el tiempo de utilización del canal como el tiempo en que realmente se está transmitiendo información sobre el canal (sender ocupado), como la fracción de tiempo en que el sender está ocupado enviando bits en el canal. Por lo que si se utiliza menos de 0.001% del enlace, para enviar un paquete de 1000 bytes, tomó 30.008 milisegundos (0.030008 segundos), entonces el throughput efectivo es de 266595,5 bps = 267 kbs aproximadamente, cuando el enlace es de 1Gbps. Por lo que esto claramente explica la importancia de los protocolos y como limitan las capacidades del canal subyacente de la capa física. Posibles planteos de solución para protocolos pipelined : 1. Incrementar el rango de los números de secuencia. 2. Que el sender y receiver puedan tener un buffer con más de un paquete: El sender tiene en buffer paquetes enviados y no reconocidos por el receiver. 12
El receiver puede tener que almacenar los paquetes recibidos correctamente. d) GBN (Go-back-N) o Retroceden N : El sender tiene un buffer de hasta N paquetes enviados y no reconocidos por el receiver. (Se limita por control de flujo). Rango de números de secuancia : ACK recibidos = [0, base-1] Esperando por ACK = [base, nextseqnum - 1] Utilizables, todavía no enviados = [nextseqnum, base + N - 1] No utilizables = [base + N, ] ya Por lo tanto, La ventana se va deslizando a la derecha a medida que se reciben ACK. GBN es un protocolo de ventana deslizante ( Sliding window protocol ). El rango de números de secuencia es [0, 2^K - 1] con k = cantidad de bits de campo en header. Y por consecuencia se utiliza aritmética en módulo 2^K. De esta forma luego del número de secuencia 2^K - 1, se utiliza el 0. Nota : RDT 3.0 utiliza aritmética 2^1 (K=1), debido a que el rango es [0, 1]=[0, 2^1-1]. Nota : TCP utiliza aritmética 2^32 (K=32), pero cuenta bytes y no paquetes. 13
Sender : Receiver : Utiliza buffer y envía muchos paquetes al no bloquearse esperando. Como el receptor siempre espera los paquetes según su nro de secuencia, se garantiza que si se entregó el k-esimo paquete a la capa superior, entonces los paquetes con nro de secuencia menor, también fueron entregados correctamente. Como se puede ver, el receiver si envía un ACK[i] es porque todos los paquetes <= i fueron entregados a la capa superior correctamente. Por lo que el Sender, si recibe alguno fuera de orden, solo necesita asegurarse de actualizar el número base al número de secuencia más grande de los ACK recibidos + 1. 14
Escenarios posibles : a) Escenario del libro: El error en este escenario que detalla el libro, es que el sender, al recibir un ACK, actualiza el base con el nro siguiente al nro de secuencia del ACK recibido sin verificar el número, puede haber recibido en orden diferente un ACK, dejando el base con un número erroneo anterior al que debería tener. Por cada ACK repetido o rroneo, se reinicia el timer nuevamente y ante algún timeout, se va a enviar innecesariamente todos los paquetes siguientes a base, incluso los que ya recibió correctamente el receiver, perjudicando el throughput. 15
Mejora 1 : El sender, al recibir ACK[i] debería hacer lo siguiente: si ACK[i] repetido (rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)){ si (base >= (getacknum(rcvpkt) + 1)){ ignorar; }else{ base = getacknum(rcvpkt) + 1; si (base == nextseqnum){ stop_timer(); }else{ start_timer(); } } } Mejora 2 : El receptor ignora paquetes no esperados (Con número de secuencia mayor al esperado), de esta forma, el receiver nunca va a enviar ACK repetidos innecesariamente y el sender nunca va a recibir paquetes ACK repetidos que puedan llevar a reiniciar el timer. b) Escenario se envía de a uno y se pierde el segundo. 16
c) ACK perdido. d) ACK perdido. 17
Algoritmo con mejoras: Sender (Mejora 1): Receiver (Mejora 2): Video de traza de algoritmo con Mejora 2 http://www.youtube.com/watch?v=9buaeejieqi Se puede ver que para paquetes que no eran los esperados no reenvía otro ACK. 18
Conclusión : Ventajas : Plantear una solución para un canal subyacente inseguro por pérdida de paquetes o paquetes corruptos. Primero en plantear una solución con pipeline o procesamiento de cadena. No es un protocolo Stop & Wait como los anteriores. El emisor puede enviar muchos paquetes sin la necesidad de esperar la confirmación de uno solo. Primero en plantear e introducir el concepto de espacio de números de secuencia (mayor cantidad que solo 0 y 1) y ventana deslizante. Como el receptor siempre espera los paquetes según su nro de secuencia, se garantiza que si se entregó el k-ésimo paquete a la capa superior, entonces los paquetes con nro de sec menor a k también fueron entregados correctamente. Modelo de buffer simple. Se entregan en orden los datos. El receptor no necesita de un buffer, basta con un índice que identifique al nro de secuencia del paquete esperado. El tamaño de la ventana puede ser igual al tamaño del espacio de números de secuencia menos 1. Desventajas : El emisor necesita un buffer para almacenamiento. Se descartan paquetes de datos correctos que no llegan en orden. Ante un error se retransmiten todos los paquetes no reconocidos por el emisor. Si la ventana es grande se produce un problema importante de rendimiento. ACK de paquetes recibidos fuera de orden y de paquetes corruptos reinician el buffer innecesariamente, cuando la idea es agilizar la retransmisión de los datos. e) SR (Repetición Selectiva) : El esquema es similar a GBN, solo que el receiver almacena los paquetes recibidos correctamente en un buffer. Se utiliza un temporizador independiente para cada paquete enviado no reconocido por el receiver. 19
El receiver confirma paquetes recibidos correctamente, por más que estén fuera de orden. Los almacena hasta obtener un lote ordenado completo para entregar a la capa superior. Sender : SendData : Comprueba el siguiente número de secuencia disponible. Si el número de secuencia está dentro de la ventana del Sender Se empaquetan los datos y se envían, iniciando su respectivo timer[i]. Sino, se almacena en un buffer, o se rechaza como en GBN. Timeout[i] : Se reenvía el paquete[i] cuyo timer llegó a su fin, luego se reinicia el timer[i]. rcv_ ACK[i] : Si el ACK[i] está dentro de la ventana, se marca el paquete[i] como recibido y se detiene el timer[i]. Si (i == base) Se desplaza la ventana un lugar a la derecha. Si al mover la ventana, existen paquetes (en buffer de salida) con número de secuencia que ahora entran en la ventana, se envían y se inician sus respectivos timers. Otro caso : Ignorar. Receiver : rcv_pkt(rp[i]) && no_corrupt(rp[i]) && ( base <= i ) && ( i <= base + N - 1 ) Se envía ACK[i] al emisor y se almacena RP[i] en el buffer. Si (base == i) Se envían todos los K paquetes almacenados y consecutivos comenzando por base. Se desplaza la ventana K lugares a la derecha. rcv_pkt(rp[i]) && no_corrupt(rp[i]) && ( base - N <= i ) && ( i <= base - 1 ) Se reenvía ACK[i]. Ya que había sido reconocido por el receptor previamente. Otro caso : Ignorar. 20
Escenarios : 1) Pérdida de paquete SP2: 21
2) Escenarios que muestran el problema del tamaño de la ventana, cuando es muy grande con respecto al rango. La respuesta es utilizar un tamaño de ventana menor o igual a la mitad del tamaño de espacio de números de secuencia. 22
Ejemplo en video : https://www.youtube.com/watch?v=cs8tr8a9jm8 Conclusión : Tamaño de ventana <= (tamaño de espacio de números de secuencia / 2) Ventajas : Cuenta con buffer en el receiver para almacenar los paquetes recibidos correctamente y no descartarlos ante una eventual pérdida de un paquete anterior como en GBN. Cuenta con temporizadores independientes para que un timeout no afecte otros paquetes. Desventajas : Contar con un temporizador por cada paquete en la ventana es muy caro (Se puede usar un solo timer de HW para emular N de sw). 23