La Capa de Transporte (Pt. 1) - Universidad Nacional del Sur

Módulo 03
La Capa de Transporte
(Pt. 1)
Redes de Computadoras
Depto. de Cs. e Ing. de la Comp.
Universidad Nacional del Sur
Copyright
Copyright © 2010-2016 A. G. Stankevicius
Se asegura la libertad para copiar, distribuir y modificar
este documento de acuerdo a los términos de la GNU
Free Documentation License, versión 1.2 o cualquiera
posterior publicada por la Free Software Foundation,
sin secciones invariantes ni textos de cubierta
delantera o trasera.
Una copia de esta licencia está siempre disponible
en la página http://www.gnu.org/copyleft/fdl.html.
La versión transparente de este documento puede
ser obtenida de la siguiente dirección:
http://cs.uns.edu.ar/~ags/teaching
Redes de Computadoras - Mg. A. G. Stankevicius
2
Contenidos
Servicios y protocolos de la capa de transporte.
Multiplexado y demultiplexado de segmentos.
Transporte no orientado a la conexión (UDP).
Teoría de transporte confiable de datos.
Transporte orientado a la conexión (TCP).
Establecimiento y cierre de conexiones.
Teoría de control de congestión.
Control de congestión en TCP.
Redes de Computadoras - Mg. A. G. Stankevicius
3
ISO/OSI - TCP/IP
7
aplicación
6
presentación
5
sesión
4
transporte
4
3
red
3
2
enlace
2
1
física
1
5
Usted está aquí
Redes de Computadoras - Mg. A. G. Stankevicius
4
Servicios de transporte
La capa de transporte provee la comunicación
lógica entre las diversas
aplicaciones de red.
El servicio brindado se
implementa a través
de los protocolos de
la capa de transporte.
Por caso en internet se
cuenta con TCP y UDP.
aplicación
transporte
red
enlace
física
aplicación
transporte
red
enlace
física
Redes de Computadoras - Mg. A. G. Stankevicius
5
Protocolos de transporte
Los protocolos de la capa de transporte corren
en las computadoras de la frontera de la red.
Cabe enfatizar que los routers en el núcleo de la red
usualmente sólo implementan hasta la capa de red.
El lado emisor de una comunicación corta los
mensajes de las aplicaciones en segmentos,
los que son pasados a la capa de red.
El lado receptor rearma los mensajes a partir
de los segmentos recibidos, que son luego
pasados a la capa de aplicaciones.
Redes de Computadoras - Mg. A. G. Stankevicius
6
Transporte vs. Red
La capa de red y la de transporte parecen ser
similares, pero en realidad brindan servicios
un tanto diferentes:
Por un lado, la capa de red brinda una conexión lógica
punta a punta entre computadoras.
Pero por otro lado, la capa de transporte brinda una
conexión lógica punta a punta entre procesos.
La capa de transporte no sólo hace uso de los
servicios provistos por la capa de red sino que
además los perfecciona y extiende.
Redes de Computadoras - Mg. A. G. Stankevicius
7
Transporte en internet
Internet cuenta con dos servicios de transporte.
TCP, orientado a la conexión, que brinda un envío
confiable y ordenado de datos e implementa control
de flujo y de congestión.
UDP, no orientado a la conexión, que brinda un envío
de datos no confiable ni ordenado y tampoco
implementa control de flujo ni de congestión.
El servicio de transporte de internet no tiene
forma de asegurar ni un ancho de banda
mínimo ni un retardo máximo.
Redes de Computadoras - Mg. A. G. Stankevicius
8
Multiplexado y demultiplexado
La capa de transporte es la encargada de
generalizar el servicio de conexión entre
computadoras provisto por la capa de red.
Para la capa de transporte no basta con
identificar a una computadora en particular,
debe poder identificar a un dado proceso.
El mecanismo que lleva a cabo esta
generalización se denomina multiplexado
del lado del emisor y demultiplexado
del lado del receptor.
Redes de Computadoras - Mg. A. G. Stankevicius
9
Multiplexado y demultiplexado
Multiplexado: se realiza en el emisor al juntar
mensajes de los sockets con un encabezado
adicional, el cual contiene información extra
que será usada luego para demultiplexar.
P1
aplicación
aplicaciónsocket
transporte
transporte
P2
socket
P3
aplicación
aplicaciónsocket
transporte
transporte
P4
socket
aplicación
aplicación
transporte
transporte
red
red
red
red
red
red
enlace
enlace
enlace
enlace
enlace
enlace
física
física
física
física
física
física
Alicia
Bruno
P5
socket
Carlos
Redes de Computadoras - Mg. A. G. Stankevicius 10
Multiplexado y demultiplexado
Demultiplexado: tiene a lugar en el receptor
al determinar a qué socket corresponde
entregar cada uno de los datos recibidos.
P1
aplicación
aplicaciónsocket
transporte
transporte
P2
socket
P3
aplicación
aplicaciónsocket
transporte
transporte
P4
socket
aplicación
aplicación
transporte
transporte
red
red
red
red
red
red
enlace
enlace
enlace
enlace
enlace
enlace
física
física
física
física
física
física
Alicia
Bruno
P5
socket
Carlos
Redes de Computadoras - Mg. A. G. Stankevicius 11
Demultiplexado
El proceso de demultiplexado comienza
al recibir un datagrama IP:
Cada datagrama tiene un IP
de origen y de destino.
Contiene exactamente
un segmento de la capa
de transporte.
Cada segmento especifica
un puerto origen y destino.
El IP y puerto destino identifica
unívocamente a un socket.
32 bits
puerto origen puerto dest.
otros campos del encabezado
cuerpo del
mensaje
formato de un segmento
TCP/UDP
Redes de Computadoras - Mg. A. G. Stankevicius 12
Demultiplexado UDP
Cada sockets UDP se asocia a un número
de puerto local determinado.
Para identificar un socket UDP arbitrario sólo
hace falta una dirección IP y un puerto.
Al recibir un segmento UDP se verifica el
puerto destino indicado en el segmento y se
entrega su contenido al socket asociado a ese
puerto.
Segmentos originados en máquinas con diversas
direcciones IP o bien distintos puertos de origen
pueden ser entregados al mismo socket UDP.
Redes de Computadoras - Mg. A. G. Stankevicius 13
Demultiplexado UDP
Supongamos que el proceso P2 crea un socket
UDP en el puerto 6428:
P1
P2
socket
socket
SP: 6428
DP: 9157
SIP: B
DIP: A
cliente
(IP: A)
P3
SP: 9157
DP: 6428
SIP: A
DIP: B
socket
SP: 6428
DP: 5775
SIP: B
DIP: C
servidor
(IP: B)
SP: 5775
DP: 6428
SIP: C
DIP: B
cliente
(IP: C)
Redes de Computadoras - Mg. A. G. Stankevicius 14
Demultiplexado TCP
Cada socket TCP se asocia a cuatro valores,
la dirección IP y puerto de origen por un lado
y la dirección IP y puerto destino por el otro.
La computadora que recibe un segmento TCP hace
uso de esos cuatro valores para determinar cuál
de los sockets TCP debe recibirlo.
Los servidores hacen uso de múltiples sockets,
uno para cada uno de los clientes conectados.
La dirección IP y puerto de origen distingue
a los distintos clientes entre sí.
Redes de Computadoras - Mg. A. G. Stankevicius 15
Demultiplexado TCP
El proceso P2 ahora necesita un socket TCP
independiente para cada cliente:
P1
P2
socket
socket socket
SP: 51211
DP: 9157
SIP: B
DIP: A
cliente
(IP: A)
P3
SP: 9157
DP: 80
SIP: A
DIP: B
socket
SP: 51112
DP: 5775
SIP: B
DIP: C
servidor
(IP: B)
SP: 5775
DP: 80
SIP: C
DIP: B
cliente
(IP: C)
Redes de Computadoras - Mg. A. G. Stankevicius 16
Protocolo UDP
El protocolo UDP representa el servicio de
transporte más elemental que brinda internet.
Se define formalmente en el RFC 768.
Se basa en el principio “best effort”,
propio del protocolo IP de la capa de red.
Se trata de un protocolo no orientado
a la conexión:
Cada segmento UDP se puede manipular
de manera independiente del resto.
Redes de Computadoras - Mg. A. G. Stankevicius 17
Protocolo UDP
¿Habiendo TCP, hace falta UDP?
UDP no necesita establecer una conexión antes
de comenzar a enviar información.
Es extremadamente simple, no necesita almacenar
información acerca del intercambio en curso.
Su encabezado es mucho más sencillo y ocupa menor
cantidad de bytes que un encabezado TCP.
No implementa control de flujo ni de congestión,
el emisor puede enviar la información al ritmo
que le plazca, sin limitaciones de ningún tipo.
Redes de Computadoras - Mg. A. G. Stankevicius 18
Protocolo UDP
El protocolo se suele utilizar para hacer
streaming de audio y video.
El streaming es tolerante
a pérdidas pero requiere
retardos acotados.
Otros usos:
DNS.
SMNP.
Juegos en línea.
largo en bytes
del segmento UDP,
incluyendo encabezado
32 bits
puerto origen puerto dest.
longitud
checksum
cuerpo del
mensaje
formato de
un segmento UDP
Redes de Computadoras - Mg. A. G. Stankevicius 19
Checksum UDP
El propósito del campo checksum es detectar
la aparición de bits en error.
El emisor calcula el checksum correcto:
Considera el contenido del segmento como
una secuencia de enteros de 16 bits.
El checksum consiste de la suma en 1-complemento
de esta secuencia de enteros.
Una vez obtenido el checksum correcto lo escribe
en el campo correspondiente del encabezado UDP.
Redes de Computadoras - Mg. A. G. Stankevicius 20
Checksum UDP
El receptor debe verificar el checksum:
Recomputa el checksum del segmento
que acaba de recibir.
Compara el valor obtenido con el checksum
registrado en el campo del encabezado.
Si difieren se detectó uno o más errores
en la transmisión.
En contraste, si son iguales no se han detectados
errores en la transmisión (¡lo cual no significa
que no se hayan producido uno o más errores!).
Redes de Computadoras - Mg. A. G. Stankevicius 21
Comunicación confiable
Aplicación
Transporte
P1
P2
datos
datos
canal confiable
P1
P2
datos
envio_rdt()
protocolo rdt
(emisor)
envio_udt()
paquete
Red
datos
entregar()
protocolo rdt
(receptor)
recep_rdt()
paquete
canal no confiable
servicio provisto
implementación
Redes de Computadoras - Mg. A. G. Stankevicius 22
Comunicación confiable
envio_rdt(): invocado desde
envio_rdt(): invocado desde
arriba, suministra los datos
arriba, suministra los datos
a ser enviados
a ser enviados
P1
P2
datos
envio_rdt()
protocolo rdt
(emisor)
envio_udt()
paquete
envio_udt(): invocado por
envio_udt(): invocado por
el protocolo para transferir
el protocolo para transferir
un paquete a través del canal
un paquete a través del canal
no confiable
no confiable
entregar(): invocado por
entregar(): invocado por
el protocolo para entregar
el protocolo para entregar
los datos recibidos
los datos recibidos
datos
entregar()
protocolo rdt
(receptor)
recep_rdt()
paquete
canal no confiable
recep_rdt(): invocado por
recep_rdt(): invocado por
el protocolo cuando llega
el protocolo cuando llega
un nuevo paquete al receptor
un nuevo paquete al receptor
Redes de Computadoras - Mg. A. G. Stankevicius 23
Protocolo RDT
A continuación analizaremos cómo se debería
definir el protocolo RDT para poder brindar
un servicio de transferencia confiable de datos.
La idea es comenzar con un protocolo básico para
luego ir considerando un escenario más realista.
Emisor y receptor tienen responsabilidades diferentes.
Sólo consideraremos una comunicación unidireccional.
Las distintas iteraciones del protocolo RDT serán
definidas a través de autómatas finitos.
Redes de Computadoras - Mg. A. G. Stankevicius 24
RDT/1.0
El protocolo RDT/1.0 permite el envío confiable
de datos a través de un canal confiable.
El canal no pierde información ni introduce errores.
Un autómata para el emisor y otro para el receptor.
esperar
llamada
de arriba
envio_rdt(datos)
paqenv = empaq(datos)
envio_udt(paqenv)
emisor
esperar
llamada
de abajo
recep_rdt(paqrec)
datos = desempaq(paqrec)
entregar(datos)
receptor
Redes de Computadoras - Mg. A. G. Stankevicius 25
RDT/2.0
El protocolo RDT/2.0 permite envío confiable
de datos a través de un canal que puede causar
errores a nivel de los bits.
El canal sigue sin perder información, sólo introduce
errores a nivel de bit.
Los errores pueden ser detectados por el campo
checksum del encabezado UDP.
No obstante, con detectar el error no basta,
se debe incorporara al protocolo algún mecanismo
de recuperación ante la detección de un error.
¿Qué hacen los humanos ante este tipo de error?
Redes de Computadoras - Mg. A. G. Stankevicius 26
RDT/2.0
La nueva versión del protocolo hará uso
de confirmaciones de recepción (ACK) para
indicar que el paquete fue recibido sin errores.
Si el paquete llega con errores, se solicita
la retransmisión del mismo haciendo uso
de un mensaje específico (NAK).
El emisor reenvía el último paquete enviado
al recibir un NAK en vez de un ACK.
¿Existe alguna situación involucrando humanos en
la que se haga uso de mensajes de ACK y/o NAK?
Redes de Computadoras - Mg. A. G. Stankevicius 27
Emisor RDT/2.0
envio_rdt(datos)
paqenv = empaq(datos,checksum)
envio_udt(paqenv)
esperar
llamada
de arriba
esperar por
ACK/NAK
recep_rdt(paqrec) &&
esNAK(paqrec)
envio_udt(paqenv)
recep_rdt(paqrec) &&
esACK(paqrec)

Redes de Computadoras - Mg. A. G. Stankevicius 28
Receptor RDT/2.0
recep_rdt(paqrec) &&
corrupto(paqrec)
paqenv = crearpaqNAK()
envio_udt(paqenv)
esperar
llamada
de abajo
recep_rdt(paqrec) &&
!corrupto(paqrec)
paqenv = crearpaqACK()
envio_udt(paqenv)
datos = desempaq(paqrec)
entregar(datos)
Redes de Computadoras - Mg. A. G. Stankevicius 29
RDT/2.0 envío sin errores
envio_rdt(datos)
paqenv = empaq(datos,checksum)
envio_udt(paqenv)
recep_rdt(paqrec) &&
esNAK(paqrec)
envio_udt(paqenv)
recep_rdt(paqrec) &&
corrupto(paqrec)
esperar
llamada
de arriba
esperar por
ACK/NAK
recep_rdt(paqrec) &&
esACK(paqrec)
paqenv = crearpaqNAK()
envio_udt(paqenv)
esperar
llamada
de abajo

recep_rdt(paqrec) &&
!corrupto(paqrec)
paqenv = crearpaqACK()
envio_udt(paqenv)
datos = desempaq(paqrec)
entregar(datos)
Redes de Computadoras - Mg. A. G. Stankevicius 30
RDT/2.0 envío con errores
envio_rdt(datos)
paqenv = empaq(datos,checksum)
envio_udt(paqenv)
recep_rdt(paqrec) &&
esNAK(paqrec)
envio_udt(paqenv)
recep_rdt(paqrec) &&
corrupto(paqrec)
esperar
llamada
de arriba
esperar por
ACK/NAK
recep_rdt(paqrec) &&
esACK(paqrec)
paqenv = crearpaqNAK()
envio_udt(paqenv)
esperar
llamada
de abajo

recep_rdt(paqrec) &&
!corrupto(paqrec)
paqenv = crearpaqACK()
envio_udt(paqenv)
datos = desempaq(paqrec)
entregar(datos)
Redes de Computadoras - Mg. A. G. Stankevicius 31
Análisis de RDT/2.0
RDT/2.0 es un protocolo tipo “stop and wait”.
El emisor envía un paquete y queda a la espera
de que le confirmen su correcta recepción.
No obstante, RDT/2.0 tiene un problema fatal:
¿Qué sucede si el canal corrompe el paquete enviado
por el receptor conteniendo un ACK o un NAK?
El problema es que el receptor desconoce qué está
pasando con el emisor.
Asumir que se trataba de un NAK no es suficiente,
puede causar que el receptor acepte un duplicado.
Redes de Computadoras - Mg. A. G. Stankevicius 32
Posibles soluciones
Una posibilidad consiste en enviar un ACK o
un NAK adicional para que el receptor sepa
si el emisor recibió correctamente el mensaje.
¿Qué pasa si se corrompe el ACK/NAK del ACK/NAK?
Otra posibilidad es agregar suficientes bits de
código como para poder corregir estos errores.
Podría funcionar, pero no se puede aplicar a canales
que pierdan paquetes.
La única solución viable parece ser numerar
los paquetes.
Redes de Computadoras - Mg. A. G. Stankevicius 33
Paquetes duplicados
Incorporar un esquema de numeración de
los paquetes implica que el emisor marque
cada paquete que envía con un cierto número.
En el escenario que se corrompía el ACK/NAK
enviado por el receptor, el emisor simplemente
asume que se trataba de un NAK y reenvía
el último paquete (usando el mismo número
de paquete que la vez anterior).
El receptor en caso de recibir por segunda vez
el mismo paquete simplemente lo descarta.
Redes de Computadoras - Mg. A. G. Stankevicius 34
Emisor RDT/2.1
envio_rdt(datos)
paqenv = empaq(0,datos,checksum)
envio_udt(paqenv)
recep_rdt(paqrec) &&
(corrupto(paqrec) || esNAK(paqrec))
envio_udt(paqenv)
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
esACK(paqrec))
esperar
llamada 0
de arriba
esperar por
ACK/NAK 0
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
esACK(paqrec))

recep_rdt(paqrec) &&
(corrupto(paqrec) ||
esNAK(paqrec))
envio_udt(paqenv)
esperar por
ACK/NAK 1
esperar
llamada 1
de arriba

envio_rdt(datos)
paqenv = empaq(1,datos,checksum)
envio_udt(paqenv)
Redes de Computadoras - Mg. A. G. Stankevicius 35
Receptor RDT/2.1
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
nrosec0(paqrec)
recep_rdt(paqrec) &&
datos = desempaq(paqrec)
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
entregar(datos)
corrupto(paqrec)
nrosec1(paqrec)
paqenv = empaq(ACK,checksum)
envio_udt(paqenv)
paqenv = empaq(NAK,checksum)
paqenv = empaq(ACK,checksum)
envio_udt(paqenv)
envio_udt(paqenv)
esperar
llamada 0
de abajo
recep_rdt(paqrec) &&
corrupto(paqrec)
esperar
llamada 1
de abajo
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
paqenv = empaq(NAK,checksum)
nrosec1(paqrec)
envio_udt(paqenv)
datos = desempaq(paqrec)
entregar(datos)
paqenv = empaq(ACK,checksum)
envio_udt(paqenv)
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
nrosec0(paqrec)
paqenv = empaq(ACK,checksum)
envio_udt(paqenv)
Redes de Computadoras - Mg. A. G. Stankevicius 36
Análisis de RDT/2.1
RDT/2.1 incorpora números de secuencia
en los paquetes enviados por el emisor.
Con sólo dos números de paquete es suficiente.
El emisor verifica la correcta recepción de
los mensajes de ACK/NAK.
Los autómatas finitos que definen el protocolo
requieren el doble de estados que en RDT/2.0.
Los estados distinguen el número de secuencia
del próximo paquete a ser enviado o recibido.
Redes de Computadoras - Mg. A. G. Stankevicius 37
Análisis de RDT/2.1
El receptor debe verificar que los paquetes
recibidos tengan el número de secuencia
esperado.
Caso contrario, se trata de un paquete duplicado,
el cual debe ser descartado.
El receptor no tiene forma de saber si el emisor
recibió correctamente el último ACK/NAK.
Se dará cuenta implícitamente que el emisor recibió
correctamente el ACK cuando vea un paquete
numerado con el próximo valor de la secuencia.
Redes de Computadoras - Mg. A. G. Stankevicius 38
RDT/2.2
El protocolo RDT/2.1 admite ser optimizado
evitando tener que hacer uso de los mensajes
NAK de reconocimiento negativo.
La idea es que el receptor indique qué paquete
está reconociendo al enviar un ACK.
Debemos incorporar el número de secuencia
en los mensajes enviados por el receptor.
La recepción por parte del emisor de
un segundo ACK hace las veces de NAK.
En ambos casos se debe reenviar el último paquete.
Redes de Computadoras - Mg. A. G. Stankevicius 39
Emisor RDT/2.2
envio_rdt(datos)
paqenv = empaq(0,datos,checksum)
envio_udt(paqenv)
recep_rdt(paqrec) &&
(corrupto(paqrec) || esACK1(paqrec))
envio_udt(paqenv)
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
esACK1(paqrec))
esperar
llamada 0
de arriba
esperar por
ACK 0
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
esACK0(paqrec)

recep_rdt(paqrec) &&
(corrupto(paqrec) ||
esACK0(paqrec))
envio_udt(paqenv)
esperar por
ACK 1
esperar
llamada 1
de arriba

envio_rdt(datos)
paqenv = empaq(1,datos,checksum)
envio_udt(paqenv)
Redes de Computadoras - Mg. A. G. Stankevicius 40
Receptor RDT/2.2
recep_rdt(paqrec) &&
!corrupto(paqrec) && nrosec0(paqrec)
datos = desempaq(paqrec)
entregar(datos)
paqenv = empaq(0,ACK,checksum)
envio_udt(paqenv)
almenosunoenv = false
recep_rdt(paqrec) &&
(corrupto(paqrec) || nrosec0(paqrec)
paqenv = empaq(0,ACK,checksum)
envio_udt(paqenv)

almenosunoenv = true
esperar
llamada 0
de abajo
recep_rdt(paqrec) &&
(corrupto(paqrec) || nrosec1(paqrec))
if(!almenosunoenv)
paqenv = empaq(1,ACK,checksum)
envio_udt(paqenv)
esperar
llamada 1
de abajo
recep_rdt(paqrec) &&
!corrupto(paqrec) && nrosec1(paqrec)
datos = desempaq(paqrec)
entregar(datos)
paqenv = empaq(1,ACK,checksum)
envio_udt(paqenv)
Redes de Computadoras - Mg. A. G. Stankevicius 41
RDT/3.0
El protocolo RDT/3.0 permite envío confiable
de datos a través de un canal que puede causar
errores a nivel de los bits y/o perder en su
totalidad alguno de los mensajes enviados.
El protocolo debe contemplar que se pierda
un paquete o un mensaje de ACK.
Se deben resolver dos problemas: cómo detectar
las pérdidas y qué hacer cuando se produzca una.
Los mecanismos presentes en RDT/2.2 no
permiten detectar que se produjo una pérdida.
Redes de Computadoras - Mg. A. G. Stankevicius 42
RDT/3.0
Un posible solución es quedar a la espera de
un paquete o un mensaje ACK y cuando se
tenga la certeza de que se perdió reenviarlo.
¿Cuánto hay que esperar para tener la certeza
que se perdió el último mensaje enviado?
Esta alternativa funciona, pero implica pagar un costo
muy alto en eficiencia al perderse un mensaje.
Una mejor opción es quedar a la espera de una
respuesta por un tiempo razonable y si no llega
asumir que se perdió y reenviarlo.
Redes de Computadoras - Mg. A. G. Stankevicius 43
RDT/3.0
¿Qué sucede si en realidad el paquete estaba
retrasado, pero no se había perdido?
El reenvió generará un mensaje duplicado, pero
el protocolo ya maneja correctamente esa situación.
Emisor y receptor deben indicar el número
de secuencia en sus mensajes.
Para implementar esta política hace falta contar
con un temporizador programable.
Redes de Computadoras - Mg. A. G. Stankevicius 44
Emisor RDT/3.0
envio_rdt(datos)
paqenv = empaq(0,datos,checksum) recep_rdt(paqrec) &&
(corrupto(paqrec) ||
envio_udt(paqenv)
nrosec1(paqrec))
poner(alarma)

recep_rdt(paqrec)

esperar
llamada 0
recep_rdt(paqrec) &&
!corrupto(paqrec) && de arriba
esperar por
ACK 0
nrosec1(paqrec)
disparo(alarma)
recep_rdt(paqrec) &&
(corrupto(paqrec) ||
nrosec0(paqrec))

envio_udt(paqenv)
poner(alarma)
recep_rdt(paqrec) &&
!corrupto(paqrec) &&
nrosec0(paqrec)
sacar(alarma)
envio_udt(paqenv)
poner(alarma)
disparo(alarma)
esperar por
ACK 1
esperar
llamada 1
de arriba
envio_rdt(datos)
sacar(alarma)
recep_rdt(paqrec)

paqenv = empaq(1,datos,checksum)
envio_udt(paqenv)
poner(alarma)
Redes de Computadoras - Mg. A. G. Stankevicius 45
RDT/3.0 ideal
emisor
envío paq. 0
recep. ACK 0
envío paq. 1
recep. ACK 1
envío paq. 0
receptor
recep. paq. 0
envío ACK 0
recep. paq. 1
envío ACK 1
recep. paq. 0
envío ACK 0
recep. ACK 0
Redes de Computadoras - Mg. A. G. Stankevicius 46
Pérdida de un paquete
emisor
receptor
envío paq. 0
recep. paq. 0
envío ACK 0
recep. ACK 0
envío paq. 1
paquete
pérdido
disparo de alarma
reenvío paq. 1
recep. paq. 1
envío ACK 1
recep. ACK 1
Redes de Computadoras - Mg. A. G. Stankevicius 47
Pérdida de un ACK
emisor
receptor
envío paq. 0
recep. paq. 0
envío ACK 0
recep. ACK 0
envío paq. 1
disparo de alarma
reenvío paq. 1
recep. paq. 1
envío ACK 1
ACK
pérdido
recep. paq. 1 (duplicado detec.)
reenvío ACK 1
recep. ACK 1
Redes de Computadoras - Mg. A. G. Stankevicius 48
Reenvío prematuro
emisor
receptor
envío paq. 0
recep. paq. 0
envío ACK 0
recep. ACK 0
envío paq. 1
disparo de alarma
reenvío paq. 0
recep. ACK 0
(duplicado detec.)
recep. paq. 0 (duplicado detec.)
reenvío ACK 0
recep. paq. 1
envío ACK 1
recep. ACK 1
Redes de Computadoras - Mg. A. G. Stankevicius 49
Análisis de RDT/3.0
El protocolo RDT/3.0 cumple con el objetivo
propuesto, esto es, permite la transmisión
confiable de datos sobre un canal no confiable.
No obstante, este protocolo presenta un
desempeño bastante pobre, lo que lo torna
poco aplicable a escenarios del mundo real.
Esta es una característica propia de los protocolos
de la familia “stop-and-wait”.
Redes de Computadoras - Mg. A. G. Stankevicius 50
Desempeño de RDT/3.0
Consideremos la siguiente situación:
Se dispone de una línea dedicada de 1 Gb/s que
une dos de las oficinas de una cierta compañía.
Se intercambian paquetes de 1 KB y el RTT entre
estas oficinas es de 30 ms.
dtrans=
L (cantidad de bits)
R (ancho de banda)
uenlace=
L/R
RTT + L/R
1 paq. / 30 ms
=
=
=
8000 b
10^9 b/s
.008 ms
30.008 ms
1 Gb/s x 0.027%
=
= 8 microseg.
= 0.027%
33.3 KB/s
Redes de Computadoras - Mg. A. G. Stankevicius 51
Operatoria stop-and-wait
envío del primer bit (t = 0)
envío del último bit (t = L/R)
recep. del primer bit
recep. del último bit
envío del ACK
RTT
recep. del ACK (t = L/R + RTT)
comienza el envío del sig. paq.
uenlace=
L/R
RTT + L/R
=
.008 ms
30.008 ms
= 0.027%
Redes de Computadoras - Mg. A. G. Stankevicius 52
Operatoria en pipeline
El factor de utilización obtenido de apenas
0.027% es evidentemente inaceptable.
Habría que permitir una operatoria en pipeline
a fin de elevar el factor de ocupación.
La idea básica es permitir que varios paquetes
estén en camino al mismo tiempo.
A tal efecto hace falta incrementar los números
de secuencia disponibles.
También hace falta alguna forma de almacenamiento
intermedio tanto en emisor como receptor.
Redes de Computadoras - Mg. A. G. Stankevicius 53
Operatoria en pipeline
envío del primer bit (t = 0)
envío del último bit (t = L/R)
recep. del primer bit
último bit 1er. paq. / envío ACK
RTT
último bit 2do. paq. / envío ACK
último bit 3er. paq. / envío ACK
recep. del ACK, comienza el envío
del sig. paq. (t = L/R + RTT)
¡mejora la utilización
por un factor de 3!
uenlace=
3 x L/R
RTT + L/R
=
.024 ms
30.008 ms
= 0.08%
Redes de Computadoras - Mg. A. G. Stankevicius 54
Operatoria en pipeline
Go-back N (GBN)
Selective Repeat (SR)
El emisor puede tener
hasta n paquetes aun
sin confirmar.
El emisor puede tener
hasta n paquetes aun
sin confirmar.
El receptor sólo envía
ACKs acumulativos
(¡no tolera huecos!).
El receptor envía ACKs
individuales para cada
paquete.
El emisor sólo requiere
un temporizador para el
paquete más antiguo
sin reconocer.
El emisor mantiene
un temporizador para
paquete aun no
reconocido.
Redes de Computadoras - Mg. A. G. Stankevicius 55
Protocolo Go-Back-N
El protocolo GBN es una de las formas
de implementar la operatorio en pipeline.
Se reservan k bits del encabezado para los números
de secuencia de los paquetes.
Se permiten hasta una ventana deslizante de N
paquetes en tránsito, esto es, aquellos cuales cuya
confirmación de recepción aún no ha sido recibida.
ventana deslizante
de tamaño N
ACK ya
recibido
todavía
enviados
a ser enviados
no usables
esperando ACK
Redes de Computadoras - Mg. A. G. Stankevicius 56
Emisor GBN
envio_rdt(datos)

base = 1
proxnum = 1
recep_rdt(paqrec) &&
corrupto(paqrec)
esperar
llamada
de arriba

recep_rdt(paqrec) &&
!corrupto(paqrec)
base = nrosec(paqrec) + 1
if (proxnum == base)
sacar(alarma)
else
poner(alarma)
if(proxnum < base + N) {
paqenv[proxnum] =
empaq(proxnum, datos, checksum)
envio_udt(paqenv[proxnum])
if (proxnum == base)
poner(alarma)
proxnum++
} else rechazar(datos)
disparo(alarma)
poner(alarma)
envio_udt(paqenv[base])
envio_udt(paqenv[base + 1])

envio_udt(paqenv[proxnum - 1])
Redes de Computadoras - Mg. A. G. Stankevicius 57
Receptor GBN
recep_rdt(paqrec) && !corrupto(paqrec) &&
(nrosec(paqrec) == proxnumreq)

proxnumreq = 1
paqenv = empaq(0,ACK,checksum)
datos = desempaq(paqrec)
entregar(datos)
paqenv = empaq(proxnumreq, ACK, checksum)
envio_udt(paqenv)
proxnumreq++
esperar
llamada
de abajo
recep_rdt(paqrec) &&
(corrupto(paqrec) || (nrosec(paqrec) != proxnumreq)))
envio_udt(paqenv)
Redes de Computadoras - Mg. A. G. Stankevicius 58
Análisis GBN
El receptor sólo envía un mensaje de ACK para
el paquete correctamente recibido con mayor
número de secuencia.
Esta política puede generar mensajes de ACK
duplicados.
El receptor sólo necesita recordar el número
de secuencia del próximo paquete que desea.
Los paquetes recibidos fuera de orden
son descartados.
El receptor no requiere almacenamiento intermedio.
Redes de Computadoras - Mg. A. G. Stankevicius 59
GBN en acción
0
0
0
0
1
1
1
1
2
2
2
2
3
3
3
3
4
4
4
4
5
5
5
5
6
6
6
6
7
7
7
7
envío paq. 0
envío paq. 1
envío paq. 2
envío paq. 3
0 1 2 3 4 5 6 7 rec. ACK 1, env. paq. 4
0 1 2 3 4 5 6 7 rec. ACK 2, env. paq. 5
0
0
0
0
1
1
1
1
2
2
2
2
3
3
3
3
4
4
4
4
5
5
5
5
6
6
6
6
7
7
7
7
reenvío paq. 2
reenvío paq. 3
reenvío paq. 4
reenvío paq. 5
recep. paq. 0, envío ACK 0
recep. paq. 1, envío ACK 1
recep. paq. 3 (se descarta)
reenvío ACK 1
recep. paq. 4 (se descarta)
reenvío ACK 1
recep. paq. 5 (se descarta)
reenvío ACK 1
recep. paq. 2, envío ACK 2
recep. paq. 3, envío ACK 3
recep. paq. 4, envío ACK 4
recep. paq. 5, envío ACK 5
Redes de Computadoras - Mg. A. G. Stankevicius 60
Repetición Selectiva
El protocolo Repetición Selectiva (SR) es otra
implementación de la operatoria en pipeline.
La idea central es disminuir el número de paquetes
a ser reenviados al recuperarse de una pérdida.
A diferencia de GBN, el receptor reconoce
por separado a cada uno de los paquetes
correctamente recibidos.
El receptor debe contar con un almacenamiento
intermedio para alojar los paquetes recibidos
correctamente pero fuera de orden.
Redes de Computadoras - Mg. A. G. Stankevicius 61
Repetición Selectiva
El emisor sólo debe reenviar aquellos paquetes
para los que aún no se haya recibido el mensaje
de ACK correspondiente
Esto implica que debemos contar con un temporizador
independiente para cada paquete enviado cuyo ACK
asociado aún no haya sido recibido.
El emisor cuenta con una ventana deslizante
de N números consecutivos de secuencia.
La ventana representa el conjunto de paquetes que
tiene permitido tener en tránsito al mismo tiempo.
Redes de Computadoras - Mg. A. G. Stankevicius 62
Visión del emisor y receptor
enviados, ACK ya recibido
enviados, esperando ACK
recibidos fuera de orden, ACK ya enviado
a la espera, aún no recibidos
usables, a ser enviados
aceptables
no usables
no usables
emisor SR
ventana deslizante
receptor SR
ventana deslizante
Redes de Computadoras - Mg. A. G. Stankevicius 63
Emisor SR
El emisor SR debe reaccionar ante los eventos
que se presenten de la siguiente manera:
Al recibir un nuevo paquete a ser enviado debe
verificar si el siguiente número de secuencia
se encuentra dentro de la ventana.
Al dispararse la alarma de un paquete debe reenviar
sólo ese paquete y debe reiniciar el temporizador.
Al recibir un ACK debe marcar ese paquete como
recibido y en caso de ser el menor número de
paquete no reconocido, debe avanzar la ventana
hasta el próximo paquete aún sin reconocer.
Redes de Computadoras - Mg. A. G. Stankevicius 64
Receptor SR
El receptor SR debe reaccionar ante los eventos
que se presenten de la siguiente manera:
Al recibir un paquete con número de secuencia base
se envía su ACK y se avanza la ventana hasta
el próximo paquete esperado pero aún no recibido.
Al recibir un paquete con número de secuencia entre
base+1 y base+N-1 se envía su ACK y se guarda
provisoriamente en el almacenamiento intermedio.
Al recibir un paquete con número de secuencia entre
base-N y base-1 sólo se envía su respectivo ACK.
En cualquier otro caso, no se toma acción alguna.
Redes de Computadoras - Mg. A. G. Stankevicius 65
Protocolo SR en acción
0
0
0
0
alarma
paq. 2
1
1
1
1
enviados conf.
enviados no conf.
fuera de orden
a la espera
usables
no usables
2
2
2
2
3
3
3
3
4
4
4
4
5
5
5
5
6
6
6
6
7
7
7
7
8
8
8
8
9
9
9
9
0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789
Redes de Computadoras - Mg. A. G. Stankevicius 66
El dilema del receptor SR
enviados conf.
enviados no conf.
fuera de orden
a la espera
usables
no usables
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
Redes de Computadoras - Mg. A. G. Stankevicius 67
El dilema del receptor SR
alarma
paq. 0
enviados conf.
enviados no conf.
fuera de orden
a la espera
usables
no usables
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
0 1 230 1 2
¡SR entrega un paquete
fuera de orden!
Redes de Computadoras - Mg. A. G. Stankevicius 68
Análisis SR
El receptor SR no tiene forma de distinguir
entre estos dos escenarios.
En el primer caso el funcionamiento es el esperado,
pero en el segundo caso, SR termina entregando
un paquete fuera de orden.
¿Qué relación tiene que cumplirse entre
el tamaño de ventana y el conjunto
de números de secuencia disponibles?
El tamaño de ventana debe ser menor o igual a
la mitad de la cantidad de números de secuencia.
Redes de Computadoras - Mg. A. G. Stankevicius 69
¿Preguntas?
Redes de Computadoras - Mg. A. G. Stankevicius 70