Módulo 03 La Capa de Transporte (Pt. 1)

Transcripción

1 Módulo 03 La Capa de Transporte (Pt. 1) Redes de Computadoras Depto. de Cs. e Ing. de la Comp. Universidad Nacional del Sur

2 Copyright Copyright 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 La versión transparente de este documento puede ser obtenida de la siguiente dirección: Redes de Computadoras - Mg. A. G. Stankevicius 2

3 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

4 ISO/OSI - TCP/IP aplicación presentación sesión transporte red enlace 1 física Usted está aquí Redes de Computadoras - Mg. A. G. Stankevicius 4

5 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 red enlace física red enlace física red enlace física red enlace física aplicación transporte red enlace física Redes de Computadoras - Mg. A. G. Stankevicius 5

6 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

7 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

8 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

9 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

10 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. aplicación aplicación transporte transporte red red enlace enlace física física Alicia P1 socket P2 socket aplicación aplicación transporte transporte red red enlace enlace física física Bruno P3 P4 aplicación P5 aplicación socket socket socket transporte transporte red red enlace enlace física física Carlos Redes de Computadoras - Mg. A. G. Stankevicius 10

11 Multiplexado y demultiplexado Demultiplexado: tiene a lugar en el receptor al determinar a qué socket corresponde entregar cada uno de los datos recibidos. aplicación aplicación transporte transporte red red enlace enlace física física Alicia P1 socket P2 socket aplicación aplicación transporte transporte red red enlace enlace física física Bruno P3 P4 aplicación P5 aplicación socket socket socket transporte transporte red red enlace enlace física física Carlos Redes de Computadoras - Mg. A. G. Stankevicius 11

12 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. puerto origen 32 bits puerto dest. otros campos del encabezado cuerpo del mensaje formato de un segmento TCP/UDP Redes de Computadoras - Mg. A. G. Stankevicius 12

13 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

14 Demultiplexado UDP Supongamos que el proceso P2 crea un socket UDP en el puerto 6428: P1 socket P2 socket P3 socket SP: 6428 DP: 9157 SP: 6428 DP: 5775 SIP: B DIP: A SIP: B DIP: C cliente (IP: A) SP: 9157 DP: 6428 SIP: A DIP: B servidor (IP: B) SP: 5775 DP: 6428 SIP: C DIP: B cliente (IP: C) Redes de Computadoras - Mg. A. G. Stankevicius 14

15 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

16 Demultiplexado TCP El proceso P2 ahora necesita un socket TCP independiente para cada cliente: P1 socket P2 socket socket P3 socket cliente (IP: A) SP: 9157 DP: 80 SIP: A DIP: B SP: DP: 9157 SIP: B DIP: A servidor (IP: B) SP: DP: 5775 SIP: B DIP: C SP: 5775 DP: 80 SIP: C DIP: B cliente (IP: C) Redes de Computadoras - Mg. A. G. Stankevicius 16

17 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

18 Protocolo UDP Habiendo TCP, hace falta UDP? UDP no necesita establecer una conexión antes de comenzar a enviar información (lo cual eleva la latencia). Es extremadamente simple, no necesita almacenar información acerca de la conexión 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

19 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 puerto origen longitud 32 bits cuerpo del mensaje puerto dest. checksum formato de un segmento UDP Redes de Computadoras - Mg. A. G. Stankevicius 19

20 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

21 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

22 Comunicación confiable Aplicación P1 P2 P1 P2 datos datos datos envio_rdt() datos entregar() Transporte canal confiable protocolo rdt (emisor) envio_udt() paquete protocolo rdt (receptor) recep_rdt() paquete Red canal no confiable servicio provisto implementación Redes de Computadoras - Mg. A. G. Stankevicius 22

23 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 entregar(): invocado por entregar(): invocado por el protocolo para entregar el protocolo para entregar los datos recibidos los datos recibidos datos envio_rdt() protocolo rdt (emisor) envio_udt() paquete datos entregar() protocolo rdt (receptor) recep_rdt() 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 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

24 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

25 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) esperar llamada de abajo recep_rdt(paqrec) datos = desempaq(paqrec) entregar(datos) emisor receptor Redes de Computadoras - Mg. A. G. Stankevicius 25

26 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. Redes de Computadoras - Mg. A. G. Stankevicius 26

27 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

28 Emisor RDT/2.0 envio_rdt(datos) paqenv = empaq(datos,checksum) esperar llamada de arriba esperar por ACK/NAK esnak(paqrec) esack(paqrec) Redes de Computadoras - Mg. A. G. Stankevicius 28

29 Receptor RDT/2.0 corrupto(paqrec) paqenv = crearpaqnak() esperar llamada de abajo!corrupto(paqrec) paqenv = crearpaqack() datos = desempaq(paqrec) entregar(datos) Redes de Computadoras - Mg. A. G. Stankevicius 29

30 RDT/2.0 envío sin errores envio_rdt(datos) paqenv = empaq(datos,checksum) esperar llamada de arriba esack(paqrec) esperar por ACK/NAK esnak(paqrec) corrupto(paqrec) paqenv = crearpaqnak() esperar llamada de abajo!corrupto(paqrec) paqenv = crearpaqack() datos = desempaq(paqrec) entregar(datos) Redes de Computadoras - Mg. A. G. Stankevicius 30

31 RDT/2.0 envío con errores envio_rdt(datos) paqenv = empaq(datos,checksum) esperar llamada de arriba esack(paqrec) esperar por ACK/NAK esnak(paqrec) corrupto(paqrec) paqenv = crearpaqnak() esperar llamada de abajo!corrupto(paqrec) paqenv = crearpaqack() datos = desempaq(paqrec) entregar(datos) Redes de Computadoras - Mg. A. G. Stankevicius 31

32 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

33 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

34 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

35 Emisor RDT/2.1 envio_rdt(datos) paqenv = empaq(0,datos,checksum) (corrupto(paqrec) esnak(paqrec))!corrupto(paqrec) && esack(paqrec)) (corrupto(paqrec) esnak(paqrec)) esperar llamada 0 de arriba esperar por ACK/NAK 1 envio_rdt(datos) esperar por ACK/NAK 0 esperar llamada 1 de arriba!corrupto(paqrec) && esack(paqrec)) paqenv = empaq(1,datos,checksum) Redes de Computadoras - Mg. A. G. Stankevicius 35

36 Receptor RDT/2.1!corrupto(paqrec) && nrosec1(paqrec) paqenv = empaq(ack,checksum)!corrupto(paqrec) && nrosec0(paqrec) datos = desempaq(paqrec) entregar(datos) paqenv = empaq(ack,checksum) corrupto(paqrec) paqenv = empaq(nak,checksum) esperar llamada 0 de abajo esperar llamada 1 de abajo corrupto(paqrec) paqenv = empaq(nak,checksum)!corrupto(paqrec) && nrosec1(paqrec) datos = desempaq(paqrec) entregar(datos) paqenv = empaq(ack,checksum)!corrupto(paqrec) && nrosec0(paqrec) paqenv = empaq(ack,checksum) Redes de Computadoras - Mg. A. G. Stankevicius 36

37 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

38 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

39 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

40 Emisor RDT/2.2 envio_rdt(datos) paqenv = empaq(0,datos,checksum) (corrupto(paqrec) esack1(paqrec))!corrupto(paqrec) && esack1(paqrec)) (corrupto(paqrec) esack0(paqrec)) esperar llamada 0 de arriba esperar por ACK 1 esperar por ACK 0 esperar llamada 1 de arriba!corrupto(paqrec) && esack0(paqrec) envio_rdt(datos) paqenv = empaq(1,datos,checksum) Redes de Computadoras - Mg. A. G. Stankevicius 40

41 Receptor RDT/2.2!corrupto(paqrec) && nrosec0(paqrec) datos = desempaq(paqrec) entregar(datos) paqenv = empaq(0,ack,checksum) almenosunoenv = false (corrupto(paqrec) nrosec0(paqrec) paqenv = empaq(0,ack,checksum) almenosunoenv = true esperar llamada 0 de abajo esperar llamada 1 de abajo (corrupto(paqrec) nrosec1(paqrec)) if(!almenosunoenv) paqenv = empaq(1,ack,checksum)!corrupto(paqrec) && nrosec1(paqrec) datos = desempaq(paqrec) entregar(datos) paqenv = empaq(1,ack,checksum) Redes de Computadoras - Mg. A. G. Stankevicius 41

42 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

43 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

44 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

45 recep_rdt(paqrec)!corrupto(paqrec) && nrosec1(paqrec) sacar(alarma) disparo(alarma) poner(alarma) (corrupto(paqrec) nrosec0(paqrec)) Emisor RDT/3.0 envio_rdt(datos) paqenv = empaq(0,datos,checksum) poner(alarma) esperar llamada 0 de arriba esperar por ACK 1 envio_rdt(datos) esperar por ACK 0 esperar llamada 1 de arriba paqenv = empaq(1,datos,checksum) poner(alarma) (corrupto(paqrec) nrosec1(paqrec)) Redes de Computadoras - Mg. A. G. Stankevicius 45 disparo(alarma) poner(alarma)!corrupto(paqrec) && nrosec0(paqrec) sacar(alarma) recep_rdt(paqrec)

46 RDT/3.0 ideal emisor receptor envío paq. 0 recep. ACK 0 envío paq. 1 recep. ACK 1 envío paq. 0 recep. ACK 0 recep. paq. 0 envío ACK 0 recep. paq. 1 envío ACK 1 recep. paq. 0 envío ACK 0 Redes de Computadoras - Mg. A. G. Stankevicius 46

47 Pérdida de un paquete emisor receptor envío paq. 0 recep. ACK 0 envío paq. 1 disparo de alarma reenvío paq. 1 recep. ACK 1 paquete pérdido recep. paq. 0 envío ACK 0 recep. paq. 1 envío ACK 1 Redes de Computadoras - Mg. A. G. Stankevicius 47

48 Pérdida de un ACK emisor receptor envío paq. 0 recep. ACK 0 envío paq. 1 recep. paq. 0 envío ACK 0 recep. paq. 1 envío ACK 1 disparo de alarma reenvío paq. 1 recep. ACK 1 ACK pérdido recep. paq. 1 (duplicado detec.) reenvío ACK 1 Redes de Computadoras - Mg. A. G. Stankevicius 48

49 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. ACK 1 recep. paq. 0 (duplicado detec.) reenvío ACK 0 recep. paq. 1 envío ACK 1 Redes de Computadoras - Mg. A. G. Stankevicius 49

50 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

51 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. d trans = L (cantidad de bits) R (ancho de banda) = 8000 b = 8 microseg. 10^9 b/s u enlace = L/R RTT + L/R =.008 ms = 0.027% ms 1 paq. / 30 ms = 1 Gb/s x 0.027% = 33.3 KB/s Redes de Computadoras - Mg. A. G. Stankevicius 51

52 Operatoria stop-and-wait envío del primer bit (t = 0) envío del último bit (t = L/R) recep. del primer bit RTT recep. del último bit envío del ACK recep. del ACK (t = L/R + RTT) comienza el envío del sig. paq. u enlace = L/R RTT + L/R =.008 ms = 0.027% ms Redes de Computadoras - Mg. A. G. Stankevicius 52

53 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

54 Operatoria en pipeline envío del primer bit (t = 0) envío del último bit (t = L/R) RTT recep. del ACK, comienza el envío del sig. paq. (t = L/R + RTT) recep. del primer bit último bit 1er. paq. / envío ACK último bit 2do. paq. / envío ACK último bit 3er. paq. / envío ACK mejora la utilización por un factor de 3! u enlace = 3 x L/R RTT + L/R =.024 ms ms = 0.08% Redes de Computadoras - Mg. A. G. Stankevicius 54

55 Protocolo Go-Back-N El protocolo GBN implementa la operatoria en pipeline antes comentada. 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 enviados esperando ACK a ser enviados todavía no usables Redes de Computadoras - Mg. A. G. Stankevicius 55

56 Emisor GBN corrupto(paqrec) base = 1 proxnum = 1!corrupto(paqrec) base = nrosec(paqrec) + 1 if (proxnum == base) sacar(alarma) else poner(alarma) esperar llamada de arriba envio_rdt(datos) if(proxnum < base + N) { paqenv[proxnum] = empaq(proxnum, datos, checksum) envio_udt(paqenv[proxnum]) if (proxnum == base) poner(alarma) proxnum++ } 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 56

57 Receptor GBN!corrupto(paqrec) && (nrosec(paqrec) == proxnumreq) proxnumreq = 1 paqenv = empaq(0,ack,checksum) datos = desempaq(paqrec) entregar(datos) paqenv = empaq(proxnumreq, ACK, checksum) proxnumreq++ esperar llamada de abajo (corrupto(paqrec) (nrosec(paqrec)!= proxnumreq))) Redes de Computadoras - Mg. A. G. Stankevicius 57

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 58

59 GBN en acción envío paq. 1 envío paq. 2 envío paq. 3 recep. paq. 1, envío ACK 1 envío paq. 4 (agota la ventana) recep. paq. 2, envío ACK 2 recep. ACK 1, envío paq. 5 recep. ACK 2, envío paq. 6 disparo de alarma, reenvío paq. 3 reenvío paq. 4 reenvío paq. 5 reenvío paq. 6 recep. paq. 4 (se descarta) reenvío ACK 2 recep. paq. 5 (se descarta) reenvío ACK 2 recep. paq. 6 (se descarta) reenvío ACK 2 recep. paq. 3, envío ACK 3 recep. paq. 4, envío ACK 4 recep. paq. 5, envío ACK 5 recep. paq. 6, envío ACK 6 Redes de Computadoras - Mg. A. G. Stankevicius 59

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 60

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 61

62 Visión del emisor y receptor enviados, ACK ya recibido enviados, esperando ACK usables, a ser enviados no usables recibidos fuera de orden, ACK ya enviado a la espera, aún no recibidos aceptables no usables emisor SR ventana deslizante receptor SR ventana deslizante Redes de Computadoras - Mg. A. G. Stankevicius 62

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 del cual faltaba recibir confirmación, debe avanzar la ventana hasta el próximo paquete aún sin confirmar. Redes de Computadoras - Mg. A. G. Stankevicius 63

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 64

65 Protocolo SR en acción enviados conf. a la espera enviados no conf. usables fuera de orden no usables alarma paq Redes de Computadoras - Mg. A. G. Stankevicius 65

66 El dilema del receptor SR enviados conf. a la espera enviados no conf. usables fuera de orden no usables Redes de Computadoras - Mg. A. G. Stankevicius 66

67 El dilema del receptor SR enviados conf. a la espera enviados no conf. usables fuera de orden no usables alarma paq SR entrega un paquete fuera de orden! Redes de Computadoras - Mg. A. G. Stankevicius 67

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 68

69 Preguntas? Redes de Computadoras - Mg. A. G. Stankevicius 69