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

Copyright Copyright © 2010-2017 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comunicación confiable envio_rdt(): invocado desde arriba, suministra los datos a ser enviados entregar(): invocado por el protocolo para entregar los datos recibidos P1 P2 datos datos envio_rdt() entregar() protocolo rdt (emisor) protocolo rdt (receptor) envio_udt() recep_rdt() paquete paquete canal no confiable envio_udt(): invocado por el protocolo para transferir un paquete a través del canal no confiable recep_rdt(): invocado por el protocolo cuando llega un nuevo paquete al receptor Redes de Computadoras - Mg. A. G. Stankevicius

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

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

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

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

esperar llamada de arriba Emisor RDT/2.0 envio_rdt(datos) paqenv = empaq(datos,checksum) envio_udt(paqenv) esperar llamada de arriba esperar por ACK/NAK envio_udt(paqenv) recep_rdt(paqrec) && esNAK(paqrec)  recep_rdt(paqrec) && esACK(paqrec) Redes de Computadoras - Mg. A. G. Stankevicius

esperar llamada de abajo Receptor RDT/2.0 paqenv = crearpaqNAK() envio_udt(paqenv) recep_rdt(paqrec) && corrupto(paqrec) esperar llamada de abajo paqenv = crearpaqACK() envio_udt(paqenv) datos = desempaq(paqrec) entregar(datos) recep_rdt(paqrec) && !corrupto(paqrec) Redes de Computadoras - Mg. A. G. Stankevicius

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 paqenv = crearpaqNAK() envio_udt(paqenv) esperar llamada de abajo recep_rdt(paqrec) && esACK(paqrec)  recep_rdt(paqrec) && !corrupto(paqrec) paqenv = crearpaqACK() envio_udt(paqenv) datos = desempaq(paqrec) entregar(datos) Redes de Computadoras - Mg. A. G. Stankevicius

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 paqenv = crearpaqNAK() envio_udt(paqenv) esperar llamada de abajo recep_rdt(paqrec) && esACK(paqrec)  recep_rdt(paqrec) && !corrupto(paqrec) paqenv = crearpaqACK() envio_udt(paqenv) datos = desempaq(paqrec) entregar(datos) Redes de Computadoras - Mg. A. G. Stankevicius

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

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

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

(corrupto(paqrec) || esNAK(paqrec)) Emisor RDT/2.1 paqenv = empaq(0,datos,checksum) envio_udt(paqenv) envio_rdt(datos) envio_udt(paqenv) recep_rdt(paqrec) && (corrupto(paqrec) || esNAK(paqrec)) esperar llamada 0 de arriba esperar por ACK/NAK 0 ACK/NAK 1 esperar llamada 1 de arriba  recep_rdt(paqrec) && !corrupto(paqrec) && esACK(paqrec))  recep_rdt(paqrec) && !corrupto(paqrec) && esACK(paqrec)) envio_udt(paqenv) recep_rdt(paqrec) && (corrupto(paqrec) || esNAK(paqrec)) paqenv = empaq(1,datos,checksum) envio_udt(paqenv) envio_rdt(datos) Redes de Computadoras - Mg. A. G. Stankevicius

Receptor RDT/2.1 Redes de Computadoras - Mg. A. G. Stankevicius 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) recep_rdt(paqrec) && !corrupto(paqrec) && nrosec1(paqrec) paqenv = empaq(NAK,checksum) envio_udt(paqenv) recep_rdt(paqrec) && corrupto(paqrec) esperar llamada 0 de abajo esperar llamada 1 de abajo paqenv = empaq(NAK,checksum) envio_udt(paqenv) recep_rdt(paqrec) && corrupto(paqrec) paqenv = empaq(ACK,checksum) envio_udt(paqenv) recep_rdt(paqrec) && !corrupto(paqrec) && nrosec0(paqrec) datos = desempaq(paqrec) entregar(datos) paqenv = empaq(ACK,checksum) envio_udt(paqenv) recep_rdt(paqrec) && !corrupto(paqrec) && nrosec1(paqrec) Redes de Computadoras - Mg. A. G. Stankevicius

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

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

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

(corrupto(paqrec) || esACK1(paqrec)) Emisor RDT/2.2 paqenv = empaq(0,datos,checksum) envio_udt(paqenv) envio_rdt(datos) envio_udt(paqenv) recep_rdt(paqrec) && (corrupto(paqrec) || esACK1(paqrec)) esperar llamada 0 de arriba esperar por ACK 0 ACK 1 esperar llamada 1 de arriba  recep_rdt(paqrec) && !corrupto(paqrec) && esACK1(paqrec))  recep_rdt(paqrec) && !corrupto(paqrec) && esACK0(paqrec) envio_udt(paqenv) recep_rdt(paqrec) && (corrupto(paqrec) || esACK0(paqrec)) paqenv = empaq(1,datos,checksum) envio_udt(paqenv) envio_rdt(datos) Redes de Computadoras - Mg. A. G. Stankevicius

Receptor RDT/2.2  Redes de Computadoras - Mg. A. G. Stankevicius 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) recep_rdt(paqrec) && (corrupto(paqrec) || nrosec0(paqrec) almenosunoenv = true  esperar llamada 0 de abajo esperar llamada 1 de abajo if(!almenosunoenv) paqenv = empaq(1,ACK,checksum) envio_udt(paqenv) recep_rdt(paqrec) && (corrupto(paqrec) || nrosec1(paqrec)) datos = desempaq(paqrec) entregar(datos) paqenv = empaq(1,ACK,checksum) envio_udt(paqenv) recep_rdt(paqrec) && !corrupto(paqrec) && nrosec1(paqrec) Redes de Computadoras - Mg. A. G. Stankevicius

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

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

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

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

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

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

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. L/R .008 ms uenlace= = = 0.027% RTT + L/R 30.008 ms Redes de Computadoras - Mg. A. G. Stankevicius

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

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! 3 x L/R .024 ms uenlace= = = 0.08% RTT + L/R 30.008 ms Redes de Computadoras - Mg. A. G. Stankevicius

Operatoria en pipeline Go-back N (GBN) El emisor puede tener hasta n paquetes aun sin confirmar. El receptor sólo envía ACKs acumulativos (¡no tolera huecos!). El emisor sólo requiere un temporizador para el paquete más antiguo sin reconocer. Selective Repeat (SR) El emisor puede tener hasta n paquetes aun sin confirmar. El receptor envía ACKs individuales para cada paquete. El emisor mantiene un temporizador para paquete aun no reconocido. Redes de Computadoras - Mg. A. G. Stankevicius

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 enviados esperando ACK a ser enviados todavía no usables Redes de Computadoras - Mg. A. G. Stankevicius

envio_udt(paqenv[proxnum - 1]) Emisor GBN envio_rdt(datos) if(proxnum < base + N) { paqenv[proxnum] = empaq(proxnum, datos, checksum) envio_udt(paqenv[proxnum]) if (proxnum == base) poner(alarma) proxnum++ } else rechazar(datos)  base = 1 proxnum = 1 recep_rdt(paqrec) && corrupto(paqrec)  esperar llamada de arriba disparo(alarma) poner(alarma) envio_udt(paqenv[base]) envio_udt(paqenv[base + 1]) ¼ envio_udt(paqenv[proxnum - 1]) recep_rdt(paqrec) && !corrupto(paqrec) base = nrosec(paqrec) + 1 if (proxnum == base) sacar(alarma) else poner(alarma) Redes de Computadoras - Mg. A. G. Stankevicius

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

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

GBN en acción 1 2 3 4 5 6 7 envío paq. 0 1 2 3 4 5 6 7 envío paq. 1 1 2 3 4 5 6 7 envío paq. 2 recep. paq. 0, envío ACK 0 1 2 3 4 5 6 7 envío paq. 3 recep. paq. 1, envío ACK 1 recep. paq. 3 (se descarta) reenvío ACK 1 1 2 3 4 5 6 7 rec. ACK 1, env. paq. 4 rec. ACK 2, env. paq. 5 1 2 3 4 5 6 7 recep. paq. 4 (se descarta) reenvío ACK 1 1 2 3 4 5 6 7 reenvío paq. 2 recep. paq. 5 (se descarta) reenvío ACK 1 1 2 3 4 5 6 7 reenvío paq. 3 1 2 3 4 5 6 7 reenvío paq. 4 recep. paq. 2, envío ACK 2 reenvío paq. 5 1 2 3 4 5 6 7 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

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

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

Visión del emisor y receptor enviados, ACK ya recibido recibidos fuera de orden, ACK ya enviado enviados, esperando ACK 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

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

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

Protocolo SR en acción enviados conf. enviados no conf. fuera de orden a la espera usables no usables 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 alarma paq. 2 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 Redes de Computadoras - Mg. A. G. Stankevicius

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

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

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

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