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