TEMA 1: Introducción a las Redes de

Telecomunicaciones

Redes de Ordenadores
 1. Modelo Genérico.
 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

Nivel de Transporte:
Introducción, UDP y TCP
1.1. ¿Qué es una Red de Telecomunicaciones?

 Es una Infraestructura.
 Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

Sistemas de
FUENTE Transmisor Transm Receptor DESTINO

Sistema Origen Sistema Destino

2
Objetivos
Conceptos y principios del nivel de transporte
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones
 1. Modelo Genérico.

> Multiplexación
 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

> Transporte fiable

> Control de flujo
> Control de congestion
‣ Estudio del nivel de transporte en Internet
Protocolos TCP y UDP
1.1. ¿Qué es una Red de Telecomunicaciones?
>
 Es una Infraestructura.
 Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

Sistemas de
FUENTE Transmisor Transmisión Receptor DESTINO

Sistema Origen Sistema Destino

2
Funciones del nivel de transporte
Comunicación lógica
TEMA 1: Introducción Transporte
a las Redes de
‣ Telecomunicaciones
Red
entre aplicaciones  1.
 2.
 3.
 4.
Modelo Genérico.
Clasificación de las Redes de Telecomunicaciones.
Estructura de Internet.
Retardos en Redes de Telecomunicaciones. Enlace

Protocolo en los Canal lógico

 5. Modelo de Referencia TCP/IP.

‣
extremos (end-to-end) Red
Red Enlace
> segmentación
Enlace
> reensamblado Red
‣ 2 niveles de transporte en
1.1. ¿Qué es una Red de Telecomunicaciones?
Red Enlace

Internet 


Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
De una manera eficiente.
Enlace

> TCP  Usando distintas tecnologías (eléctricas, electrónicas,

electromagnéticas, ópticas,…)
Transporte
> UDP Red
Sistemas de
FUENTE Transmisor Transmisión Receptor DESTINO
Enlace
Sistema Origen Sistema Destino

2
Red y transporte
Nivel de red
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones
 1. Modelo Genérico.

Comunicación lógica entre hosts

 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

‣ Nivel de transporte
Comunicación lógica entre procesos
> mejora y utiliza la comunicación entre hosts
App 1 App 1
1.1. ¿Qué es una Red de Telecomunicaciones?

 Es una Infraestructura.
Transporte Proporciona comunicación entre múltiples entidades. Transporte
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

Red Red Red Red Red

Sistemas de
FUENTE Transmisor Transmisión Receptor DESTINO

Sistema Origen Sistema Destino

Enlace Enlace Enlace Enlace Enlace
2
Transporte en Internet
Entrega fiable y en
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones

orden (TCP) Transporte

 1. Modelo Genérico.
 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4.
 5.
Retardos en Redes de Telecomunicaciones.
Modelo de Referencia TCP/IP. Red
> control de congestión Enlace
> control de flujo
> establecimiento de conexión Red
Red Enlace
‣ Entrega no fiable, sin Enlace
garantias de orden 1.1. ¿Qué es una Red de Telecomunicaciones?
Red

(UDP) 



Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
De una manera eficiente.
Usando distintas tecnologías (eléctricas, electrónicas,
Red Enlace

Enlace
> best-effort igual que IP electromagnéticas, ópticas,…)

‣ En los dos casos FUENTE Transmisor

Sistemas de
Transmisión Receptor DESTINO
Transporte
Red
retardo no garantizado
Sistema Origen Sistema Destino

>
2
Enlace
> ancho de banda no garantizado
Funciones TCP/UDP
Función común
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones
 1. Modelo Genérico.

Multiplexación/demultiplexación de
 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

aplicaciones

‣ Funciones sólo UDP

> Envio no orientado a conexión
1.1. ¿Qué es una Red de Telecomunicaciones?

‣ Funciones sólo TCP 




Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
De una manera eficiente.
Usando distintas tecnologías (eléctricas, electrónicas,

> Manejo de conexiones electromagnéticas, ópticas,…)

> Transporte fiable de datos

FUENTE Transmisor
Sistemas de
Transmisión Receptor DESTINO

> Control de flujo y de congestión

Sistema Origen Sistema Destino

2
Multiplexación y demultiplexación
‣ Un host con varias aplicaciones/programas/
TEMA 1: Introducción a las Redes de

procesos corriendo Telecomunicaciones

 1.
 2.
Modelo Genérico.
Clasificación de las Redes de Telecomunicaciones.

> El nivel de red envía los paquetes al nivel de red del ordenador destino
 3.
 4.
 5.
Estructura de Internet.
Retardos en Redes de Telecomunicaciones.
Modelo de Referencia TCP/IP.

> El nivel de transporte arbitra la comunicación entre diferentes aplicaciones

> un nivel de red, un nivel de transporte, varias aplicaciones

Aplicación 1 Aplicación 2 Aplicación 3 Aplicación 4

1.1. ¿Qué es una Red de Telecomunicaciones?

Transporte Transporte
 Es una Infraestructura.
 Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
Red electromagnéticas, ópticas,…) Red

Emisor:
Receptor:
‣ recoger datos de distintas fuentes
Sistemas de
FUENTE Transmisor Transmisión Receptor DESTINO

‣ entregar a la
‣ encapsular con información del
Sistema Origen Sistema Destino

aplicación (socket)
origen
2

correcta
Multiplexación y demultiplexación
El host recibe datagramas IP
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones
 1. Modelo Genérico.

> Cada datagrama IP lleva una

 2.
 3.
Clasificación de las Redes de Telecomunicaciones.
Estructura de Internet.

dirección IP de origen y de destino

 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

Cabecera IP
> Cada datagrama IP lleva un
segmento del nivel de transporte ...
> Cada segmento del niel de puerto origen puerto destino
transporte lleva un puerto origen y
destino (puerto: identificador de cabecera de transporte
proceso/aplicación)1.1. ¿Qué es una Red de Telecomunicaciones?

El nivel de transporte usa

 Es una Infraestructura.

‣ Datos aplicación
 Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,

las direcciones IP y los

electromagnéticas, ópticas,…)

puertos para decidir a FUENTE Transmisor

Sistemas de
Transmisión Receptor DESTINO

quien entrega los datosSistema Origen Sistema Destino

2 Segmento del nivel

de transporte
Demultiplexación no orientada a conexión

Cuando UDP recibe un paquete...

TEMA 1: Introducción a las Redes de
Telecomunicaciones

‣ Se extraen de la cabecera
 1. Modelo Genérico.
 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.

IP la dirección IP destino y proceso 1 proceso 2

 5. Modelo de Referencia TCP/IP.

de la cabecera UDP el
puerto destino
80 6881 1234
‣ Se entregan los datos al sockets
socket identificado por la S1 S2 S3
tupla 1.1. ¿Qué es una Red de Telecomunicaciones?

UDP
 Es una Infraestructura.
(dirIP destino, puerto destino)


Proporciona comunicación entre múltiples entidades.
De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,

Paquetes provenientes de
electromagnéticas, ópticas,…)

‣
diferentes direcciónes origen y Sistemas de

puertos origen se entregan al

FUENTE Transmisor Transmisión Receptor DESTINO

Sistema Origen Sistema Destino

mismo socket 2
 Demultiplexación no orientada a conexión

Ejemplo
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones SP: source port
 1.
 2.
Modelo Genérico.
Clasificación de las Redes de Telecomunicaciones.
DP: destination port
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

P2 P1
P1
P3

SP: 6428 SP: 6428

DP: 9157 DP: 5775
1.1. ¿Qué es una Red de Telecomunicaciones?

SP: 9157  Es una Infraestructura.

SP: 5775
Proporciona comunicación entre múltiples entidades.
DP: 6428 DP: 6428


client Client
De una manera eficiente.

server

 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

IP: A IP: C IP:B

Sistemas de
FUENTE Transmisor Transmi Receptor DESTINO

‣ La dirección origen y puerto origen permiten

Sistema Origen Sistema Destino

responder al cliente
2

/ 11
Demultiplexación orientada a conexión

Cuando TCP recibe un paquete puede pertenecer a

TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones

varias conexiones establecidas  1.

 2.
 3.
 4.
Modelo Genérico.
Clasificación de las Redes de Telecomunicaciones.
Estructura de Internet.
Retardos en Redes de Telecomunicaciones.

‣ Varios sockets con el mismo puerto...

 5. Modelo de Referencia TCP/IP.

proceso 1 proceso 2 proceso 3

23421 80 23421
CNX establecida CNX establecida
S4 S12y3 S5
1.1. ¿Qué es una Red de Telecomunicaciones?
TCP TCP TCP
 Es una Infraestructura.
 Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

Sistemas de
FUENTE Transmisor Receptor DESTINO

Se entrega al socket identificado por la 4-tupla

Transmisión

‣ Sistema Origen Sistema Destino

(dirIP origen, puerto origen, dirIP destino, puerto destino) 2

 Demultiplexación orientada a conexión

Ejemplo
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones
SP: source port
S-IP: source IP
 1. Modelo Genérico.
 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4.
 5.
Retardos en Redes de Telecomunicaciones.
Modelo de Referencia TCP/IP. DP: destination port
D-IP: destination IP

P1 P4 P5 P6 P2 P1P3

SP: 5775
1.1. ¿Qué es una Red de Telecomunicaciones?
DP: 80
S-IP: B
Es una Infraestructura.
D-IP:C

 Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

SP: 9157 SP: 9157

client DP: 80 Sistemas de
DP: 80 Client
server
FUENTE Transmisor Transmisión Receptor DESTINO

S-IP: A S-IP: B
IP: A Sistema Origen

IP: C
Sistema Destino
IP:B
D-IP:C 2
D-IP:C

1
 Demultiplexación orientada a conexión

Otro ejemplo
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones
SP: source port
S-IP: source IP
 1. Modelo Genérico.
 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4.
 5.
Retardos en Redes de Telecomunicaciones.
Modelo de Referencia TCP/IP. DP: destination port
D-IP: destination IP

P1 P4 P2 P1P3

SP: 5775
1.1. ¿Qué es una Red de Telecomunicaciones?
DP: 80
S-IP: B
Es una Infraestructura.
D-IP:C

 Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

SP: 9157 SP: 9157

client DP: 80 Sistemas de
DP: 80 Client
server
FUENTE Transmisor Transmisión Receptor DESTINO

S-IP: A S-IP: B
IP: A Sistema Origen

IP: C
Sistema Destino
IP:B
D-IP:C 2
D-IP:C

1
UDP: User Datagram Protocol
UDP: User Datagram Protocol (RFC-768)
TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones
 1. Modelo Genérico.

Proporciona un servicio de transporte para

 2. Clasificación de las Redes de Telecomunicaciones.

‣  3.
 4.
 5.
Estructura de Internet.
Retardos en Redes de Telecomunicaciones.
Modelo de Referencia TCP/IP.

aplicaciones sobre IP de tipo Best-Effort

> Sin garantizar la entrega
> Sin garantizar el orden de entrega
> Mucho menos con tiempo o con ancho de banda garantizado
Lo único que añade a IP es la multiplexación de aplicaciones y
1.1. ¿Qué es una Red de Telecomunicaciones?
>
detección de errores


Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.

No orientado a conexión
Usando distintas tecnologías (eléctricas, electrónicas,

‣

electromagnéticas, ópticas,…)

> No hay establecimiento

FUENTE Transmisor
Sistemas de
Transmisión Receptor DESTINO

> Cada datagrama se trata independientemente (protocolo sin

Sistema Origen Sistema Destino

estado) 2
UDP
¿Por qué un protocolo como UDP?
TEMA 1: Introducción a las Redes de
Telecomunicaciones
 1. Modelo Genérico.

‣ Es rapido: no hay establecimiento

 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

aunque no garantice el retardo no añade retardos

innecesarios
‣ Es simple: no hay estado de conexión
ni en el emisor ni en el receptor
1.1. ¿Qué es una Red de Telecomunicaciones?

‣ Poco overhead 


Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,

la cabecera UDP ocupa lo mínimo posible

electromagnéticas, ópticas,…)

‣ Es eficiente: no hay control de congestión

Sistemas de
FUENTE Transmisor Transmisión Receptor DESTINO

Sistema Origen Sistema Destino

puede usar todo el ancho de banda que consigas 2

UDP: detalles
32 bits

Formato del paquete

TEMA 1: Introducción a las Redes de
Telecomunicaciones
 1. Modelo Genérico. Cabecera IP
‣ puerto origen
 2. Clasificación de las Redes de Telecomunicaciones.

...
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

‣ puerto destino puerto origen puerto destino

‣ longitud del segmento longitud checksum

segmento UDP
UDP
> 8 - 65535 bytes 1.1. ¿Qué es una Red de Telecomunicaciones?
Datos aplicación
‣ checksum 

Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
De una manera eficiente.

sólo 8 bytes de

 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

cabecera ! FUENTE Transmisor

Sistemas de
Transmisión Receptor DESTINO

Sistema Origen Sistema Destino

2
UDP: checksum 32 bits

Cálculo del checksum

TEMA 1: Introducción a las Redes de
‣ Telecomunicaciones dirección IP origen
 1. Modelo Genérico.
dirección IP destino
> Se trata el segmento como serie de
 2.
 3.
Clasificación de las Redes de Telecomunicaciones.
Estructura de Internet.

0s proto longitud UDP

valores de 16 bits
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

> Suma binaria puerto origen puerto destino

longitud checksum
en complemento a 1
+ pseudo-cabecera con algunos
campos de la cabecera IP (para Datos aplicación
proteger errores en las direcciones
y el protocolo) 1.1. ¿Qué es una Red de Telecomunicaciones?

+ segmento UDP 

Es una Infraestructura.
Proporciona comunicación entre múltiples entidades.
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,

Detecta errores en todo el segmento UDP

electromagnéticas, ópticas,…)

‣
(aunque no todos) FUENTE Transmisor
Sistemas de
Transmisión Receptor DESTINO

Si UDP detecta errores en un paquete

Sistema Origen Sistema Destino

‣ 2

recibido no lo entrega
UDP
En que se usa UDP ?
TEMA 1: Introducción a las Redes de
Telecomunicaciones
 1. Modelo Genérico.

‣ Aplicaciones de streaming multimedia (audio/

 2. Clasificación de las Redes de Telecomunicaciones.
 3. Estructura de Internet.
 4. Retardos en Redes de Telecomunicaciones.
 5. Modelo de Referencia TCP/IP.

video en tiempo real o audio/video-

conferencia)
> tolerantes a las pérdidas y sensibles al ancho de banda
‣ Mensajes de DNS 1.1. ¿Qué es una Red de Telecomunicaciones?

> bajo retardo y poco overhead

 Es una Infraestructura.

SNMP (monitorización de red)

 Proporciona comunicación entre múltiples entidades.

‣
 De una manera eficiente.
 Usando distintas tecnologías (eléctricas, electrónicas,
electromagnéticas, ópticas,…)

> poco overhead y protocolo sencillo Sistemas de

FUENTE Transmisor Receptor DESTINO

Juegos en red
Transmisión

‣ Sistema Origen Sistema Destino

> mínimo retardo posible

2
 Transporte fiable
‣ ¿Se puede conseguir un transporte fiable sobre
un nivel de datagramas de entrega no fiable?

t_envia(datos)
t_recibe(datos)
Nivel de
Transporte
r_envia(datos) r_recibe(datos)

Nivel de Red

Entrega no garantizada
se pueden perder datos
 Protocolo de transporte fiable
‣ Descripción con máquinas de estados finitos. Notación
Un Otro
estado estado

Una transición
Evento que causa la transición

Acciones que provoca la transición

‣ Ejemplo: protocolo de transporte sobre un nivel de red

fiable Receptor r_recibe(p)
Emisor t_envia(datos) datos= extrae(p)
Espera t_recibe(datos)
p= paquete(datos)
r_envia(p) llegada
Espera de datos
llamada
de app
red fiable:
r_envia(p) siempre causa un r_recibe(p)
10 octubre 2005 Transporte-2 4 /24
Errores de bit
)P nivel de red puede cambiar bits
(probabilidad de error)
‣ Cambios necesarios en el protocolo de
transporte
> Detección de errores
+ Uso de checksum

> Comunicación de fallos al emisor

+ ACK (acknowledgement): avisar al emisor de los paquetes que
recibimos
+ NACK (negative acknowledgement): avisar al emisor de los
paquetes que no recibimos
> Reenvío de paquetes
Protocolo de transporte fiable
‣ Para un canal con errores de bits
Emisor t_envia(datos)

p= paquete(datos) r_recv(datos) == NACK

r_envia(p)
r_envia(p)
Espera Espera
llamada ACK o
de app NACK

r_recv(datos) == ACK
Receptor r_recibe(p) sin error

nada datos= extrae(p)

Espera t_recibe(datos)
r_recibe(p) con error llegada r_envia(ACK)
de datos
r_envia(NACK)

‣ Más conocido como Stop-and-Wait

‣ ¿Tiene algun problema este protocolo?
Problemas con stop-and-wait
‣ ¿Qué pasa si hay un error en la transmisión del
ACK o NACK?
‣ ¿Qué pasa si el canal puede perder paquetes?
‣ Soluciones complican el protocolo
> Detección de errores para ACK y NACK?
> Checksums que permitan no solo detectar sino corregir errores?
> Reenviar los datos si no entiendo el ACK/NACK ??
+ Nuevo problema: paquetes duplicados

‣ Los protocolos más usados utilizan contra esto

numeros de secuencia del paquete
Protocolo con número de secuencia
‣ Cada paquete de datos lleva un numero de
secuencia 0 o 1
> Si llega el que esperamos mandamos ACK y lo entregamos
> Si llega el que no esperamos mandamos ACK pero no son datos
nuevos
r_recibe(datos)
sin error y seq 0
datos= extrae(p)
r_recibe(datos)
r_recibe(datos) t_recibe(datos)
con error
con error r_envia(ACK)
r_envia(NACK)
r_envia(NACK)
Espera Espera
paquete paquete
0 1
r_recibe(datos)
r_recibe(datos)
sin error y seq 1
sin error y seq 0
r_envia(ACK) r_recibe(datos)
sin error y seq 1 r_envia(ACK)

datos= extrae(p)
t_recibe(datos)
r_envia(ACK)
Protocolo con número de secuencia
‣ Estados del emisor
t_envia(datos)

p= paquete(datos,0) r_recibe(datos)
r_envia(p) con error o ack 1
r_envia(p)
Espera
Espera
datos
ACK 0
app 0
r_recibe(datos)
r_recibe(datos) sin error y ack 0
sin error y ack 1

Espera
Espera
datos
ACK 1
app 1

r_recibe(datos)
con error o ack 0 t_envia(datos)
r_envia(p) p= paquete(datos,1)
r_envia(p)
Protocolo con número de secuencia
‣ Podemos eliminar los
NACKs
> En lugar de un ACK enviamos ACK
y la secuencia del siguiente paquete s0
ack1
que esperamos recibir
s1
> En lugar de un NACK enviamos ack0
ACK y la secuencia del siguiente s0
paquete que esperamos recibir ack0
> El emisor sabe que tiene que s0
reenviar si recibe el ACK del ack1
paquete que no espera
‣ Problema pendiente:
¿Qué pasa si se pierde un
paquete?
Pérdidas de paquetes
‣ Si se pierde un paquete el emisor se queda
bloqueado en un estado
‣ Para romper el bloqueo usamos un
temporizador en el emisor
> Al enviar un paquete de datos ponemos en marcha un temporizador
> Si transcurrido un tiempo, no se ha recibido ACK (TIMEOUT),
reenviamos el paquete
‣ El receptor no se modifica
Protocolo con timeout
‣ Emisor con t_envia(datos) r_recibe(datos)

retransmisión por
con error o ack 1
p= paquete(datos,0)
r_envia(p)

timeout inicia_temp()
timeout
Espera r_envia(p)
Espera
datos inicia_temp()
ACK 0
app 0
r_recibe(datos)
r_recibe(datos) sin error y ack 0
sin error y ack 1
para_temp()
para_temp()
Espera
Espera
timeout datos
ACK 1
app 1
r_envia(p)
inicia_temp()
t_envia(datos)
r_recibe(datos) p= paquete(datos,1)
con error o ack 0 r_envia(p)
inicia_temp()
Ejemplos Emisor
r_send(paq0) paq0
Receptor

r_recv(paq0)
Emisor Receptor ack0 r_send(ack0)
r_send(paq0) paq0 r_recv(ack0)
r_recv(paq0) r_send(paq1) paq1 perdido
ack0 r_send(ack0)
r_recv(ack0)
r_send(paq1) paq1
r_recv(paq1)
ack1 r_send(ack1) timeout paq1
r_recv(ack1) r_send(paq1)
paq0 r_recv(paq1)
r_send(paq0)
ack1 r_send(ack1)
r_recv(paq0) r_recv(ack1)
ack0 paq0
r_send(ack0) r_send(paq0)
r_recv(paq0)
ack0
r_send(ack0)

Operación normal

Pérdida de paquete
1
Ejemplos Emisor
r_send(paq0) paq0
Receptor
Emisor Receptor r_recv(paq0)
r_send(paq0) paq0 ack0 r_send(ack0)
r_recv(ack0)
r_recv(paq0)
ack0 r_send(paq1) paq1
r_send(ack0)
r_recv(ack0)
r_send(paq1) paq1
r_recv(paq1) r_recv(paq1)
ack1 ack1 r_send(ack1)
r_send(ack1)
perdido timeout paq1
r_send(paq1)
timeout
paq1 r_recv(ack1) paq0 r_recv(paq1)
r_send(paq1) r_recv(paq1) r_send(paq0) (detecto duplicado)
ack1 r_send(ack1) r_send(ack1)
r_recv(ack1) ack1
paq0 r_recv(ack1)
r_send(paq0) ignorado
r_recv(paq0) ack0
ack0 r_send(ack0)

Pérdida de ACK Timeout prematuro

1
Prestaciones
‣ El protocolo anterior es fiable pero es muy poco
eficiente
‣ Ejemplo:
Enlace de 1Gbps con un retardo de 15ms (4500Km),
paquetes de 1000 bytes
A que velocidad puedo enviar?

RoundTripTime
=30ms

tam 8000bits
v= = = 266Kbps
RoundTripTime .03s 0.026% !! :-(
Protocolos más eficientes
‣ Para aumentar la eficiencia, se envían varios
paquetes mientras llega el ACK
Varios paquetes en la red por confirmar
> Se usan más números de secuencia que 0 y 1
> Emisor y receptor necesitarán buffer para varios paquetes
> Varias políticas para reaccionar a los errores
+ Go-Back N Emisor Receptor
paq 0
+ Selective reject paq 1 ack 0
paq 2
paq 3
Go back-N
‣ Se utiliza número de secuencia en el paquete
‣ Se permite una ventana de N paquetes sin
confirmar
‣ Cada ACK confirma todos los paquetes
anteriores (cumulative ACK)
‣ Cada paquete inicia su propio timeout
‣ Si caduca el timeout de un paquete se
retransmiten todos los siguientes
Go back-N
‣ Ventana deslizante
enviados se pueden
no ACKed enviar

transmitidos no se pueden
ACKed Ventana de N paquetes enviar

Llega este ACK Timeout del primer paquete

pueden enviarse
nuevos paquetes

La ventana se desliza hacia Volvemos a enviar

mayores números de secuencia
Go back-N
Ventana de 4 paquetes Emisor Receptor
paq 0
paq 1 ack 0
paq 2 ack 1
paq 3
paq 4 ack 1
paq 5 ack 1
ack 1
timeout paq 2
paq 2
paq 3 ack 2
paq 4 ack 3
paq 5 ack 4
...
Selective Reject
‣ El receptor confirma (ACK) individualmente
cada paquete
> Mantiene en buffer los paquetes recibidos a la espera de reconstruir
la secuencia y pasarlos al nivel de aplicación

paquetes recibidos que no pueden

Ventana
pasarse todavía al nivel de aplicacion
‣ Se reenvian los paquetes no confirmados por
timeout
> Timeout individual por cada paquete
‣ Ventana de N paquetes que pueden enviarse
sin recibir ACK
Selective Reject
‣ Ventana deslizante del emisor
enviados confirmados se pueden
no ACKed ACKed enviar

transmitidos no se pueden
ACKed Ventana de N paquetes enviar
‣ Ventana deslizante del receptor
recibidos y confirmados
esperados en espera de poder entregarse
aceptables

confirmados no aceptables
y entregados Ventana de N paquetes fuera de la ventana
Selective reject
Ventana de 4 paquetes Emisor Receptor
paq 0
paq 1 ack 0
paq 2 ack 1
paq 3
paq 4 ack 3
paq 5 ack 4
ack 5
timeout
paq 2
ack 2

paq 5
...
El problema del selective reject
0 1 2 3 0 1 2 3

‣ Número de secuencia 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
finito 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
‣ Ejemplo
> seq= {0,1,2,3} 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
> N=3
paq duplicado
‣ El receptor no puede entregado !!!
notar la diferencia entre
los dos escenarios 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
‣ Y entrega datos 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
duplicados como buenos 0 1 2 3 0 1 2 3

‣ Que relación debe haber 0 1 2 3 0 1 2 3

entre #secuencia y N? 0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3
0 1 2 3 0 1 2 3

paq correcto
entregado
TCP
‣ Protocolo de transporte de Internet (RFC 793)
‣ Transporte fiable
> Entrega garantizada
> Entrega en orden
‣ Orientado a conexión
> Stream bidireccional (como si fuera un fichero) entre los dos
extremos
> No mantiene las fronteras de los mensajes
‣ Con control de flujo y congestión
TCP
‣ Interfaz con el nivel de aplicación
> Tras establecer una conexión proporciona un stream bidireccional entre sockets
> Sin fronteras entre mensajes
> 2 buffers por conexión
+ Escribir en el socket pone los datos en buffer de envio
+ Buffer de recepción para esperar el read()

TCP TCP
connexión
connexión
connexión
connexión connexión
connexión

IP IP IP IP
TCP
‣ Demultiplexación de datos que llegan a TCP:
> Se identifica al socket destino por la tupla
( IP origen, puerto origen, IP destino, puerto destino )

> La tabla de tuplas (ip,puerto,ip,puerto) con sus sockets de un nivel TCP es la tabla
de conexiónes.

‣ La conexión sólo existe en los extremos TCP

write(datos) read(datos)
puertos A1 A2 A3 puertos B1 B3

TCP connexión
TCP
connexión
connexión Tabla de connexión
connexión

conexiones
IPB, puertoB1, IPA, puertoA1 : cnx1 IPA, puertoA1, IPB, puertoB1 : cnx1
IPB, puertoB3, IPA, puertoA2 : cnx2
IPX, puertoP , IPA, puertoA3 : cnx3
Paquete a IPB IPA, puertoA2, IPB, puertoB3 : cnx2
...
puertoB3
recibido paquete

host IPA host IPB

TCP
‣ Los buffers aislan a TCP de las operaciónes del
usuario.
> TCP hará lo posible por enviar los datos cuando pueda
> TCP colocara los datos en el buffer de recepción cuando lleguen
‣ Para realizar esto TCP necesitara un conjunto
de mensajes para comunicarse con el TCP del
otro lado
> Mensajes de establecimiento y cierre de conexión
> Mensajes de datos
> Mensajes con ACKs
‣ Veamos los mensajes del protocolo TCP
TCP 32 bits

‣ Segmento TCP Cabecera IP

‣ Cabecera de tamaño ...
variable puerto origen puerto destino

Cabecera TCP
obligatorios
> 20 hasta 60 bytes según las numero secuencia
opciones

20 bytes
numero ack
‣ Datos del nivel de HL nada flags ventena recep.
aplicación checksum urgent data ptr
opciones

Datos aplicación
TCP
Contenido Cabecera IP
‣ Datos de ...
multiplexación puerto origen puerto destino
> Puerto origen numero secuencia
> Puerto destino numero ack
HL nada flags ventena recep.
checksum urgent data ptr
opciones

Datos aplicación
TCP
Contenido Cabecera IP
‣ Datos para transporte ...
fiable puerto origen puerto destino
> Número de secuencia numero secuencia
> Número de ACK numero ack
> Checksum HL nada flags ventena recep.
Cabecera + datos de applicación + checksum urgent data ptr
algunos datos de IP (pseudo cabecera
como en UDP) opciones
‣ En un mismo paquete
podemos mandar datos y Datos aplicación
confirmar datos del
sentido contrario
TCP
Contenido Cabecera IP
‣ FLAGs: diferentes tipos ...
de paquetes del puerto origen puerto destino
protocolo numero secuencia
> URG urgente numero ack
> ACK acknowledgement HL nada flags ventena recep.
checksum urgent data ptr
> PSH push
> RST reset opciones
> SYN syn
Datos aplicación
> FIN fin
TCP
Contenido Cabecera IP
‣ Control de flujo ...
> ventana de recepción puerto origen puerto destino
numero secuencia
‣ Datos urgentes numero ack
‣ HL (header length) HL nada flags ventena recep.
> Tamaño de la cabecera (en checksum urgent data ptr
palabras de 4 bytes)
opciones
> 4 bits de de 5 a 15 palabras
de 20 a 60 bytes Datos aplicación
‣ Opciones extras
TCP
‣ Permiten especificar operaciones y tipos de
paquetes que se han ido añadiendo
posteriormente al protocolo
‣ Las opciones se colocan seguidas. 2 formatos
> opciones de 1 byte tipo

> opciones de varios bytes tipo longitud variable

‣ Opciones básicas
> Fin-de-la-lista de opciones 00000000

> No-operacion (para rellenar) 00000001

> Maximum segment size 00000010 00000100 max seg size

Permite descubrir el tamaño máximo de segmento en una conexión

TCP: envío de datos
‣ No hay separación de paquetes. Los bytes a enviar se
colocan en el buffer y forman una corriente de bytes
sin fronteras de paquetes
‣ El número de secuencia y el numero de ACK hacen
referencia al byte concreto
0 17 51 Buffer
Datos de aplicacion a enviar al otro extremo... y no tienen fronteras de mensajes...

seq # =17
on a enviar al otro extremo... y n

o tienen fronteras de mensajes

Segmentos TCP
seq # =51
TCP: envío de datos
‣ Secuencia y ACK: campos de 32 bits
> 4 Gb de datos para dar la vuelta
> La secuencia no empieza de 0 sino que se genera al azar al principio
de cada conexión y para cada sentido
‣ El campo ACK
> es valido si esta activado el flag ACK
> indica la próxima secuencia que el receptor espera recibir
cumulative ACK: Go back N a nivel de byte
‣ Si una conexión está transmitiendo en ambos
sentidos los ACKs de un sentido van en los
paquetes de datos del opuesto piggyback
Ejemplo
‣ Paquetes de un telnet desde 10.1.1.253 a 10.1.1.22

Cliente conexión establecida Servidor

el usuario seq=6 ack=16 datos=’c’
pulsa la letra ‘c’ el servidor recibe la
letra ‘c’ y se la envia al
seq=16 ack=7 datos=’c’ usuario para que
aparezca en pantalla
el cliente del usuario
seq=7 ack=17 nodatos
confirma la recepción
Ejemplo
‣ Paquetes de un telnet desde 10.1.1.253 a 10.1.1.22
‣ Usando tcpdump para ver los paquetes

Tiempo secuencia paquete

ack sin datos

1124031783.543465 10.1.1.253.48129 > 10.1.1.22.23: P 6:7(1) ack 16 win 1460

1124031783.544283 10.1.1.22.23 > 10.1.1.253.48129: P 16:17(1) ack 7 win 5792
1124031783.544303 10.1.1.253.48129 > 10.1.1.22.23: . ack 17 win 1460
1124031783.652335 10.1.1.253.48129 > 10.1.1.22.23: P 7:8(1) ack 17 win 1460
1124031783.653109 10.1.1.22.23 > 10.1.1.253.48129: P 17:18(1) ack 8 win 5792
1124031783.653123 10.1.1.253.48129 > 10.1.1.22.23: . ack 18 win 1460
1124031783.798259 10.1.1.253.48129 > 10.1.1.22.23: P 8:10(2) ack 18 win 1460
1124031783.798918 10.1.1.22.23 > 10.1.1.253.48129: P 18:20(2) ack 10 win 5792
1124031783.798932 10.1.1.253.48129 > 10.1.1.22.23: . ack 20 win 1460

Origen Destino
{ ip, puerto } { ip, puerto }
Datos urgentes
‣ Si URG está activado. Cabecera IP
El paquete lleva datos urgentes.
>
...
Canal de datos Out-of-band
> El puntero urgente indica donde puerto origen puerto destino
acaban los datos urgentes numero secuencia
> Los datos normales se entregan numero ack
normalmente en el buffer para la
aplicación HL nada flags ventena recep.
> Los datos urgentes se entregan aparte checksum urgent data ptr
opciones
‣ No se usa mucho
En sockets los datos Datos urgentes
urgentes hay que pedirlos
con setsockopt Datos normales
TCP: transporte fiable
‣ TCP utiliza una ventana deslizante
> Número de secuencia: el primer byte enviado en el segmento
> ACK: el próximo byte que espera recibir el receptor
‣ Los paquetes TCP llevan
> Número de secuencia de los datos. Si no llevan datos, el campo número
de secuencia indica el proximo numero de secuencia que se enviará
> Próximo número de secuencia que espera recibir su emisor. Es válido si
el byte ACK está activado
> Los números de secuencia son independientes en ambos sentidos
‣ Transmisiones simultáneas en los dos sentidos
Cada extremo funciona como un emisor y un
receptor independientes
TCP: emisor
‣ Eventos en el emisor timeout
‣ retransmitir el
Llegan datos desde el segmento que causó el
nivel de aplicacion timeout
‣ crear segmento nuevo ‣ reiniciar timeout
‣ sec # el siguiente de la
stream recibido ACK
‣ iniciar temporizador si ‣ Si confirme un
no hay uno iniciado segmento nuevo
> actualizar ventana
EcumulativE ACK
> reiniciar timeout si
quedan segmentos
por confirmar
 Ejemplos
Emisor Receptor
sendbase=92
8bytes sec
Emisor Receptor =92
20bytes dat
sendbase=92 sec os
=10 8B 0
8bytes sec=92 datos 8B 10
0 d a c k
ato
ack 100 s2
timeout 0B
sec
=92
dat
os 8
sec=92 datos 8B sendbase=100 B
timeout 1 2 0
ac k
ack 100 sendbase=120
12 0
sendbase=100 a c k
sendbase=120

pérdida de ACK timeout prematuro

 Ejemplos
Emisor Receptor
sendbase=92
Emisor Receptor 8bytes sec
=92
sendbase=92 dat
8bytes sec sec os
=92 20bytes =10 8B
dat 0 d
os 8 ato
20bytes sec B s2
=10 0B
0 d ack 100
ato
s 20 k 1 00
B ac 20
k 1
timeout sendbase=100 ac
timeout datos
ack 120 pendientes
sendbase=120 sec
=10
timeout 0 d
ato
cancelado s2
0B
ACK acumulado
reinicio timeout
TCP: varias retransmisiones
‣ El timeout se dobla Emisor Receptor
cada vez que caduca y
se envía de nuevo el
paquete
Exponential
backoff
TCP: receptor
‣ Eventos del receptor
> Llega segmento en orden con el numero de secuencia esperado
No hay ACKs pendientes de enviar
último ACK Acción: Delayed ACK, espera hasta
enviado
500ms al siguiente paquete, si no llega
manda ACK
último byte
recibido
> Llega segmento en orden con el numero de secuencia esperado
Hay un delayed ACK pendiente
último ACK
enviado
Acción: envía inmediatamente ACK
(al ser acumulado confirma los dos)
último byte
recibido
TCP: receptor
‣ Eventos del receptor
> Llega segmento fuera de orden generando hueco
último ACK
enviado
Acción: envía inmediatamente ACK
causando ACK duplicado
último byte
recibido ACK #
> Llega segmento rellenando hueco
último ACK
enviado Acción: envía inmediatamente ACK

ACK #
> Llega segmento ya reconocido Acción: ignorar
TCP: Fast retransmit
Emisor Receptor
‣ El timeout normalmente
es relativamente largo
> Si se pierde un paquete de datos ack 100
se genera hueco y se detendrá la
transmisión durante un timeout ack 200
> Normalmente el emisor envía
varios paquetes seguidos ack 200
ack 200
‣ El receptor no puede ack 200
hacer un NACK pero ack 200
está generando ACKs
duplicados !!
timeout
TCP: Fast retransmit
Emisor Receptor
‣ Fast retransmit
> Si el emisor recibe 3 ACKs con el
mismo numero de ACK supondrá
que se ha perdido el paquete que ack 100
llevaba ese numero de secuencia ack 200
> Reenvia el paquete
inmediatamente sin esperar a que ack 200
caduque el timeout
3 dup ACKs !!! ack 200
= fast retransmit ack 200
ack 200
recibidos todos ack 700
timeout cancelado
TCP: timeout
‣ ¿Qué timeout se debe usar?
> Suficiente para que el paquete llegue a su destino y el ACK vuelva.
A este tiempo se le denomina tiempo de ida y vuelta o
Round Trip Time (RTT)
> El RTT depende de muchos factores
+ velocidad de la red

+ tiempos de respuesta del destino RTT

+ tiempos de espera en routers

> Muy variable, incl entre origen y destino fijos

> timeout < RTT
retransmisiones innecesarias
> timeout >> RTT
reacción lenta ante las pérdidas
TCP: timeout
‣ Solución: estimar el RTT y
adaptar el timeout al valor
de RTT estimado
SampleRTT1

‣ Estimando el RTT
> Se toma una muestra SampleRTT por SampleRTT2
cada vez que se envía un segmento
hasta que llega su correspondiente
ACK
+ Se ignora la muestra si el segmento
se retransmite
+ Se mide con delayed acks Descartado por
(overestimation) retransmisión
+ Sólo se puede medir una muestra a SampleRTT3
la vez (1 solo timer)
y normalmente con precisión de
500ms
TCP: estimación RTT
‣ El valor medido SampleRTT varía
queremos un RTT estimado suave
> Utilizamos el promedio de varias muestras
Exponential weighted moving average
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

> La influencia de muestras pasadas decrece exponencialmente

> Típicamente: α= 0.125
 TCP: estimación de RTT
‣ Ejemplo

24 octubre 2005 Transporte-4 15 /17

TCP: estimación de RTT
‣ Eligiendo el timeout
> EstimatedRTT mas un márgen de seguridad
+ A mayor variación de EstimatedRTT mayor debe ser el margen
de seguridad
+ Estimamos la variación de EstimatedRTT con
DevRTT = (1-β)*DevRTT +
β*|SampleRTT-EstimatedRTT|

(typically, β = 0.25)

‣ Se toma como timeout

TimeoutInterval = EstimatedRTT + 4*DevRTT
TCP: Control de flujo
‣ El receptor de TCP tiene un buffer en el que TCP va
colocando los datos que llegan.
> Estos datos se le entregan al nivel de aplicación al hacer un read() sobre el socket
> La aplicación puede ser lenta al leer los datos. Qué pasa si los datos llegan y no hay
buffer?
> Hace falta un mecanismo que ajuste la velocidad de los datos que llegan a la velocidad a
la que lee la aplicación

‣ Este es el problema del control de flujo.

> Es un problema general de los protocolos de comunicaciones
> Normalmente se resuelve haciendo que el receptor sea capaz de enviar indicaciones al
emisor de que su buffer se esta llenando para que este reduzca la velocidad de envío
read()

buffer de recepción
TCP: Control de flujo
‣ TCP informa al emisor de cuanto Cabecera IP
...
buffer tiene libre en cada puerto origen puerto destino

paquete que le envía !! numero secuencia

numero ack

> Esa es la función del campo ventana de HL nada flags ventena recep.
checksum urgent data ptr
recepción de la cabecera opciones

> En cada paquete el receptor anuncia cuantos Datos aplicación

datos es capaz de recibir
> Este valor se utiliza como máximo numero de
bytes que se pueden tener en la red sin recibir
ACK. Máximo de la ventana deslizante
ventana anunciada

buffer de recepción
Ejemplo
‣ De una transferencia de página web
1124207801.184011 IP 130.206.169.177.53611 > 130.206.166.105.80: . ack 1 win 65535
1124207825.463815 IP 130.206.169.177.53611 > 130.206.166.105.80: P 1:39(38) ack 1 win 65535
1124207825.464062 IP 130.206.166.105.80 > 130.206.169.177.53611: . ack 39 win 24616
1124207825.466289 IP 130.206.166.105.80 > 130.206.169.177.53611: P 1:291(290) ack 39 win 24616
1124207825.466784 IP 130.206.166.105.80 > 130.206.169.177.53611: . 291:1739(1448) ack 39 win 24616
1124207825.466915 IP 130.206.166.105.80 > 130.206.169.177.53611: P 1739:3187(1448) ack 39 win 24616
1124207825.511610 IP 130.206.169.177.53611 > 130.206.166.105.80: . ack 3187 win 63422
1124207825.512278 IP 130.206.166.105.80 > 130.206.169.177.53611: . 3187:4635(1448) ack 39 win 24616
1124207825.512382 IP 130.206.166.105.80 > 130.206.169.177.53611: . 4635:6083(1448) ack 39 win 24616
1124207825.512503 IP 130.206.166.105.80 > 130.206.169.177.53611: . 6083:7531(1448) ack 39 win 24616
1124207825.512626 IP 130.206.166.105.80 > 130.206.169.177.53611: P 7531:8979(1448) ack 39 win 24616
1124207825.711709 IP 130.206.169.177.53611 > 130.206.166.105.80: . ack 8979 win 57630
1124207825.712371 IP 130.206.166.105.80 > 130.206.169.177.53611: . 8979:10427(1448) ack 39 win 24616
1124207825.712474 IP 130.206.166.105.80 > 130.206.169.177.53611: . 10427:11875(1448) ack 39 win 24616
1124207825.712595 IP 130.206.166.105.80 > 130.206.169.177.53611: . 11875:13323(1448) ack 39 win 24616
1124207825.712723 IP 130.206.166.105.80 > 130.206.169.177.53611: . 13323:14771(1448) ack 39 win 24616
1124207825.712842 IP 130.206.166.105.80 > 130.206.169.177.53611: P 14771:16219(1448) ack 39 win 24616
1124207825.911783 IP 130.206.169.177.53611 > 130.206.166.105.80: . ack 16219 win 50390

‣ Conforme recibo datos se va llenando el buffer

TCP: Control de flujo
‣ El campo para anunciar RTT
ventana sólo tiene 16
bits
> Solo puede anunciar 65KBytes !!!
(el numero de secuencia direcciona La máxima velocidad
4GB) de transferencia es:
Podían ser suficientes en los
ventanamax
>
primeros tiempos de TCP...
v=
‣ Consecuencias RT T
> no hay que preocuparse del
overlflow de numero de secuencia
En el ejemplo de 1Gbps y 30 ms
> si hay que preocuparse por las
velocidad de transferencia 65535bytes
v= ≈ 17.5Mbps
30ms
Al menos llegamos al 17%
TCP: conexiones
‣ Hasta ahora hemos visto los mecanismos de
transporte fiable y control de flujo entre un emisor y
un receptor TCP.
‣ TCP es orientado a conexión
‣ Previamente comunicarse datos entre un emisor y un
receptor deben negociar un establecimiento de
conexión.
> TCP inicializa sus variables para la conexión y crea los buffers
> Esto se hace mediante los paquetes que utilizan los flags SYN, FIN y RST
> Protocolo para establecer la conexión
> Protocolo para liberar la conexión
TCP: establecimiento de conexión
‣ Mecanismo: Three way handshake
> Lado cliente (socket que hace connect) SYN
envía un paquete sin datos con el flag SYN
Establece el numero de secuencia inicial
ACK+SYN
> Lado servidor (socket que hace accept)
responde con un paquete sin datos con ACK y SYN
ACK
Establece el numero de secuencia inicial
> Lado cliente reconoce este paquete con un ACK
Este paquete ya puede llevar datos
> Al recibir el ACK el servidor puede enviar ya datos

> Los SYNs gastan un número de secuencia para poder

confirmarse con ACKs
 Ejemplo
‣ Otra conexión web... Los SYNs usan un número
de secuencia para poder ser
confirmados
SYN
IP ...177.53656 > ...105.80: S 3482203897:3482203897(0) win 65535
SYN
IP ...105.80 > ...177.53656: S 3356369201:3356369201(0) ack 3482203898 win 24616
+ACK
IP ...177.53656 > ...105.80: . ack 3356369202 win 65535 ACK
IP ...177.53656 > ...105.80: P 3482203898:3482204138(240) ack 3356369202 win 65535
IP ...105.80 > ...177.53656: . ack 3482204138 win 24616
IP ...105.80 > ...177.53656: P 3356369202:3356369502(300) ack 3482204138 win 24616
IP ...105.80 > ...177.53656: . 3356369502:3356370950(1448) ack 3482204138 win 24616
IP ...105.80 > ...177.53656: P 3356370950:3356372398(1448) ack 3482204138 win 24616

Aqui empieza la transferencia

Paquete 4
Cierre de la conexión
FIN
‣ Cualquiera de los dos
extremos puede ACK+FIN

iniciarlo
> Envia un paquete sin datos con
el flag FIN. Consume tambien ACK
un numero de secuencia
> El otro extremo, confirma
enviando un ACK e indica que FIN
cierra tambien con otro FIN.
Este segundo FIN puede ir en
el mismo paquete o en otro. ACK
> El extremo original confirma FIN
con un ACK

ACK
Cierre de la conexión
&LHUUHGH&RQH[LyQ
FIN

‣ Medio cierre ACK

> El cierre de cada sentido de la
conexión es en realidad datos
independiente
> Un extremo puede cerrar la
conexión indicando que no enviara
mas datos pero puede seguir ACKs
recibiendo lo que le envian
close(s)
FIN

ACK
 Ejemplo
‣ El final de una conexión web...
El cliente decide cerrar y manda un FIN
...
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.169.177.53701 > 130.206.166.105.80:
IP 130.206.169.177.53701 > 130.206.166.105.80:
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.166.105.80 > 130.206.169.177.53701:
IP 130.206.169.177.53701 > 130.206.166.105.80:
El servidor cierra su sentido
El servidor está enviando datos
P 80314174:80315622(1448) ack 4067364561 win 24616
P 80315622:80316551(929) ack 4067364561 win 24616
. ack 80316551 win 65535
F 4067364561:4067364561(0) ack 80316551 win 65535
. ack 4067364562 win 24616
F 80316551:80316551(0) ack 4067364562 win 24616
. ack 80316552 win 65535
TCP: abortar una conexión
‣ Paquete Reset (RST)
> Se envía cuando TCP recibe un paquete que datos
es inconsistente con su estado de la
conexión
recibir datos sin tener conexión abierta RST
> Le dice al otro extremo que esa conexión
no existe y que destruya toda la
información de ese estado de conexión
> También se usa para decir que no hay nadie
escuchando un puerto
> También se puede usar por el nivel de
aplicación para cerrar una conexión de
forma rápida
> El otro extremo no hace falta que conteste
nada
TCP: establecmimiento de conexión
‣ ¿Qué pasa si se pierden paquetes del
establecimiento o del cierre?
> Tienen un número de secuencia así que se pueden retransmitir. Es como si
fueran un byte de datos.
> Se utiliza retransmisión por timeout
‣ Retransmision de SYNs
> Problema: al comenzar la conexión no ha habido tiempo de hacer
estimaciones del RTT.
La mayoría de las implementaciones utilizan un timeout inicial de 6
segundos. Si falla el timeout se pone a 24 segundos y se va doblando
‣ Retransmision de FINs
> Problema: el sistema operativo no puede deshacerse del estado de la
conexión inmediatamente. Tiene que mantenerlo un tiempo por si acaso
hacen falta retransmisiones
TCP estados

TCP Estados
del servidor

TCP Estados
del cliente
 TCP: establecimiento de conexión
‣ Casos especiales: apertura simultánea
> Si dos clientes inician simultaneamente una conexión entre ellos
> Nótese que los dos tienen que usar puertos conocidos por el otro
> Se usa muy poco

connect() SYN
SYN connect()
ACK+SYN

ACK+SYN
conexión establecida
ACK conexión establecida

ACK
TCP: establecimiento de conexión
‣ Casos especiales: cierre simultáneo
> Los dos extremos deciden cerrar a la vez
> Los dos extremos deben esperar en TIME_WAIT para poder
retransmitir el FIN

close() FIN
FIN close()
ACK

ACK
TIME_WAIT
TIME_WAIT
¿Por qué se pierden los paquetes?
‣ Varias causas
> Errores de transmisión.
Modifican bits aleatorios de los
paquetes. Los niveles que hacen
detección de errores se ven obligados
a descartar el paquete al no estar R1
seguros de entregarlo correctamente Para R3 R2
Independiente del tráfico R3
R3
> Desbordamiento de buffer R1 R4

Un router que debe reenviar un

paquete se encuentra con que todos
sus recursos de memoria (por R2 R4
ejemplo en la cola de paquetes
esperando la salida están ocupados).
Debe descartar el paquete por falta
de recursos
Dependiente de la carga de la
red
Congestión de red
¿Qué es?
‣ Demasiadas fuentes enviando demasiado trafico
para que la red pueda manejarlo
‣ No es lo mismo que el control de flujo
> Relacionado con que el receptor pueda manejar el tráfico
> La congestión puede darse aunque todos los receptores sean capaces de
aceptar el trafico que se está enviando

‣ Efectos:
> Pérdidas de paquetes (debido a desbordamiento de colas de routers)
> Tiempos de espera elevados (debido a tiempos de espera en colas altos)
‣ Es uno de los problemas más importantes de redes
Escenario 1
‣ Dos emisores y dos receptores
‣ Un router común (supongamos que con buffer infinito)
> Nunca ocurren retransmisiones
> Las dos fuentes envian a una media de λin
> La capacidad del router es C

‣ Como se comporta el sistema??

 Escenario 1
‣ Entrada y salida. Cuanto throughput obtenemos del sistema?
λout para cada λin aceptable (mitad de capacidad para cada uno)

retardo
C/2
!out

!in C/2 !in C/2

‣ Pero el retardo aumenta indefinidamente

‣ Cada vez tiene más paquetes que procesar
‣ Recursos infinitos no garantizan un buen funcionamiento
31 octubre 2005 Transporte-6 6 /18
Escenario 2
‣ Igual que el anterior pero ahora el router tiene
recursos finitos.
> Los paquetes no esperan indefinidamente (retardo limitado)
> Si se transmite a mucha velocidad algunos paquetes se perderan
y el nivel de transporte los retransmitirá
> Tráfico
λ’in = λin + retransmisiones
 Escenario 2
‣ λin = λout (goodput)
‣ Envío perfecto (no hay retransmisiones hasta que alcancemos R/2)
Retransmisión implica λ’in > λout
!out

!out

!out
R/2
R/3
R/4

R/2 !'in R/2 !'in R/2 !'in

Perfecto Retransmisiones sólo Retransmisiones por
no retransmisiones por desbordamiento timeout prematuro

‣ Coste de la congestión
> Más trabajo (retransmisiones) para el mismo resultado (goodput)
> Retransmisiones innecesarias: capacidad perdida
Control de congestión
‣ Problema:
cuando la red está saturada por alta carga
proveniente de muchas fuentes
se pierden paquetes, se cursa menos tráfico útil y
aumenta el retardo de los paquetes que llegan a su
destino
Los protocolos de transporte reaccionan
aumentando las retransmisiones causando
más carga y más congestión
Control de congestión
Dos enfoques para control de congestión
‣ Control de congestión extremo a extremo
> No hay indicación explicita de la congestión
> Los extremos estiman la congestión basandose en sus propias
observaciones de la red
+ Perdidas observadas

+ Retardo observado

> Los extremos reacciónan a la congestión reduciendo la carga:

disminuyendo retransmisiones, tasa de envíos, aumentando
timeouts...
> Esta es la filosofía que utiliza TCP
Control de congestión
Dos enfoques para control de congestión
‣ Control de congestión asistido por la red
> Los routers informan de la congestión a los extremos de la
comunicación
+ Modificando un bit para indicar congestión:

SNA, DECnet, TCP/IP ECN (RFC2481), ATM

+ Indicando la tasa máxima a la que puede enviar

ATM ABR
Control de congestión en Internet
‣Internet se basa en un nivel de red simple que
no asiste en la detección de la congestión
‣ TCP utiliza control de congestión extremo a
extremo
> Como inferimos que hay congestión en la red?
+ Perdidas?

+ Retardo?

> Qué hacemos para evitarlo?

+ Reducir la tasa de envío? Cómo?

+ Aumentar el timeout?
‣ Si hay errores bajar la tasa de transferencia?
TCP: Control de congestión
‣ Usa control de congestión extremo a extremo
> La ventana deslizante de transporte fiable tenia un limite máximo impuesto
por el control de flujo igual a la ventana anunciada por el receptor
> Se utiliza otra ventana de congestión que limita los datos que se
pueden enviar a la red dependiendo de la percepción que tiene TCP de la
congestión
> La ventana anunciada depende del receptor
> La ventana de congestión se reduce ante la congestión limitando la tasa a la
que enviamos
CongWin
v=
RT T
Ventana = min { ventana anunciada, ventana de congestión }

confirmados se pueden
no se pueden
enviados enviar
enviar
TCP: Control de congestión
‣ ¿Cómo percibe TCP la congestión?
> Perdida de paquetes = congestión
+ Evento de timeout
+ 3 ACKs duplicados (Fast retransmit)
‣ Ajustando la ventana de congestión
> Congestion avoidance (evitación de congestion)
> Slow start
> Fast recovery
> Timeout
‣ MSS: maximun segment size
> Aun cuando TCP utiliza secuencias y ACKs por bytes individuales cuando tiene
mucho que enviar utiliza un máximo tamaño de segmento, que llamaremos
MSS
> En la siguiente clase veremos como se elige el MSS
TCP: Congestion avoidance
‣ Tras detectar congestión TCP entra en una fase de
evitación de congestión (congestion avoidance)
> Si la ventana de congestión tiene un valor de N MSS
> En congestion avoidance se abre 1 MSS cada vez que enviamos con exito
toda la ventana
> La ventana sube linealmente CongWin=4 MSS
Buscando encontrar el punto de
equilibrio sin aumentar demasiado la
congestión

CongWin=5 MSS
Enviado
por RTT

tiempo
TCP: Congestion avoidance
‣ Si en esta situación se produce una pérdida
> De un sólo paquete, lo que provoca 3 ACKs duplicados. Se interpreta como
congestión ligera
> La ventana se reduce inmediatamente a la mitad
A la vez que se hace fast retrasmit del paquete perdido
Esto se conoce como fast recovery (originalmente se reducía a 1MSS)
> Buscando reducir notablemente la tasa CongWin=8 MSS
de transmisión y colaborar en que la
congestión no crezca
> Si se siguen recibiendo ACKs la
ventana sigue creciendo linealmente

Enviado
CongWin=4 MSS
por RTT

tiempo
TCP: Congestion avoidance
‣ Se puede ver que la tasa se va ajustando
alrededor del punto de congestión
> si hay muchos errores la tasa baja y se tarda más en recuperarla
> si hay pocos errores el crecimiento lineal es capaz de llegar mas a mas
velocidad
> Este mecanismo se suele llamar AIMD
Additive Increase Multiplicative Decrease
‣ Y cómo empieza la conexión??
> Con CongWin = 1 MSS

1 pérdida 1 pérdida
Enviado
por RTT 1 pérdida

tiempo
TCP: Slow Start
CongWin
‣ En el principio CongWin=1 MSS pero... =1 MSS

> Crecer linealmente es demasiado precavido,

no tenemos motivos para pensar que hay
congestión CongWin
=2 MSS
> Se utiliza un enfoque más agresivo,
crecimiento exponencial
> Slow Start: cada vez que transmitimos una
ventana con éxito la ventana se dobla CongWin
=4 MSS

CongWin
=8 MSS

tiempo
TCP: Slow Start
‣ El slow start se mantiene hasta que se produce una
pérdida (o bien se alcanza la ventan de control de
flujo) haciendo entrar en congestion avoidance
> Si la perdida se detecta por ACKs duplicados...
+ Fast retransmit + fast recovery CongWin = CongWin/2
‣ Y si se produce un timeout?
slow start congestion avoidance

tiempo
TCP: pérdidas y congestión
‣ Pérdida detectada por ACK duplicados
> Congestión “ligera”: hay perdidas pero siguen llegando paquetes
> Acciones:
+ Retransmitir el paquete perdido (Fast retransmit)

+ Bajar la ventana de congestion para reducir la tasa

+ Pasar a congestion avoidance (si no estabas)

‣ Pérdida detectada por timeout

> Congestión “grave”. Probablemente hemos perdido toda la ventana. Si el
timeout ha caducado llevamos un rato parados sin transmitir. Tasa =0
> Acciones:
+ Poner la ventana de congestión a 1MSS

+ Pasar a slow start

+ Recordar a cuanto estaba la ventana de congestión al producirse el

error (poner la variable threshold=CongWin/2)
TCP: slow start
‣ Despues de una perdida por timeout
> el slow start no espera a otra pérdida para entrar en congestion
avoidance.
> Pasa a congestion avoidance en cuanto llega al humbral de la mitad
de la ventana de congestion al producirse el timeout

pérdidas y
congestion avoidance
timeout
slow start

tiempo
TCP: control de congestión
En resumen
‣ Cuando CongWin está por debajo de Threshold.
Slow start. La ventana crece exponencialmente
‣ Cuando CongWin está por encima de Threshold.
Congestion avoidance. La ventana crece
linealmente
‣ Cuando ocurre un triple ACK duplicado.
Threshold se pone a CongWin/2 y CongWin a
Threshold
‣ Cuando ocurre un timeout. Threshold se pone a
CongWin/2 y CongWin se pone a 1MSS
TCP: control de congestión
‣ Eventos en el emisor
Evento Estado Acción Notas

Recibe ACK para Slow Start CongWin = CongWin + MSS, CongWin se dobla por cada
datos no (SS) If (CongWin > Threshold) RTT
confirmados set state to “Congestion Avoidance”

Recibe ACK para Congestion CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, CongWin
datos no Avoidance aumenta 1 MSS por cada
confirmados (CA) RTT

Perdida SS or CA Threshold = CongWin/2, Fast recovery+multiplicative

detectada por CongWin = Threshold, decrease. CongWin nunca
triple ACK Set state to “Congestion Avoidance” baja a menos de 1MSS
duplicado
Timeout SS or CA Threshold = CongWin/2, vuelve a slow start
CongWin = 1 MSS,
Set state to “Slow Start”

ACK duplicado SS or CA Incrementar contador de ACKs duplicados CongWin y Threshold no

para ese segmento cambian
 TCP: evolución de la conexión
‣ Ejemplo, una conexión TCP

La ventana de control de
flujo impone el máximo

t i o n t ion
ge s e s
c o n
a n c e cong ance
avoi
d avoid
t
star

rt
sta
slow

pérdida pérdida
w
slo

muchas
perdidas
TCP: eficiencia de la conexión
‣ Sigue el límite de AdvertisedWindow/RTT
‣ Esto es para una conexión que este siempre
enviando
> Tenga siempre datos en el buffer de emisión
> La aplicación del receptor lea los datos suficientemente rápido
como para que el emisor siempre anuncie la ventana máxima
‣ Cómo podemos transmitir a mayor velocidad?
> Mejorando TCP para que permita ventanas mayores
> Usando más de una conexión TCP??
> UDP tiene control de flujo??
TCP: equidad (fairness)
‣ Equidad para TCP
> Si N conexiones TCP comparten un enlace la capacidad del enlace R
debería repartirse entre todas por igual R/N

Cuello de botella
capacidad R
Más sobre equidad
‣ ¿Qué pasa con UDP?
> Las aplicaciones multimedia suelen usar UDP para evitar el control
de congestión.
> Envían a tasa constante y no quieren que esta se vea reducida
> Son capaces de tolerar pérdidas
‣ Sin embargo
> Es dificil garantizar la equidad en ese ambiente TCP+UDP
> El control de congestión de TCP es justo si compite con otros TCPs
> Esto es un área de investigación activa
+ UDP que sea TCP friendly?

+ Envio de multimedia sobre TCP?

Más sobre equidad
‣ Las aplicaciones pueden abrir más de una
conexión TCP entre dos hosts
> Así podrían superar la limitación de la ventana de control de flujo de
65KB
> Los navegadores web hacen esto
> Parte de la mejora de transferencia de los sistemas P2P viene de
este efecto !!
‣ Sin embargo
> Esto también dificulta el problema de la equidad en TCP
> Si en un enlace de capacidad R hay 9 conexiónes TCP
+ Puedo abrir una conexión y conseguir un reparto de R/10

+ O puedo abrir 11 y conseguir R/2 !!!

TCP: últimos detalles
‣ Hemos estudiado el control de congestión y el
transporte fiable, cuando las aplicaciones envían
datos constantemente
‣ Algunos problemas cuando las aplicaciones leen
y escriben de forma poco eficiente
> Enviando pocos bytes, el algoritmo de Nagle
> El problema de la ventana tonta (silly window sindrome)
TCP: algoritmo de Nagle
cliente servidor
‣ El problema de escribir
despacio
l
‣ Aplicación de acceso remoto l
s
> El usuario escribe a razon de una letra
cada muchos milisegundos. El servidor
hace echo de todo lo que le llega s
\n
> El nivel TCP envía paquetes de 41 bytes
para enviar una letra \n

‣ Demasiado overhead para enviar 6 bytes

sobre todo si no estamos en hemos enviado a la
red 246 bytes
una LAN
TCP: algoritmo de Nagle
cliente servidor
‣ Algoritmo de Nagle
> Si una conexión tiene datos
enviados sin confirmar no ‘l’
puede enviar segmentos ‘l’
‘s’
pequeños (menores que MSS)
hasta que reciba el ACK de los ‘‘ ‘l’
que envió ‘-’
‘l’
> Los datos se van acumulando en ‘s -l’
un paquete que se envía al llegar ‘\n’
el ACK
‘s -l’
> Algoritmo self-clocking en una
LAN no tiene efecto porque las
confirmaciones llegan muy
deprisa ‘\n’
TCP: persist timer
‣ El problema de leer despacio
> Si la aplicación receptora lee muy despacio el buffer se puede llenar.
El receptor aununcia ventana 0
> Cuando la ventana vuelve a aumentar el receptor debe anunciar
mayor ventana. Si no tiene datos que enviar lo hace en un paquete
simple de ACK
> Que ocurre si este ACK se pierde?
+ El emisor no puede enviar mas datos porque la ventana esta a
cero
+ El receptor no sabe que su ACK se ha perdido

‣ Para evitar esto TCP envía periódicamente

window probes con 1 byte de datos
> Tambien usan exponential backoff (hasta 60s) pero nunca caducan
TCP: silly window
win 500
‣ Qué pasa si la aplicación lee
los datos muy despacio? win 0
> El emisor se ve forzado a enviar byte a
byte. A pesar de que la aplicación
tardara un tiempo en estar interesado
en ese byte ! 1byte
win 1

‣ Soluciones win 0
> Delayed ACK : este es uno de los
1byte
motivos
win 1
> No se anuncia ventana hasta que haya
un minimo tamaño en el buffer, 1MSS
win 0
TCP: detalles
‣ Para que sirve el flag PUSH ??
> Originalmente para indicar a TCP que debe entregar esos datos
inmediatamente a la aplicación. La aplicación emisora podía notificar a TCP
en que punto debía entregar.
Hoy en día las aplicaciones no tienen esa opción y TCP pone el flag PUSH
a 1 cuando vacía el buffer del emisor
Los sistemas derivados de BSD nunca retrasan la entrega de datos a las
aplicaciones
‣ Si los dos extremos no envían nada. TCP envia
paquetes para mantener la conexión activa???
> NO,
Hay una opción KEEPALIVE que hace enviar periódicamente paquetes para
confirmar que el otro extremo sigue ahí. Pero es objeto de gran polémica
Si tengo un telnet, pierdo la red y la recupero un tiempo después, por qué
debería perder la conexión?