Tema III: El nivel de transporte en Internet

Tema III: El nivel de transporte en Internet
Luis López Fernández 2005

Conocimientos previos
Conocimientos adquiridos fuera de la asignatura Conocimientos básicos sobre sistemas operativos Conocimientos básicos sobre lenguajes de programación (sintaxis y semántica) Conveniente conocimientos básicos del lenguaje Java y del lenguaje C Capacidad de lectura de textos en el idioma inglés Conocimientos adquiridos en el contexto de la asignatura Contar con unas nociones básicas sobre arquitectura de redes de ordenadores Comprender el concepto de protocolo Comprender el concepto de servicio Conocer los modelos de referencia OSI, TCP/IP e híbrido Conocer los servicios prestados por la capa de transporte en los modelos de referencia Conocer los servicios prestados por la capa de red en los modelos de referencia Conocer la arquitectura básica de Internet Conocer los requisitos que se imponen a la interfaz de la capa de transporte Tema III: El nivel de transporte en Internet

Tema III: Contenidos Lección 3.1: Protocolos y servicios del nivel de transporte 3.1.1 El nivel de transporte Vs el nivel de red en Internet 3.1.2 Servicios ofrecidos por el nivel de transporte en Internet Lección 3.2: El protocolo UDP 3.2.1 El servicio UDP y el protocolo UDP 3.2.2 RTP como ejemplo de protocolo que utiliza los servicios de UDP Lección 3.3: Transmisión fiable de datos 3.3.1 Transmisión fiable: una visión software 3.3.2 Protocolos básicos para la transmisión fiable de datos 3.3.3 Protocolos de ventana deslizante Lección 3.4: El protocolo TCP 3.4.1 Formato del segmento TCP 3.4.2 Ciclo de vida de la conexión TCP 3.4.3 Gestión de temporizadores TCP Lección 3.5: Control de congestión 3.5.1 Conceptos básicos sobre congestión y colas 3.5.2 Control de la congestión en TCP 3.5.3 Reparto equitativo de recursos y TCP Tema III: El nivel de transporte en Internet

Introducción: Transporte y red
Ofrece un servicio de comunicación de extremo-a-extremo (end-to-end) Se ocupa de el nivel de aplicación vea “la red” como “un cable” Utiliza los servicios del nivel de red para el envío de paquetes Aplicación Transporte Ofrece un servicio de envío de paquetes no fiable (los paquetes pueden perderse) Se ocupa de que cada paquete sea encaminado de manera apropiada hacia su destino El servicio no es orientado a conexión (cada paquete debe contener la dirección de destino) Red Enlace Física Servicio ofrecido por el nivel de red Tema III: El nivel de transporte en Internet

Protocolos y servicios del nivel de transporte
Objetivo Proporcionar un “canal lógico” entre procesos de aplicación que residen en diferentes nodos de la red Las propiedades de ese “canal lógico” dependen del protocolo utilizado y de las características de los servicios ofrecidos por el nivel de red Función Hacer que la red sea “invisible” para el nivel de aplicación Los protocolos del nivel de transporte se ejecutan en los extremos de la comunicación (sistemas finales) Extremo de envío: Parte los mensajes de aplicación en segmentos que son enviados al nivel de red Extremo de recepción: Recupera los segmentos del nivel de red y los ensambla formando mensajes para el nivel de aplicación aplicación transp. red enlace físico aplicación Transp. red enlace físico Tema III: El nivel de transporte en Internet

El nivel de transporte frente al nivel de red
El nivel de red Se ocupa de enviar los paquetes desde el nodo que los origina hasta el nodo que debe recibirlos Utiliza un mecanismo de direccionamiento (dirección IP) para determinar los nodos origen y destino Todo paquete debe contener la dirección IP de su nodo origen y la dirección IP de su nodo destino Analogía Imaginemos que queremos enviar un documento muy grande (p.e. 500 páginas) a través de correo postal tradicional no certificado Podemos enviar una página en cada sobre Cada sobre contiene la dirección del destinatario Cada sobre es enviado de manera independiente Se pueden perder o retrasar envíos No podemos garantizar que el envío del documento sea satisfactorio 1 2 . red enlace físico aplicación transp. red enlace físico . red enlace físico . red enlace físico 3 4 3 … 500 . red enlace físico . red enlace físico aplicación Transp. red enlace físico . red enlace físico … Tema III: El nivel de transporte en Internet

El nivel de transporte frente al nivel de red
Se ocupa de mejorar las propiedades del servicio ofrecido por el nivel de red Puede ofrecer un servicio orientado a conexión, en el que el nivel de aplicación percibe la red como si fuese un canal (cable) dedicado Analogía Imaginemos que queremos enviar un documento muy grande (p.e. 500 páginas) a través de correo postal tradicional no certificado El servicio de transporte es como dos secretarias que se encuentran en los extremos receptores y emisores Se ocupan de meter en los sobres las páginas Se ocupan de enviarlas al nivel de red Se ocupan de ordenar los sobres de llegan desordenados Se ocupan de que se repitan los envíos de sobres perdidos Necesitan un acuerdo previo (establecimiento de conexión) 1 2 aplicación transp. red enlace físico 3 4 … 500 1 aplicación Transp. red enlace físico 2 3 4 … 500 Tema III: El nivel de transporte en Internet

Protocolos de nivel de transporte en Internet
El protocolo TCP (Transmission Control Protocol) Servicio TCP Orientado a conexión: Requiere el establecimiento de conexión entre los dos extremos Transporte fiable: Toda información enviada por el emisor es recibida por el receptor en el mismo orden Control de flujo: El emisor no saturará a un receptor más lento Control de congestión: El emisor bajará su tasa si se detecta congestión en la red No proporciona Garantías de temporización Garantías de ancho de banda El protocolo UDP (User Datagram Protocol) Servicio UDP Transporte no fiable de datagramas: Los datagramas emitidos por el emisor podrán alcanzar eventualmente el receptor No proporciona Servicio orientado a conexión Transporte fiable Control de flujo Control de congestión Garantías de temporización Garantías de ancho de banda ¿Es UDP igual que IP? ¿Por qué existe el servicio UDP? Tema III: El nivel de transporte en Internet

Multiplexación y demultipleación
La capa de transporte es la responsable de la multiplexación y demultiplexación Consiste en la conversión del servicio de entrega de paquetes host a host, proporcionado por la capa de red, en un servicio de entrega proceso a proceso La multiplexación y demultiplexación se realiza a través de los sockets Cuando un paquete sale del host origen, este se entrega al socket apropiado Cuando un paquete llega al host destino, este se entrega al socket apropiado El socket actúa como intermediario entre el proceso y la capa de transporte = socket = proceso aplicación transporte red enlace física aplicación transporte red enlace física aplicación transporte red enlace física P4 P3 P1 P1 P2 host 3 host 1 host 2 Tema III: El nivel de transporte en Internet

Multiplexación y demultiplexación cont.
Se realiza en emisión Se reúnen los datos de los diferentes sockets y se entregan al nivel de transporte (que es único) Se debe incluir la información necesaria para la demultiplexación Demultiplexación: Se realiza en recepción Se extraen los segmentos del nivel de transporte y se entregan al socket apropiado Utiliza la información incluida por el emisor para realizarlo P1 P2 P3 P4 P5 P6 transporte transporte red red enlace enlace Internet física física host 1 host 2 Tema III: El nivel de transporte en Internet

Cómo funciona la demultiplexación
La capa de transporte utiliza un identificador denominado puerto para realizar la demultiplexación Cada socket está asociado a un número de puerto El número de puerto de origen estará asociado con el socket que genera el segmento El número de puerto de destino estará asociado con el socket que recibe el segmento Datos de aplicación Nivel de aplicación Socket Envío de datos Puerto origen Puerto destino Otros Campos Tx Datos Appl. Nivel de transporte IP origen IP destino Otros Campos red Puerto origen Puerto destino Otros Campos Tx Datos Appl. Nivel de red Niveles inferiores Tema III: El nivel de transporte en Internet

Cómo funciona la demultiplexación
La capa de transporte utiliza un identificador denominado puerto para realizar la demultiplexación Cada socket está asociado a un número de puerto El número de puerto de origen estará asociado con el socket que genera el segmento El número de puerto de destino estará asociado con el socket que recibe el segmento Datos de aplicación Nivel de aplicación Socket Recepción de datos Puerto origen Puerto destino Otros Campos Tx Datos Appl. Nivel de transporte IP origen IP destino Otros Campos red Puerto origen Puerto destino Otros Campos Tx Datos Appl. Nivel de red Niveles inferiores Tema III: El nivel de transporte en Internet

Números de puerto en Internet
El número de puerto es un entero de 16 bits ( ) Los segmentos TCP y UDP contienen un puerto de origen y un puerto de destino TCP y UDP tienen numeración de puertos independiente Todo socket con capacidad de enviar – recibir datos debe estar asociado a un puerto Los números de puerto están restringidos (well-known ports) Están reservados para protocolos de aplicación bien conocidos La lista de números de puerto bien conocido se encuentra en RFC 1700 Actualizada en [RFC 3232] Ejemplos HTTP: 80/TCP FTP: 21/TCP SMTP: 25/TCP DNS: 53/TCP, 53/UDP SSH: 22/TCP TELNET: 23/TCP Tema III: El nivel de transporte en Internet

Multiplexación y demultiplexación sin conexión
Cuando trabajamos con UDP no hay noción de conexión Para crear un socket con capacidad de envío – recepción basta con asignarle un puerto Ejemplo java: DatagramSocket miSocket = new DatagramSocket(); Asignación de un puerto libre entre 1024 y 65535 DatagramSocket miSocket = new DatagramSocket(19157); Asignación del puerto si no está ocupado por otro socket Todo socket UDP queda completamente identificado por el par (dirección IP destino, número puerto destino) Cuando en un host se recibe un datagrama UDP - Se recupera el puerto de destino - Se envía el datagrama al socket asociado al puerto de destino La dirección IP de origen y el puerto de origen no son utilizados para realizar la demultiplexación La dirección IP de origen y el puerto de origen se incluyen en los paquetes para proporcionar una dirección de respuesta (remitente) al proceso receptor Tema III: El nivel de transporte en Internet

Demultiplexación sin conexión
DatagramSocket serverSocket = new DatagramSocket(6428); Cliente IP:B P2 IP: A P1 P3 servidor IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 DP: 5775 SP: 5775 SP: Source port DP: Destination port Tema III: El nivel de transporte en Internet

Multiplexación y demultiplexación orientado a conexión
Cuando trabajamos con TCP tenemos una noción de conexión Para disponer de un socket con capacidad de envío – recepción hay que Crearlo asignándolo un puerto Conectarlo a un socket remoto (que tendrá su propio puerto) Ejemplo java: Socket miSocket = new Socket(“nombre de host”, 6789); Creamos un nuevo socket asignándole un puerto libre entre y lo conectamos a un socket remoto que se encuentra en el host indicado y en el puerto 6789 Socket miSocket = socketServidor.accept(); Creamos un nuevo socket asignádole el mismo puerto que el socketServidor y lo conectamos con el socket remoto que ha solicitado la conexión Todo socket TCP queda completamente identificado por una tupla de 4 elementos (dirección IP origen, número puerto origen, dirección IP destino, número puerto destino) Cada socket con capacidad de envío – recepción queda entonces asociado con una conexión establecida (que queda definida a partir de sus dos puntos terminales) Tema III: El nivel de transporte en Internet

Multiplexación y demultiplexación orientado a conexión cont.
Por tanto, pueden existir varios sockets TCP asignados al mismo puerto en un mismo host, siempre y cuando estos sockets pertenezcan a conexiones distintas: Ejemplo: Un servidor HTTP Un primer cliente (sckCli1.port = 5775) se conecta al servidor (sckSer1.port = 80) Un segundo cliente (sckCli1.port = 9157) se conecta al servidor (sckSer2.port = 80) Etc. P2 Cliente IP: A P3 P4 P1 P1 SP: 80 DP: 9157 SP: 80 DP: 5775 SP: 9157 SP: 5775 DP: 80 DP: 80 servidor IP: C Cliente IP:B Tema III: El nivel de transporte en Internet

Multiplexación y demultiplexación orientado a conexión cont.
Hemos descrito cómo se realiza la multiplexación en sockets que actúan como extremo de una conexión Existe otro tipo de socket TCP cuyo funcionamiento es sensiblemente diferente Sockets de escucha y aceptación Estos sockets no pueden funcionar como extremo de una conexión Escuchan esperando solicitudes de conexión de sockets remotos Al recibirlas, crean un nuevo socket (con su mismo puerto) y establecen la conexión entre el socket remoto y el recién creado Los sockets de escucha y aceptación quedan determinados por el par (dirección IP destino, número puerto destino) Tema III: El nivel de transporte en Internet

Lección 3.1: Comentarios y referencias
Comentarios y reflexiones Existe un tipo de tecnología de conmutación de paquetes que se denomina de “circuito virtual”. Investigue las diferencias entre esa tecnología y la de conmutación de paquetes habitual. ¿En qué se diferenciará el nivel de transporte asociado a dicha tecnología y el básico de Internet? El sistema operativo ofrece mecanismos para averiguar en qué puertos se encuentran escuchando sockets a la espera de recibir solicitudes de conexión. Utilice dicho mecanismo para averiguar qué puertos están ocupados en su ordenador. Trate de crear un nuevo socket que “escuche” sobre un puerto ya ocupado y observe lo que sucede. ¿Por qué? Decimos que TCP ofrece un servicio “fiable” de transferencia de datos. Reflexione sobre el significado de la palabra “fiable” en este contexto. ¿Se puede garantizar que toda información que ha salido del emisor llegará, tarde o temprano al emisor? ¿Se puede garantizar que si una parte de la información ha llegado, el resto llegará tarde o temprano? Referencias Redes de Computadores. Andrew S. Tanenbaum. Prentice Hall, Cuarta Edición, 2003 Capítulo 6: La Capa de Transporte Redes de Computadores, un enfoque descendente basado en Internet. James F. Kurose y Keith W. Ross. Addison Wesley, Segunda Edición, 2003 Capítulo 3: La Capa de Transporte Tema III: El nivel de transporte en Internet

Lección 3.1: Resumen Contenidos El nivel de transporte frente al nivel de red El nivel de red como servicio insuficiente Servicios y protocolos del nivel de transporte Protocolos del nivel de transporte en Internet Multiplexación y demultiplexación Números de puerto Demultiplexación sin conexión Demultiplexación con conexión ¿Qué hemos aprendido? ¿Por qué decimos que TCP es un protocolo de “extremo a extremo”? ¿Qué aporta TCP frente a IP y por qué es necesario añadirlo? ¿Qué son los puertos TCP y UDP y para qué sirven? ¿En qué se basa la multiplexación y demultiplexación de paquetes? ¿Cómo decide el S.O. a qué socket TCP debe entregar el contenido de un paquete? ¿Cómo decide el S.O. a qué socket UDP debe entregar el contenido de un paquete? ¿Puede haber varios sockets asociados a un mismo puerto en un mismo host? Tema III: El nivel de transporte en Internet

El protocolo UDP Las aplicaciones de red pueden tener objetivos muy variados Pueden requerir servicios de transporte también diversos Servicio TCP: Transporte fiable orientado a conexión “best effort” Sin garantías en la temporización Sin garantías en el ancho de banda Sin garantías de atomicidad ante fallos de red o en los nodos ¿Qué sucede si nos interesa un protocolo de transporte con otras propiedades? El protocolo UDP (User Datagram Protocol) [RFC 768]: Protocolo de Datagramas de Usuario Nos ofrece una interfaz sencilla para poder desarrollar protocolos basados en el concepto de la conmutación de paquetes UDP = IP + Multiplexación/Demultiplexación Servicio no orientado a conexión Se pueden perder paquetes Se pueden desordenar paquetes Tema III: El nivel de transporte en Internet

¿Por qué usar UDP? UDP tiene propiedades que lo hacen interesante frente a TCP para algunas aplicaciones No hay establecimiento de conexión  se evita el retardo asociado Emisores y receptores simples  ocupan pocos recursos del sistema en términos de memoria y CPU Añade una cabecera pequeña (8 bytes)  añade menos sobrecarga en los paquetes No impone ningún mecanismo de control de congestión  los flujos de datos pueden seguir patrones de tiempo más flexibles y adaptables La unidad de transferencia (el datagrama) es atómica y visible por el desarrollador  mejor adaptado cuando la aplicación tiene requisitos transaccionales Tema III: El nivel de transporte en Internet

Estructura de la cabecera UDP
Cada datagrama UDP tiene la estructura siguiente: Cabecera (8 bytes) Datos ( 0 o más bytes) El tamaño máximo del datagrama puede venir limitado por el tamaño máximo del paquete IP (en cuyo caso, se podrían incluir hasta bytes de datos) El tamaño máximo puede venir limitado por la tecnología de enlace que se utilice Vamos a analizar cada uno de los campos de la cabecera fija del datagrama UDP detalladamente 32 bits Puerto de origen Puerto de destino Longitud UDP Suma comprobación Datos Tema III: El nivel de transporte en Internet

Puerto de origen y Puerto de destino (16 bits) El puerto de origen y el puerto de destino son la parte de la dirección de red que identifica a un proceso dentro de un host Como ya hemos visto en la introducción, el puerto de destino es utilizado por UDP para demultiplexar los datagramas que se reciben en un host De este modo, los diferentes datagramas que se reciben se pueden enviar al socket UDP apropiado El puerto de origen sólo será utilizado para responder al socket UDP que emitió el datagrama. 32 bits Puerto de origen Puerto de destino Longitud UDP Suma comprobación Datos Tema III: El nivel de transporte en Internet

Longitud UDP (16 bits) Indica la longitud del datagrama UDP en bytes incluyendo la cabecera y los datos Por tanto, su valor mínimo debe ser 8 32 bits Puerto de origen Puerto de destino Longitud UDP Suma comprobación Datos Tema III: El nivel de transporte en Internet

Suma de comprobación (16 bits) Es un campo opcional Si no se calcula, se almacena como cero Sólo suele desactivarse cuando un paquete perdido es más dañino que un paquete corrompido (p.e. voz digitalizada) Se proporciona una suma de comprobación para mejorar la confiabilidad La suma de comprobación se calcula utilizando el encabezado, los datos y un pseudoencabezado conceptual que contiene información adicional | Dirección origen | | Dirección destino | | cero | Proto. | Long. UDP | Este pseudoencabezado tiene por objetivo detectar segmentos que hayan sido encaminados de manera incorrecta 32 bits Puerto de origen Puerto de destino Longitud UDP Suma comprobación Datos Tema III: El nivel de transporte en Internet

Suma de comprobación (16 bits) Se calcula del modo siguiente: Se ponen en secuencia: el pseudoencabezado, la cabecera UDP (con suma de comprobación de cero) y los datos Se rellena el campo de datos con un byte a cero adicional si el número de bytes del segmento es impar. Ese byte adicional no se transmite, sólo se usa para trabajar con palabras de 16 bits. Se suman todas las palabras de 16 bits de la secuencia en complemento a 1 La suma de comprobación es el complemento a 1 del resultado así obtenido En el receptor, la suma de comprobación se utiliza para detectar errores de transmisión. Para ello, se realiza un cálculo equivalente en el receptor, pero ahora incluyendo la suma de comprobación recibida (en vez ceros) Si no hay errores en la transmisión, el resultado obtenido debe ser 0 32 bits Puerto de origen Puerto de destino Longitud UDP Suma comprobación Datos Tema III: El nivel de transporte en Internet

Ejemplo de un protocolo basado en UDP: RTP
RTP (Protocolo de Tiempo Real - Real Time Protocol) Se describe en la RFC 1889 Es un protocolo de transporte de datos con restricciones de tiempo real Se utiliza ampliamente en aplicaciones multimedia Aunque es un protocolo de transporte (no está directamente asociado a ninguna aplicación concreta) se ubica en espacio de usuario Es decir, RTP utiliza sockets para acceder a los servicios de UDP Aplicación Espacio de usuario RTP Sockets UDP Kernel del S.O. IP Niveles Inferiores Tema III: El nivel de transporte en Internet

Id. origen sincronización Id. origen contribución
La cabecera RTP La cabecera RTP tiene la estructura que aparece en la figura Ver: Versión del protocolo (la 2 actualmente) P: Indica que el paquete se ha rellenado a un múltiplo de 4 bytes X: Hay una cabecera de extensión. El formato y significado de la extensión no se definen. Lo único que se define es que la primera palabra de la extensión proporciona la longitud CC: Indica el número de orígenes de contribución que están presentes (de 0 a 15) M: Es un marcador específico de la aplicación (la aplicación lo puede usar como desee). Por ejemplo, puede indicar el comienzo de un nuevo cuadro de vídeo, etc. Tipo de carga útil: Indica la codificación de los datos del paquete RTP Número de secuencia: Se incrementa en cada paquete enviado Los otros campos los explicamos en más detalle a continuación 32 bits Tipo carga útil Ver P X CC M Número secuencia Marca de tiempo Id. origen sincronización Id. origen contribución Tema III: El nivel de transporte en Internet

Funcionamiento de RTP RTP multiplexa varios flujos de datos de tiempo real en un solo flujo UDP El flujo UDP resultante puede Ser enviado a un solo destino (unidifusión) Ser enviado a múltiples destinos (multidifusión) Cada paquete RTP lleva un número de secuencia que se incrementa De este modo se pueden detectar pérdidas de paquetes Si se produce alguna pérdida NO hay repetición El receptor puede tratar de “interpolar” los datos que a perdido desde su entorno Cada paquete RTP indica el mecanismo de codificación de sus datos PCM de 8 bits MP3 GSM etc Tema III: El nivel de transporte en Internet

Funcionamiento de RTP. Cont.
En RTP, los paquetes llevan una marca de tiempo La marca de tiempo es relativa al origen del flujo Indica el instante de tiempo asociado a la primera muestra del paquete El objetivo de la marca de tiempo es doble Reducir los efectos de la fluctuación (jitter) Gracias a ella el receptor sabe en qué momento tiene que “reproducir” cada paquete Esto permite la utilización de un buffer de compensación de la fluctuación Sincronizar varios flujos Las aplicaciones multimedia pueden contar con diversos flujos Vídeo + dos canales de audio Vídeo + 8 canales de audio Las marcas de tiempo permiten sincronizar la reproducción de todos los flujos Incluso si los flujos se transmiten de manera irregular Tema III: El nivel de transporte en Internet

Funcionamiento de RTP. Cont.
La demultiplexación se realiza a través de un identificador de 32 bits: Campo: identificador de origen de sincronización Cada uno de los flujos que se transmiten por el mismo socket UDP tiene un valor de este campo distinto. Por ejemplo Vídeo Audio Audio estéreo Audio en varios idiomas El campo identificador de origen de contribución se utiliza para mezclar flujos Si dos o más flujos deben mezclarse, se listan en los campos reservados a tal efecto Tema III: El nivel de transporte en Internet

Funcionamiento de RTP: Ejemplo
Ejemplo de aplicación multimedia con vídeo y audio Flujo de Vídeo Flujo de audio

Establecemos un origen de tiempos común a todos los flujos Flujo de Vídeo Origen de tiempos en el emisor Flujo de audio

Muestreamos, codificamos y convertimos los flujos en una secuencia de paquetes T0 T1 T2 T3 Tiempo Origen de tiempos en el emisor t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

Los paquetes se envían por RTP incluyendo su marca de tiempos y su identificador T0 T1 T2 T3 Tiempo Flujo RTP vídeo UDP IP Etc. Socket UDP Origen de tiempos en el emisor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

Los paquetes se reciben, se demultiplexan y se almacenan en un búfer de compensación T0 T1 T2 T3 Tiempo Flujo RTP vídeo UDP IP Etc. Socket UDP Origen de tiempos en el emisor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 Flujo RTP vídeo Etc. UDP IP Socket UDP Flujo RTP audio

Cuando la aplic. receptora lo considera oportuno, empieza a reproducir T0 T1 T2 T3 Tiempo Flujo RTP vídeo UDP IP Etc. Socket UDP Origen de tiempos en el emisor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 T0 T1 T2 T3 Tiempo Flujo RTP vídeo Etc. UDP IP Socket UDP Origen de tiempos en el receptor Flujo RTP audio t0 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

Los paquetes se van reproduciendo respetando el origen de tiempos del receptor T0 T1 T2 T3 Tiempo Flujo RTP vídeo UDP IP Etc. Socket UDP Origen de tiempos en el emisor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 T0 T1 T2 T3 Tiempo Flujo RTP vídeo Etc. UDP IP Socket UDP Origen de tiempos en el receptor Flujo RTP audio t0 t1 t2 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

Los paquetes se van reproduciendo respetando el origen de tiempos del receptor T0 T1 T2 T3 Tiempo Flujo RTP vídeo UDP IP Etc. Socket UDP Origen de tiempos en el emisor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 T0 T1 T2 T3 Tiempo Flujo RTP vídeo Etc. UDP IP Socket UDP Origen de tiempos en el receptor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

La emisión, recepción y reproducción puede continuar con el desfase que añaden los búferes T0 T1 T2 T3 Tiempo Flujo RTP vídeo UDP IP Etc. Socket UDP Origen de tiempos en el emisor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 T0 T1 T2 Tiempo Flujo RTP vídeo Etc. UDP IP Socket UDP Origen de tiempos en el receptor Flujo RTP audio t0 t1 t2 t3 t4 t5 t6 t7 t8 t9

El protocolo de control de RTP: RTCP
RTP viene acompañado de un protocolo de control que se denomina RTCP (Real Time Control Protocol) Solo transporta información de control, no transporta datos “útiles” Ofrece un mecanismo de realimentación que permite informar al emisor sobre Retardos Fluctuaciones Ancho de banda disponible Presencia de congestión Esta información puede utilizarla el emisor para adaptarse a las condiciones de la red de modo que se proporcione el mejor servicio posible RTCP también proporciona un servicio de sincronización de relojes De este modo, flujos diferentes con diferentes relojes (granularidades, derivas, etc), pueden compartir una referencia común Tema III: El nivel de transporte en Internet

Comentarios y reflexiones Uno de los problemas más relevantes en las redes de conmutación de paquetes es el de la congestión. TCP ofrece mecanismos para el control de congestión en Internet, pero UDP no. ¿Cree que esto supone algún problema? Si tenemos dos flujos TCP compitiendo por una misma línea, el protocolo TCP garantiza que los recursos se comparten de manera equitativa entre ambos. Si son dos flujos UDP, ¿cuál de los dos se llevará más recursos? ¿Es positivo este resultado? UDP suele utilizarse como protocolo de preferencia para implementar mecanismos cliente servidor RPC (Remote Procedure Call) ¿Por qué? A la hora de obtener un servicio multimedia de gran calidad en Internet ¿qué papel desempeña lo que sucede en el nivel de transporte y qué papel desempeña lo que sucede en el nivel de red? Referencias Redes de Computadores. Andrew S. Tanenbaum. Prentice Hall, Cuarta Edición, 2003 Capítulo 6: La Capa de Transporte Redes de Computadores, un enfoque descendente basado en Internet. James F. Kurose y Keith W. Ross. Addison Wesley, Segunda Edición, 2003 Capítulo 3: La Capa de Transporte Tema III: El nivel de transporte en Internet

Lección 3.2: Resumen Contenidos El protocolo UDP Servicios UDP Formato del datagrama UDP RTP como ejemplo de protocolo basado en UDP Formato de la cabecera RTP Funcionamiento de RTP Ejemplo de funcionamiento RTP RTCP ¿Qué hemos aprendido? ¿Por qué decimos que TCP es un protocolo de “extremo a extremo”? ¿Qué aporta TCP frente a IP y por qué es necesario añadirlo? ¿Qué son los puertos TCP y UDP y para qué sirven? ¿En qué se basa la multiplexación y demultiplexación de paquetes? ¿Cómo decide el S.O. a qué socket TCP debe entregar el contenido de un paquete? ¿Cómo decide el S.O. a qué socket UDP debe entregar el contenido de un paquete? ¿Puede haber varios sockets asociados a un mismo puerto en un mismo host? Tema III: El nivel de transporte en Internet

Transmisión fiable de datos: problema
Disponemos de un servicio de envío de paquetes no fiable Queremos un servicio de envío de mensajes fiable (sin pérdidas, en orden) Aparece en: Capa de aplicación (usando servicio UDP no fiable) Capa de transporte (usando servicio IP no fiable) Capa de enlace (usando servicio nivel físico no fiable) emisor receptor Capa superior que requiere el servicio fiable emisor receptor tfd_enviar( ) tfd_recibir( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) Capa intermedia que implementa el servicio fiable tnd_enviar( ) tnd_recibir( ) tnd_enviar( ) tnd_recibir( ) Capa inferior que proporciona el servicio no fiable canal no fiable canal no fiable Tema III: El nivel de transporte en Internet

Principios de la transmisión fiable de datos
Es uno de los problemas de mayor relevancia en el ámbito de la telemática El protocolo a implementar depende de las características del canal no fiable Objetivo: ofrecer un servicio de transporte fiable de datos a la capa superior Implementación del servicio Servicio fiable emisor receptor emisor receptor tfd_enviar( ) tfd_recibir( ) tfd_enviar( ) tfd_recibir( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) canal lógico fiable tnd_enviar( ) tnd_recibir( ) canal no fiable Tema III: El nivel de transporte en Internet

Primitivas de servicio
tfd_enviar( ): Servicio de Transporte Fiable de Datos (tfd). La capa superior llama a este servicio para enviar datos tfd_evento_enviar( ): Función de la capa que implementa el protocolo fiable. Se desbloquea cuando la capa superior envía datos tnd_enviar( ): Servicio de Transporte No fiable de Datos (tnd) que ofrece la capa inferior tnd_evento_enviar( ): Función de la capa inferior que se desbloquea cuando hay un paquete que enviar entregar_paquete( ): Función que la capa inferior invoca cuando se recibe un paquete del canal tnd_recibir( ): Función de la capa que implementa el protocolo fiable que se desbloquea cuando se recibe un paquete de la capa inferior entregar_datos( ): Función que la capa que implementa el protocolo fiable invoca cuando se han recibido nuevos datos tfd_recibir( ): Función de la capa superior que se desbloquea cuando se reciben nuevos datos Implementación del servicio emisor receptor tfd_enviar( ) tfd_recibir( ) tfd_evento_enviar( ) entregar_datos( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) tnd_enviar( ) tnd_recibir( ) tnd_evento_enviar( ) entregar_paquete( ) canal no fiable Tema III: El nivel de transporte en Internet

Protocolos de envío fiable
La complejidad del protocolo depende de las características del canal no fiable subyacente Iremos incrementando la complejidad del modelo de canal progresivamente, acercándonos a la realidad de Internet Para simplificar, y sin pérdida de generalidad, consideraremos que los datos de aplicación fluyen en una sola dirección en el canal La información de control del protocolo podrá viajar en ambas direcciones en el canal Utilizaremos máquinas de estados finitos (FSM – Finite State Machines) para representar los protocolos tanto en el emisor como en el receptor evento que causa la transición acciones que se ejecutan en la transición estado 1 estado: cuando estamos en un estado, el estado siguiente viene determinado, exclusivamente, por el evento siguiente estado 2 evento acciones Tema III: El nivel de transporte en Internet

Protocolo de envío fiable 1: Utopía
Asumimos que el canal subyacente es fiable No se pierden paquetes No se producen alteraciones de los paquetes Asumimos que el receptor puede procesar los paquetes entrantes a gran velocidad (un emisor rápido no puede saturar a un receptor lento) Las FSMs de los protocolos emisor y receptor son las siguientes Espera evento arriba tfd_enviar(datos) Espera evento abajo tnd_recibir(paquete) extraer (paquete,datos) entregar_datos(datos) paquete = hacer_paq(data) tnd_enviar(packet) emisor receptor while (true){ tfd_evento_enviar(&datos); paquete = hacer_paquete(datos); tnf_enviar(&paquete); } while (true){ tnd_recibir(&paquete); extraer(paquete, &datos); entregar_datos(&datos); } Tema III: El nivel de transporte en Internet

Protocolo Utopía, ejemplo
emisor receptor tfd_enviar( ) tfd_recibir( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) tnd_enviar( ) tnd_recibir( ) Canal punto a punto subyacente (fiable) Tema III: El nivel de transporte en Internet

Protocolo Utopía: gráfico de tiempo
emisor receptor tiempo tiempo Tema III: El nivel de transporte en Internet

Protocolo de envío fiable 2: Parada y Espera (Stop and Wait)
Asumimos que el canal subyacente es fiable No se pierden paquetes No se producen alteraciones de los paquetes Asumimos que el receptor NO puede procesar los paquetes entrantes con velocidad infinita (un emisor rápido SÍpuede saturar a un receptor lento) Ejemplo: El receptor recibe de una red de alta velocidad y reenvía por un modem lento Las FSMs de los protocolos emisor y receptor son las siguientes tfd_enviar(datos) paquete = hacer_paquete(datos) tnd_enviar(paquete) tnd_recibir(paquete) extraer (paquete,datos) entregar_datos(datos) tnd_enviar(ack) Espera evento abajo Espera ACK Espera evento arriba emisor receptor tnd_recibir(paq) && isACK(paq) while (true){ tfd_evento_enviar(&datos); paquete = hacer_paquete(datos); tnd_enviar(&paquete); tnd_recibir(&ack); } while (true){ tnd_recibir(&paquete); extraer(paquete, &datos); entregar_datos(&datos); tnd_enviar(ack); } Tema III: El nivel de transporte en Internet

Protocolo de Parada y Espera: ejemplo
Paquete de Asentimiento (ACK – ACKnowledgement) emisor receptor tfd_enviar( ) tfd_recibir( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) tnd_enviar( ) tnd_recibir( ) Canal punto a punto subyacente (fiable) Tema III: El nivel de transporte en Internet

Protocolo de Parada y Espera: gráfico de tiempo
emisor receptor tiempo tiempo Tema III: El nivel de transporte en Internet

Protocolo de envío fiable 3: Incorrecto
Asumimos que el canal subyacente puede producir errores de bit en la transmisión NO se pierden paquetes SÍ se producen alteraciones de los paquetes Asumimos que el receptor NO puede procesar los paquetes entrantes con velocidad infinita (un emisor rápido SÍ puede saturar a un receptor lento) Consideramos que los es posible detectar los paquetes erróneos Existen mecanismos que utilizan información redundante para detectar corrupción en los bits de un paquete. Entre otros se encuentran los mecanismos basados en paridad, las sumas de comprobación o los códigos cíclicos redundantes (CRC). Los estudiaremos en temas siguientes Por ahora, nos conformamos con saber que disponemos de una función que nos permite averiguar si un paquete contiene errores de bit o no - corrupto(paquete) == true  el paquete tiene errores de bit - corrupto(paquete) == false  el paquete no tiene errores de bit Para controlar los errores introducimos dos paquetes de control receptoremisor ACK – ACKnowledgements: Indican que el paquete se recibió correctamente NAK – Negative ACK: Indican que el paquete se recibió con errores y fue descartado Tema III: El nivel de transporte en Internet

Protocolo Incorrecto FSMs
tfd_enviar(data) paquete = hacer_paq(data, checksum) tnd_enviar(paquete) receptor tnd_recibir(paq) && isNAK(paq) espera ACK o NAK Espera evento arriba tnd_enviar(NAK) tnd_recibir(paq) && corrupto(paq) tnd_enviar(paquete) tnd_recibir(paq) && isACK(paq) Espera evento abajo L emisor tnd_recibir(paq) && not corrupto(paq) extraer(paq,data) entregar_datos(data) tnd_enviar(ACK) Tema III: El nivel de transporte en Internet

Protocolo Incorrecto: diagrama de tiempos
emisor receptor Paquete correcto Paquete incorrecto ACK NAK tiempo tiempo Tema III: El nivel de transporte en Internet

¿Por qué el protocolo se llama Incorrecto?
Asumimos que el canal subyacente puede producir errores de bit en la transmisión NO se pierden paquetes SÍ se producen alteraciones de los paquetes También los paquetes de ACK y NAK pueden corromperse haciéndose irreconocibles En ese caso, el emisor no sabe qué sucedió en el emisor El paquete pudo recibirse correctamente (y enviarse un ACK) El paquete pudo recibirse incorrectamente (y enviarse un ACK) Tenemos dos posibilidades Continuar como si nada: si el paquete se recibió de manera incorrecta se habrá perdido Repetir el paquete: si el paquete se recibió de manera correcta lo estaremos duplicando ¿Cómo podemos solucionar el problema de los duplicados? El emisor añadirá un número de secuencia en cada paquete que permitirá detectar si un paquete ya ha sido recibido previamente Si el receptor recibe un paquete duplicado, envía un ACK pero no entrega los datos del paquete al nivel superior (el paquete es descartado) Tema III: El nivel de transporte en Internet

Protocolo de envío fiable 4: Simplex con ruido
emisor tfd_enviar(data) sndpkt = hacer_paq(0, data, checksum) tnd_enviar(sndpkt) tnd_recibir(rcvpkt) && ( corrupto(rcvpkt) || isNAK(rcvpkt) ) Espera ACK o NAK 0 Espera evento 0 arriba tnd_enviar(sndpkt) tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt) tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt) L L Espera ACK o NAK 1 Espera evento 1 arriba tnd_recibir(rcvpkt) && ( corrupto(rcvpkt) || isNAK(rcvpkt) ) tfd_enviar(data) sndpkt = hacer_paq(1, data, checksum) tnd_enviar(sndpkt) tnd_enviar(sndpkt) Tema III: El nivel de transporte en Internet

Protocolo de envío fiable 4: Simplex con ruido
tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && has_seq0(rcvpkt) receptor extraer(rcvpkt,data) entregar_datos(data) sndpkt = hacer_paq(ACK, cheksum) tnd_enviar(sndpkt) tnd_recibir(rcvpkt) && (corrupto(rcvpkt) tnd_recibir(rcvpkt) && (corrupto(rcvpkt) sndpkt = hacer_paq(NAK, cheksum) tnd_enviar(sndpkt) sndpkt = hacer_paq(NAK, cheksum) tnd_enviar(sndpkt) Espera 0 de abajo Espera 1 de abajo tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && has_seq1(rcvpkt) tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && has_seq0(rcvpkt) sndpkt = hacer_paq(ACK, cheksum) tnd_enviar(sndpkt) sndpkt = hacer_paq(ACK, cheksum) tnd_enviar(sndpkt) tnd_recibir(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) extraer(rcvpkt,data) entregar_datos(data) sndpkt = hacer_paq(ACK, chksum) tnd_enviar(sndpkt) Tema III: El nivel de transporte en Internet

Protocolo Simplex con Ruido: ejemplo
ACK NAK Caso 1: Transmisión sin error del paquete y sin error del ACK emisor receptor tfd_enviar( ) tfd_recibir( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) + tnd_enviar( ) tnd_recibir( ) Canal punto a punto subyacente (no fiable) Tanto el emisor como el receptor comienzan en el estado (espera) 0 Tema III: El nivel de transporte en Internet

ACK Caso 1: Transmisión sin error del paquete y sin error del ACK NAK emisor receptor + Entrega 0 Entrega 1 + tiempo tiempo Tanto el emisor como el receptor comienzan en el estado (espera) 0 Tema III: El nivel de transporte en Internet

ACK NAK Caso 2: Transmisión sin error del paquete y con error del ACK emisor receptor tfd_enviar( ) tfd_recibir( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) + + + tnd_enviar( ) tnd_recibir( ) Canal punto a punto subyacente (no fiable) Tanto el emisor como el receptor comienzan en el estado (espera) 0 Tema III: El nivel de transporte en Internet

ACK Caso 2: Transmisión sin error del paquete y con error del ACK NAK emisor receptor Entrega 0 + + + + Entrega 1 tiempo tiempo Tanto el emisor como el receptor comienzan en el estado (espera) 0 Tema III: El nivel de transporte en Internet

ACK NAK Caso 3: Transmisión con error del paquete y sin error del NAK emisor receptor tfd_enviar( ) tfd_recibir( ) Protocolo de transferencia fiable (emisor) Protocolo de transferencia fiable (receptor) + tnd_enviar( ) tnd_recibir( ) Canal punto a punto subyacente (no fiable) Tanto el emisor como el receptor comienzan en el estado (espera) 0 Tema III: El nivel de transporte en Internet

ACK Caso 3: Transmisión con error del paquete y sin error del NAK NAK emisor receptor + Entrega 0 + + Entrega 1 tiempo tiempo Tanto el emisor como el receptor comienzan en el estado (espera) 0 Tema III: El nivel de transporte en Internet

ACK Caso 4: Transmisión con error del paquete y con error del NAK NAK emisor receptor + + Entrega 0 + + Entrega 1 tiempo tiempo Tanto el emisor como el receptor comienzan en el estado (espera) 0 Tema III: El nivel de transporte en Internet

Protocolo Simplex con Ruido: comentarios
Para probar la validez del protocolo deberíamos analizar todas las transiciones posibles Podemos ganar intuición sobre el funcionamiento del protocolo observando lo siguiente Hemos añadido un número de secuencia en los paquetes El número de secuencia toma sólo dos valores (0,1) ¿Es esto suficiente en todos los casos? La respuesta es sí, porque la única ambigüedad de duplicación se produce cuando un ACK es corrompido por el canal El emisor debe comunicar al receptor que recibió bien el ACK, para ello “cambia” el número de secuencia Como la única ambigüedad es de un paquete con el siguiente, basta con dos valores Protocolo sin NAKs Observemos que es posible eliminar los NAKs si añadimos un número de secuencia al ACK El ACK envía el número de secuencia del último paquete que se recibió correctamente En este caso, en el emisor Si el ACK contiene el número de secuencia del último envío  enviamos siguiente Si el ACK contiene un número de sec. diferente  repetimos Si el ACK está corrupto  repetimos Tema III: El nivel de transporte en Internet

Protocolo de envío fiable 6: Bit Alternante
Asumimos que el canal subyacente puede producir errores de bit y pérdidas de paquetes SÍ se pierden paquetes SÍ se producen alteraciones de los paquetes NO se desordenan los paquetes Asumimos que el receptor NO puede procesar los paquetes entrantes con velocidad infinita (un emisor rápido SÍ puede saturar a un receptor lento) Consideramos que los es posible detectar los paquetes erróneos - corrupto(paquete) == true  el paquete tiene errores de bit - corrupto(paquete) == false  el paquete no tiene errores de bit Un paquete erróneo es simplemente descartado (error de pérdida) Por tanto, basta con solucionar los errores de pérdida de paquetes Hay dos problemas que solucionar ¿Cómo detectamos que un paquete se ha perdido? ¿Qué hacemos cuando detectamos que un paquete se ha perdido? La respuesta a la segunda cuestión es sencilla: repetimos el paquete La respuesta a la primera cuestión es más compleja Existen varios mecanismos para detectar paquetes perdidos El más habitual es utilizar temporizadores Tema III: El nivel de transporte en Internet

Uso de temporizadores para detectar la pérdida de paquetes
RTT – Round Trip Time: Es el que tarda un paquete en ir del emisor al receptor, más el tiempo que tarda el ACK en volver El RTT de una comunicación puede variar Si la comunicación es a través de un medio dedicado (un cable dedicado) el RTT fluctúa poco Si la comunicación es a través de un medio compartido (un cable compartido) el RTT fluctúa algo Si la comunicación es a través de una red, el RTT fluctúa bastante (dependiendo de las condiciones de la red) emisor receptor RTT + RTT + tiempo tiempo Tema III: El nivel de transporte en Internet

Idea: El emisor lanza un temporizador de cuenta atrás cada vez que envía un paquete. El temporizador está inicializado con el valor de peor caso para el RTT Si al agotarse el temporizador no se ha recibido el ACK, tenemos garantías de que Bien se perdió el paquete Bien se perdió el ACK En ese caso, repetimos el envío del paquete Si el ACK se recibe antes de que se agote el temporizador, detenemos este último y consideramos el paquete como enviado Problema: No siempre es posible establecer un valor de peor caso para el RTT con plenas garantías Aunque sea posible, el valor puede ser tan elevado que suponga un desperdicio de recursos considerable emisor receptor Temporizador Paquete enviado Peor RTT posible ACK de respuesta tiempo tiempo Tema III: El nivel de transporte en Internet

Compromiso: Temporizador largo  No hacemos retransmisiones inútiles  Desperdicio de recursos en caso de pérdidas Temporizador corto  Muchas retransmisiones inútiles  El canal tiene mayor utilización Solución: Tomar un valor intermedio que se encuentre en el equilibrio entre ambos extremos El valor depende de la distribución de probabilidades del RTT Existen numerosos (y complicados) algoritmos de estimación del RTT y de cálculo del temporizador óptimo Estudiaremos alguno en próximos temas emisor receptor Paquete enviado ACK de respuesta Temporizador largo Tiempo desperdiciado tiempo tiempo Tema III: El nivel de transporte en Internet

Compromiso: Temporizador largo  No hacemos retransmisiones inútiles  Desperdicio de recursos en caso de pérdidas Temporizador corto  Muchas retransmisiones inútiles  El canal tiene mayor utilización Solución: Tomar un valor intermedio que se encuentre en el equilibrio entre ambos extremos El valor depende de la distribución de probabilidades del RTT Existen numerosos (y complicados) algoritmos de estimación del RTT y de cálculo del temporizador óptimo Estudiaremos alguno en próximos temas emisor receptor Paquete enviado Temporizador corto ACK de respuesta Reenvíos inútiles tiempo tiempo Tema III: El nivel de transporte en Internet

Compromiso: Temporizador largo  No hacemos retransmisiones inútiles  Desperdicio de recursos en caso de pérdidas Temporizador corto  Muchas retransmisiones inútiles  El canal tiene mayor utilización Solución: Tomar un valor intermedio que se encuentre en el equilibrio entre ambos extremos El valor depende de la distribución de probabilidades del RTT Existen numerosos (y complicados) algoritmos de estimación del RTT y de cálculo del temporizador óptimo Estudiaremos alguno en próximos temas emisor receptor Paquete enviado Temporizador adaptado ACK de respuesta tiempo tiempo Tema III: El nivel de transporte en Internet

FSMs del protocolo Bit Alternante: emisor
tfd_enviar(data) tnd_recibir(rcvpkt) && ( corrupto(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = hacer_pqt(0, data, checksum) tnd_enviar(sndpkt) start_timer tnd_recibir(rcvpkt) L L Espera evento 0 arriba Espera ACK 0 abajo timeout tnd_enviar(sndpkt) start_timer tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt,1) tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer Espera evento 1 arriba Espera ACK 1 abajo timeout tnd_enviar(sndpkt) start_timer tnd_recibir(rcvpkt) L tfd_enviar(data) tnd_recibir(rcvpkt) && ( corrupt0(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = hacer_pqt(1, data, checksum) tnd_enviar(sndpkt) start_timer L Tema III: El nivel de transporte en Internet

FSMs del protocolo Bit Alternante: receptor
tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && has_seq0(rcvpkt) extraer(rcvpkt,data) entregar_datos(data) sndpkt = hacer_pqt(ACK0, cheksum) tnd_enviar(sndpkt) tnd_recibir(rcvpkt) && (corrupto(rcvpkt) || has_seq1(rcvpkt)) tnd_recibir(rcvpkt) && (corrupto(rcvpkt) || has_seq0(rcvpkt)) Espera 1 de abajo Espera 0 de abajo tnd_enviar(sndpkt) tnd_enviar(sndpkt) tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && has_seq1(rcvpkt) extraer(rcvpkt,data) entregar_datos(data) sndpkt = hacer_pqt(ACK1, cheksum) tnd_enviar(sndpkt) Tema III: El nivel de transporte en Internet

Bit Alternante: ejemplos
Caso1: No hay pérdidas Los temporizadores en el emisor no se agotan Vamos alternando el número de secuencia del paquete enviado Se van entregrando a la capa superior los sucesivos paquetes emisor receptor Paquete 0 Entrega 0 ACK 0 Paquete 1 Entrega 1 ACK 1 Paquete 0 Entrega 0 ACK 0 tiempo tiempo Tema III: El nivel de transporte en Internet

Caso2: Paquete perdido Se agota el temporizador del emisor Se repite el paquete perdido hasta que el ACK apropiado es recibido Se continúa con la secuencia emisor receptor Paquete 0 Entrega 0 ACK 0 Paquete 1 temporizador Paquete 1 Entrega 1 ACK 1 Tema III: El nivel de transporte en Internet

Caso3: ACK perdido Se agota el temporizador del emisor Se repite el paquete perdido En el receptor, se descarta el duplicado del paquete emisor receptor Paquete 0 Entrega 0 ACK 0 Paquete 1 Entrega 1 temporizador ACK 1 Paquete 1 Descarta 1 ACK 1 Tema III: El nivel de transporte en Internet

Caso3: Timeout prematuro Se agota el temporizador del emisor Se repite el paquete perdido En el receptor, se descarta el duplicado del paquete emisor receptor Paquete 0 Entrega 0 ACK 0 Paquete 1 Entrega 1 temporizador ACK 1 Paquete 1 Descarta 1 ACK 1 Tema III: El nivel de transporte en Internet

Bit Alternante: Problema
Paquetes especialmente lentos Si en el canal existen paquetes especialmente lentos (con respecto a los demás) puede darse el caso de la figura Ese caso produce un funcionamiento incorrecto del protocolo Se evita si el canal no desordena paquetes (si A enviado antes que B  A recibido antes que B) En canales punto a punto sobre un medio físico (nivel de enlace) los canales no desordenan paquetes y el protocolo funciona sin mayores modificaciones Cuando el canal va sobre una red, la ruta seguida por cada paquete puede variar. En ese caso este protocolo puede presentar problemas. Por ahora asumiremos que el canal no desordena paquetes ¿Cómo se podría solucionar en caso contrario? emisor receptor Paquete 0 lento temporizador Repite 0 lento Entrega 0 lento Paquete 1 Entrega 1 Entrega 0 lento Paquete 0 rápido Descarta 0 rápido Tema III: El nivel de transporte en Internet

Bit Alternante: prestaciones
Bajo las suposiciones descritas, el protocolo de Bit Alternante funciona sin producir errores en la entrega Analicemos sus prestaciones con un ejemplo típico Enlace de R=1Gbps, RTT = 30ms, L = 1KB (longitud del paquete) T = Transmisión L (Long. pqt, bits) R (tasa trans. enlace, pbs) = 8Kb 109 bps = 8 microsec U = emisor L / R RTT + L / R = 0.008 30,008 = Estamos infrautilizando los recursos del canal Dicho de otro modo R = útil 8Kb 30,008 ms = 270Kbps emisor receptor Paquete 0 El protocolo que hemos diseñado limita drásticamente el uso del la capacidad de canal disponible ACK 0 Tema III: El nivel de transporte en Internet

Para y espera y sus prestaciones
emisor receptor Emitido primer bit del pqt, t = 0 Emitido último bit del pqt, t = L / R Llega el primer bit RTT Llega el último bit, envía ACK Llega ACK, envía siguiente paquete, t = RTT + L / R U = emisor L / R RTT + L / R = 0.008 30,008 = Tema III: El nivel de transporte en Internet

Protocolos entubados (pipelined)
Entubado (pipelining): El emisor permite que haya varios paquetes “en camino” antes de recibir el ACK del primero Es necesario añadir algunas modificaciones a los protocolos: Los rangos en los números de secuencia deben ser incrementados, ya que los paquetes en tránsito deben tener un número de secuencia único Tanto el emisor como el receptor tendrán que poder almacenar varios paquetes. El emisor, los paquetes transmitidos y no reconocidos, los paquetes correctamente recibidos en el receptor Dos mecanismos básicos: Retroceder N (Go-Back-N) Repetición Selectiva (Selective Repeat) Tema III: El nivel de transporte en Internet

Protocolos entubados: ejemplo
emisor receptor Emitido primer bit del pqt, t = 0 Último bit del pqt, t = L / R Primer bit del primer pqt RTT Último bit primer pqt envío ACK Último bit segundo pqt, envío ACK Último bit tercer pqt, envío ACK ACK llega, envía siguiente paquete, t = RTT + L / R Incrementa tasa utilización por 3! U = emisor 3*L / R RTT + L / R = 0.024 30,008 = Tema III: El nivel de transporte en Internet

Protocolo Retroceder N (GBN -- Go-Back-N)
Asumimos que el canal subyacente puede producir errores de bit y pérdidas de paquetes SÍ se pierden paquetes SÍ se producen alteraciones de los paquetes NO se desordenan los paquetes (un paquete rápido no adelanta a uno lento) Asumimos que el receptor NO puede procesar los paquetes entrantes con velocidad infinita (un emisor rápido SÍ puede saturar a un receptor lento) Este protocolo se basa en los principios del Bit Alternante pero añade lo siguiente: El emisor puede transmitir varios paquetes sin esperar ningún reconocimiento El número máximo de paquetes no reconocidos está restringido a un valor N El emisor detecta la pérdida de paquetes a través de temporizadores Si el ACK de un paquete no llega antes de que el temporizador se agote, el emisor repite el envío de todos los paquetes que hayan sido enviados pero no confirmados Si el receptor recibe el paquete con el número de secuencia correcto (número de secuencia n, siendo n-1 el número de secuencia del último paquete recibido de forma correcta y en secuencia) envía un ACK para el paquete n Si el receptor recibe un paquete incorrecto o fuera de secuencia, envía un ACK correspondiente al último paquete recibido de forma correcta y en secuencia Se permiten ACKs acumulativos (ACK(n)  todos los paquetes hasta el n han sido recibidos correctamente) Comenzamos asumiendo que los números de secuencia son enteros crecientes Tema III: El nivel de transporte en Internet

Protocolo Retroceder N: mecánica en emisión
Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se inicializan las variables en el emisor base signumsec Base+N-1 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se envía el paquete con número de secuencia 1 base signumsec Base+N-1 1 2 3 4 5 6 7 8 9 10 11 12 1 Ventana de emisión Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se envía el paquete con número de secuencia 2 base signumsec Base+N-1 1 2 3 4 5 6 7 8 9 10 11 12 2 Ventana de emisión Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se envían los siguientes paquetes de la ventana base Base+N-1 signumsec 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 3 4 Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se recibe el ACK del paquete 1, la ventana se “desliza” base Base+N-1 signumsec 1 2 3 4 5 6 7 8 9 10 11 12 1 Ventana de emisión Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se recibe el ACK del paquete 1, la ventana se “desliza” base Base+N-1 signumsec 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se envía el paquete con número de secuencia 5 base Base+N-1 signumsec 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 5 Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se pueden utilizar ACKs acumulativos, un ACK sobre el paquete 5 indica que todos los paquetes anteriores se recibieron de manera correcta base Base+N-1 signumsec 1 2 3 4 5 6 7 8 9 10 11 12 5 Ventana de emisión Tema III: El nivel de transporte en Internet

Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior siempre tiene datos que enviar Definimos: base: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar [1, base -1]: Paquetes que han sido enviados y reconocidos [base, signumsec-1]: Paquetes que han sido enviados pero no reconocidos [signumsec, base+N-1]: Paquetes que pueden ser enviados según lleguen de la capa superior [base+N, ]: Paquetes que no pueden ser enviados al estar fuera de la ventana Se pueden utilizar ACKs acumulativos, un ACK sobre el paquete 5 indica que todos los paquetes anteriores se recibieron de manera correcta base signumsec Base+N-1 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión Tema III: El nivel de transporte en Internet

Retroceder N: FSM extendida para el emisor
tfd_enviar(data) if (signumseq < base + N) { sndpkt[signumseq] = hacer_pqt(signumseq,data,checksum) tnd_enviar(sndpkt[signumseq]) if (base == signumseq) start_timer signumseq++ } else rechazar_datos(data) L base=1 signumseq=1 timeout start_timer tnd_enviar(sndpkt[base]) tnd_enviar(sndpkt[base+1]) … tnd_enviar(sndpkt[signumseq-1]) Espera tnd_recibir(rcvpkt) && corrupto(rcvpkt) L tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && acknum(rcvpkt) >= base base = acknum(rcvpkt)+1 If (base == signumseq) stop_timer else start_timer Tema III: El nivel de transporte en Internet

Algunos comentarios sobre el emisor
Invocación desde arriba: Cuando se invoca tfd_enviar el emisor comprueba si la ventana está llena, en caso negativo se crea un nuevo paquete y se envía, actualizando las variables convenientemente. Si la ventana está llena, el emisor devuelve los datos a la aplicación, que deberá ocuparse de reenviarlos con posterioridad. En un caso real, el emisor podría tener un buffer o compartir un semáforo con la aplicación haciendo que la llamada sea bloqueante. Recepción de un ACK: Un reconocimiento con número de secuencia n será tomado como acumulativo (todos los paquetes con número de secuencia inferior han sido recibidos correctamente) Timeout: En nombre del protocolo (Retroceder N) deriva del comportamiento del emisor en presencia de pérdida (o retraso) de paquetes. Si el temporizador expira, el emisor reenvía todos los paquetes que han sido previamente enviados pero no reconocidos. Temporizador: Se ha utilizado un único temporizador en el emisor, que puede considerarse el temporizador del paquete más antiguo no reconocido. Esto tiene ventajas e inconvenientes ¿puedes decir cuáles? Tema III: El nivel de transporte en Internet

Retroceder N: FSM extendida para el receptor
default tnd_enviar(sndpkt) tnd_recibir(rcvpkt) && not currupto(rcvpkt) && (seqnum(rcvpkt) == expectedseqnum) L Espera expectedseqnum=1 sndpkt = hacer_pqt(expectedseqnum,ACK,chksum) extraer(rcvpkt,data) entregar_datos(data) sndpkt = hacer_pqt(expectedseqnum,ACK,chksum) tnd_enviar(sndpkt) expectedseqnum++ Envía ACK del último paquete recibido correctamente y en secuencia Puede generar ACKs duplicados Sólo necesita mantener en memoria la variable expectedseqnum Paquetes fuera de secuencia: Se descartan (no se almacenan). Por tanto, el receptor no tiene “ventana” Se responde con un ACK al último paquete recibido correctamente y en secuencia Tema III: El nivel de transporte en Internet

Retroceder N: ejemplo Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior nos ha enviado datos para crear 5 paquetes emisor receptor Paquete 0 Paquete 1 Entrega 0 Paquete 2 Entrega 1 Paquete 3 ACK 0 ACK 1 Paquete 4 Paquete 5 ACK 1 Paquete 2 ACK 1 Paquete 3 Entrega 2 Paquete 4 Entrega 3 ACK 2 Paquete 5 Entrega 4 ACK 3 Entrega 5 ACK 4 ACK 5 Tema III: El nivel de transporte en Internet

Repetición Selectiva (SR -- Selective Repeat)
Asumimos que el canal subyacente puede producir errores de bit y pérdidas de paquetes SÍ se pierden paquetes SÍ se producen alteraciones de los paquetes NO se desordenan los paquetes (un paquete rápido no adelanta a uno lento) Asumimos que el receptor NO puede procesar los paquetes entrantes con velocidad infinita (un emisor rápido SÍ puede saturar a un receptor lento) Este protocolo Retroceder N permite solucionar los problemas del de Bit Alternante con respecto a la ocupación de la línea, sin embargo, en determinadas situaciones puede presentar problemas. Imaginemos una comunicación con los parámetros siguientes: Tamaño de la ventana N grande Retardo de transmisión elevado Un solo error de transmisión puede suponer repetir un gran número de paquetes A medida que se incremente la probabilidad de pérdida o error en el canal, aumentarán las retransmisiones innecesarias, con lo que empeorarán las prestaciones. Los protocolos de Repetición Selectiva evitan retransmisiones innecesarias haciendo que se reenvíen solamente los paquetes sospechosos de contener errores o de haber sido perdidos Comenzamos asumiendo que los números de secuencia son enteros crecientes Tema III: El nivel de transporte en Internet

Repetición Selectiva: mecánica de funcionamiento
Asumimos que N = 4 (tamaño de la ventana de 4) Asumimos que el nivel superior nos ha enviado datos para crear 6 paquetes Definimos en el emisor: base_emision: Número de secuencia del paquete más antiguo sin reconocer signumsec: Número de secuencia del próximo paquete a enviar Definimos en el receptor: base_recepción: Siguiente número de secuencia que se espera base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 Receptor Ventana de recepción

Emisor y receptor comparten el mismo tamaño de ventana Se inicializan las variables de manera apropiada base_emision = 1 signumsec = 1 base_recepción = 1 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 Receptor Ventana de recepción

El emisor envía paquetes hasta que llega al extremo de la ventana Emisor Receptor 1 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 1 base_r base_r+N-1 Receptor Ventana de recepción

El emisor envía paquetes hasta que llega al extremo de la ventana Emisor Receptor 1 2 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 2 base_r base_r+N-1 Receptor Ventana de recepción

El emisor envía paquetes hasta que llega al extremo de la ventana Emisor Receptor 1 2 3 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 3 4 base_r base_r+N-1 Receptor Ventana de recepción

Tras el retardo de comunicación, el receptor recibe un paquete pqt Definimos dos intervalos de números de secuencia: VentanaRecepción = [base_recepción, base_recepción + N -1] VentanaAnterior = [base_recepción - N, base_recepción -1] Si pqt.seqVentanaRecepción U VentanaAnterior Se envía ACK(pqt.seq) Si pqt.seqVentanaRecepción  Se almacena el paquete en un buffer o se entrega En caso contrario, se descarta el paquete Emisor Receptor 1 2 3 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 1 base_r+N-1 Receptor 1 Ventana de recepción

VentanaRecepción = [base_recepción, base_recepción + N -1] VentanaAnterior = [base_recepción - N, base_recepción -1] Si pqt.seqVentanaRecepción U VentanaAnterior Se envía un ACK(pqt.seq) Si pqt.seqVentanaRecepción  Se almacena el paquete en un buffer o se entrega Emisor Receptor 1 2 3 1 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 1 base_r+N-1 Receptor 1 Ventana Anterior Ventana Recepción

VentanaRecepción = [base_recepción, base_recepción + N -1] VentanaAnterior = [base_recepción - N, base_recepción -1] Si pqt.seqVentanaRecepción U VentanaAnterior Se envía un ACK(pqt.seq) Si pqt.seqVentanaRecepción  Se almacena el paquete en un buffer o se entrega Emisor Receptor 1 2 3 1 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 2 base_r+N-1 Receptor 1 2 Ventana de recepción Ventana Anterior

VentanaRecepción = [base_recepción, base_recepción + N -1] VentanaAnterior = [base_recepción - N, base_recepción -1] Si pqt.seqVentanaRecepción U VentanaAnterior Se envía un ACK(pqt.seq) Si pqt.seqVentanaRecepción  Se almacena el paquete en un buffer o se entrega Emisor Receptor 1 2 3 1 4 2 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 2 base_r+N-1 Receptor 1 2 Ventana de recepción Ventana Anterior

Supongamos ahora que el paquete 3 se pierde en la transmisión, pero el 4 llega a su destino. En este caso, el receptor almacena en el buffer el paquete 4 y envía un ACK(4) para confirmar su recepción Emisor Receptor 1 2 3 1 4 2 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 3 base_r 4 base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Supongamos ahora que el paquete 3 se pierde en la transmisión, pero el 4 llega a su destino. En este caso, el receptor almacena en el buffer el paquete 4 y envía un ACK(4) para confirmar su recepción Emisor Receptor 1 2 3 1 4 2 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 4 base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Los ACKs de los paquetes recibidos correctamente podrán ir llegando al emisor Supongamos que no se pierde ninguno: En primer lugar llegará ACK(1), esto producirá que la ventana se desplace una unidad y que se pueda enviar un nuevo paquete si el nivel superior tiene datos disponibles Emisor Receptor 1 2 3 1 4 2 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 1 base_r base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Los ACKs de los paquetes recibidos correctamente podrán ir llegando al emisor Supongamos que no se pierde ninguno: En primer lugar llegará ACK(1), esto producirá que la ventana se desplace una unidad y que se pueda enviar un nuevo paquete si el nivel superior tiene datos disponibles Emisor Receptor 1 2 3 1 4 2 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Los ACKs de los paquetes recibidos correctamente podrán ir llegando al emisor Supongamos que no se pierde ninguno: En primer lugar llegará ACK(1), esto producirá que la ventana se desplace una unidad y que se pueda enviar un nuevo paquete si el nivel superior tiene datos disponibles Emisor Receptor 1 2 3 1 4 2 5 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 5 base_r base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Supongamos que ahora llegan los ACKs restantes: ACK(2) y ACK(4) La llegada de ACK(2) producirá otro deslizamiento de la ventana Si el nivel superior tiene datos disponibles se enviará el siguiente paquete Emisor Receptor 1 2 3 1 4 2 5 4 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 2 base_r base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Supongamos que ahora llegan los ACKs restantes: ACK(2) y ACK(4) La llegada de ACK(2) producirá otro deslizamiento de la ventana Si el nivel superior tiene datos disponibles se enviará el siguiente paquete Emisor Receptor 1 2 3 1 4 2 5 4 6 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 6 base_r base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Supongamos que ahora llegan los ACKs restantes: ACK(2) y ACK(4) La llegada de ACK(4) se registrará en el emisor y hará que se detenga el temporizador asociado al paquete 4. Esto evita que el paquete 4, que ya ha sido recibido correctamente, se retransmita Emisor Receptor 1 2 3 1 4 2 5 4 6 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 4 base_r base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

Supongamos ahora que el temporizador asociado al paquete 3 se agota En este caso, el emisor retransmite el paquete 3, y solamente el paquete 3. Obsérvese que esto supone una gran diferencia con respecto al comportamiento de los protocolos Retroceder N Emisor Receptor 1 2 3 1 4 2 5 4 6 3 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 3 base_r base_r+N-1 Receptor 1 2 4 Ventana de recepción Ventana Anterior

En esta situación, si no hay pérdidas, se irán alcanzando el receptor los paquetes enviados desde el emisor. Por cada paquete recibido correctamente, se enviará el correspondiente ACK Emisor Receptor 1 2 3 1 4 2 5 4 6 3 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 5 base_r+N-1 6 Receptor 1 2 4 5 6 Ventana de recepción Ventana Anterior

En esta situación, si no hay pérdidas, se irán alcanzando el receptor los paquetes enviados desde el emisor. Por cada paquete recibido correctamente, se enviará el correspondiente ACK Emisor Receptor 1 2 3 1 4 2 5 4 6 3 5 6 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 5 6 Receptor 1 2 4 5 6 Ventana de recepción Ventana Anterior

Si no se vuelve a perder, en algún momento llegará el paquete 3 al receptor En ese caso, se enviará el correspondiente ACK(3) Dado que base_recepción es justamente 3, esta llegada producirá que se puedan entregar a la capa superior los datos recibidos correctamente y en secuencia Emisor Receptor 1 2 3 1 4 2 5 4 6 3 5 6 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 3 base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Si no se vuelve a perder, en algún momento llegará el paquete 3 al receptor En ese caso, se enviará el correspondiente ACK(3) Dado que base_recepción es justamente 3, esta llegada producirá que se puedan entregar a la capa superior los datos recibidos correctamente y en secuencia Emisor Receptor 1 2 3 1 4 2 5 4 6 3 5 6 3 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r 3 base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Si no se vuelve a perder, en algún momento llegará el paquete 3 al receptor En ese caso, se enviará el correspondiente ACK(3) Dado que base_recepción es justamente 3, esta llegada producirá que se puedan entregar a la capa superior los datos recibidos correctamente y en secuencia Emisor Receptor 1 2 3 1 4 2 5 4 6 3 5 6 3 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Supongamos ahora que se pierde el ACK(5) y que llegan correctamente ACK(6) y ACK(3) Emisor Receptor 1 2 3 1 4 2 5 4 6 3 5 6 3 base_e base_e+N-1 signumsec Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 5 base_r base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Supongamos ahora que se pierde el ACK(5) y que llegan correctamente ACK(6) y ACK(3) Al llegar ACK(3), la ventana del emisor se desliza, dado que el paquete asentido coincide con base_emisión Mientras el nivel superior no proporcione más datos, no podremos enviar más paquetes. Emisor Receptor 1 2 3 1 4 2 5 4 6 3 5 6 3 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

En algún momento, se agotará el temporizador asociado al paquete 5, que se reenviará Emisor Receptor 3 5 6 3 5 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 5 base_r base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Cuando llegue a su destino, el receptor se percatará de que ese paquete ya ha sido recibido (está dentro del intervalo definido por VentanaAnterior), por lo que simplemente se enviará un ACK(5) Emisor Receptor 3 5 6 3 5 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 5 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Cuando llegue a su destino, el receptor se percatará de que ese paquete ya ha sido recibido (está dentro del intervalo definido por VentanaAnterior), por lo que simplemente se enviará un ACK(5) Emisor Receptor 3 5 6 3 5 5 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 5 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Cuando el emisor reciba el ACK(5) desplazará la ventana de emisión dejando atrás todos los paquetes para los que se haya recibido un ACK correcto Emisor Receptor 3 5 6 3 5 5 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión 5 base_r base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Cuando el emisor reciba el ACK(5) desplazará la ventana de emisión dejando atrás todos los paquetes para los que se haya recibido un ACK correcto Cuando se reciban nuevos datos del nivel superior, se podrá continuar con el protocolo Emisor Receptor 3 5 6 3 5 5 base_e signumsec base_e+N-1 Emisor 1 2 3 4 5 6 7 8 9 10 11 12 Ventana de emisión base_r base_r+N-1 Receptor 1 2 3 4 5 6 Ventana de recepción Ventana Anterior

Protocolos de ventana deslizante: utilización de números de secuencia finitos Hemos asumido que los números de secuencia son enteros crecientes En realidad, el número de secuencia se representa a través de un conjunto finito de bits Los valores posibles serán enteros en un intervalo [0, SEQ_MAX] Para el incremento se utilizará la aritmética módulo SEQ_MAX+1 Dado un protocolo de ventana deslizante de tamaño N, bajo las suposiciones que hemos asumido (no se desordenan paquetes), ¿Cuál es el mínimo valor de SEQ_MAX que podemos utilizar? Evidentemente SEQ_MAX >= N-1 (puede haber N paquetes sobre el canal) ¿Es suficiente con N? La respuesta es NO Ejemplo: El receptor recibe los paquetes 0, 2, …, N-1 Acto seguido, el receptor vuelve a recibir paquetes con nº secuencia 1, 2, …, N ¿Son los mismos repetidos porque se perdieron los ACKs? ¿Son nuevos paquetes y no se perdieron los ACSs? El receptor no tiene modo de saberlo Para evitar este problema, es necesario que haya 2N números de secuencia distintos Por tanto SEQ_MAX >= 2N-1 Tema III: El nivel de transporte en Internet

Utilización de números de secuencia finitos. Ejemplo
N números de secuencia no son suficientes Es imposible que el receptor distinga entre ambos casos emisor emisor receptor receptor Paquete 0 Paquete 0 Paquete 1 Paquete 1 Paquete 2 Paquete 2 Paquete 3 Paquete 3 ACK 0 ACK 1 ACK 1 ACK 2 ACK 2 ACK 3 ACK 3 Paquete 0 Paquete 0 Paquete 1 Paquete 1 Paquete 2 Paquete 2 Paquete 3 Paquete 3 tiempo tiempo tiempo tiempo Tema III: El nivel de transporte en Internet

Utilización de números de secuencia finitos. Ejemplo
2N números de secuencia sí son suficientes El receptor puede distinguir entre ambos casos emisor emisor receptor receptor Paquete 0 Paquete 0 Paquete 1 Paquete 1 Paquete 2 Paquete 2 Paquete 3 Paquete 3 ACK 0 ACK 1 ACK 1 ACK 2 ACK 2 ACK 3 ACK 3 Paquete 4 Paquete 0 Paquete 5 Paquete 1 Paquete 6 Paquete 2 Paquete 7 Paquete 3 tiempo tiempo tiempo tiempo Tema III: El nivel de transporte en Internet

Comentarios y reflexiones Como puede observar en las referencias, algunos libros tratan este tema en la capa de enlace y otros en la de transporte. ¿Por qué? Esperar a que se agote un temporizador para poder continuar retransmitiendo suele ser muy costoso ¿Se le ocurre algún mecanismo que permita, al menos en algunas ocasiones, no esperar a que se agote el temporizador? Tome como referencia el protocolo de Bit Alternante y el Retroceder N. Si los paquetes pueden tener un tiempo de vida en la red muy elevado los protocolos de ventana deslizante dejan de ser fiables. ¿Por qué? ¿Cómo se puede solucionar este problema? ¿Cuántos bits debe tener una ventana de emisión como mínimo para que la utilización del canal sea del 100%? Referencias Redes de Computadores. Andrew S. Tanenbaum. Prentice Hall, Cuarta Edición, 2003 Capítulo 3: La Capa de Enlace de Datos Redes de Computadores, un enfoque descendente basado en Internet. James F. Kurose y Keith W. Ross. Addison Wesley, Segunda Edición, 2003 Capítulo 3: La Capa de Transporte Tema III: El nivel de transporte en Internet

Lección 3.3: Resumen Contenidos Transmisión fiable de datos: una visión sofware Protocolos para la transferencia fiable de datos Protocolo Utopía Protocolos de Parada y Espera Protocolos de Bit Alternante Protocolos Retroceder N Protocolos de Repetición Selectiva ¿Qué hemos aprendido? ¿Qué primitivas de servicio aparecerán en la pila de protocolos en relación a la transferencia fiable de datos? ¿En qué afectan las características de la capa inferior sobre la complejidad del protocolo de transferencia fiable? ¿Por qué los protocolos de parada y espera no son muy utilizados? ¿Qué mejora la introducción del mecanismo de ventana deslizante? ¿Qué ventajas e inconvenientes tiene el protocolo Retroceder N frente al de Repetición Selectiva? ¿Cuál es el mínimo cardinal del conjunto de números de secuencia para un protocolo de ventana deslizante? ¿En qué afecta que los números de secuencia sean finitos? Tema III: El nivel de transporte en Internet

El servicio TCP El protocolo TCP (Transmission Control Protocol) define cómo se implementa el servicio TCP Servicio TCP Orientado a conexión: Requiere el establecimiento de conexión entre los dos extremos Transporte fiable: Toda información enviada por el emisor es recibida por el receptor en el mismo orden Control de flujo: El emisor no saturará a un receptor más lento Control de congestión: El emisor bajará su tasa si se detecta congestión en la red No proporciona Garantías de temporización Garantías de ancho de banda Tema III: El nivel de transporte en Internet

El protocolo TCP Está descrito en las RFCs: 793, 1122, 1323, 2018, 2581 El protocolo TCP es un protocolo de extremo a extremo (end-to-end) Las entidades de nivel de transporte que comunican están situadas en los puntos terminales de la comunicación (emisor y receptor) El intercambio de información es full-duplex Se intercambian paquetes de datos, cada uno de los cuales se denomina un segmento TCP El tamaño máximo de un segmento viene determinado por los tamaños de paquete máximos de las capas inferiores En el nivel de red, el protocolo IP limita el tamaño de modo que el segmento debe ser menor que la carga útil del paquete IP ( bytes) En el nivel de enlace, el tamaño del paquete IP está limitado por el MTU (Maximum Transfer Unit) de la tecnología que se utilice. En Ethernet el MTU es de bytes El protocolo TCP se basa en un protocolo de ventana deslizante para ofrecer un servicio fiable y orientado a la conexión Este protocolo utiliza el servicio (no fiable) de envío de paquetes ofrecido por el protocolo IP Un paquete IP puede perderse, alterarse o desordenarse con respecto al resto de paquetes enviados desde un emisor hacia un receptor dados Tema III: El nivel de transporte en Internet

Estructura del segmento TCP
Cada segmento TCP tiene la estructura siguiente: Cabecera Cabecera fija (20 bytes) Opciones de cabecera Datos Las cabeceras opcionales pueden o no aparecer Los datos también son opcionales Si los datos están presentes, pueden ocupar cualquier número de bytes comprendido entre 1 y un tamaño máximo El tamaño máximo puede venir limitado por el paquete IP (en cuyo caso, se podrían incluir hasta bytes de datos) El tamaño máximo puede venir limitado por la tecnología de enlace que se utilice Vamos a analizar cada uno de los campos de la cabecera fija del segmento TCP detalladamente 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Puerto de origen y Puerto de destino (16 bits) El puerto de origen y el puerto de destino son la parte de la dirección de red que identifica a un proceso dentro de un host Como ya hemos visto en la introducción, los puertos de origen y de destino son utilizados para que el nivel de transporte pueda demultiplexar los segmentos TCP que se reciben en un host De este modo, los diferentes segmentos que se reciben se pueden clasificar en función a la conexión a la que pertenecen y ser entregados al socket que actúa como punto terminal de la misma Los puertos TCP ocupan 16 bits 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Número de secuencia (32 bits) En una conexión TCP, cada byte de datos tiene su propio número de secuencia de 32 bits En paquetes con datos, el número de secuencia del segmento TCP indica el asociado al primer byte de datos del paquete En paquetes de inicio de conexión (que no contienen datos), el número de secuencia se denomina ISN (Initial Sequence Number). El primer byte de datos, que será enviado si la conexión se establece, tendrá un número de secuencia igual a ISN + 1 Los números de secuencia de los bytes de una conexión se incrementan de manera cíclica siguiendo una aritmética módulo 232 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Número de confirmación de recepción (ACK) (32 bits) Ya sabemos que en los protocolos de ventana deslizante es necesario confirmar (a través de ACKs) los datos que se hayan recibido correctamente Hemos visto que en una conexión TCP, cada byte de datos enviado por el emisor tiene su propio número de secuencia de 32 bits El número de confirmación es sólo relevante cuando el paquete actúa como un ACK En ese caso, indica el número de secuencia del siguiente byte que la entidad TCP espera recibir Obsérvese que NO indica el número de secuencia del último byte recibido correctamente 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Longitud de la cabecera TCP (4 bits) Indica la longitud de la cabecera TCP medida en palabras de 32 bits Esta información es necesaria porque el campo Opciones es de longitud variable, por lo que la cabecera también Técnicamente, este campo indica el comienzo de los datos en el segmento, medido en palabras de 32 bits 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Bits reservados para usos futuros (6 bits) Este campo se reservó para usos futuros de TCP Como TCP está bien diseñado, no ha sido necesario utilizar estos bits, que han permanecido intactos durante más de 15 años Existen algunas propuestas para usar algunos de ellos. Por ejemplo, la RFC 3168 utiliza dos de estos bits para la función de notificación explícita de congestión 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Indicador URG (1 bit) Este bit indica si el apuntador urgente está en uso (1) o no (0) El apuntador urgente sirve para indicar un desplazamiento en bytes a partir del número actual de secuencia en el que se encuentran datos urgentes Este recurso permite al emisor enviar una señal urgente al receptor, permitiendo que esos datos se traten de manera especial en la aplicación 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Indicador ACK (1 bit) Este bit se establece a 1 para indicar que el número de confirmación de recepción es válido, es decir, para indicar que el segmento contiene un ACK Si el bit está a 0, el segmento no contiene ninguna confirmación de recepción, por lo que el valor del campo se ignorará Obsérvese que, gracias a este mecanismo, un mismo segmento TCP puede enviar datos en un sentido y confirmar el envío de datos en el sentido opuesto 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Indicador PSH (1 bit) Cuando el bit PSH está a 1, se indica que los datos deben ser transmitidos de inmediato. De este modo, se solicita al receptor que entregue los datos de inmediato a la aplicación y no los almacene en un buffer intermedio (lo que se podría hacer por razones de eficiencia) Este mecanismo es útil para indicar que se ha llegado al fin de un bloque 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Indicador RST (1 bit) El bit reset se utiliza para indicar al otro extremo que hay algún tipo de problema con la conexión y que esta debe ser restablecida. Existen numerosas ocasiones en las que este bit se usa como por ejemplo: Recepción de un segmento fuera de secuencia Intento no válido de establecer una conexión Etc En general, la presencia del indicador RST en un segmento suele ser síntoma de un problema 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Indicador SYN (1 bit) El bit SYN se utiliza para establecer conexiones, combinado con el indicador ACK La solicitud de una nueva conexión se caracteriza por tener SYN = 1 y ACK = 0 La aceptación de una solicitud de conexión se caracteriza por tener SYN = 1 y ACK = 1 En indicador SYN consume un número de secuencia equivalente a 1 byte 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Indicador FIN (1 bit) El bit FIN se utiliza para liberar una conexión previamente establecida La presencia de un bit FIN activo en un segmento indica que el emisor de ese segmento no tiene más datos que transmitir Sin embargo, ese proceso puede continuar recibiendo datos indefinidamente El indicador FIN consume un número de secuencia equivalente a 1 byte 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Tamaño de ventana (16 bit) Como ya hemos adelantado, TCP es un protocolo de ventana deslizante. La novedad que incorpora es que el tamaño de esta ventana es variable El tamaño de ventana variable permite establecer mecanismos de control de flujo entre el emisor y el receptor El campo tamaño de ventana indica la cantidad de bytes que el sistema receptor está dispuesto a aceptar, comenzando por el byte cuya confirmación ya ha sido aceptada Es válido un tamaño de ventana de 0, que indica que el receptor no tiene más espacio disponible y que el emisor debe parar la transmisión durante un tiempo Para restablecer la transmisión, se deberá enviar otro segmento con un tamaño diferente de cero 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Suma de comprobación (16 bit) Se proporciona una suma de comprobación para mejorar la confiabilidad La suma de comprobación se calcula utilizando el encabezado, los datos y un pseudoencabezado conceptual que contiene información adicional | Dirección origen | | Dirección destino | | cero | Proto. | Long. TCP | Este pseudoencabezado tiene por objetivo detectar segmentos que hayan sido encaminados de manera incorrecta 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Suma de comprobación (16 bit) Se calcula del modo siguiente: Se ponen en secuencia: el pseudoencabezado, la cabecera TCP (con suma de comprobación de cero) y los datos Se rellena el campo de datos con un byte a cero adicional si el número de bytes del segmento es impar. Ese byte adicional no se transmite, sólo se usa para trabajar con palabras de 16 bits. Se suman todas las palabras de 16 bits de la secuencia en complemento a 1 La suma de comprobación es el complemento a 1 del resultado así obtenido En el receptor, la suma de comprobación se utiliza para detectar errores de transmisión. Para ello, se realiza un cálculo equivalente en el receptor, pero ahora incluyendo la suma de comprobación recibida (en vez ceros) Si no hay errores en la transmisión, el resultado obtenido debe ser 0 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Apuntador urgente (16 bit) Este campo sólo tiene sentido cuando el indicador URG está activo Indica el número de bytes, a partir del número de secuencia indicado en el paquete, que corresponden con datos urgentes También se puede interpretar como el offset (en bytes) del primer byte no urgente del paquete 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Opciones (palabras de 32 bits) Este campo ofrece un mecanismo para agregar características extra no cubiertas por el encabezado normal Hay múltiples opciones que se usan con frecuencia en la actualidad y que estudiaremos más adelante Este campo es opcional 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Datos Los datos pueden estar constituidos por cero o más bytes (hasta cubrir el tamaño máximo del segmento) Los datos corresponderán con los mensajes de nivel de aplicación que se estén enviando 32 bits Puerto de origen Puerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP U R G A C K P S H R S T S Y N F I N Tamaño ventana Suma Comprobación Apuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional) Tema III: El nivel de transporte en Internet

Estados de la conexión TCP Evento que ocasiona la transición
CONNECT / SYN CLOSED Estado de la conexión CLOSED CLOSE / - LISTEN / - LISTEN Primitiva de servicio ejecutada en el servidor CLOSE / - SYN / SYN + ACK LISTEN RST / - SEND / SYN SYN RCVD SYN SEND CONNECT Primitiva de servicio ejecutada en el cliente SYN / SYN + ACK ACK / - SYN + ACK / ACK Indicador en el segmento enviado o recibido ESTABLISHED CLOSE / FIN SYN CLOSE / FIN FIN / ACK Transición habitual en el servidor FIN WAIT 1 FIN / ACK CLOSE WAIT CLOSING Transición habitual en el cliente FIN + ACK / ACK ACK / - CLOSE / FIN ACK / - Transición poco habitual FIN WAIT 2 TIME WAIT LAST ACK FIN / ACK Evento que ocasiona la transición / acción resultante CONNECT / SYN Temporizador / - ACK / - CLOSED Tema III: El nivel de transporte en Internet

Estados de la conexión TCP
CLOSED: La conexión no existe LISTEN: Espera solicitudes de conexión SYN SENT: Lanzada solicitud de conexión, espera SYN/ACK del otro extremo SYN RCVD: Lanzado SYN/ACK aceptando solicitud de conexión, espera confirmación ESTABLISHED: La conexión está abierta, los datos pueden viajar en ambos sentidos FIN WAIT 1: Se ha solicitado cerrar la conexión desde esta entidad, espera ACK de la solicitud o cierre definitivo. Esta entidad no puede enviar más datos FIN WAIT 2: Espera que la entidad remota solicite cierre definitivo de conexión. No se pueden enviar más datos. Se pueden seguir recibiendo datos TIME WAIT: La entidad remota ha solicitado el cierre de conexión, se espera para asegurar que la entidad remota ha recibido confirmación. No se pueden recibir más datos CLOSING: La entidad remota ha solicitado el cierre de la conexión. Espera confirmación de solicitud propia. No se pueden recibir más datos CLOSE WAIT: La entidad remota ha solicitado cierre de conexión. No se pueden recibir más datos. Se puede seguir enviado datos LAST ACK: El nivel de aplicación ha solicitado cierre de conexión. Esperamos confirmación del nodo remoto. No se pueden enviar más datos CONNECT / SYN CLOSED CLOSE / - LISTEN / - CLOSE / - SYN / SYN + ACK LISTEN RST / - SEND / SYN SYN RCVD SYN SEND SYN / SYN + ACK ACK / - SYN + ACK / ACK ESTABLISHED CLOSE / FIN CLOSE / FIN FIN / ACK FIN WAIT 1 FIN / ACK CLOSE WAIT CLOSING FIN + ACK / ACK ACK / - CLOSE / FIN ACK / - FIN WAIT 2 TIME WAIT LAST ACK FIN / ACK Temporizador / - ACK / - CLOSED Tema III: El nivel de transporte en Internet

Establecimiento de la conexión: acuerdo de tres vías
Cliente Servidor La conexión se establece a través de un mecanismo que se conoce como “acuerdo de tres vías” (three-way handshake) Lo habitual es que el procedimiento lo inicie un extremo (cliente) al que responde otro (servidor) El procedimiento también funciona cuando los dos extremos tratan de iniciar la conexión simultáneamente El procedimiento se basa en el intercambio de un mínimo de tres mensajes con información de control Ambos extremos deben sincronizar (SYN) sus números de secuencia para que la conexión se establezca Este procedimiento ha sido diseñado para minimizar los problemas asociados a paquetes duplicados que pueden aparecer debido a las características de la red subyacente CLOSED LISTEN CONNECT SYN (seq = X) SYN SEND SYN/ACK (seq = Y, ack = X+1) SYN RCVD ACK (seq = X+1, ack = Y+1) ESTABLISHED Datos (seq = X+1) ESTABLISHED Datos/ACK (seq = Y+1, ack = X+d+1) tiempo tiempo Tema III: El nivel de transporte en Internet

Recuperación frente a SYNs duplicados
La recuperación frente a duplicados impide que solicitudes de conexión antiguas interfieran con el correcto funcionamiento del protocolo Se basa en detectar números de secuencia “incorrectos” Para que funcione correctamente, el número de secuencia inicial de una conexión (ISN – Initial Sequence Number) no debe poder coincidir con el de cualquier otra solicitud de conexión de la que pueda existir un duplicado presente en la red Para lograrlo, se suele hacer que el ISN dependa de la hora del día Por tanto, el ISN puede ir avanzando sobre los 2**32 valores posibles Si los duplicados antiguos no pueden sobrevivir mucho tiempo en la red, se podrá lograr que no haya varias solicitudes de conexión con el mismo ISN en la red simultáneamente Estudiaremos más adelante cómo se garantiza que los duplicados antiguos no puedan sobrevivir en la red durante mucho tiempo Cliente Servidor SYN (seq = 100) Duplicado SYN (seq = 90) SYN/ACK (seq = 300, ack = 91) ERROR, Espera ack=101 RST (seq = 91) Inicializa el estado tiempo tiempo Tema III: El nivel de transporte en Internet

Números de secuencia y envío de datos
En TCP, cada octeto de datos tiene su propio número de secuencia El indicador SYN y el indicador FIN son los únicos paquetes de control que tienen su propio número de secuencia (de un byte) El SYN está antes del primer byte de datos El FIN está después del último byte de datos El asentimiento (ACK) de datos es acumulativo, por tanto, un paquete con el indicador ACK y con número de confirmación X significa que todos los bytes hasta el X (sin incluir) han sido recibidos correctamente El espacio de números de secuencia va de 0 a 2**32-1 Se utiliza una aritmética módulo 2**32 para el incremento y las comparaciones Vimos que en los protocolos de ventana deslizante basta con que existan el doble de números de secuencia que de posibles posiciones en la ventana del receptor Sin embargo, habíamos asumido que el nivel inferior no desordena paquetes La utilización de un espacio de números de secuencia tan grande en TCP se debe a que, en este caso, la red puede desordenar paquetes La presencia de duplicados antiguos con el mismo número de secuencia que paquetes nuevos puede ser problemática En TCP, la idea es la de garantizar que no es posible que un duplicado antiguo pueda sobrevivir en la red el tiempo suficiente como para colisionar con un paquete nuevo Tema III: El nivel de transporte en Internet

Números de secuencia y envío de datos. Cont.
¿En qué condiciones se pueden producir colisiones de los números de secuencia? Para que se produzca colisión, un paquete duplicado debe poder sobrevivir en la red durante un ciclo completo de los números de secuencia Eso supone que la conexión debe haber enviado 2**32 bytes Línea de 56Kbps: segundos Línea de 1Mbps: segundos Línea de 1Gbps: 34.3 segundos Cuanto más rápida sea la conexión menor es el tiempo que pueden vivir los duplicados Es necesario ofrecer mecanismos que garanticen que un segmento no pueda sobrevivir en la red durante más de algunos segundos Se encomienda al nivel de red a que implemente algún mecanismo que ofrezca esta garantía El nivel de red lo implementa a través de un mecanismo de tiempo de vida (TTL – Time To Live) Ya lo estudiaremos en próximos temas TCP A TCP B (seq = X) Duplicado (seq = X) (seq = X+d1) (seq = X+d1+d2) Tiempo de vida del duplicado … (seq = X) (seq = X) tiempo tiempo Tema III: El nivel de transporte en Internet

Control de flujo en TCP El mecanismo de control de flujo es el que evita que un emisor rápido pueda saturar a un receptor lento En los protocolos de ventana deslizante, la propia ventana actúa como mecanismo de control de flujo Cuando la ventana del receptor está llena, el emisor no puede enviar más paquetes Una ventana de tamaño fijo simplifica el protocolo pero es poco flexible En TCP, es posible que un mismo host deba gestionar decenas de miles de conexiones Cada conexión debe poseer su propia ventana y los buferes asociados Para gestionar de manera apropiada los recursos, TCP introduce un mecanismo de ventana deslizante, pero en el que el tamaño de la ventana es variable Cada host anuncia (utilizando el campo tamaño de ventana) a otro extremo el número de bytes que está dispuesto a recibir, a partir del último confirmado De este modo, cada host puede seleccionar el tamaño de su ventana de recepción El nodo remoto debe ajustar su ventana de emisión para que no sobrepase a la ventana de recepción del otro extremo El tamaño particular de la ventana anunciada depende de la implementación de TCP que se esté utilizando y de los recursos disponibles en el host correspondiente Tema III: El nivel de transporte en Internet

Política de transmisión de TCP
Imaginemos una conexión en la que el Host A envía datos al Host B El Host B podría también enviar datos al Host A, pero para simplificar, consideramos que esta situación no se produce El Host B está a la espera de recibir solicitudes de conexión En el Host A, la aplicación lanza una solicitud de conexión sobre el socket del Host B TCP A TCP B LISTEN CONNECT SYN (seq = 0) Ventana de recepción SYN/ACK (seq = 300, ack = 1, WIN=4096) Ventana de emisión 4096 ACK (seq = 1, ack = 301) 4096 Tema III: El nivel de transporte en Internet

La conexión ya está establecida La aplicación realiza un envío desde A hacia B de 2K (2048 bytes) La entidad TCP A realiza el envío. Para ello, utiliza segmentos que contienen 1K (1024 bytes) de datos TCP A TCP B Ventana de emisión SEND(buf, 2048) 1K (seq = 1) Ventana de recepción ACK (ack = 1025, WIN=3072) Ventana de emisión 3072 1K (seq = 1025) Ventana de recepción Ventana de emisión ACK (ack = 2049, WIN=2048) 2048 Tema III: El nivel de transporte en Internet

La aplicación realiza un envío desde A hacia B de 3K (3072 bytes) La entidad TCP A realiza el envío. Para ello, utiliza segmentos que contienen 1K (1024 bytes) de datos TCP A TCP B Ventana de emisión SEND(buf, 3072) 1K (seq = 2049) Ventana de recepción ACK (ack = 3073, WIN=1024) Ventana de emisión 1024 1K (seq = 3073) Ventana de recepción Ventana de emisión ACK (ack = 4097, WIN=0) Tema III: El nivel de transporte en Internet

La entidad TCP A no puede enviar más datos mientras no se anuncie una ventana de recepción mayor que cero Supongamos que TCP B lee 2K (2048 bytes) de datos TCP A TCP B Ventana de emisión Ventana de recepción RCV(buf, 2048) Ventana de recepción ACK (ack = 4097, WIN=2048) Ventana de emisión 2048 1K (seq = 4097) Ventana de recepción ACK (ack = 5121, WIN=1024) Ventana de emisión 1024 Tema III: El nivel de transporte en Internet

Algunos detalles del protocolo TCP
Pérdidas de anuncios de ventana Suponga que TCP A está bloqueado tras un paquete anunciando WIN = 0 Cuando TCP B libera espacio en su buffer, envía un nuevo paquete anunciando WIN > 0 ¿Qué sucede si ese último paquete se pierde? Para evitar un bloqueo indefinido, el estándar TCP permite que la entidad A envíe datos en dos situaciones, aunque la ventana anunciada por el receptor haya sido de 0 Cuando los datos son urgentes (por ejemplo, para permitir que el usuario elimino el proceso en ejecución en la máquina remota) El emisor puede enviar un segmento de 1 byte para hacer que el receptor reanuncie el siguiente byte esperado y el tamaño de la ventana TCP A TCP B ACK (ack = X, WIN = 0) ACK (ack = X, WIN = 4096) ¿Bloqueo Indefinido? 1Byte (seq = X) ACK (ack = X+1, WIN=4095) Tema III: El nivel de transporte en Internet

El algoritmo de Nagle Considere una aplicación que produce los bytes a enviar lentamente (p.e. interactiva) Cada byte que se envía, supone el intercambio de 2 paquetes La cabecera TCP son 20 bytes La cabecera IP son 20 bytes Enviar un bite, cuesta transmitir 81 bytes sobre la línea Solución: 1- Retardar el envío de paquetes y asentimientos durante algunos milisegundos 2- Algoritmo de Nagle El emisor envía el primer byte Los bytes siguientes se almacenan en el emisor hasta que se reciba el ACK del primer byte enviado La mayoría de las implementaciones de TCP utilizan el algoritmo de Nagle En ocasiones es mejor evitarlo ¿en cuáles?¿Por qué? TCP A TCP B SEND(1byte) 1Byte (seq = X) SEND(1byte) 1Byte (seq = X+1) SEND(1byte) SEND(1byte) 1Byte (seq = X+3) Sin Nagle SEND(1byte) 1Byte (seq = X) SEND(1byte) SEND(1byte) SEND(1byte) ACK (ack = X+1) 3Bytes (seq = X+1) Con Nagle ACK (ack = X+4) Tema III: El nivel de transporte en Internet

TCP A TCP B El síndrome de la ventana tonta Se produce en sistemas en los que la aplicación receptora lee los datos del buffer TCP del receptor byte por byte El problema es que, de este modo, el receptor puede estar constantemente anunciando ventanas de 0 y 1 byte respectivamente Esta situación puede ser muy dañina para las prestaciones Solución: La solución de Clark Evitar que el receptor envíe una actualización de ventana de 1 byte El receptor debe esperar a tener disponible una cantidad de espacio suficientemente grande (p.e. la mitad del espacio de su buffer) SEND(buf) D bytes (seq = X) ACK (ack = Y, WIN = 0) RECV(buf, 1byte) ACK (ack = Y, WIN = 1) 1 byte (seq = Y) ACK (ack = Y+1, WIN = 0) RECV(buf, 1byte) Sin Clark ACK (ack = Y+1, WIN = 1) 1 byte (seq = Y+1) Tema III: El nivel de transporte en Internet

Generación de ACKs en TCP
Para mejorar las prestaciones, se han definido una serie de reglas a la hora de general los ACKs en el receptor [RFC 1122, RFC 2581] Evento en el receptor Acción tomada por el receptor Llegada de un segmento en orden con El nº sec esperado. Todos los datos hasta el nº sec han sido ya ACKed Se retrasa el ACK. TCP espera hasta 500ms por si llega otro segmento. Si no, se envía el ACK Llegada de un segmento en orden con El nº sec esperado. Otro segmento tiene su ACK pendiente de envío Se envía un ACK acumulado inmediatamente Llegada de un segmento fuera de orden, con nº sec superior al esperado. Se detecta un “hueco” Se envía inmediatamente un ACK duplicado del nº sec del siguiente byte esperado “en orden” Llegada de un segmento que rellena un “hueco” total o partialmente Si el segmento cubre el extremo inferior del “hueco”, se envía inmediatamente un ACK Tema III: El nivel de transporte en Internet

Extensiones de TCP para altas prestaciones
Utilización del canal con ventana de emisión W: Tamaño de la ventana de emisión (bits) L: Tamaño de un segmento (bits) R: Capacidad de transmisión del canal (bps) RTT: Round Trip Time (s) U: Tasa de utilización del canal U = emisor W / R RTT + L / R emisor receptor Emitido primer bit del pqt, t = 0 Último bit del pqt, t = L / R Primer bit del primer pqt RTT Último bit primer pqt envío ACK ACK llega, envía siguiente paquete, t = RTT + L / R Tema III: El nivel de transporte en Internet

Extensiones de TCP para altas prestaciones cont
Utilización del canal con ventana de emisión W: Tamaño de la ventana de emisión (bits) L: Tamaño de un segmento (bits) R: Capacidad de transmisión del canal (bps) RTT: Round Trip Time (s) U: Tasa de utilización del canal W / R W U = ~ emisor RTT + L / R RTT*R Queremos que U ~ 1, para ello, W/R ~ RTT+L/R En redes de alta velocidad, R es grande, por tanto, T/R << RTT  RTT+L/R ~ RTT Por tanto, nuestro objetivo es hacer que W/R ~ RTT, es decir, W ~ RTT*R El tamaño de la ventana debe ser similar al producto del ancho de banda por el retardo de extremo a extremo para que la utilización sea óptima En el estándar original de TCP, el tamaño de la ventana viene definido (en bytes) por un número de 16 bits. Por tanto, WMAX = ( ) * 8 bits = bits En Internet, un RTT típico intercontinental ronda los 100ms Una línea de alta velocidad puede rondar 1Gbps En ese caso U ~ WMAX/108 = 0.005 Dicho de otro modo, la capacidad útil máxima para una conexión TCP será RMAX=WMAX/RTT ~ 5Mbps Tema III: El nivel de transporte en Internet

Solución propuesta en RTF 1323 Para mejorar la capacidad útil la única solución es permitir ventanas de mayor tamaño Para lograrlo, se extiende el tamaño de la ventana TCP añadiendo un campo opcional en la cabecera del segmento TCP denominado desplazamiento (shift) Si al establecer la conexión, ambas entidades TCP envían esta opción, el tamaño de la ventana W.Size se calculará del modo siguiente Se toma el campo Tamaño_de_Ventana de la cabecera estándar TCP (16 bits) Se toma el desplazamiento Shift (8 bits) Se desplaza a la izquierda el Tamaño_de_Ventana tantas posiciones como indique el campo Shift. W.Size = Tamaño_de_Ventana << Shift El estándar limita el desplazamiento máximo a un valor de 14 Por tanto, WMAX= (216-1)*214bytes Siguiendo el escenario descrito en la transparencia anterior, la capacidad máxima de transmisión últil de una conexión TCP en este caso será entonces RMAX = WMAX/RTT ~ 90Gbps Lo que constituye un valor acorde con el estado de la tecnología Tema III: El nivel de transporte en Internet

Solución propuesta en RFC 1323 Si la tasa de transmisión de una conexión TCP puede aproximarse a los 100Gbps aparece un nuevo problema A 100Gbps, el tiempo que tarda la conexión en recorrer los 232 números de secuencia ronda los 3 segundos Esto hace muy difícil la detección de paquetes duplicados “antiguos”, lo que pone en riesgo la consistencia de los datos transmitidos sobre la conexión TCP Para solucionar el problema, la RFC 1323 propone una solución Se basa en la introducción de una opción adicional sobre la cabecera Esta opción incluye un sello de tiempos de 32 bits El sello de tiempos se lee de un reloj “virtual” que se incrementa de manera monótona siguiendo una aritmética módulo 32 El tic del reloj es variable, pero se recomienda que ronde los 100 ms El sello de tiempos se puede utilizar entonces para detectar paquetes antiguos, aunque estos presenten un número de secuencia “admisible” Tema III: El nivel de transporte en Internet

Liberando la conexión TCP
Liberación activa La conexión se libera por iniciativa de la aplicación que corre sobre “este” host Liberación pasiva La conexión se libera por iniciativa del la aplicación que corre sobre el host remoto Liberación abrupta Se produce cuando hay algún tipo de problema en el canal o en alguno de los hosts terminales Puede producir inconsistencias en los datos emitidos o recibidos Se detecta a través de temporizadores Las transiciones no se dibujan en el diagrama de estados CONNECT / SYN CLOSED CLOSE / - LISTEN / - CLOSE / - SYN / SYN + ACK LISTEN RST / - SEND / SYN SYN RCVD SYN SEND SYN / SYN + ACK ACK / - SYN + ACK / ACK ESTABLISHED CLOSE / FIN CLOSE / FIN FIN / ACK Liberación activa Liberación pasiva FIN WAIT 1 FIN / ACK CLOSE WAIT CLOSING FIN + ACK / ACK ACK / - CLOSE / FIN ACK / - FIN WAIT 2 TIME WAIT LAST ACK FIN / ACK Temporizador / - ACK / - CLOSED Tema III: El nivel de transporte en Internet

Liberando la conexión TCP cont.
TCP A TCP P Puede enviar datos Puede enviar datos Puede recibir datos ESTABLISHED ESTABLISHED Puede recibir datos CLOSE FIN (seq = X) FIN WAIT 1 Puede recibir datos ACK (seq = Y, ack = X+1) CLOSE WAIT Puede enviar datos FIN WAIT 2 Datos/ACK (seq = Y+1, ack = X+1) CLOSE Puede recibir datos FIN (seq = Z) LAST ACK Puede enviar FIN TIME WAIT ACK (seq = X, ack = Z+1) Puede recibir FIN CLOSED CLOSED Tema III: El nivel de transporte en Internet

Administración de temporizadores en TCP
El temporizador de retransmisión Al enviarse un segmento se inicia el temporizador de retransmisión Si el ACK del segmento llega antes de que expire el temporizador  Se detiene el temporizador Si el ACK del segmento no llega antes de que expire el temporizador  Se retransmite el segmento y se inicia nuevamente el temporizador ¿Qué valor elegimos para el temporizador? Valor grande - Ventaja: No se producen retransmisiones innecesarias - Inconveniente: Las esperas innecesarias hacen que empeoren las prestaciones Valor pequeño - Ventaja: No se producen esperas innecesarias que empeoren las prestaciones - Inconveniente: Se pueden producir retransmisiones innecesarias La distribución del RTT depende de la topología de red subyacente - Un cable: El RTT se estima fácilmente con gran fiabilidad - Una red compleja con múltiples saltos (Internet): La estimación del RTT es difícil y poco fiable Tema III: El nivel de transporte en Internet

El algoritmo de Jacobson
Por cada conexión, TCP mantiene una variable denominada RTT RTT trata de ser una estimación del Round Trip Time de esa conexión RTT se actualiza siguiendo el algoritmo siguiente: 1- Por cada segmento que se envía se inicia un temporizador 2- Si la confirmación de recepción llega antes de que expire el temporizador, el temporizador se detiene y se lee su valor M 3- Se calcula el nuevo valor de RTT utilizando la fórmula siguiente: RTT = ·RTT + (1 - )·M Donde  es un factor de amortiguamiento. Por lo general =7/8 La variable RTT es una buena estimación del “valor medio” del RTT en en el pasado cercano Sin embargo, el RTT en una red compleja puede tener una gran varianza Por ese motivo, no es una buena idea utilizar directamente la variable RTT como valor del temporizador de retransmisión Para evitar este problema, se introduce un nuevo parámetro que trata de estimar la desviación típica de RTT Tema III: El nivel de transporte en Internet

El algoritmo de Jacobson cont.
Además de RTT, por cada conexión se mantiene la variable D D se calcula como la desviación media (que es una estimación de la estándar) Al llegar una confirmación de recepción, el valor de D se actualiza como D = ·D + (1 - ) · |RTT – M| Donde  es un factor de amortiguamiento. Normalmente =1/4 La mayoría de las implementaciones de TCP calculan RTT y D A partir de ellas, se establece el intervalo de expiración del temporizador en Temporizador_de_retransmisión = RTT + 4·D La elección del valor 4 se realizó por motivos prácticos y empíricos Queda una cuestión por resolver ¿Qué sucede con los segmentos para los que expira el temporizador? El segmento se envía de nuevo, pero ¿El ACK recibido pertenece a la primera o a la segunda transmisión? Una respuesta incorrecta puede contaminar seriamente la estimación del RTT Tema III: El nivel de transporte en Internet

El algoritmo de Karn Se utiliza para tratar los segmentos cuyo temporizador ha expirado El algoritmo se puede describir del modo siguiente La variable RTT no se actualiza con ninguno de los segmentos retransmitidos La expiración del temporizador se duplica con cada fallo, hasta que los datos pasan a la primera (backoff exponencial) TCP A TCP P

Ejemplo de estimación del RTT
Tema III: El nivel de transporte en Internet

Comentarios y reflexiones Con las suposiciones que hemos realizado, es muy difícil que el protocolo TCP acepte un segmento “extraño” como parte del flujo de datos de la conexión, pero, ¿sería muy difícil que un atacante malintencionado lograse la inclusión de un segmento en una conexión? ¿Qué necesitaría? La pregunta anterior puede ser planteada en términos de cierre de conexión. Reflexione sobre esta problemática. Qué relación cree que existe entre la pérdida de paquetes y la congestión Qué relación hay entre la congestión y el valor del RTT Referencias TCP/IP Illustrated, Volume 1: The Protocols: W. Richard Stevens. Chapters 17, 18, 19, 20, 21, 22, 23 and 24. Redes de Computadores. Andrew S. Tanenbaum. Prentice Hall, Cuarta Edición, 2003 Capítulo 6: La Capa de Transporte Redes de Computadores, un enfoque descendente basado en Internet. James F. Kurose y Keith W. Ross. Addison Wesley, Segunda Edición, 2003 Capítulo 3: La Capa de Transporte Tema III: El nivel de transporte en Internet

Lección 3.4: Resumen Contenidos Servicios ofrecidos por el protocolo TCP Formato del segmento TCP Funcionamiento de TCP Establecimiento de la conexión Mecanismos de control de flujo Números de secuencia y envío de datos Detalles de funcionamiento de TCP TCP para líneas de gran capacidad Liberación de conexiones Gestión de temporizadores en TCP ¿Qué hemos aprendido? ¿Cuál es el formato de la cabecera TCP y qué significado tiene cada uno de sus camplos? ¿Cómo representa TCP una conexión y cuál es su ciclo de vida? ¿Cuál es la mecánica de funcionamiento de la ventana deslizante de TCP? ¿Qué problemas presenta el envío fiables de datos en Internet y cómo se han solucionado en TCP? ¿Qué opciones se han introducido para que TCP pueda funcionar en líneas de alta velocidad? ¿Por qué son necesarias estas opciones? ¿Cómo se estima el valor del RTT en una conexión TCP? Tema III: El nivel de transporte en Internet

Requisitos previos Tema I: Introducción Conmutación de paquetes Vs conmutación de circuitos El caso de Internet: Multiplexación estadística como base de la conmutación Tema 3: Transmisión fiable de datos Protocolos para la transferencia fiable de datos El papel de los ACKs y los temporizadores Repetición como base de la recuperación ante pérdidas Evitar duplicados en la red Dificultad de estimar el RTT Tema 3: El protocolo TCP Formato del segmento TCP ACKs y números de secuencia La ventana de recepción de TCP Objetivos de TCP Garantizar la comunicación fiable “best effort” Garantizar reparto equitativo de recursos (fairness) Tema III: El nivel de transporte en Internet

Congestión en redes de paquetes: principio básico
Ley de conservación en un sistema sin pérdidas: Llegadas al sistema en Δt = Incremento almacenados en Δt – Salidas en Δt Si llegadas al sistema en Δt > Salidas en Δt  Incremento neto de almacenados tiempo En esa situación, el número de elementos almacenados crece con el tiempo Bien el almacén de elementos puede crecer hasta el infinito Bien se dejan de aceptar algunas llegadas (se descartan llegadas) Ley de conservación de un sistema con pérdidas Llegados en Δt – Descartados en Δt = Incremento almacenados en Δt – Salidas en Δt Tema III: El nivel de transporte en Internet

Estudio de la congestión en redes de paquetes
En redes de paquetes, la congestión se produce en los routers Los routers reciben paquetes a través de sus líneas de entrada y los reenvían a través de sus líneas de salida Los routers cuentan con buffers finitos que implementan colas de paquetes Consideramos que cada línea de salida tiene asociada su propia cola Cuando las colas se llenan, el router descarta (pierde) paquetes El modelo que se suele estudiar de manera habitual es el de cuello de botella simple - Un router con una sola línea de salida asociada a una cola - A partir de este modelo se pueden construir otras topologías de red más complejas Modelo de cuello de botella simple Router Línea de salida Líneas de entrada Cola Tema III: El nivel de transporte en Internet

Parámetros que definen el comportamiento de la cola
Definiciones ligadas a la cola de paquetes Tasa de llegada Número medio de elementos que se reciben por unidad de tiempo Se mide en elementos (paquetes, bits, etc) por segundo Se suele representar mediante la letra  Tasa de servicio Número medio de elementos servidos por unidad de tiempo Se suele representar mediante la letra  Tráfico ofrecido Se define como  = / Mide lo “ocupado” que está el sistema atendiendo llegadas No tiene unidades, aunque se mide en Erlangs Disciplina de la cola FIFO: First In First Out LIFO: Last In First Out SIFO: Shortest In First Out Etc: (LIS, SIS, …) En Internet, lo habitual es utilizar FIFO o algún derivado Tema III: El nivel de transporte en Internet

Patrones de llegada y de servicio
El tiempo entre llegadas consecutivas es, en general, una variable aleatoria El tiempo de servicio es, en general, una variable aleatoria El patrón seguido por ambas tiene una gran influencia sobre lo que sucede en la cola Ejemplo: Tiempo entre llegadas constante y tiempo de servicio constante Si  <   La cola, a largo plazo, estará vacía Si  >   La cola, a largo plazo, se irá a infinito Ejemplo: Tiempo entre llegadas exponencial y tiempo de servicio exponencial Si  <   La cola tendrá un tamaño medio no nulo que crecerá con  Cada tipo de patrón de llegada y de servicio producirá un comportamiento de la cola con unas características determinadas Notación del Kendall: Patrón llegada/Patrón servicio/Nº servidores/Nº Cli. Sist. M/M/1: Exponencial / Exponencial / 1 servidor (cola infinita) M/M/1/10: Exponencial / Exponencial / 1 servidor / Tam. máximo de cola de 9 M/D/1: Exponencial / Determinista / 1 servidor G/D/1: General / Determinista / 1 servidor Tema III: El nivel de transporte en Internet

Algunos resultados básicos de teoría de colas
El modelo más popular es el M/M/1 Se resuelve analíticamente Aunque su modelo de tráfico es demasiado “ideal”, los resultados obtenidos por el modelo suelen ser extrapolables a otro tipo de patrones de tráfico Es una herramienta conceptual de referencia Número de paquetes en el sistema N = Tiempo de espera (incluyendo el tiempo de servicio) T = Fórmula de Little (Es válida para cualquier modelo de cola y tráfico) N = T Intuición: Justo cuando un paquete va a salir lleva T segundos esperando, en ese tiempo hay T nuevos paquetes que se han colocado esperando salir  1 -  1  -  Tema III: El nivel de transporte en Internet

Algunos resultados básicos de teoría de colas. Cont.
Un modelo más realista es el M/M/1/K En este caso, el tamaño máximo de la cola es de K Si la cola está completamente llena (K paquetes), cualquier nuevo paquete que llegue será descartado (se producirá una pérdida) El modelo se puede resolver analíticamente La probabilidad de que haya i paquetes en la cola es 1 -  PiK = i 1 - K+1 Por tanto, la probabilidad de que un paquete se pierda es: 1 -  PPérdida = K 1 - K+1 Observa que, en este caso, el tráfico  puede tomar valores superiores a 1 Tema III: El nivel de transporte en Internet

Principios de la Congestión en Internet
La congestión se produce cuando el número de paquetes que quieren atravesar una línea es “superior” a la capacidad de la línea en un intervalo de tiempo No hay que confundir congestión con control de flujo En las redes de paquetes tipo Internet, la congestión se produce en los routers La congestión es uno de los problemas más importantes en las redes de paquetes tipo Internet La congestión tiene dos efectos sobre las prestaciones Se pierden paquetes Si llegan más paquetes de los que se pueden transmitir Podemos pensar en utilizar búferes muy grandes (infinitos) para evitar que se pierdan paquetes. Sin embargo esto tendría consecuencias muy negativas. ¿Por qué? Aumenta la latencia de los paquetes Un paquete que entra en un búfer lleno tiene que esperar “su turno” antes de poder ser encaminado Si el búfer es muy grande, el tiempo de espera también será muy grande La presencia de congestión impide que se puedan ofrecer garantías de prestaciones en redes de paquetes Tema III: El nivel de transporte en Internet

Causas y consecuencias de la congestión: escenario 1
Búfer infinito en el router Dos sesiones diferentes Comparten misma línea de salida Capacidad de las líneas C Fuentes generan a in Sumideros reciben a out Resultado: A medida que el tráfico ofrecido al router se aproxima a 1 Aumenta la latencia Si el tráfico ofrecido al router es mayor que 1 La latencia estacionaria se hace infinita Los sumideros no reciben más paquetes que los que la línea saturada puede transmitir Búferes infinitos en el router Host A lin Host B lout Tema III: El nivel de transporte en Internet

Como el del escenario 1 pero … Buffer finito en el router Transmisión fiable de datos (TCP) in: Tasa de emisión de aplicación ’in: Tasa de entrada ’out: Tasa de salida out: Tasa de recepción de aplicac. in = out Resultado: Se producen duplicados en la red La presencia de duplicados hace que la capacidad útil disminuya Retransmisión perfecta sin duplicados ’out = out C/2 ’in Retransmisión real con duplicados ’out C/2 out ’in Aplicación emisora in out ’out Aplicación receptora ’in Duplicados Retransmisiones Perdidos Tema III: El nivel de transporte en Internet

Host A lout lin : Búferes finitos Host B Línea lenta out Línea rápida in Un paquete perdido hace inútiles los recursos que haya utilizado antes de perderse Tema III: El nivel de transporte en Internet

Mecanismos para el control de congestión
La congestión es muy perjudicial para las prestaciones en redes de paquetes Hay que contar con mecanismos que eviten que se alcancen estados de congestión Los mecanismos están siempre basados en dos pasos Detección de la (posible) congestión Disminución de las tasas de inyección de paquetes de los emisores Existen dos aproximaciones diferentes Control de la congestión de extremo a extremo No hay realimentación explícita por parte de la red La (posible) congestión se deduce a través de Pérdidas de paquetes Patrón seguido por la latencia de los paquetes Los emisores “voluntariamente” reducen su tasa al detectar la congestión Control de la congestión asistido por la red Los routers del nivel de red facilitan realimentación sobre su estado a los emisores A través de un flag que se activa en el paquete (DECbit, TCP ECN) Explicitando la tasa a la que el emisor debe enviar Los emisores reducen su tasa de acuerdo a lo explicitado por el nivel de red Tema III: El nivel de transporte en Internet

Control de congestión en el protocolo TCP
El control de congestión de TCP se basa en los siguientes principios Control de congestión de extremo a extremo (end-to-end) No hay asistencia del nivel de red para realizar el control de congestión La (posible) congestión debe detectarse por métodos indirectos El emisor limita su tasa de envío a través de un mecanismo de ventana deslizante Se define una ventana de congestión de tamaño CongWin Se usa el mínimo entre CongWin y la ventana anunciada por el receptor Como máximo: Tasa_de_envío = CongWin toma valores dinámicos que cambian en función del estado de la red Cómo detecta el emisor la (posible) congestión? Se detecta a través de pérdida de paquetes Se asume la pérdida de un paquete cuando - Se dispara el temporizador asociado al envío de un segmento - Se reciben 3 ACKs duplicados (4 ACKs con el mismo número de secuencia) CongWin RTT Tema III: El nivel de transporte en Internet

Mecanismos para el control de congestión en TCP
Los mecanismos básicos del control de congestión están definidos en RFC 2581 La mayoría de las implementaciones de TCP se basan en estos mecanismos Control de Congestión (Congestion Control) También se le denomina AIMD (Additive Increase Multiplicative Decrease) Este algoritmo se utiliza cuando la conexión lleva mucho tiempo activa Comienzo Lento (Slow Start) Este algoritmo se utiliza al comienzo de la conexión También se puede utilizar tras la pérdida de un paquete Retransmisión Rápida (Fast Retransmit) Este mecanismo se basa en detectar pérdidas a través de ACK duplicados De este modo no hay que esperar a que se agote el temporizador Recuperación Rápida (Fast Recovery) Es una optimización que se utiliza en algunas versiones Tema III: El nivel de transporte en Internet

Control de Congestión: AIMD
Se utiliza el MSS (Maximum Segment Size) como unidad de medida Additive Increase Se incrementa CongWin en 1 MSS cada RTT en ausencia de pérdidas Es decir, cuando se han recibido los ACKs de una ventana completa, se incrementa el tamaño de la misma en 1 MSS Multiplicative Decrease En presencia de un evento de pérdida, CongWin se divide entre dos TCP A TCP B 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Comienzo Lento (Slow Start)
El mecanismo se activa Al comienzo de una conexión Tras agotarse un temporizador Mecanismo CongWin empieza siendo de 1 MSS CongWin se dobla cada RTT en ausencia de pérdidas Es decir, cada vez que se recibe un ACK, CongWin se incrementa en 1 MSS CongWin sigue creciendo hasta que se alcanza un umbral (threshold). En ese momento comienza a actuar AIMD TCP A TCP B 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Retransmisión Rápida (Fast Retransmit)
El mecanismo se activa Cuando se reciben 3 ACKs duplicados Es decir 4 ACKs con el mismo número de secuencia De este modo evitamos tener que esperar a que se agote un temporizador completamente (desperdicio de tiempo) Menos de 3 ACKs duplicados no se considera pérdida, se considera desorden de un segmento respecto a otros Mecanismo Se considera perdido el paquete sobre el que se han recibido los ACKs duplicados Se repite la emisión del paquete Se vuelve a activar el temporizador del paquete TCP A TCP B Tema III: El nivel de transporte en Internet

Recuperación Rápida (Fast Recovery)
Cuando se detecta un evento de périda hay dos posibles estrategias que se utilizan Recuperación lenta CongWin se hace de 1MSS Incremento exponencial Incremento lineal Recuperación rápida Si el evento de pérdida se detecta a través de un temporizador agotado Se utiliza recuperación lenta Si el evento de pérdida se detecta por 3 ACKs duplicados CongWin se hace la mitad + Incremento lineal TCP A TCP B Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe
TCP Tahoe es una versión muy utilizada Se caracteriza por usar: AIMD + Slow Start + Fast Retransmit El cambio Slow Start  AIMD se realiza al alcanzar un umbral (Threshold) El umbral se re calcula como CongWin/2 en el instante de pérdida Como se utiliza Fast Retransmit, la recepción de 4 ACKs de la misma secuencia se traduce en la repetición del segmento asociado Como no se utiliza Fast Recovery, cualquier pérdida de paquete se traduce en el recomenzar con Slow Start Vamos a estudiar el funcionamiento de TCP Tahoe con un ejemplo Asumimos que el emisor siempre tiene paquetes por enviar (envío de un fichero grande) CongWin Timeout 4 ACKs Threshold Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold Al comenzar la conexión: El tamaño de la ventana de congestión es 1 MSS El threshold toma un valor muy elevado Se activa el mecanismo Slow Start 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold Slow Start: Enviamos 1 segmento, se recibe su ACK CongWin = 2CongWin = 2 MSS 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold Slow Start: Enviamos 2 segmentos, se reciben sus ACKs CongWin = 2CongWin = 4 MSS 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold Pérdida de paquete: Enviamos 16 segmentos, se reciben 3 ACKs duplicados Threshold = CongWin/2 = 8 MSS CongWin = 1 MSS 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold Slow Start: Tras la detección de la pérdida, se repite el segmento Recomienza Slow Start partiendo de CongWin=1 MSS Se envía un segmento y se recibe su ACK CongWin = 2CongWin = 2 MSS 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold Slow Start: Si no hay péridas, continua Slow Start hasta que la ventana alcanza el nivel del Threshold 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold AIMD: Comienza el algoritmo de control de congestión AIMD Se envían 8 segmentos se reciben sus ACKs CongWin = CongWin + 1 = 9 MSS 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold AIMD: Continúa el algoritmo de control de congestión hasta que se produce la pérdida de un paquete Threshold = CongWin/2 = 6 MSS CongWin = 1 MSS Se activa Slow Start 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold Slow Start: Slow Start hace su trabajo hasta que se alcanza el umbral, en ese momento se activa AIMD 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Tahoe. Cont. CongWin Timeout 4 ACKs Threshold El proceso continúa mientras la conexión siga abierta 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Reno
TCP Reno es la versión de TCP más utilizada en la actualidad Se caracteriza por usar: AIMD + Slow Start + Fast Retransmit + Fast Recovery El cambio Slow Start  AIMD se realiza al alcanzar un umbral (Threshold) El umbral se re calcula como CongWin/2 en el instante de pérdida Como se utiliza Fast Retransmit, la recepción de 4 ACKs de la misma secuencia se traduce en la repetición del segmento asociado Como se utiliza Fast Recovery, las pérdidas se procesan de dos maneras Si es por timeout  Recomienza Slow Start Si es por 3 ACKs duplicados  Multiplicative Decrease y continúa AIMD Vamos a estudiar el funcionamiento de TCP Reno con un ejemplo Asumimos que el emisor siempre tiene paquetes por enviar (envío de un fichero grande) CongWin Timeout 4 ACKs Threshold Tema III: El nivel de transporte en Internet

Control de congestión en TCP Reno. Cont. CongWin Timeout 4 ACKs Threshold Al comenzar la conexión: El tamaño de la ventana de congestión es 1 MSS El threshold toma un valor muy elevado Se activa el mecanismo Slow Start 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Reno. Cont. CongWin Timeout 4 ACKs Threshold Slow Start: Slow Start realiza su trabajo hasta que se producen pérdidas En este caso, asumimos que la pérdida se detecta por 4 ACKs 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Reno. Cont. CongWin Timeout 4 ACKs Threshold Fast Recovery: Entra en acción el mecanismo Fast Recovery CongWin = CongWin/2 Se activa AIMD 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Reno. Cont. CongWin Timeout 4 ACKs Threshold AIMD Continúa el algoritmo AIMD hasta que se produce una pérdida Si la pérdida es por timeout, recomienza Slow Start Theshold = CongWin/2 = 6 MSS CongWin = 1 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Control de congestión en TCP Reno. Cont. CongWin Timeout 4 ACKs Threshold Continuamos de este modo mientras la conexión siga activa 16 14 12 10 8 6 CongWin (MSS) 4 2 Tiempo (RTT) Tema III: El nivel de transporte en Internet

Algunos comentarios sobre el control de congestión en TCP
Cuello de botella simple Línea de capacidad C compartida entre N conexiones Cada conexión puede utilizar hasta CCON = C/N La tasa realmente utilizada es Ci = CongWin/RTT Es decir, TCP debe estimar CCON * RTT para evaluar su ventana de congestión La estrategia de TCP se basa en dos principios Incrementar la tasa de envío hasta producir congestión Entonces dar marcha atrás para controlar la congestión Forzamos a que la congestión aparezca para después controlarla Esta estrategia presenta numerosos problemas La tasa de envío sigue un patrón en diente de sierra que no suele responder al óptimo Al producir congestión, aumenta la varianza del RTT, lo que hace más difícil la estimación de CCON Con Fast Recovery nos recuperamos bien de la pérdida de un segmento por ventana, pérdidas mayores hacen que las prestaciones disminuyan de manera notable Tema III: El nivel de transporte en Internet

Prevención de la congestión
Principio En vez de producir congestión y luego disminuir … … predecir cuando se va a producir congestión … … y disminuir la tasa de envío antes de que se tiren paquetes Es decir, evitar la congestión para no tener que controlar la congestión Existen dos tipos de propuestas para predicción de congestión en TCP Utilizando información del estado de la red: TCP ECN [RFC 3168] Utilizando técnicas predictivas extremo a extremo: TCP Vegas [ Tema III: El nivel de transporte en Internet

Reparto equitativo de recursos en Internet (Fairness)
Finalidad Cuando K conexiones comparten un recurso (línea) de capacidad C, el protocolo debería garantizar que el mismo se reparte de forma equitativa Es decir, que cada una de ellas disponga de una tasa C/K En estado estacionario, TCP logra que los recursos se compartan de manera equitativa Esto es posible gracias a que todas las conexiones respetan el mecanismo de funcionamiento de AIMD Por eso es importante que TODAS las implementaciones de TCP respeten el mismo estándar Linea de capacidad C Tema III: El nivel de transporte en Internet

¿Por qué TCP es equitativo?
Idea intuitiva Asumimos dos conexiones TCP “compitiendo” por un recurso común AIMD incrementa de forma lineal la tasa en ambas conexiones AIMD decrementa de forma multiplicativa la tasa en ambas conexiones Por simplicidad, asumimos que son simétricas (emiten y pierden a la vez) C Reparto equitativo Estado inicial injusto Additive Increase Multiplicative Decrease Tasa de la conexión 1 Pérdida de paquete Tasa de la conexión 1 C Tema III: El nivel de transporte en Internet

Riesgos para el reparto equitativo de recursos en Internet
Flujos TCP y flujos UDP El reparto equitativo se logra gracias a AIMD AIMD es un algoritmo de TCP, pero UDP no tiene por qué respetarlo UDP se usa cada vez más en Internet con flujos muy agresivos Flujos multimedia Distribución de contenidos P2P La presencia de estos flujos puede ser muy perjudicial para TCP El diseño de protocolos UDP “compatibles” (friendly) con TCP es un área de investigación activa Utilización de conexiones TCP paralelas Una aplicación puede abrir varias conexiones TCP Algunos navegadores web lo hacen Ejemplo: Un enlace de capacidad C que cuenta con 9 conexiones Una aplicación abre una nueva conexión y obtiene C/10 Una aplicación abre 9 conexiones y obtiene C/2 Tema III: El nivel de transporte en Internet

Comentarios y reflexiones Poco después de iniciar una conexión TCP suelen aparecer un gran número de retransmisiones. ¿Por qué? ¿Cómo podría evitarse? El mecanismo de control de congestión de TCP impide que una conexión utilice de manera óptima su capacidad de transmisión disponible. Esto es especialmente cierto en conexiones de corta duración. ¿Por qué? ¿Qué efecto puede tener esto sobre servicios como el WWW? Existen implementaciones de TCP que permiten que los ordenadores que las usan obtengan mejoras de prestaciones del hasta el 50% con respecto a las implementaciones normales ¿Cómo lo logran? ¿Podría todo el mundo usarlas? Considere un cliente web que se descarga una página compuesta por tres recursos, el recurso 1 ocupa 1 MSS, el recurso 2, 4 MSS y el recurso 3, 8 MSS. Si no hay pérdidas de paquetes, determine el tiempo necesario para descargar la página utilizando HTTP 1.0. Realice el mismo ejercicio utilizando HTTP 1.1 (en ambos casos considere un RTT = 30 ms, MSS = 512 bytes, C = 56Kbps) Una determinada línea puede ser compartida por sesiones de diferente prioridad. ¿Se le ocurre algún mecanismo para que los paquetes de mayor importancia tengan preferencia a la hora de ser encaminados frente a los menos importantes?

TCP/IP Illustrated, Volume 1: The Protocols. W. Richard Stevens. Chapters 21: TCP Timeout and Retransmission Teoría de Colas y Simulación de Eventos Discretos. J. J. Pazos, A. Suárez, R. P. Díaz. Pearson Prentice Hall 2003 Redes de Computadores. Andrew S. Tanenbaum. Prentice Hall, Cuarta Edición, 2003 Capítulo 5: La Capa de Red Capítulo 6: La Capa de Transporte Redes de Computadores, un enfoque descendente basado en Internet. James F. Kurose y Keith W. Ross. Addison Wesley, Segunda Edición, 2003 Capítulo 3: La Capa de Transporte

Lección 3.5: Resumen Contenidos Introducción y conceptos básicos Nociones de Teoría de Colas Control de congestión en TCP AIMD Slow Start Fast Retransmit Fast Recovery TCP Tahoe TCP Reno TCP y reparto equitativo de recursos ¿Qué hemos aprendido? ¿Qué origina la congestión en redes de paquetes? ¿Qué efectos tiene la congestión sobre las redes de paquetes? ¿Que mecanismos define TCP para controlar la congestión? ¿Qué implementaciones de TCP son las más habituales y qué algoritmos utilizan para el control de congestión? ¿Existen otras aproximaciones para prevenir la congestión en vez de controlarla? ¿En qué se basan? ¿Por qué TCP garantiza un reparto equitativo de recursos? ¿Qué sucede si se utilizan flujos que no respetan el estándar TCP? Tema III: El nivel de transporte en Internet

Tema III: El nivel de transporte en Internet

Presentaciones similares

Presentación del tema: "Tema III: El nivel de transporte en Internet"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Tema III: El nivel de transporte en Internet

Presentaciones similares

Presentación del tema: "Tema III: El nivel de transporte en Internet"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback