tema iii: el nivel de transporte en internet luis lópez fernández 2005

Tema III:El nivel de transporte

en Internet

Luis López Fernández

2005

Tema III: El nivel de transporte en Internet

Conocimientos previosConocimientos 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: ContenidosTema III: Contenidos

Lección 3.1: Protocolos y servicios del nivel de transporte3.1.1 El nivel de transporte Vs el nivel de red en Internet3.1.2 Servicios ofrecidos por el nivel de transporte en Internet

Lección 3.2: El protocolo UDP3.2.1 El servicio UDP y el protocolo UDP3.2.2 RTP como ejemplo de protocolo que utiliza los servicios de UDP

Lección 3.3: Transmisión fiable de datos3.3.1 Transmisión fiable: una visión software3.3.2 Protocolos básicos para la transmisión fiable de datos3.3.3 Protocolos de ventana deslizante

Lección 3.4: El protocolo TCP3.4.1 Formato del segmento TCP3.4.2 Ciclo de vida de la conexión TCP3.4.3 Gestión de temporizadores TCP

Lección 3.5: Control de congestión3.5.1 Conceptos básicos sobre congestión y colas3.5.2 Control de la congestión en TCP3.5.3 Reparto equitativo de recursos y TCP



Introducción: Transporte y redIntroducción: Transporte y red

Aplicación

Transporte

Red

Enlace

Física

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

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)

Servicio ofrecido por el nivel de red


Protocolos y servicios del nivel de transporteProtocolos 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

enlacefísico

aplicación

Transp.red

enlacefísico

.red

enlacefísico

.red

enlacefísico

.red

enlacefísico

.red

enlacefísico


El nivel de transporte frente al nivel de redEl nivel de transporte frente al nivel de red

aplicación

transp.red

enlacefísico

aplicación

Transp.red

enlacefísico

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

3

500

…4

…

3

.red

enlacefísico

.red

enlacefísico


El nivel de transporte frente al nivel de redEl nivel de transporte frente al nivel de red

aplicación

transp.red

enlacefísico

aplicación

Transp.red

enlacefísico

El nivel de transporte•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

3

500

…4

1

2

3

500

…4


Protocolos de nivel de transporte en InternetProtocolos 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?


Multiplexación y demultipleaciónMultiplexació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

aplicación

transporte

red

enlace

física

P1 aplicación

transporte

red

enlace

física

aplicación

transporte

red

enlace

física

P2P3 P4P1

host 1 host 2 host 3

= proceso= socket


Multiplexación y demultiplexación cont.Multiplexación y demultiplexación cont.

transporte

red

enlace

física

P1

host 1

transporte

red

enlace

física

host 2

P2 P3 P4 P5 P6

InternetInternet

•Multiplexación:•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


Cómo funciona la demultiplexaciónCó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

Puertoorigen

Puertodestino

DatosAppl.

OtrosCampos Tx

IPorigen

IPdestino

Otros Campos red

Puertoorigen

Puertodestino

DatosAppl.

OtrosCampos Tx

Nivel de aplicación

Nivel de transporte

Nivel de red

Niveles inferiores

Socket

En

vío d

e dato

s


Cómo funciona la demultiplexaciónCó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

Puertoorigen

Puertodestino

DatosAppl.

OtrosCampos Tx

IPorigen

IPdestino

Otros Campos red

Puertoorigen

Puertodestino

DatosAppl.

OtrosCampos Tx

Nivel de aplicación

Nivel de transporte

Nivel de red

Niveles inferiores

Socket

Rec

epci

ón

de

dat

os


Números de puerto en InternetNúmeros de puerto en Internet•El número de puerto es un entero de 16 bits (0 .. 65535)•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 0 .. 1023 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 http://www.iana.org/assignments/port-numbers [RFC 3232]

•Ejemplos•HTTP: 80/TCP•FTP: 21/TCP•SMTP: 25/TCP•DNS: 53/TCP, 53/UDP•SSH: 22/TCP•TELNET: 23/TCP


Multiplexación y demultiplexación sin conexiónMultiplexació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 19157 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


Demultiplexación sin conexiónDemultiplexación sin conexión

DatagramSocket serverSocket = new DatagramSocket(6428);

ClienteIP:B

P2

Cliente IP: A

P1P1P3

servidorIP: C

SP: 6428

DP: 9157

SP: 9157

DP: 6428

SP: 6428

DP: 5775

SP: 5775

DP: 6428

SP: Source portDP: Destination port


Multiplexación y demultiplexación orientado a conexiónMultiplexació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 1024 .. 65535 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)


Multiplexación y demultiplexación orientado a conexión cont.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.

ClienteIP:B

P2

Cliente IP: A

P1P1P3

servidorIP: C

SP: 80

DP: 9157

SP: 9157

DP: 80

SP: 80

DP: 5775

SP: 5775

DP: 80

P4


Multiplexación y demultiplexación orientado a conexión cont.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)

Lección 3.1: Comentarios y referenciasLecció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


Lección 3.1: ResumenLecció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?



El protocolo UDPEl 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


¿Por qué usar UDP?¿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


Estructura de la cabecera UDPEstructura de la cabecera UDP

32 bits

Puerto de origen Puerto de destino

Longitud UDP Suma comprobación

•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 65.507 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

Datos

Luis Lopez

Tamaño del paquete IP en bytes limitado a 16 bits2^16-1 = 65535IP quita 20 bytesUDP quita 8 bytesEn total, 65507 bytes disponibles para datos UDP



32 bits



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.

Datos



32 bits



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

Datos



32 bits



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

Datos



32 bits



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

Datos


Ejemplo de un protocolo basado en UDP: RTPEjemplo 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

IP

Niveles Inferiores

UDP

Sockets

RTP

Aplicación

Kernel del S.O.

Espacio de usuario


La cabecera RTPLa cabecera RTP

Número secuencia

Id. origen sincronización

Id. origen contribución

Marca de tiempo

Tipo cargaútil

CC MP X

Ver

32 bits

•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


Funcionamiento de RTPFuncionamiento 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


Funcionamiento de RTP. Cont.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


Funcionamiento de RTP. Cont.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

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Ejemplo de aplicación multimedia con vídeo y audio

Flujo de Vídeo

Flujo de audio

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Establecemos un origen de tiempos común a todos los flujos

Flujo de Vídeo

Flujo de audio

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Muestreamos, codificamos y convertimos los flujos en una secuencia de paquetes

Tiempo

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

T1 T2 T3

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Los paquetes se envían por RTP incluyendo su marca de tiempos y su identificador

Tiempo

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

T1 T2 T3

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

Flujo RTP vídeo

Flujo RTP audio

SocketUDP U

DP

IP Etc

.

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Los paquetes se reciben, se demultiplexan y se almacenan en un búfer de compensación

Tiempo

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

T1 T2 T3

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

Flujo RTP vídeo

Flujo RTP audio

SocketUDP U

DP

IP Etc

.

UD

P

IP

Etc

.

SocketUDP

Flujo RTP vídeo

Flujo RTP audio

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Cuando la aplic. receptora lo considera oportuno, empieza a reproducir

Tiempo

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

T1 T2 T3

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

Flujo RTP vídeo

Flujo RTP audio

SocketUDP U

DP

IP Etc

.

UD

P

IP

Etc

.

SocketUDP

Flujo RTP vídeo

Flujo RTP audio

TiempoO

rig

en

de

tie

mp

os

en

el

rec

ep

tor

t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

T1 T2 T3

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Los paquetes se van reproduciendo respetando el origen de tiempos del receptor

Tiempo

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

T1 T2 T3

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

Flujo RTP vídeo

Flujo RTP audio

SocketUDP U

DP

IP Etc

.

UD

P

IP

Etc

.

SocketUDP

Flujo RTP vídeo

Flujo RTP audio

TiempoO

rig

en

de

tie

mp

os

en

el

rec

ep

tor

t1 t2 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

T1 T2 T3

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•Los paquetes se van reproduciendo respetando el origen de tiempos del receptor

Tiempo

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

T1 T2 T3

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

Flujo RTP vídeo

Flujo RTP audio

SocketUDP U

DP

IP Etc

.

UD

P

IP

Etc

.

SocketUDP

Flujo RTP vídeo

Flujo RTP audio

TiempoO

rig

en

de

tie

mp

os

en

el

rec

ep

tor

t1 t2 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

T1 T2 T3

t3

Funcionamiento de RTP: EjemploFuncionamiento de RTP: Ejemplo•La emisión, recepción y reproducción puede continuar con el desfase que añaden los búferes

Tiempo

Ori

ge

n d

e t

iem

po

se

n e

l e

mis

or

T1 T2 T3

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13

T0

t0

Flujo RTP vídeo

Flujo RTP audio

SocketUDP U

DP

IP Etc

.

UD

P

IP

Etc

.

SocketUDP

Flujo RTP vídeo

Flujo RTP audio

TiempoO

rig

en

de

tie

mp

os

en

el

rec

ep

tor

t1 t2 t3 t4 t5 t6 t7 t8 t9

T0

t0

T1 T2


El protocolo de control de RTP: RTCPEl 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



•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?






•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?


Transmisión fiable de datos: problemaTransmisión fiable de datos: problema

•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)

Capa superior que requiereel servicio fiable

Capa inferior que proporcionael servicio no fiable

Capa intermedia que implementael servicio fiable

tnd_enviar( ) tnd_recibir( )

tfd_enviar( )

emisor receptor

canal no fiable


emisor receptor

canal no fiable

Protocolo detransferencia fiable (emisor)

Protocolo detransferencia

fiable (receptor)

tfd_recibir( )


Principios de la transmisión fiable de datosPrincipios 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

tfd_enviar( )


emisor receptor

canal no fiable



fiable (receptor)

tfd_enviar( )

emisor receptor

canal lógico fiable

Implementación del servicio Servicio fiable

tfd_recibir( )tfd_recibir( )


Primitivas de servicioPrimitivas de servicio

tfd_enviar( )entregar_datos( )


emisor receptor

canal no fiable



fiable (receptor)

Implementación del 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

tfd_evento_enviar( )

tfd_recibir( )

tnd_evento_enviar( ) entregar_paquete( )


Protocolos de envío fiableProtocolos 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

estado1

estado2

evento que causa la transiciónacciones que se ejecutan en la transición

estado: cuando estamos en un estado, el estado siguiente

viene determinado, exclusivamente, por el

evento siguiente

eventoacciones


Protocolo de envío fiable 1: UtopíaProtocolo 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

Esperaeventoarriba paquete = hacer_paq(data)

tnd_enviar(packet)

tfd_enviar(datos)

extraer (paquete,datos)entregar_datos(datos)

Esperaeventoabajo

tnd_recibir(paquete)

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);

}


Protocolo Utopía, ejemploProtocolo Utopía, ejemplo

emisor receptor

tfd_enviar( ) tfd_recibir( )



fiable (receptor)

Canal punto a punto subyacente (fiable)



Protocolo Utopía: gráfico de tiempoProtocolo Utopía: gráfico de tiempo

emisor receptor

tiemp

o

tiemp

o


Protocolo de envío fiable 2: Parada y Espera (Stop and Wait)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

emisor

receptor

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); }

Esperaeventoarriba

paquete = hacer_paquete(datos)tnd_enviar(paquete)

tnd_recibir(paq) && isACK(paq)

EsperaACK

tfd_enviar(datos)

extraer (paquete,datos)entregar_datos(datos)tnd_enviar(ack)

Esperaeventoabajo

tnd_recibir(paquete)


Protocolo de Parada y Espera: ejemploProtocolo de Parada y Espera: ejemplo

emisor receptor




fiable (receptor)

Canal punto a punto subyacente (fiable)


Paquete de Asentimiento (ACK – ACKnowledgement)


Protocolo de Parada y Espera: gráfico de tiempoProtocolo de Parada y Espera: gráfico de tiempo

emisor receptor

tiemp

o

tiemp

o


Protocolo de envío fiable 3: Incorrecto 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 receptoremisor•ACK – ACKnowledgements: Indican que el paquete se recibió correctamente•NAK – Negative ACK: Indican que el paquete se recibió con errores y fue descartado


Protocolo Incorrecto FSMsProtocolo Incorrecto FSMs

Esperaeventoarriba

paquete = hacer_paq(data, checksum)tnd_enviar(paquete)

extraer(paq,data)entregar_datos(data)tnd_enviar(ACK)

tnd_recibir(paq) && not corrupto(paq)

tnd_recibir(paq) && isACK(paq)

tnd_enviar(paquete)

tnd_recibir(paq) && isNAK(paq)

tnd_enviar(NAK)

tnd_recibir(paq) && corrupto(paq)

espera ACK o NAK

Esperaeventoabajoemisor

receptortfd_enviar(data)


Protocolo Incorrecto: diagrama de tiemposProtocolo Incorrecto: diagrama de tiempos

emisor receptor

tiemp

o

tiemp

o

Paquete correcto

Paquete incorrecto

ACK

NAK


¿Por qué el protocolo se llama Incorrecto?¿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)


Protocolo de envío fiable 4: Simplex con ruidoProtocolo de envío fiable 4: Simplex con ruido

Esperaevento 0

arriba

sndpkt = hacer_paq(0, data, checksum)tnd_enviar(sndpkt)

tfd_enviar(data)

Espera ACK o NAK 0 tnd_enviar(sndpkt)

tnd_recibir(rcvpkt) && ( corrupto(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = hacer_paq(1, data, checksum)tnd_enviar(sndpkt)

tfd_enviar(data)

tnd_enviar(sndpkt)

tnd_recibir(rcvpkt) && ( corrupto(rcvpkt) ||isNAK(rcvpkt) )

tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt)

Espera evento 1

arriba

Espera ACK o NAK 1

tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt)

emisor


Protocolo de envío fiable 4: Simplex con ruidoProtocolo de envío fiable 4: Simplex con ruido

Espera0 de abajo

sndpkt = hacer_paq(NAK, cheksum)tnd_enviar(sndpkt)

tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && has_seq0(rcvpkt)

tnd_recibir(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)

extraer(rcvpkt,data)entregar_datos(data)sndpkt = hacer_paq(ACK, chksum)tnd_enviar(sndpkt)

Espera 1 de abajo


extraer(rcvpkt,data)entregar_datos(data)sndpkt = hacer_paq(ACK, cheksum)tnd_enviar(sndpkt)

tnd_recibir(rcvpkt) && (corrupto(rcvpkt)

sndpkt = hacer_paq(ACK, cheksum)tnd_enviar(sndpkt)


tnd_recibir(rcvpkt) && (corrupto(rcvpkt)

sndpkt = hacer_paq(ACK, cheksum)tnd_enviar(sndpkt)

sndpkt = hacer_paq(NAK, cheksum)tnd_enviar(sndpkt)

receptor


Protocolo Simplex con Ruido: ejemploProtocolo Simplex con Ruido: ejemplo

emisor receptor




fiable (receptor)

Canal punto a punto subyacente (no fiable)


0 +

Caso 1: Transmisión sin error del paquetey sin error del ACK

ACK

NAK

+

Tanto el emisor como el receptor comienzan en el estado (espera) 0


Protocolo Simplex con Ruido: ejemploProtocolo Simplex con Ruido: ejemploCaso 1: Transmisión sin error del paquete

y sin error del ACK

ACK

NAK


emisor receptor

tiemp

o

tiemp

o

0 +

+

1 +

+

Entrega 0

Entrega 1



emisor receptor




fiable (receptor)



Caso 2: Transmisión sin error del paquetey con error del ACK

ACK

NAK

+


0 +

+

0 +

+


Protocolo Simplex con Ruido: ejemploProtocolo Simplex con Ruido: ejemploCaso 2: Transmisión sin error del paquete

y con error del ACK

ACK

NAK


emisor receptor

tiemp

o

tiemp

o

0 +

+ +

0 +

+

1 +

+

Entrega 0

Entrega 1



emisor receptor




fiable (receptor)



Caso 3: Transmisión con error del paquetey sin error del NAK

ACK

NAK

+0 +


0 +

0 +


Protocolo Simplex con Ruido: ejemploProtocolo Simplex con Ruido: ejemploCaso 3: Transmisión con error del paquete

y sin error del NAK

ACK

NAK


emisor receptor

tiemp

o

tiemp

o

0 +

+

0 +

+

1 +

+

Entrega 0

Entrega 1

0 +


Protocolo Simplex con Ruido: ejemploProtocolo Simplex con Ruido: ejemploCaso 4: Transmisión con error del paquete

y con error del NAK

ACK

NAK


emisor receptor

tiemp

o

tiemp

o

0 +

+

0 +

+

1 +

+

Entrega 0

Entrega 1

0 +

+


Protocolo Simplex con Ruido: comentariosProtocolo 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


Protocolo de envío fiable 6: Bit AlternanteProtocolo 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


•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


Uso de temporizadores para detectar la pérdida de paquetesUso de temporizadores para detectar la pérdida de paquetes

emisor receptor

tiemp

o

tiemp

o

0 +

+

•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)

0 +

+

RT

TR

TT



emisor receptor

tiemp

o

tiemp

o

•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

Peo

r R

TT

po

sib

le

Paquete enviado

ACK de respuesta

Tem

po

riza

do

r



emisor receptor

tiemp

o

tiemp

o

•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

Paquete enviado

ACK de respuesta

Tem

po

riza

do

r la

rgo

Tie

mp

o d

es

pe

rdic

iad

o



emisor receptor

tiemp

o

tiemp

o








Paquete enviado

ACK de respuesta

Tem

po

riza

do

r co

rto

Reenvíos inútiles



emisor receptor

tiemp

o

tiemp

o








Paquete enviado

ACK de respuesta

Tem

po

riza

do

r ad

apta

do


FSMs del protocolo Bit Alternante: emisorFSMs del protocolo Bit Alternante: emisor

sndpkt = hacer_pqt(0, data, checksum)tnd_enviar(sndpkt)start_timer

tfd_enviar(data)

Espera ACK 0abajo

tnd_recibir(rcvpkt) && ( corrupto(rcvpkt) ||isACK(rcvpkt,1) )

Espera evento 1

arriba

sndpkt = hacer_pqt(1, data, checksum)tnd_enviar(sndpkt)start_timer

tfd_enviar(data)

tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt,0)

tnd_recibir(rcvpkt) && ( corrupt0(rcvpkt) ||isACK(rcvpkt,0) )

tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && isACK(rcvpkt,1)

stop_timerstop_timer

tnd_enviar(sndpkt)start_timer

timeout

tnd_enviar(sndpkt)start_timer

timeout

tnd_recibir(rcvpkt)

Espera evento 0

arriba

Espera ACK 1abajo

tnd_recibir(rcvpkt)


FSMs del protocolo Bit Alternante: receptorFSMs del protocolo Bit Alternante: receptor

Espera 0 de abajo


extraer(rcvpkt,data)entregar_datos(data)sndpkt = hacer_pqt(ACK1, cheksum)tnd_enviar(sndpkt)

tnd_recibir(rcvpkt) && (corrupto(rcvpkt) || has_seq1(rcvpkt))

tnd_enviar(sndpkt)

Espera 1 de abajo


extraer(rcvpkt,data)entregar_datos(data)sndpkt = hacer_pqt(ACK0, cheksum)tnd_enviar(sndpkt)

tnd_recibir(rcvpkt) && (corrupto(rcvpkt) || has_seq0(rcvpkt))

tnd_enviar(sndpkt)

Luis Lopez

Esto hace falta por si se pierde el ACK0E----P0------->RE<----*A0*---RE------P------>R


Bit Alternante: ejemplosBit Alternante: ejemplos

emisor receptor

tiemp

o

tiemp

o

Paquete 0

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

ACK 0Entrega 0

Paquete 1

ACK 1Entrega 1

Paquete 0

ACK 0Entrega 0



emisor receptor

Paquete 0

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

ACK 0Entrega 0

Paquete 1

Paquete 1

ACK 1Entrega 1

tem

po

riza

do

r



emisor receptor

Paquete 0

Caso3: ACK perdido•Se agota el temporizador del emisor•Se repite el paquete perdido •En el receptor, se descarta el duplicado del paquete

ACK 0Entrega 0

Paquete 1

Paquete 1

ACK 1

Entrega 1

tem

po

riza

do

r

ACK 1

Descarta 1



emisor receptor

Paquete 0

Caso3: Timeout prematuro•Se agota el temporizador del emisor•Se repite el paquete perdido •En el receptor, se descarta el duplicado del paquete

ACK 0Entrega 0

Paquete 1

Paquete 1

ACK 1

Entrega 1

tem

po

riza

do

r

ACK 1

Descarta 1


Bit Alternante: ProblemaBit Alternante: Problema

emisor receptorPaquete 0 lento

Entrega 0 lento

Paquete 1

Entrega 1

tem

po

riza

do

r

Descarta 0 rápido

Repite 0 lento

Entrega 0 lentoPaquete 0 rápido

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?


Bit Alternante: prestacionesBit 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ónL (Long. pqt, bits)

R (tasa trans. enlace, pbs)=

8Kb

109 bps= 8 microsec

U =emisor

L / R

RTT + L / R=

0.00830,008

= 0.00027

•Estamos infrautilizando los recursos del canal•Dicho de otro modo

emisor receptor

Paquete 0

ACK 0

R =útil8Kb

30,008 ms= 270Kbps

•El protocolo que hemos diseñado limita drásticamente el uso del la capacidad de canal disponible


Para y espera y sus prestacionesPara y espera y sus prestaciones

Emitido primer bit del pqt, t = 0

emisor receptor

RTT

Emitido último bit del pqt, t = L / R

Llega el primer bitLlega el último bit, envía ACK

Llega ACK, envía siguiente paquete, t = RTT + L / R

U =emisor

L / R

RTT + L / R=

0.00830,008

= 0.00027


Protocolos entubados (pipelined)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)


Protocolos entubados: ejemploProtocolos entubados: ejemplo


emisor receptor

RTT

Último bit del pqt, t = L / R

Primer bit del primer pqtÚltimo bit primer pqt envío ACK

ACK llega, envía siguiente paquete, t = RTT + L / R

Último bit segundo pqt, envío ACKÚltimo bit tercer pqt, envío ACK

Incrementa tasautilización por 3!

U =emisor

3*L / R

RTT + L / R=

0.02430,008

= 0.0008


Protocolo Retroceder N (GBN -- Go-Back-N)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


Protocolo Retroceder N: mecánica en emisiónProtocolo Retroceder N: mecánica en emisión

1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

sig

nu

ms

ec

Ba

se

+N

-1Ventana de emisión

Se inicializan las variables en el emisor



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N


Se envía el paquete con número de secuencia 1

1



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N



2



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N


Se envían los siguientes paquetes de la ventana

3 4



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N


Se recibe el ACK del paquete 1, la ventana se “desliza”

1



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N

-1

Ventana de emisión

Se recibe el ACK del paquete 1, la ventana se “desliza”



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N

-1

Ventana de emisión


5



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N

-1

Ventana de emisión

Se pueden utilizar ACKs acumulativos, un ACK sobre el paquete 5 indicaque todos los paquetes anteriores se recibieron de manera correcta

5



1 2 3 4 5 6 7 8 910

11

12




ba

se

sig

nu

ms

ec

Ba

se

+N

-1

Ventana de emisión

Se pueden utilizar ACKs acumulativos, un ACK sobre el paquete 5 indicaque todos los paquetes anteriores se recibieron de manera correcta


Retroceder N: FSM extendida para el emisorRetroceder N: FSM extendida para el emisor

Espera start_timertnd_enviar(sndpkt[base])tnd_enviar(sndpkt[base+1])…tnd_enviar(sndpkt[signumseq-1])

timeout

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)

base = acknum(rcvpkt)+1If (base == signumseq) stop_timer else start_timer

tnd_recibir(rcvpkt) && not corrupto(rcvpkt) && acknum(rcvpkt) >= base

base=1signumseq=1

tnd_recibir(rcvpkt) && corrupto(rcvpkt)

Luis Lopez

Ya no es una máquina de estados, ahora se permite el uso de variables.Se parece más a la descripción de un programa de ordenador orientado a eventos

Luis Lopez

Esto no está en el kurose, pero hace falta para que ACKs enviados por paquetes fuera de secuencia no retrasen el reenvio de los perdidos. Si no se añade esta línea, el contador se resetea cada vez que se recibe un ACK(base-1)


Algunos comentarios sobre el emisorAlgunos comentarios sobre el emisor

•Comentarios:

•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?

Luis Lopez

Inconveniente: Puede bajar las prestaciones. Al recibir un ACK en secuencia, se resetea el temporizador, por lo que si se pierde el siguiente paquete habrá que esperar todo el tiempo del temporizador de nuevo.


Retroceder N: FSM extendida para el receptorRetroceder N: FSM extendida para el receptor

Espera

tnd_enviar(sndpkt)

default

tnd_recibir(rcvpkt) && not currupto(rcvpkt) && (seqnum(rcvpkt) == expectedseqnum) extraer(rcvpkt,data)entregar_datos(data)sndpkt = hacer_pqt(expectedseqnum,ACK,chksum)tnd_enviar(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = hacer_pqt(expectedseqnum,ACK,chksum)

•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


Retroceder N: ejemploRetroceder N: ejemplo

emisorreceptor

Paquete 0Paquete 1Paquete 2Paquete 3

ACK 0

Paquete 5

Paquete 2

Paquete 3

Paquete 4

•Asumimos que N = 4 (tamaño de la ventana de 4)•Asumimos que el nivel superior nos ha enviado datos para crear 5 paquetes

ACK 1

ACK 1

ACK 1

Paquete 4

Paquete 5

Entrega 0

Entrega 1

Entrega 2

Entrega 3

Entrega 4

Entrega 5

ACK 2

ACK 3

ACK 4

ACK 5

Luis Lopez

Este diagrama no corresponde con la máquina de estados que se ha presentado. Dicha máquina sólo tiene un temporizador. En este caso, el temporizador del paquete 2 sólo comenzaría a contar desde el momento en que se recibe el ACK1. El diagrama no respeta la máquina de estados por claridad de la explicación.


Repetición Selectiva (SR -- Selective Repeat)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)


•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

Repetición Selectiva: mecánica de funcionamientoRepetición Selectiva: mecánica de funcionamiento

1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

sig

nu

ms

ec

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1

Ventana de recepción

Emisor

Receptor


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

sig

nu

ms

ec

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor


1 2 3 4 5 6 7 8 910

11

12

•El emisor envía paquetes hasta que llega al extremo de la ventana

ba

se

_e

sig

nu

ms

ec

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

1

Emisor Receptor

1


1 2 3 4 5 6 7 8 910

11

12


ba

se

_e

sig

nu

ms

ec

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

2

Emisor Receptor

12


1 2 3 4 5 6 7 8 910

11

12


ba

se

_e

sig

nu

ms

ec

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

3 4

Emisor Receptor

1234


1 2 3 4 5 6 7 8 910

11

12

•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.seqVentanaRecepción U VentanaAnterior Se envía ACK(pqt.seq)•Si pqt.seqVentanaRecepción Se almacena el paquete en un buffer o se entrega•En caso contrario, se descarta el paquete

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

1

1

sig

nu

ms

ec

Emisor Receptor

1234

1


1 2 3 4 5 6 7 8 910

11

12

VentanaRecepción = [base_recepción, base_recepción + N -1]VentanaAnterior = [base_recepción - N, base_recepción -1]•Si pqt.seqVentanaRecepción U VentanaAnterior Se envía un ACK(pqt.seq)•Si pqt.seqVentanaRecepción Se almacena el paquete en un buffer o se entrega

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1

Ventana Recepción

Emisor

Receptor1

Ventana Anterior

sig

nu

ms

ec

Emisor Receptor

1

1234

1


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

2

2

Ventana Anterior

sig

nu

ms

ec


Emisor Receptor

1234

1

21


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor2

Ventana Anterior

sig

nu

ms

ec


2

Emisor Receptor

1234

1

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

3

4

4

sig

nu

ms

ec

2

Emisor Receptor

1234

1

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

4s

ign

um

se

c

2

Emisor Receptor

1234

1

4

21


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

1

sig

nu

ms

ec

•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

2

Emisor Receptor

1234

1

4

21


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec


2

Emisor Receptor

1234

1

4

21


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

5

sig

nu

ms

ec


2

Emisor Receptor

1234

1

45

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

2

2

Emisor Receptor

1234

1

45

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

6

2

Emisor Receptor

1234

1

456

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

4

2

Emisor Receptor

1234

1

456

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

3

2

Emisor Receptor

1234

1

456

3

21


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

5

5

6

6

•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

2

Emisor Receptor

1234

1

456

3

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

5 6

5 6

2

Emisor Receptor

1234

1

456

3 56

21


1 2 3 4 5 6 7 8 910

11

12

•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

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

5 63

3

2

Emisor Receptor

1234

1

456

3 56

21


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

4

sig

nu

ms

ec

5 63

3


2

Emisor Receptor

1234

1

456

3 563

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec


2

Emisor Receptor

1234

1

456

3 563

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec

•Supongamos ahora que se pierde el ACK(5) y que llegan correctamente ACK(6) y ACK(3)

2

Emisor Receptor

1234

1

456

3 563

5

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec


2

Emisor Receptor

1234

1

456

3 563

6

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec


2

Emisor Receptor

1234

1

456

3 563

3

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N


ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec

•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.

2

Emisor Receptor

1234

1

456

3 563

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N


ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec

•En algún momento, se agotará el temporizador asociado al paquete 5, que se reenviará

Emisor Receptor

3 563

5

5

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N


ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec

•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 563

5

5

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N


ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec

•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 563

5

5

5

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N


ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec

•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 563

5

5

5

4 5 6321


1 2 3 4 5 6 7 8 910

11

12

ba

se

_e

ba

se

_e

+N

-1

Ventana de emisión

ba

se

_r

ba

se

_r+

N-1


Emisor

Receptor

Ventana Anterior

sig

nu

ms

ec

•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 563

5

5

Protocolos de ventana deslizante: utilización de números de Protocolos de ventana deslizante: utilización de números de secuencia finitossecuencia 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


Utilización de números de secuencia finitos. EjemploUtilización de números de secuencia finitos. Ejemplo


emisorreceptor

tiemp

o

tiemp

o


ACK 1

ACK 2

ACK 3

ACK 0

Paquete 1Paquete 2Paquete 3

emisorreceptor

tiemp

o

tiemp

o


ACK 1

ACK 2

ACK 3


N números de secuencia no son suficientesEs imposible que el receptor distinga entre ambos casos

Paquete 0Paquete 0

Utilización de números de secuencia finitos. EjemploUtilización de números de secuencia finitos. Ejemplo


emisorreceptor

tiemp

o

tiemp

o


ACK 1

ACK 2

ACK 3

ACK 0


emisorreceptor

tiemp

o

tiemp

o


ACK 1

ACK 2

ACK 3


2N números de secuencia sí son suficientesEl receptor puede distinguir entre ambos casos

Paquete 4Paquete 0



•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%?


-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


Luis Lopez

Mirando ACKs duplicados

Luis Lopez

BW*RTT+1paquete



•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?

El servicio TCPEl 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

El protocolo TCPEl 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 (65.515 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 1.500 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

32 bits

Estructura del segmento TCPEstructura del segmento TCP



Número de secuencia

Número de confirmación de recepción (ACK)

Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana

Suma Comprobación Apuntador urgente

Opciones (0 o más palabras de 32 bits)

Datos (opcional)

•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 65.495 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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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•EtcEn general, la presencia del indicador RST en un segmento suele ser síntoma de un problema

32 bits






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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






Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana



Datos (opcional)

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

Estados de la conexión TCPEstados de la conexión TCP


CLOSED

LISTEN

SYN RCVD

SYNSEND

ESTABLISHED

FINWAIT 1

FINWAIT 2

TIMEWAIT

CLOSINGCLOSEWAIT

LASTACK

CLOSED

LISTEN / - CLOSE / -

CONNECT / SYN

CLOSE / -

SYN / SYN + ACK

SYN / SYN + ACK

RST / - SEND / SYN

SYN + ACK / ACK

ACK / -

CL

OS

E /

FIN

CLOSE / FIN

FIN / ACK

ACK / -

FIN / ACK

FIN + ACK / ACK

FIN / ACK

CLOSE / FIN

ACK / -

Estado de la conexión

Primitiva de servicio ejecutada en el servidor

Primitiva de servicio ejecutada en el cliente

Indicador en el segmento enviado o recibido

Transición habitual en el servidor

Transición habitual en el cliente

Transición poco habitual

ACK / -

Temporizador / -Evento que ocasiona la transición /

acción resultante

CLOSED

LISTEN

CONNECT

SYN

CONNECT /

SYN

Estados de la conexión TCPEstados de la conexión TCP


CLOSED

LISTEN

SYN RCVD

SYNSEND

ESTABLISHED

FINWAIT 1

FINWAIT 2

TIMEWAIT

CLOSINGCLOSEWAIT

LASTACK

CLOSED


CONNECT / SYN

CLOSE / -

SYN / SYN + ACK

SYN / SYN + ACK

RST / - SEND / SYN

SYN + ACK / ACK

ACK / -

CL

OS

E /

FIN

CLOSE / FIN

FIN / ACK

ACK / -

FIN / ACK

FIN + ACK / ACK

FIN / ACK

CLOSE / FIN

ACK / -

ACK / -

Temporizador / -

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

Establecimiento de la conexión: acuerdo de tres víasEstablecimiento de la conexión: acuerdo de tres vías


Cliente Servidor

tiemp

o

tiemp

o

SYN (seq = X)

SYN/ACK (seq = Y, ack = X+1)

ACK (seq = X+1, ack = Y+1)

Datos (seq = X+1)

Datos/ACK (seq = Y+1, ack = X+d+1)

CLOSED LISTEN

CONNECT

SYN SEND

SYN RCVD

ESTABLISHED

ESTABLISHED

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

Recuperación frente a SYNs duplicadosRecuperación frente a SYNs duplicados


Cliente Servidor

tiemp

o

tiemp

o

SYN (seq = 100)

SYN/ACK (seq = 300, ack = 91)

RST (seq = 91)

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

SYN (seq = 90)

ERROR,Espera ack=101

Duplicado

Inicializa el estado

Números de secuencia y envío de datosNú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

Números de secuencia y envío de datos. Cont.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: 613.566 segundos•Línea de 1Mbps: 34.359 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

tiemp

o

tiemp

o

(seq = X)

Duplicado (seq = X)

(seq = X+d1)

(seq = X+d1+d2)

…

(seq = X)

(seq = X)

Tie

mp

o d

e v

ida

de

l d

up

lic

ad

o

Control de flujo en TCPControl 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

Política de transmisión de TCPPolítica de transmisión de TCP


TCP A TCP B

SYN (seq = 0)

•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

LISTEN

CONNECT

SYN/ACK

(seq = 300, ack = 1, WIN=4096)


Ventana de emisión

4096

4096

ACK (seq = 1, ack = 301)



TCP A TCP B

1K (seq = 1)

•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

SEND(buf, 2048)

ACK

(ack = 1025, WIN=3072)


Ventana de emisión

3072

Ventana de emisión

1K (seq = 1025) Ventana de recepción

2048

ACK

(ack = 2049, WIN=2048)Ventana de emisión



TCP A TCP B

1K (seq = 2049)

•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

SEND(buf, 3072)

ACK

(ack = 3073, WIN=1024)

1K (seq = 3073)


1024

ACK

(ack = 4097, WIN=0)

Ventana de emisión

Ventana de emisión


0

Ventana de emisión



TCP A TCP B

•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

1K (seq = 4097)

ACK

(ack = 4097, WIN=2048)


0

Ventana de emisión

RCV(buf, 2048)Ventana de recepción

2048


1024

ACK

(ack = 5121, WIN=1024)

Ventana de emisión

Ventana de emisión

Algunos detalles del protocolo TCPAlgunos 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

1Byte (seq = X)

ACK (ack = X, WIN = 0)

ACK

(ack = X+1, WIN=4095)

ACK

(ack = X, WIN = 4096)

¿BloqueoIndefinido?



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

1Byte (seq = X)1Byte (seq = X+1)

1Byte (seq = X)

ACK (ack = X+1)

1Byte (seq = X+3)

SEND(1byte)

SEND(1byte)

SEND(1byte)

SEND(1byte)

SEND(1byte)

SEND(1byte)

SEND(1byte)

SEND(1byte)

3Bytes (seq = X+1)

ACK (ack = X+4)

Sin

Nag

le C

on

Nag

le



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)

TCP A TCP B

D bytes (seq = X)

SEND(buf)

Sin

Cla

rk

ACK (ack = Y, WIN = 0)

RECV(buf, 1byte)

ACK (ack = Y, WIN = 1)

1 byte (seq = Y)

RECV(buf, 1byte)

ACK (ack = Y+1, WIN = 1)

1 byte (seq = Y+1)

ACK (ack = Y+1, WIN = 0)

Generación de ACKs en TCPGeneració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

Llegada de un segmento en orden conEl nº sec esperado. Todos los datos hasta el nº sec han sido ya ACKed

Llegada de un segmento en orden conEl nº sec esperado. Otro segmento tiene su ACK pendiente de envío

Llegada de un segmento fuera de orden, con nº sec superior al esperado. Se detecta un “hueco”

Llegada de un segmento que rellena un“hueco” total o partialmente

Se retrasa el ACK. TCP espera hasta500ms por si llega otro segmento. Si no, se envía el ACK

Se envía un ACK acumulado inmediatamente

Se envía inmediatamente un ACKduplicado del nº sec del siguiente byteesperado “en orden”

Si el segmento cubre el extremo inferior del “hueco”, se envía inmediatamente un ACK

Acción tomada por el receptor

Extensiones de TCP para altas prestacionesExtensiones 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

RTT

Último bit del pqt, t = L / R

Primer bit del primer pqtÚltimo bit primer pqt envío ACK

ACK llega, envía siguiente paquete, t = RTT + L / R

Extensiones de TCP para altas prestaciones contExtensiones 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

U =emisor

W / R

RTT + L / 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 = (216 - 1) * 8 bits = 524.280 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

RTT*R

W~



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



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”

Liberando la conexión TCPLiberando la conexión TCP


CLOSED

LISTEN

SYN RCVD

SYNSEND

ESTABLISHED

FINWAIT 1

FINWAIT 2

TIMEWAIT

CLOSINGCLOSEWAIT

LASTACK

CLOSED


CONNECT / SYN

CLOSE / -

SYN / SYN + ACK

SYN / SYN + ACK

RST / - SEND / SYN

SYN + ACK / ACK

ACK / -

CL

OS

E /

FIN

CLOSE / FIN

FIN / ACK

ACK / -

FIN / ACK

FIN + ACK / ACK

FIN / ACK

CLOSE / FIN

ACK / -

ACK / -

Temporizador / -

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

Liberación activa Liberación pasiva

Liberando la conexión TCP cont.Liberando la conexión TCP cont.


TCP A TCP P

FIN (seq = X)

ACK (seq = Y, ack = X+1)

ACK (seq = X, ack = Z+1)

Datos/ACK (seq = Y+1, ack = X+1)

ESTABLISHED ESTABLISHED

CLOSE

FIN WAIT 1

CLOSE WAIT

LAST ACK

TIME WAIT

FIN WAIT 2

CLOSED

CLOSE

FIN (seq = Z)

CLOSED

Puede enviar datosPuede recibir datos

Puede enviar datosPuede recibir datos

Puede recibir datos

Puede recibir datos

Puede recibir FIN

Puede enviar datos

Puede enviar FIN

Administración de temporizadores en TCPAdministració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

El algoritmo de JacobsonEl 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

El algoritmo de Jacobson cont.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

El algoritmo de KarnEl algoritmo de KarnSe 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 RTTEjemplo de estimación del RTT


RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT



•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. http://www.thinkingsecure.com/docs/TCPIP-Illustrated-1/.

-Chapters 17, 18, 19, 20, 21, 22, 23 and 24.•Redes de Computadores. Andrew S. Tanenbaum. Prentice Hall, Cuarta Edición, 2003





•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?

Requisitos previosRequisitos 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)

Congestión en redes de paquetes: principio básicoCongestió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

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

tiempo

Estudio de la congestión en redes de paquetesEstudio 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

Router

Cola

Lín

ea

s d

e e

ntr

ad

a

Línea de salida

Modelo de cuello de botella simple

Parámetros que definen el comportamiento de la colaPará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 mide en elementos (paquetes, bits, etc) por segundo•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

Patrones de llegada y de servicioPatrones 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 •Si > La cola, a largo plazo, se irá a infinito

•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

Algunos resultados básicos de teoría de colasAlgunos 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 = TIntuició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

-

Algunos resultados básicos de teoría de colas. Cont.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 - 1 - K+1

iPiK =

•Por tanto, la probabilidad de que un paquete se pierda es:

1 - 1 - K+1

KPPérdida =

•Observa que, en este caso, el tráfico puede tomar valores superiores a 1

Principios de la Congestión en InternetPrincipios 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

Luis Lopez

Hablar de tráfico ofrecidoCon tráfico inferior a 1 también hay congestión

Causas y consecuencias de la congestión: escenario 1Causas y consecuencias de la congestión: escenario 1


Búferes infinitos en el router

Host Ain

Host B

out

•Escenario:•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



•Escenario:•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

in

Retransmisiones

’in’out

out

PerdidosDuplicados

Aplicaciónemisora

Aplicaciónreceptora

Retransmisión perfecta sin duplicados

Retransmisión real con duplicados

’out = out

’in

’out

’in

out

C/2

C/2

Luis Lopez

Es la tasa de salida la que viene limitada por la capacidad de la línea.Cuando el router esté completamente saturado, la tasa de salidad de cada sesión será de C/2Como lamda_out < lambda'_out --> se pierde capacidad de transmisión útil



Búferes finitos

Host Ain :

Host B

out

out

in

•Un paquete perdido hace inútiles los recursos que haya utilizado antes de perderse

Línea lenta

Línea rápida

Mecanismos para el control de congestiónMecanismos 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

Control de congestión en el protocolo TCPControl 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

Mecanismos para el control de congestión en TCPMecanismos 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

Control de Congestión: AIMDControl 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

Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

TCP A TCP B

Comienzo Lento (Slow Start)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

Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

TCP A TCP B

Retransmisión Rápida (Fast Retransmit)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 BTCP A

Luis Lopez

Hacer notar por qué este mecanismo mejora las prestacionesHacer notar que sólo funciona para pérdidas simples

Recuperación Rápida (Fast Recovery)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 BTCP A

Control de congestión en TCP TahoeControl 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

Control de congestión en TCP Tahoe. Cont.Control de congestión en TCP Tahoe. Cont.


Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdAl 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



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdSlow Start:Enviamos 1 segmento, se recibe su ACKCongWin = 2CongWin = 2 MSS



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdSlow Start:Enviamos 2 segmentos, se reciben sus ACKsCongWin = 2CongWin = 4 MSS



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs




Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdPérdida de paquete:Enviamos 16 segmentos, se reciben 3 ACKs duplicadosThreshold = CongWin/2 = 8 MSSCongWin = 1 MSS



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdSlow Start:Tras la detección de la pérdida, se repite el segmentoRecomienza Slow Start partiendo de CongWin=1 MSSSe envía un segmento y se recibe su ACKCongWin = 2CongWin = 2 MSS



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdSlow Start:Si no hay péridas, continua Slow Start hasta que la ventana alcanza el nivel del Threshold



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdAIMD:Comienza el algoritmo de control de congestión AIMDSe envían 8 segmentos se reciben sus ACKsCongWin = CongWin + 1 = 9 MSS



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdAIMD:Continúa el algoritmo de control de congestión hasta que se produce la pérdida de un paqueteThreshold = CongWin/2 = 6 MSSCongWin = 1 MSSSe activa Slow Start



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdSlow Start:Slow Start hace su trabajo hasta que se alcanza el umbral, en ese momento se activa AIMD



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdEl proceso continúa mientras la conexión siga abierta

Control de congestión en TCP RenoControl 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

Control de congestión en TCP Reno. Cont.Control de congestión en TCP Reno. Cont.


Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdAl 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



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdSlow Start:Slow Start realiza su trabajo hasta que se producen pérdidasEn este caso, asumimos que la pérdida se detecta por 4 ACKs



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdFast Recovery:Entra en acción el mecanismo Fast RecoveryCongWin = CongWin/2Se activa AIMD



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdAIMDContinúa el algoritmo AIMD hasta que se produce una pérdidaSi la pérdida es por timeout, recomienza Slow StartTheshold = CongWin/2 = 6 MSSCongWin = 1



Tiempo (RTT)

Co

ng

Win

(M

SS

)

2

4

6

8

10

12

14

16

CongWin

Timeout

4 ACKs

ThresholdContinuamos de este modo mientras la conexión siga activa

Algunos comentarios sobre el control de congestión en TCPAlgunos 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

Prevención de la congestiónPrevenció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 [http://www.cs.arizona.edu/protocols/]

Reparto equitativo de recursos en Internet (Fairness)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

¿Por qué TCP es equitativo?¿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)

Tasa de la conexión 1

Ta

sa

de

la

co

ne

xió

n 1

Repar

to e

quitativ

o

C

C

Additive Increase

Multiplicative Decrease

Pérdida de paquete

Estado inicial injusto

Riesgos para el reparto equitativo de recursos en InternetRiesgos 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


•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?

Lección 3.5: Comentarios y referenciasLección 3.5: Comentarios y referencias•Referencias

•TCP/IP Illustrated, Volume 1: The Protocols. W. Richard Stevens. http://www.thinkingsecure.com/docs/TCPIP-Illustrated-1/.

-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




•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 luis lópez fernández 2005

Documents