Está en la página 1de 115

TEMA 1: Introduccin a las Redes de

Telecomunicaciones

Redes de Ordenadores
1. Modelo Genrico.
2. Clasificacin de las Redes de Telecomunicaciones.
3. Estructura de Internet.
4. Retardos en Redes de Telecomunicaciones.
5. Modelo de Referencia TCP/IP.

Nivel de Transporte:
Introduccin, UDP y TCP
1.1. Qu es una Red de Telecomunicaciones?

Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

Sistemas de
FUENTE Transmisor Transm Receptor DESTINO

Sistema Origen Sistema Destino

2
Objetivos
Conceptos y principios del nivel de transporte
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico.

> Multiplexacin
2. Clasificacin 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 comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

Sistemas de
FUENTE Transmisor Transmisin Receptor DESTINO

Sistema Origen Sistema Destino

2
Funciones del nivel de transporte
Comunicacin lgica
TEMA 1: Introduccin Transporte
a las Redes de
Telecomunicaciones
Red
entre aplicaciones 1.
2.
3.
4.
Modelo Genrico.
Clasificacin de las Redes de Telecomunicaciones.
Estructura de Internet.
Retardos en Redes de Telecomunicaciones. Enlace

Protocolo en los Canal lgico


5. Modelo de Referencia TCP/IP.

extremos (end-to-end) Red


Red Enlace
> segmentacin
Enlace
> reensamblado Red
2 niveles de transporte en
1.1. Qu es una Red de Telecomunicaciones?
Red Enlace

Internet


Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.
Enlace

> TCP Usando distintas tecnologas (elctricas, electrnicas,


electromagnticas, pticas,)
Transporte
> UDP Red
Sistemas de
FUENTE Transmisor Transmisin Receptor DESTINO
Enlace
Sistema Origen Sistema Destino

2
Red y transporte
Nivel de red
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico.

Comunicacin lgica entre hosts


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

Nivel de transporte
Comunicacin lgica entre procesos
> mejora y utiliza la comunicacin entre hosts
App 1 App 1
1.1. Qu es una Red de Telecomunicaciones?

Es una Infraestructura.
Transporte Proporciona comunicacin entre mltiples entidades. Transporte
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

Red Red Red Red Red


Sistemas de
FUENTE Transmisor Transmisin Receptor DESTINO

Sistema Origen Sistema Destino


Enlace Enlace Enlace Enlace Enlace
2
Transporte en Internet
Entrega fiable y en
TEMA 1: Introduccin a las Redes de
Telecomunicaciones

orden (TCP) Transporte


1. Modelo Genrico.
2. Clasificacin de las Redes de Telecomunicaciones.
3. Estructura de Internet.
4.
5.
Retardos en Redes de Telecomunicaciones.
Modelo de Referencia TCP/IP. Red
> control de congestin Enlace
> control de flujo
> establecimiento de conexin 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 comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
Red Enlace

Enlace
> best-effort igual que IP electromagnticas, pticas,)

En los dos casos FUENTE Transmisor


Sistemas de
Transmisin Receptor DESTINO
Transporte
Red
retardo no garantizado
Sistema Origen Sistema Destino

>
2
Enlace
> ancho de banda no garantizado
Funciones TCP/UDP
Funcin comn
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico.

Multiplexacin/demultiplexacin de
2. Clasificacin de las Redes de Telecomunicaciones.
3. Estructura de Internet.
4. Retardos en Redes de Telecomunicaciones.
5. Modelo de Referencia TCP/IP.

aplicaciones

Funciones slo UDP


> Envio no orientado a conexin
1.1. Qu es una Red de Telecomunicaciones?

Funciones slo TCP





Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,

> Manejo de conexiones electromagnticas, pticas,)

> Transporte fiable de datos


FUENTE Transmisor
Sistemas de
Transmisin Receptor DESTINO

> Control de flujo y de congestin


Sistema Origen Sistema Destino

2
Multiplexacin y demultiplexacin
Un host con varias aplicaciones/programas/
TEMA 1: Introduccin a las Redes de

procesos corriendo Telecomunicaciones


1.
2.
Modelo Genrico.
Clasificacin de las Redes de Telecomunicaciones.

> El nivel de red enva 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 comunicacin entre diferentes aplicaciones


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

Aplicacin 1 Aplicacin 2 Aplicacin 3 Aplicacin 4

1.1. Qu es una Red de Telecomunicaciones?


Transporte Transporte
Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
Red electromagnticas, pticas,) Red

Emisor:
Receptor:
recoger datos de distintas fuentes
Sistemas de
FUENTE Transmisor Transmisin Receptor DESTINO

entregar a la
encapsular con informacin del
Sistema Origen Sistema Destino

aplicacin (socket)
origen
2

correcta
Multiplexacin y demultiplexacin
El host recibe datagramas IP
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico.

> Cada datagrama IP lleva una


2.
3.
Clasificacin de las Redes de Telecomunicaciones.
Estructura de Internet.

direccin 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/aplicacin)1.1. Qu es una Red de Telecomunicaciones?

El nivel de transporte usa


Es una Infraestructura.

Datos aplicacin
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,

las direcciones IP y los


electromagnticas, pticas,)

puertos para decidir a FUENTE Transmisor


Sistemas de
Transmisin Receptor DESTINO

quien entrega los datosSistema Origen Sistema Destino

2 Segmento del nivel


de transporte
Demultiplexacin no orientada a conexin

Cuando UDP recibe un paquete...


TEMA 1: Introduccin a las Redes de
Telecomunicaciones

Se extraen de la cabecera
1. Modelo Genrico.
2. Clasificacin de las Redes de Telecomunicaciones.
3. Estructura de Internet.
4. Retardos en Redes de Telecomunicaciones.

IP la direccin 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 comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,

Paquetes provenientes de
electromagnticas, pticas,)

diferentes direccines origen y Sistemas de

puertos origen se entregan al


FUENTE Transmisor Transmisin Receptor DESTINO

Sistema Origen Sistema Destino

mismo socket 2
Demultiplexacin no orientada a conexin

Ejemplo
TEMA 1: Introduccin a las Redes de
Telecomunicaciones SP: source port
1.
2.
Modelo Genrico.
Clasificacin 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 comunicacin entre mltiples entidades.
DP: 6428 DP: 6428

client Client
De una manera eficiente.

server

Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

IP: A IP: C IP:B


Sistemas de
FUENTE Transmisor Transmi Receptor DESTINO

La direccin origen y puerto origen permiten


Sistema Origen Sistema Destino

responder al cliente
2

/ 11
Demultiplexacin orientada a conexin

Cuando TCP recibe un paquete puede pertenecer a


TEMA 1: Introduccin a las Redes de
Telecomunicaciones

varias conexiones establecidas 1.


2.
3.
4.
Modelo Genrico.
Clasificacin 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 comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

Sistemas de
FUENTE Transmisor Receptor DESTINO

Se entrega al socket identificado por la 4-tupla


Transmisin

Sistema Origen Sistema Destino

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


Demultiplexacin orientada a conexin

Ejemplo
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
SP: source port
S-IP: source IP
1. Modelo Genrico.
2. Clasificacin 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 comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

SP: 9157 SP: 9157


client DP: 80 Sistemas de
DP: 80 Client
server
FUENTE Transmisor Transmisin 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
Demultiplexacin orientada a conexin

Otro ejemplo
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
SP: source port
S-IP: source IP
1. Modelo Genrico.
2. Clasificacin 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 comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

SP: 9157 SP: 9157


client DP: 80 Sistemas de
DP: 80 Client
server
FUENTE Transmisor Transmisin 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: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico.

Proporciona un servicio de transporte para


2. Clasificacin 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 aade a IP es la multiplexacin de aplicaciones y
1.1. Qu es una Red de Telecomunicaciones?
>
deteccin de errores


Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.

No orientado a conexin
Usando distintas tecnologas (elctricas, electrnicas,


electromagnticas, pticas,)

> No hay establecimiento


FUENTE Transmisor
Sistemas de
Transmisin Receptor DESTINO

> Cada datagrama se trata independientemente (protocolo sin


Sistema Origen Sistema Destino

estado) 2
UDP
Por qu un protocolo como UDP?
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico.

Es rapido: no hay establecimiento


2. Clasificacin 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 aade retardos


innecesarios
Es simple: no hay estado de conexin
ni en el emisor ni en el receptor
1.1. Qu es una Red de Telecomunicaciones?

Poco overhead


Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,

la cabecera UDP ocupa lo mnimo posible


electromagnticas, pticas,)

Es eficiente: no hay control de congestin


Sistemas de
FUENTE Transmisor Transmisin 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: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico. Cabecera IP
puerto origen
2. Clasificacin 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 aplicacin
checksum

Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.

slo 8 bytes de

Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

cabecera ! FUENTE Transmisor


Sistemas de
Transmisin Receptor DESTINO

Sistema Origen Sistema Destino

2
UDP: checksum 32 bits

Clculo del checksum


TEMA 1: Introduccin a las Redes de
Telecomunicaciones direccin IP origen
1. Modelo Genrico.
direccin IP destino
> Se trata el segmento como serie de
2.
3.
Clasificacin 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 aplicacin
proteger errores en las direcciones
y el protocolo) 1.1. Qu es una Red de Telecomunicaciones?

+ segmento UDP

Es una Infraestructura.
Proporciona comunicacin entre mltiples entidades.
De una manera eficiente.
Usando distintas tecnologas (elctricas, electrnicas,

Detecta errores en todo el segmento UDP


electromagnticas, pticas,)

(aunque no todos) FUENTE Transmisor


Sistemas de
Transmisin Receptor DESTINO

Si UDP detecta errores en un paquete


Sistema Origen Sistema Destino

recibido no lo entrega
UDP
En que se usa UDP ?
TEMA 1: Introduccin a las Redes de
Telecomunicaciones
1. Modelo Genrico.

Aplicaciones de streaming multimedia (audio/


2. Clasificacin 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 prdidas 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 (monitorizacin de red)


Proporciona comunicacin entre mltiples entidades.

De una manera eficiente.


Usando distintas tecnologas (elctricas, electrnicas,
electromagnticas, pticas,)

> poco overhead y protocolo sencillo Sistemas de


FUENTE Transmisor Receptor DESTINO

Juegos en red
Transmisin

Sistema Origen Sistema Destino

> mnimo 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
Descripcin con mquinas de estados finitos. Notacin
Un Otro
estado estado

Una transicin
Evento que causa la transicin

Acciones que provoca la transicin

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
> Deteccin de errores
+ Uso de checksum

> Comunicacin 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
> Reenvo 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)

Ms conocido como Stop-and-Wait


Tiene algun problema este protocolo?
Problemas con stop-and-wait
Qu pasa si hay un error en la transmisin del
ACK o NACK?
Qu pasa si el canal puede perder paquetes?
Soluciones complican el protocolo
> Deteccin 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 ms usados utilizan contra esto


numeros de secuencia del paquete
Protocolo con nmero 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 nmero 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 nmero 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?
Prdidas 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)

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

Operacin normal

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

Prdida 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 ms eficientes
Para aumentar la eficiencia, se envan varios
paquetes mientras llega el ACK
Varios paquetes en la red por confirmar
> Se usan ms nmeros de secuencia que 0 y 1
> Emisor y receptor necesitarn buffer para varios paquetes
> Varias polticas 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 nmero 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 nmeros 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 aplicacin

paquetes recibidos que no pueden


Ventana
pasarse todava 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

Nmero 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 relacin 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 conexin
> Stream bidireccional (como si fuera un fichero) entre los dos
extremos
> No mantiene las fronteras de los mensajes
Con control de flujo y congestin
TCP
Interfaz con el nivel de aplicacin
> Tras establecer una conexin proporciona un stream bidireccional entre sockets
> Sin fronteras entre mensajes
> 2 buffers por conexin
+ Escribir en el socket pone los datos en buffer de envio
+ Buffer de recepcin para esperar el read()

TCP TCP
connexin
connexin
connexin
connexin connexin
connexin

IP IP IP IP
TCP
Demultiplexacin 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 conexines.

La conexin slo existe en los extremos TCP


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

TCP connexin
TCP
connexin
connexin Tabla de connexin
connexin

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 operacines del
usuario.
> TCP har lo posible por enviar los datos cuando pueda
> TCP colocara los datos en el buffer de recepcin 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 conexin
> Mensajes de datos
> Mensajes con ACKs
Veamos los mensajes del protocolo TCP
TCP 32 bits

Segmento TCP Cabecera IP


Cabecera de tamao ...
variable puerto origen puerto destino

Cabecera TCP
obligatorios
> 20 hasta 60 bytes segn las numero secuencia
opciones

20 bytes
numero ack
Datos del nivel de HL nada flags ventena recep.
aplicacin checksum urgent data ptr
opciones

Datos aplicacin
TCP
Contenido Cabecera IP
Datos de ...
multiplexacin puerto origen puerto destino
> Puerto origen numero secuencia
> Puerto destino numero ack
HL nada flags ventena recep.
checksum urgent data ptr
opciones

Datos aplicacin
TCP
Contenido Cabecera IP
Datos para transporte ...
fiable puerto origen puerto destino
> Nmero de secuencia numero secuencia
> Nmero de ACK numero ack
> Checksum HL nada flags ventena recep.
Cabecera + datos de applicacin + checksum urgent data ptr
algunos datos de IP (pseudo cabecera
como en UDP) opciones
En un mismo paquete
podemos mandar datos y Datos aplicacin
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 aplicacin
> FIN fin
TCP
Contenido Cabecera IP
Control de flujo ...
> ventana de recepcin puerto origen puerto destino
numero secuencia
Datos urgentes numero ack
HL (header length) HL nada flags ventena recep.
> Tamao 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 aplicacin
Opciones extras
TCP
Permiten especificar operaciones y tipos de
paquetes que se han ido aadiendo
posteriormente al protocolo
Las opciones se colocan seguidas. 2 formatos
> opciones de 1 byte tipo

> opciones de varios bytes tipo longitud variable

Opciones bsicas
> Fin-de-la-lista de opciones 00000000

> No-operacion (para rellenar) 00000001


> Maximum segment size 00000010 00000100 max seg size

Permite descubrir el tamao mximo de segmento en una conexin


TCP: envo de datos
No hay separacin de paquetes. Los bytes a enviar se
colocan en el buffer y forman una corriente de bytes
sin fronteras de paquetes
El nmero 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: envo 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 conexin y para cada sentido
El campo ACK
> es valido si esta activado el flag ACK
> indica la prxima secuencia que el receptor espera recibir
cumulative ACK: Go back N a nivel de byte
Si una conexin 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 conexin 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 recepcin
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
aplicacin 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
> Nmero de secuencia: el primer byte enviado en el segmento
> ACK: el prximo byte que espera recibir el receptor
Los paquetes TCP llevan
> Nmero de secuencia de los datos. Si no llevan datos, el campo nmero
de secuencia indica el proximo numero de secuencia que se enviar
> Prximo nmero de secuencia que espera recibir su emisor. Es vlido si
el byte ACK est activado
> Los nmeros de secuencia son independientes en ambos sentidos
Transmisiones simultneas 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

prdida 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 enva 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 Accin: 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
Accin: enva 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
Accin: enva inmediatamente ACK
causando ACK duplicado
ltimo byte
recibido ACK #
> Llega segmento rellenando hueco
ltimo ACK
enviado Accin: enva inmediatamente ACK

ACK #
> Llega segmento ya reconocido Accin: 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
transmisin durante un timeout ack 200
> Normalmente el emisor enva
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
reaccin lenta ante las prdidas
TCP: timeout
Solucin: 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 enva 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) retransmisin
+ Slo se puede medir una muestra a SampleRTT3
la vez (1 solo timer)
y normalmente con precisin de
500ms
TCP: estimacin RTT
El valor medido SampleRTT vara
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


> Tpicamente: = 0.125
TCP: estimacin de RTT
Ejemplo

24 octubre 2005 Transporte-4 15 /17


TCP: estimacin de RTT
Eligiendo el timeout
> EstimatedRTT mas un mrgen de seguridad
+ A mayor variacin de EstimatedRTT mayor debe ser el margen
de seguridad
+ Estimamos la variacin 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 aplicacin al hacer un read() sobre el socket
> La aplicacin 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 aplicacin

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 envo
read()

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

paquete que le enva !! numero secuencia


numero ack

> Esa es la funcin del campo ventana de HL nada flags ventena recep.
checksum urgent data ptr
recepcin de la cabecera opciones

> En cada paquete el receptor anuncia cuantos Datos aplicacin


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

buffer de recepcin
Ejemplo
De una transferencia de pgina 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 slo tiene 16
bits
> Solo puede anunciar 65KBytes !!!
(el numero de secuencia direcciona La mxima velocidad
4GB) de transferencia es:
Podan 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 conexin
Previamente comunicarse datos entre un emisor y un
receptor deben negociar un establecimiento de
conexin.
> TCP inicializa sus variables para la conexin y crea los buffers
> Esto se hace mediante los paquetes que utilizan los flags SYN, FIN y RST
> Protocolo para establecer la conexin
> Protocolo para liberar la conexin
TCP: establecimiento de conexin
Mecanismo: Three way handshake
> Lado cliente (socket que hace connect) SYN
enva 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 nmero de secuencia para poder


confirmarse con ACKs
Ejemplo
Otra conexin web... Los SYNs usan un nmero
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 conexin
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 conexin
&LHUUHGH&RQH[LyQ
FIN

Medio cierre ACK


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

ACK
Ejemplo
El final de una conexin web...
El servidor est enviando datos
El cliente decide cerrar y manda un FIN
...
IP 130.206.166.105.80 > 130.206.169.177.53701: P 80314174:80315622(1448) ack 4067364561 win 24616
IP 130.206.166.105.80 > 130.206.169.177.53701: P 80315622:80316551(929) ack 4067364561 win 24616
IP 130.206.169.177.53701 > 130.206.166.105.80: . ack 80316551 win 65535
IP 130.206.169.177.53701 > 130.206.166.105.80: F 4067364561:4067364561(0) ack 80316551 win 65535
IP 130.206.166.105.80 > 130.206.169.177.53701: . ack 4067364562 win 24616
IP 130.206.166.105.80 > 130.206.169.177.53701: F 80316551:80316551(0) ack 4067364562 win 24616
IP 130.206.169.177.53701 > 130.206.166.105.80: . ack 80316552 win 65535

El servidor cierra su sentido


TCP: abortar una conexin
Paquete Reset (RST)
> Se enva cuando TCP recibe un paquete que datos
es inconsistente con su estado de la
conexin
recibir datos sin tener conexin abierta RST
> Le dice al otro extremo que esa conexin
no existe y que destruya toda la
informacin de ese estado de conexin
> Tambin se usa para decir que no hay nadie
escuchando un puerto
> Tambin se puede usar por el nivel de
aplicacin para cerrar una conexin de
forma rpida
> El otro extremo no hace falta que conteste
nada
TCP: establecmimiento de conexin
Qu pasa si se pierden paquetes del
establecimiento o del cierre?
> Tienen un nmero de secuencia as que se pueden retransmitir. Es como si
fueran un byte de datos.
> Se utiliza retransmisin por timeout
Retransmision de SYNs
> Problema: al comenzar la conexin no ha habido tiempo de hacer
estimaciones del RTT.
La mayora 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
conexin 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 conexin
Casos especiales: apertura simultnea
> Si dos clientes inician simultaneamente una conexin entre ellos
> Ntese que los dos tienen que usar puertos conocidos por el otro
> Se usa muy poco

connect() SYN
SYN connect()
ACK+SYN

ACK+SYN
conexin establecida
ACK conexin establecida

ACK
TCP: establecimiento de conexin
Casos especiales: cierre simultneo
> 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 transmisin.
Modifican bits aleatorios de los
paquetes. Los niveles que hacen
deteccin de errores se ven obligados
a descartar el paquete al no estar R1
seguros de entregarlo correctamente Para R3 R2
Independiente del trfico 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 estn ocupados).
Debe descartar el paquete por falta
de recursos
Dependiente de la carga de la
red
Congestin 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 trfico
> La congestin puede darse aunque todos los receptores sean capaces de
aceptar el trafico que se est enviando

Efectos:
> Prdidas 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 ms importantes de redes
Escenario 1
Dos emisores y dos receptores
Un router comn (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 ms 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
> Trfico
in = in + retransmisiones
Escenario 2
in = out (goodput)
Envo perfecto (no hay retransmisiones hasta que alcancemos R/2)
Retransmisin implica in > out
!out

!out

!out
R/2
R/3
R/4

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


Perfecto Retransmisiones slo Retransmisiones por
no retransmisiones por desbordamiento timeout prematuro

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

+ Retardo observado

> Los extremos reaccinan a la congestin reduciendo la carga:


disminuyendo retransmisiones, tasa de envos, aumentando
timeouts...
> Esta es la filosofa que utiliza TCP
Control de congestin
Dos enfoques para control de congestin
Control de congestin asistido por la red
> Los routers informan de la congestin a los extremos de la
comunicacin
+ Modificando un bit para indicar congestin:

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


+ Indicando la tasa mxima a la que puede enviar

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

+ Retardo?

> Qu hacemos para evitarlo?


+ Reducir la tasa de envo? Cmo?

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

confirmados se pueden
no se pueden
enviados enviar
enviar
TCP: Control de congestin
Cmo percibe TCP la congestin?
> Perdida de paquetes = congestin
+ Evento de timeout
+ 3 ACKs duplicados (Fast retransmit)
Ajustando la ventana de congestin
> Congestion avoidance (evitacin 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 mximo tamao de segmento, que llamaremos
MSS
> En la siguiente clase veremos como se elige el MSS
TCP: Congestion avoidance
Tras detectar congestin TCP entra en una fase de
evitacin de congestin (congestion avoidance)
> Si la ventana de congestin 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
congestin

CongWin=5 MSS
Enviado
por RTT

tiempo
TCP: Congestion avoidance
Si en esta situacin se produce una prdida
> De un slo paquete, lo que provoca 3 ACKs duplicados. Se interpreta como
congestin 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 reduca a 1MSS)
> Buscando reducir notablemente la tasa CongWin=8 MSS
de transmisin y colaborar en que la
congestin 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 congestin
> si hay muchos errores la tasa baja y se tarda ms 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 cmo empieza la conexin??
> Con CongWin = 1 MSS

1 prdida 1 prdida
Enviado
por RTT 1 prdida

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
congestin CongWin
=2 MSS
> Se utiliza un enfoque ms 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
prdida (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: prdidas y congestin
Prdida detectada por ACK duplicados
> Congestin 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)

Prdida detectada por timeout


> Congestin 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 congestin a 1MSS

+ Pasar a slow start

+ Recordar a cuanto estaba la ventana de congestin 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 prdida 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

prdidas y
congestion avoidance
timeout
slow start

tiempo
TCP: control de congestin
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 congestin
Eventos en el emisor
Evento Estado Accin 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: evolucin de la conexin
Ejemplo, una conexin TCP

La ventana de control de
flujo impone el mximo

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

prdida prdida
w
slo

muchas
perdidas
TCP: eficiencia de la conexin
Sigue el lmite de AdvertisedWindow/RTT
Esto es para una conexin que este siempre
enviando
> Tenga siempre datos en el buffer de emisin
> La aplicacin del receptor lea los datos suficientemente rpido
como para que el emisor siempre anuncie la ventana mxima
Cmo podemos transmitir a mayor velocidad?
> Mejorando TCP para que permita ventanas mayores
> Usando ms de una conexin TCP??
> UDP tiene control de flujo??
TCP: equidad (fairness)
Equidad para TCP
> Si N conexiones TCP comparten un enlace la capacidad del enlace R
debera repartirse entre todas por igual R/N

Cuello de botella
capacidad R
Ms sobre equidad
Qu pasa con UDP?
> Las aplicaciones multimedia suelen usar UDP para evitar el control
de congestin.
> Envan a tasa constante y no quieren que esta se vea reducida
> Son capaces de tolerar prdidas
Sin embargo
> Es dificil garantizar la equidad en ese ambiente TCP+UDP
> El control de congestin de TCP es justo si compite con otros TCPs
> Esto es un rea de investigacin activa
+ UDP que sea TCP friendly?

+ Envio de multimedia sobre TCP?


Ms sobre equidad
Las aplicaciones pueden abrir ms de una
conexin TCP entre dos hosts
> As podran superar la limitacin 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 tambin dificulta el problema de la equidad en TCP
> Si en un enlace de capacidad R hay 9 conexines TCP
+ Puedo abrir una conexin y conseguir un reparto de R/10

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


TCP: ltimos detalles
Hemos estudiado el control de congestin y el
transporte fiable, cuando las aplicaciones envan
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
Aplicacin 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 enva 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 conexin tiene datos
enviados sin confirmar no l
puede enviar segmentos l
s
pequeos (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 enva 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 aplicacin 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 enva peridicamente


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 aplicacin lee
los datos muy despacio? win 0
> El emisor se ve forzado a enviar byte a
byte. A pesar de que la aplicacin
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 tamao 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 aplicacin. La aplicacin emisora poda notificar a TCP
en que punto deba entregar.
Hoy en da las aplicaciones no tienen esa opcin y TCP pone el flag PUSH
a 1 cuando vaca el buffer del emisor
Los sistemas derivados de BSD nunca retrasan la entrega de datos a las
aplicaciones
Si los dos extremos no envan nada. TCP envia
paquetes para mantener la conexin activa???
> NO,
Hay una opcin KEEPALIVE que hace enviar peridicamente paquetes para
confirmar que el otro extremo sigue ah. Pero es objeto de gran polmica
Si tengo un telnet, pierdo la red y la recupero un tiempo despus, por qu
debera perder la conexin?