PDF de programación - principio de transferencia de datos confiable

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.



Receiver​:

rdt_rcv ​es una llamada procedural de la
inferior.

de la

capa



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.


b)​ ​RDT 2.0​:


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​:



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.

Receiver​:

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​:



corruptos.

● No plantea el caso de que los​ paquetes de control ​(​ACK ​y ​NACK​)​ ​puedan llegar
● 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

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​:

corruptos.

● No plantea el caso de que los​ paquetes de control ​(​ACK ​y ​NACK​)​ ​puedan llegar
● 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​.


c)​ ​RDT 2.2​:


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:

Iniciar temporizador luego de emisión.

1.
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

● Introduce la idea del timer con un tiempo límite. El cuál debe ser calculado mediante probabilidad

paquetes o paquetes corruptos. ​Primero que sirve de algo​.
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 d