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 de la

capa superior.

Receiver​:

rdt_rcv ​es una llamada procedural de la capa

inferior.

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

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:

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 ya
recibidos = [0, base-1]
Esperando por ACK = [base, nextseqnum - 1]
Utilizables, todavía no enviados = [nextseqnum, base + N - 1]
No utilizables = [base + N, →]

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

Utiliza buffer y envía muchos paquetes al no bloquearse esperando.

Receiver​:

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