LA CAPA DE TRANSPORTE

Capa de transporte

3-1

El contexto de la capa de transporte

Capa de transporte

3-2

La capa de transporte
Principios detrs de los

servicios de la capa de
transporte:

multiplexado/demultiplex
ado
Transferencia de datos
fiable
Control de flujo
Control de
congestionamiento

Los protocolos de

transporte en Internet:

UDP: transporte no orientado

a la conexin
TCP: transporte orientado a
la conexin
SCTP: Stream Control
transmission Protocol

Capa de transporte

3-3

Servicios y protocolos de transporte

Proporcionar comunicacin lgica
entre procesos de aplicaciones
ejecutndose en hosts diferentes
Los protocolos de transporte se
ejecutan en sistemas finales
Lado emisor: dividir los
mensajes de las aplicaciones
en segmentos, pasarlos a la
capa de red
Lado receptor: re ensamblar
segmentos en mensajes, pasar
a la capa de aplicacin
Ms de un protocolo de transporte
disponible para las aplicaciones
TCP , UDP y SCTP

Capa de transporte

3-4

Capa de transporte vs. capa de red

Capa de red:

comunicacin lgica
entre hosts
Capa de transporte:

Comunicacin lgica
entre procesos

Opera sobre la capa de

red y mejora los servicios
de la capa de red

Analoga con una familia:

12 nios envan cartas a
otros 12 nios

Procesos = nios
Mensajes de aplicacin = cartas
en sobres
Hosts = casas
Protocolo de transporte = Ana y
Bill
Protocolo de la capa de red =
servicio postal

Capa de transporte

3-5

Nmero de puerto
Un puerto es una interfaz lgica asociada a una

aplicacin de red.
Se define mediante un entero de 16 bits.

Capa de transporte

3-6

Nmero de puerto
Los nmeros de puerto son administrados por ICANN (Internet

Corporation for Assigned Names and numbers) a traves de IANA

(Internet Assigned numbers Authority).
Se han definido los siguientes rangos:

Puertos bien conocidos: de 0 a 1023 reservado para su uso por parte de

aplicaciones bien conocidas. Son asignados y controlados por ICANN
Puertos registrados: de 1024 a 49151 pueden ser usados por cualquier
aplicacin. No son ni controlados ni asignados por ICANN, pero pueden
registrarse con ICANN para evitar duplicidad.
Puertos dinmicos o privados: de 49152 a 65535 pueden ser usados como
puertos efmeros o privados.

Capa de transporte

3-7

Direccin IP y nmero de puerto

Direccin IP Identifica al host
Nmero de puerto identifica al servicio

Capa de transporte

3-8

SOCKET
Es un extremo en una comunicacin interprocesos a

travs de una red de computadoras.

La direccin de un socket se determina por la direccin
IP del host y el nmero de puerto del servicio

Capa de transporte

3-9

Encapsulamiento y desencapsulamiento

Capa de transporte

3-10

Protocolos de la capa de transporte

Entrega fiable y ordenada:

TCP

Una extensin sin mas del

protocolo IP de mejor
esfuerzo

rt
po
ns

a
tr

orden: UDP

network
data link
physicalnetwork

Entrega no fiable y fuera de

network
data link
physical

en
den

network
data link
physical

l
ca

Control de congestionamiento
Control de flujo
Configuracin de conexin

gi
lo

application
transport
network
data link
physical

network
data link
physical

Servicios no disponibles:
Garantas de retardo
Garantas de ancho de banda
Capa de transporte

data link
physical

network
data link
physical

application
transport
network
data link
physical

3-11

Servicio no orientado a la conexin

Capa de transporte

3-12

Servicio orientado a la conexin

Capa de transporte

3-13

Multiplexado y
demultiplexado

Capa de transporte

3-14

Multiplexado y demultiplexado

Capa de transporte

3-15

Multiplexado/demultiplexado
Demultiplexado en el host receptor:
Entregar los segmentos recibidos
al socket correcto

Multiplexado en el host emisor:

Reunir datos de mltiples
sockets, etiquetando los datos
con un encabezado (usado
luego para el demultiplexado)

Capa de transporte

3-16

Como funciona el demultiplexado

Un host recibe datagramas IP

Cada datagrama tiene una direccin IP de origen y una

direccin IP de destino
Cada datagrama transporta 1 segmento de la capa de
transporte
Cada segmento tiene un nmero de puerto de origen y de
destino
El host usa las direcciones IP y los nmeros de puerto para dirigir
los segmentos a los sockets apropiados

Capa de transporte

3-17

Demultiplexado no orientado a la conexin

Crear sockets con

nmeros de puerto:
DatagramSocket mySocket1 =
new DatagramSocket(12534);
DatagramSocket mySocket2 =
new DatagramSocket(12535);

Un socket UDP se

identifica por la tupla :

(direccin IP destino, nmero de
puerto destino)

Cuando un host recibe un

segmento UDP:

Verifica el nmero de puerto

destino en el segmento
Dirige el segmento UDP al socket
con dicho nmero de puerto

Datagramas IP con direcciones

IP de origen y/o nmeros de

puerto origen diferentes se
direccionan al mismo puerto, si
tienen la direccin IP y puerto
destino iguales

Capa de transporte

3-18

Demultiplexado no orientado a la conexin

DatagramSocket serverSocket = new DatagramSocket(6428);
P2

SP: 6428
DP: 9157

IP de
Cliente: A

P1
P1

P3

SP: 9157
DP: 6428

SP: 6428
DP: 5775

IP de Servidor: C

SP: 5775
DP: 6428

IP de
Cliente:B

SP proporciona la direccin de retorno

Capa de transporte

3-19

Demultiplexado orientado a la conexin

Un socket TCP se

identifica por la tupla:

Direccin IP de origen
Nmero de puerto origen
Direccin IP de destino
Nmero de puerto destino

El host receptor usa los

4 valores para dirigir el

segmento al socket
apropiado

El host servidor puede

admitir muchos sockets

TCP simultneos:

Cada socket se identifica

mediante su propia tupla

Los servidores Web tiene

diferentes sockets para

cada conexin de cliente

HTTP no persistente tendr

sockets diferentes para
cada consulta

Capa de transporte

3-20

Demultiplexado orientado a la conexin

Capa de transporte

3-21

Demultiplexado orientado a la conexin:

Web Server multihilo
P1

P2

P4

P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

IP de
Cliente: A

SP: 9157
DP: 80
S-IP: A
D-IP:C

IP de
Servidor: C

SP: 9157
DP: 80
S-IP: B
D-IP:C

Capa de transporte

IP de
Cliente:B

3-22

Multiplexado y demultiplexado TPC/IP

Transporte no orientado a la conexin

UDP

Capa de transporte

3-24

UDP: User Datagram Protocol [RFC 768]

Protocolo de transporte de

Internet sin adornos

Servicio de mejor esfuerzo,
los segmentos UDP pueden
ser:
Perdidos
Entregados fuera de orden
a las aplicaciones
No orientado a la conexin:
Sin handshaking entre el
emisor y receptor UDP
Cada segmento UDP se
maneja independientemente
de los dems

Porqu existe UDP?

No hay establecimiento de

conexin (lo que puede

agregar retardo)
Simple: sin estado de
conexin en emisor o en
receptor
Encabezado de segmento
pequeo
Sin control de
congestionamiento
Capa de transporte

3-25

UDP
Comnmente utilizado para

Longitud, en bytes, de segmento UDP,

incluyendo el encabezado

aplicaciones de difusin
multimedia
Tolerante a prdidas
Sensibles a la velocidad
Otros usos para UDP
DNS
SNMP
Transferencia fiable sobre UDP:
agregar fiabilidad en la capa de
aplicacin
Recuperacin de errores
especfica de cada
aplicacin

32 bits
# puerto origen

# puerto dest.

Longitud

checksum

Datos de aplicacin
(mensaje)

Formato de segmento UDP

Capa de transporte

3-26

Checksum UDP
Objetivo: Detectar errores en segmentos transmitidos
Emisor:
Procesa un segmento como una secuencia de enteros de 16 bits
Checksum: suma (complemento a 1) de los contenidos del

segmento: Seudoencabezado + encabezado UDP + Datos

El emisor coloca el valor de la suma de verificacin en el campo
UDP checksum y descarta el seudoencabezado

Capa de transporte

3-27

Checksum UDP
Ejemplo
El campo checksum tiene un valor inicial de cero.
Despus de calcular la suma de verificacin, el pseudoencabezado

se descarta (no se transmite)

Capa de transporte

3-28

Checksum UDP
Receptor:
Calcula la suma de verificacin del segmento recibido +

pseudoencabezado
Verifica si la suma calculada es igual al valor del campo checksum:
NO error detectado
SI no se detectaron errores.

Capa de transporte

3-29

Ejemplo de checksum Internet

Nota

Cuando se suma nmeros, un acarreo del bit ms

significativo debe sumarse al resultado

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Capa de transporte

3-30

Principios de transferencia
de datos fiable

Capa de transporte

3-31

Principios de trasferencia de datos fiable

Importante en las capas de aplicacin, transporte y enlace
En la lista de los 10 tpicos ms importantes de redes!

Las caractersticas del canal no fiable determinarn la complejidad

del protocolo de transferencia de datos fiable (rdt)

Capa de transporte

3-32

Principios de trasferencia de datos fiable

Importante en las capas de aplicacin, transporte y enlace
En la lista de los 10 tpicos ms importantes de redes!

Las caractersticas del canal no fiable determinarn la complejidad

del protocolo de transferencia de datos fiable (rdt)

Capa de transporte

3-33

Principios de trasferencia de datos

fiable
Importante en las capas de aplicacin, transporte y enlace
En la lista de los 10 tpicos ms importantes de redes!

Las caractersticas del canal no fiable determinarn la complejidad

del protocolo de transferencia de datos fiable (rdt)

Capa de transporte

3-34

Transferencia de datos fiable: comenzando

rdt_send(): llamado de arriba, (e.g.,
por una aplicacin). Pasa datos para
entregar a la capa superior del receptor

deliver_data(): llamado por rdt

para entregar datos a la capa
superior

Lado
emisor

udt_send(): llamado por rdt,

para transferir un paquete
sobre un canal no fiable al
receptor

Lado
receptor

rdt_rcv(): llamado cuando llega un

paquete al lado receptor del canal
Capa de transporte

3-35

Transferencia de datos fiable: comenzando

Qu haremos? :
Desarrollar incrementalmente los extremos emisor y receptor del
protocolo de transferencia de datos fiable (rdt)
Considerar solo la transferencia de datos unidireccional
Pero la informacin de control fluir en ambas direcciones!
Usar mquinas de estado finito (FSM) para especificar el emisor y
el receptor

estado: estando en
este estado, el
siguiente estado
se determina
univocamente
por el siguiente
evento

Evento que causa el cambio de estado

Acciones tomadas al cambiar el estado

estado
1

estado
2

evento
accin

Capa de transporte

3-36

Rdt1.0: Transferencia fiable sobre un canal fiable

Canal subyascente perfectamente fiable
No hay errores de bit
No hay prdida de paquetes
FSMs separados para emisor, receptor:

Emisor envia datos al canal subyascente

Receptor lee datos del canal subyascente

Espera
llamada
de arriba

rdt_send(data)
packet = make_pkt(data)
udt_send(packet)

emisor

Espera
llamada
de abajo

rdt_rcv(packet)
extract (packet,data)
deliver_data(data)

receptor
Capa de transporte

3-37

Rdt2.0: canal con errores de bit

Canal subyascente puede invertir los bits en un

paquete

checksum para detectar errores de bit

La pregunta: como recuperarse de errores:

confirmacin (ACKs): el receptor explcitamente le dice al
emisor que un paquete se recibio bien
Confirmacin negativa (NAKs): el receptor explcitamente le
dice al emisor que el paquete tuvo errores
El emisor retransmite el paquete al recibir un NAK
Nuevos mecanismos en rdt2.0 (sobre rdt1.0):

Deteccin de errores
Retroalimentacin del receptor: mensajes de control (ACK,
NAK) del receptor al emisor
Capa de transporte

3-38

rdt2.0: Especificacin FSM

rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Espera
Wait for
llamada de
ACK or
udt_send(sndpkt)
arriba
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)

emisor

receptor
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Espera
llamada de
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Capa de transporte

3-39

rdt2.0: operacin sin errores

rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Espera
Espera
llamada de
ACK o
udt_send(sndpkt)
arriba
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Espera
llamada de
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Capa de transporte

3-40

rdt2.0: Escenario con error

rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Espera
Espera
llamada de
ACK o
udt_send(sndpkt)
arriba
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Espera
llamada de
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Capa de transporte

3-41

rdt2.0 tiene una falla fatal!

Qu ocurre si los
ACK/NAK se corrompen?

Manejar duplicados:
El emisor retransmite el

paquete atual si el ACK/NAK

est daado
El emisor no sabe que ocurri
El emisor agrega un nmero de
en el receptor!
secuencia a cada paquete
No puede retransmitir
El receptor descarta (no
simplemente: posible
entrega hacia arriba) el
duplicado
paquete duplicado
Parada y espera (Stop and wait)
El emisor envia un paquete y espera la respuesta del receptor
Capa de transporte

3-42

rdt2.1: El emisor maneja ACK/NAKs

daados
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&

rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)

Espera
llamada 0
de arriba

rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)

rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)

( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)

Espera
ACK o
NAK 0

Espera
ACK o
NAK 1

Espera
llamada 1
de arriba

rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)

Capa de transporte

3-43

rdt2.1: el receptor maneja ACK/NAKs

daados
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(NAK, chksum)

udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)

udt_send(sndpkt)
Espera
0 de
abajo

Espera
1 de
abajo

rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq1(rcvpkt)

sndpkt = make_pkt(ACK, chksum)

udt_send(sndpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
Capa de transporte

3-44

rdt2.1: Discusin
Emisor:
#sec agregado al
paquete
Dos #sec (0,1) sern
suficientes. Porqu?
Debe verificar si el
ACK/NAK recibido esta
daado
Dos veces mas estados

Un estado debe recordar

si el paquete actual tiene
#sec 0 o 1

Receptor:
Debe verificar si el
paquete recibido es
duplicado

El estado indica si el
#sec esperado es 0 o 1

nota: el receptor no

puede saber si su
ltimo ACK/NAK fu
recibido correctamente
en el emisor
Capa de transporte

3-45

rdt2.2: Un protocolo libre de NAK

La misma funcionalidad que rdt2.1, usando solo ACKs
En vez de un NAK, el receptor enva un ACK por el

ltimo paquete recibido OK

El receptor debe incluir explcitamente el #sec del paquete

confirmado

Un ACK duplicado en el emisor resulta en la misma

accin que un NAK: se retransmite el paquete actual

Capa de transporte

3-46

rdt2.2: Fragmentos del emisor y receptor

rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for
call 0 from
above

rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)

Wait for
0 from
below

( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
udt_send(sndpkt)

Wait for
ACK
0

sender FSM
fragment

rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)

receiver FSM
fragment

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
Capa de transporte
udt_send(sndpkt)

3-47

rdt3.0: Canal con errores y prdida

Nueva presuncin:
El canal subyascente
puede tambin perder
paquetes (de datos o
ACKs)

Suma de verificacin,
#sec, ACKs y
retransmisiones son de
ayuda, pero no
suficientes

Enfoque: el emisor espera por un

tiempo razonable un ACK
Retransmite si no se recibe ningun
ACK en ese tiempo
Si el paquete (o ACK) solo se retras
(no se perdi) :
La retransmisin generar un
duplicado, pero el uso de #sec
resuelve este problema
El receptor debe especificar #sec
del paquete confirmado
Requiere de un contador
descendente

Capa de transporte

3-48

rdt3.0 emisor
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer

rdt_rcv(rcvpkt)

rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)

rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )

timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer

stop_timer
timeout
udt_send(sndpkt)
start_timer

Wait
for
ACK0

Wait for
call 0from
above

rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )

Wait
for
ACK1

Wait for
call 1 from
above

rdt_rcv(rcvpkt)

rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer

Capa de transporte

3-49

rdt3.0 en accin

Capa de transporte

3-50

rdt3.0 en accin

Capa de transporte

3-51

Desempeo de rdt3.0
rdt3.0 funciona, pero el desempeo es bajo
Ejemplo:

En un enlace de 1 Gbps, con retardo de propagacin de 15 ms, y

tamao de paquete de 8000 bits:

Utilizacin del emisor

Uemisor
:
Fraccin de tiempo que el emisor est ocupado
enviando
RTT
:
Tiempo de ida y vuelta (Round Trip Time)

3-52

rdt3.0: operacin de parada y espera

emisor

receptor

Primer bit de paquete transmitido, t = 0

Ultimo bit de paquete transmitido,
t=L/R
Llega primer bit de paquete

RTT

Llega ltimo bit de paquete, enviar

ACK

ACK llega, enviar siguientepaquete,

t = RTT + L / R

1 PDU de 1KB cada 30 ms 33KBps (267Kbps) an sobre un enlace de 1Gbps

El protocolo de red limita el uso de los recursos fsicos!
3-53

Protocolos entubados (encauzados)

Encauzamiento: el emisor permite mltiples paquetes, en camino,
por confirmar

El rango de nmeros de secuencia debe incrementarse

Buffers en el emisor y receptor

Dos formas genricas de protocolos encauzados: regresar a N,

repeticin selectiva
3-54

Encauzamiento: utilizacin mejorada

sender

receiver

Primer bit de paq. transmitido, t = 0

Ultimo bit transmitido,
t=L/R
Llega primer bit de paquete
Llega ltimo bit de paquete, enviar ACK
Llega ltimo bit de 2 paquete, enviar ACK
Llega ltimo bit de 3 paquete, enviar ACK

RTT

ACK llega, enviar siguiente paquete,

t = RTT + L / R

Incrementa la utilizacin
en un factor de 3!

3-55

Protocolos encauzados
Regresar a N:

Repeticin selectiva:

El emisor puede tener hasta N

El emisor puede tener hasta

paquetes sin confirmar en el

cauce
El receptor solo enva ACKs
acumulativos

No confirma un paquete si existe

un espacio

El emisor tiene un temporizador

para el paquete mas viejo sin

confirmar

Si el temporizador expira,
retransmite todos los paquetes
no confirmados

N paquetes sin confirmar en

el cauce
El receptor confirma
paquetes individuales
El emisor mantiene un
temporizador por cada
paquete sin confirmar

Cuando expira el
temporizador, retransmite
solo el paquete no
confirmado

3-56

Regresar a N
Emisor:
#sec de k bits en encabezado de paquete
Ventana de hasta N, paquetes consecutivos sin confirmar permitidos

ACK(n): Confirma todos los paquetes hasta #sec n inclusive ACK

acumulativo
Puede recibir ACKs duplicados (ver receptor)
Timer para cada paquete en camino
timeout(n): Retransmite el paquete n y todos los paquetes con #sec mayor en
la ventana

3-57

Regresar a N: FSM extendido del emisor

rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
else
refuse_data(data)

base=1
nextseqnum=1

Esperar
rdt_rcv(rcvpkt) && corrupt(rcvpkt)

timeout
start_timer
udt_send(sndpkt[base])
udt_send(sndpkt[base+1])

udt_send(sndpkt[nextseqnum1])

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer

3-58

Regresar a N: FSM extendido del receptor

default
udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcurrupt(rcvpkt)
&& hasseqnum(rcvpkt,expectedseqnum)

Wait
expectedseqnum=1
sndpkt = make_pkt(0,ACK,chksum)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++

ACK-only: siempre enva un ACK por paquete correctamente recibido con

el mayor #sec en orden

Puede generar ACKs duplicados

Solo necesita recordar expectedseqnum

Paquetes fuera de orden:

descartar (no poner en buffer) -> no requiere buffer en el receptor!

Reconfirmar el paquete con el mayor #sec en orden
3-59

Regresar a N en accin

3-60

Repeticin selectiva
El receptor confirma individualmente todos los

paquetes correctamente recibidos

Pone en buffer los paquetes, segn se requiera, para su

eventual entrega ordenada a la capa superior

El emisor solo reenva los paquetes para los cuales no

se recibi un ACK

Un timer por cada paquete no confirmado en el emisor

Ventana del emisor

N #sec consecutivos
Limita los #sec de paquetes enviados sin confirmar

3-61

Repeticin selectiva: ventanas de emisor y

receptor

3-62

Repeticin selectiva
Emisor
Datos desde arriba :

Si el siguiente #sec disponible

esta en la ventana, enviar
paquete

Timeout(n):

Reenviar paquete n, reiniciar

timer

Receptor
Paquete n en [rcvbase, rcvbase+N-1]
enviar ACK(n)
Fuera de orden: buffer
En orden: entregar (tambin
entregar paquetes ordenados
en buffer), avanzar la ventana al
siguiente paquete por recibir

ACK(n) en [sendbase,sendbase+N]:

Paquete n en [rcvbase-N,rcvbase-1]

Marcar paquete n como recibido

Si n es el paquete menor sin
confirmar, avanzar la base de la
ventana al siguiente #sec sin
confirmar

Paquete duplicado. Enviar

ACK(n)

En otro caso:

Ignorar paquete

3-63

Repeticin selectiva en accin

3-64

Repeticin selectiva:
dilema
Ejemplo:
#s sec: 0, 1, 2, 3
Tamao de ventana=3

El receptor no ve ninguna
diferencia en los dos escenarios!
Erroneamente pasa datos
duplicados como nuevos en (a)

Preg: Que relacin existe entre el

tamao de #sec y el tamao de la
ventana?

3-65

TCP
Transmission Control Protocol

3-66

TCP: Revisin

RFCs: 793, 1122, 1323, 2018, 2581

Transmisin full duplex:
Flujo de datos bidireccional en
la misma conexin
MSS: maximum segment size
Orientado a la conexin:
handshaking (intercambio de
mensajes de control) inicia el
estado de emisor y receptor
antes del intercambio de datos
Flujo controlado:
El emisor no inundar al
receptor

Punto a punto:
Un emisor, un receptor
Fiable, flujo de bytes en orden:
No existe delimitacin de
mensajes
Encauzado:
Control de congestionamiento y
flujo.
TCP determina el tamao de la
ventana
Buffers de envo y recepcin

socket
door

a p p l ic a t io n
w r ite s d a ta

a p p l ic a t io n
re a d s d a ta

TCP
s e n d b u ffe r

TCP
r e c e iv e b u f f e r
segm ent

socket
door

3-67

Estructura de segmento TCP

32 bits
URG: datos urgentes
(forzar el
procesamiento
prioritario de un
segmento)

#puerto origen

#puerto dest.

Nro de secuencia
Nro confirmacin (ACK#)
head no
UA P RS F
len usado

Receive window

checksum

Urgent data ptr

ACK: ACK # vlido

PSH: push data now
(forzar transmisin
inmediata)

RST: reset conexin

SYN: sincronizar #seq
FIN: cerrar conexin

Opciones (longitud variable)

Datos de aplicacin
(longitud variable)

Conteo por bytes

de datos
(no segmentos!)

# bytes que el
Receptor desea
aceptar
Suma de
verificacin
(como en UDP)

3-68

#sec y ACKs TCP

#Sec:

nmero de byte en el
flujo del primer byte
en el segmento de
datos

Usuario
escribe
C

ACKs:
Nmero de secuencia
del siguiente byte
esperado del otro lado
ACK acumulativos
P: Cmo maneja el
receptor los segmentos
fuera de orden?
R: TCP deja esto al
implementador

Host B

Host A
Seq=4
2, AC
K=7

9, dat
a

= C

= C
a
t
a
d
=43,
K
C
A
79,
Seq=

host ACKs
La recepcin
del C
reenviado

Seq=4

3, ACK

host confirma
La recepcin
deC.
Devuelve C

=80

tiempo
ESCENARIO SIMPLE DE TELNET
3-69

TCP: Round Trip Time y Timeout

P: Como establecer el
valor del timeout de
TCP?
Mayor que RTT

pero RTT vara

Muy corto: timeout prematuro

Retransmisiones
innecesarias
Muy largo: reaccin lenta
ante la prdida de
segmentos

P: Como estimar RTT?

SampleRTT: tiempo medido

desde la transmisin del

segmento hasta la recepcin
del ACK
Ignorar retransmisiones
SampleRTT variar , se
requiere un RTT estimado
suave
Promediar varias
mediciones recientes, no
solo el SampleRTT actual

3-70

TCP: Round Trip Time y Timeout

Media mvil ponderada exponencial (Exponential Weighted

Moving Average EWMA)

La influencia de muestras anteriores decrece exponencialmente
rpido
Valor tpico de = 0.125

3-71

Ejemplo de estimacin RTT:

3-72

TCP: Round Trip Time y Timeout

Establecimiento del timeout
EstimatedRTT ms un margen de seguridad

Mayor variacion en EstimatedRTT -> margen de seguridad mayor

Primero estimar en cunto SampleRTT se desva del

EstimatedRTT:

(valor tpico de = 0.25)

Luego establecer el intervalo del timeout :

3-73

TCP
Transporte orientado a la conexin: TCP
Estructura de segmento
Transferencia de datos fiable
Control de flujo
Gestin de conexin
Principios de control de congestionamiento
Control de congestionamiento TCP

3-74

Transferencia de datos fiable TCP

TCP crea un servicio

TDF sobre el servicio

no fiable de IP
Segmentos entubados
ACKs acumulativos
TCP utiliza un
temporizador de
retransmisin nico

Las retransmisiones

ocurren cuando:

Ocurre un timeout
Se recibe acks duplicados

Considere inicialmente un

emisor TCP simplificado:

Ignora acks duplicados

Ignora control de flujo y
control de congestionamiento

3-75

Eventos del emisor TCP:

Datos recibidos de la aplicacin:
Crear segmento con seq#
seq# es el nmero en el flujo
de bytes del primer byte de
datos del segmento
Iniciar timer si ste an no esta
activado (el timer se asocia al
segmento no confirmado ms
antiguo)
Intervalo de expiracin:
TimeOutInterval

timeout:
Retransmitir el segmento que
ocasion el timeout
Reiniciar timer
ACK recibido:
Si confirma segmentos
previamente no confirmados

Actualizar aquello que deba

ser confirmado
Iniciar timer si existen
segmentos pendientes

3-76

Emisor TCP (simplificado)

NextSeqNum=InitialSeqNumber
SendBase=InitialSeqNumber
loop(eternamente){
switch(event)
event: Datos recibidosdesdedesde aplicacion
Crear segmento TCP con numero de secuencia NextSeqNum
if
(timer no esta corriendo)
Iniciar timer
pasar segmento a IP
NextSeqNum = NextSeqNum + length(datos)
break;
event: Timeout de timer
Retransmitir segmento aun-no-confirmado con el menor numero de
secuencia
Iniciar timer
break;
event: ACK recibido,con campo ACK igual a y
if
(y>SendBase){
SendBase=y
if (existen segmentos aun-no-reconocidos)
Iniciar timer
}
break;
}
SendBase-1: ltimo byte confirmado acumulativamente
Ejemplo:
Si SendBase-1 = 71; y = 73, entonces el receptor espera 73+ ;
Si y > SendBase, entonces se confirma segmentos previamente no confirmados

3-77

TCP: Escenarios de retransmisin

La prdida de un
ACK obliga una
retransmisin

SendBase =
100
ACK PERDIDO

3-78

TCP: Escenarios de retransmisin

Sendbase =
100
SendBase =
120
SendBase =
120

El segmento 100 no
se retransmite

TIMEOUT PREMATURO

3-79

TCP Escenarios de retransmisin

SendBase =
120

El ack acumulativo
evita la retransmisin
del primer segmento

ACK ACUMULATIVO

3-80

Generacin de ACK TCP

[RFC 1122, RFC 2581]

Evento en el Receptor

Accin en el Receptor TCP

Llegada de segmento con seq#

esperado.
Todos los datos hasta el seq#
esperado ya confirmados

ACK retrasado. Esperar hasta 500

ms por un siguiente segmento-enorden.
Si no hay, enviar ACK

Llegada de segmento con seq#

esperado. Otro segmento tiene
un ACK pendiente

Enviar inmediatamente un nico ACK

Acumulativo, confirmando los dos
segmentos llegados en orden

Llegada de un segmento fuera

de orden con seq# mayor al
esperado. Se detecta un hueco

Enviar inmediatamente un ACK

duplicado, Indicando el seq# del sgte
byte esperado (que es el limite inferior
del hueco)
Enviar inmediatamente un ACK,
siempre que el segmento comience
en el limite inferior del hueco

Llegada de un segmento que

llena parcial o completamente
un hueco

3-81

Retransmisin rpida
Periodo de Timeout suele

ser relativamente largo:

Retardo largo antes de

reenviar un paquete perdido

Deteccin de segmentos

perdidos mediante ACKs

duplicados.

El emisor suele enviar

muchos segmentos
seguidos (back-to-back)
Si se pierde un segmento,
puede haber muchos ACKs
duplicados.

Si el emisor recibe 3

ACKs para el mismo dato,

este supone que el
segmento despus de los
datos confirmados se
perdi:

Retransmisin rpida:
reenviar segmento
antes que el timer
expire

3-82

Retransmisin rpida
Reenvio de un segmento despus de un ACK duplicado TRES veces

Antes que venza el

temporizador

Capa de transporte

3-83

Algoritmo de Retransmisin Rpida:

evento: ACK recibido, con campo ACK con valor y
si (y > SendBase) {
SendBase = y
si (existen segmentos aun-no-confirmados)
iniciar timer
}
sino {
incrementar cuenta de ACKs duplicados recibidos por y
si (cuenta de ACKs duplicados recibidos por y = 3) {
renviar segmento con numero de secuencia y
}

Un ACK duplicado
para un segmento ya
confirmado

Retransmisin rpida

3-84

Algoritmo de Retransmisin Rpida:

event:
ACK recibido,con campo ACK igual a y
if(y>SendBase){
SendBase = y
if(existen segmentos aun-no-confirmados)
Iniciar timer
}
else{/* un ACK duplicado para un segmento ya confirmado */
Incrementar contador de ACKs duplicados recibidos para y
if(numero de ACKs duplicados para y ==3)
/* Retransmisin rpida TCP */
reenviar segmento con numero de secuencia y
}
break;

3-85

Control de flujo TCP

Capa de transporte

3-86

Control de flujo TCP

Control de flujo
El receptor TCP tiene

un buffer de recepcin

El emisor no desbordar el
buffer del receptor
transmitiendo demasiado a
excesiva velocidad
El control de flujo es un

El proceso de la aplicacin

puede ser lento al leer del

buffer

servicio de conciliacin de
velocidad:
Conciliar la tasa de
transmisin con la tasa de
recuperacin de la
aplicacin receptora

Capa de transporte

3-87

Control de flujo TCP: Cmo funciona

El receptor notifica espacio

libre incluyendo el valor de

RcvWindow en los
segmentos
El emisor limita datos no
confirmados a RcvWindow

Garantiza que el buffer de

recepcin no se desbordar

3-88

Gestin de conexin TCP

Capa de transporte

3-89

Gestion de conexin TCP

Recuerde: el emisor y el receptor TCP establecen una conexin
antes de intercambiar segmentos de datos
Inicializar variables TCP :
seq. #s
buffers, informacin de control de flujo (e.g. RcvWindow)
Cliente: iniciador de la conexin
Socket clientSocket = new

Socket("hostname","port number");

Servidor: contactado por cliente

Socket connectionSocket = welcomeSocket.accept();

Capa de transporte

3-90

Gestin de conexin TCP

Three way handshake:
1: El cliente enva un segmento
TCP SYN al servidor
Especifica su seq# inicial
No enva datos
2: El servidor recibe SYN, responde
con un segmento SYN-ACK

Servidor asigna buffers

Especifica el seq# inicial del
servidor

3: El cliente recibe SYN-ACK;

responde con un segmento
ACK, que puede contener datos
Capa de transporte

3-91

Gestin de conexin TCP

client

Cierre de conexin:
Cliente cierra socket:
clientSocket.close();

close

Paso 1: host cliente enva un

segmento de control TCP
FIN al servidor

FIN

ACK

close

FIN

timed wait

Paso 2: host servidor recibe

FIN, responde con ACK.
Cierrra conexin, envia FIN.

server

ACK

closed
Capa de transporte

3-92

Gestion de conexin TCP

Paso 3: host cliente recibe
FIN, responde con ACK.

Ingresa en timed wait

responder con ACK a
los FINs recibidos

client

closing

server
FIN

ACK

Paso 4: host servidor, recibe

ACK. Conexin cerrada.

closing

timed wait

FIN

ACK

closed

closed
Capa de transporte

3-93

Gestion de conexin TCP

Ciclo de vida de cliente TCP

Capa de transporte

3-94

Gestion de conexin TCP

Ciclo de vida de servidor TCP

Capa de transporte

3-95

Principios de control de
congestionamiento

Capa de transporte

3-96

Principios de control de congestionamiento

Congestion:
Informalmente: muchas fuentes enviando muchos

datos mas rpido de lo que la red puede manejar

Manifestaciones:
Paquetes perdidos (desbordamiento de buffers en
los enrutadores)
Retardos largos (encolamiento en buffer de
enrutadores)
Diferente del control de flujo!
Un problema crtico!
Capa de transporte

3-97

Causas/costos de la congestion: escenario 1

Host A

Dos emisores, dos

receptores
Un enrutador, buffer
infinito
Sin retransmisin

Host B

in : datos originales

out

Buffers de enlace de
salida compartidos infinito

Retardos largos

cuando
congestionado
Rendimiento
mximo alcanzable

Capa de transporte

3-98

Causas/costos de la congestion: escenario 2

Un enrutador, buffer finito
Retransmision de paquetes perdidos por el emisor

Host A

out

in : datos originales
'in : datos originales , mas
datos retransmitidos

Host B

Buffers de enlace de
salida compartidos finito

Capa de transporte

3-99

Causas/costos de la congestion: escenario 2

in

= out

Siempre:

(goodput)

Retransmisin perfecta solo por prdidas:

Retransmisin de paquetes retrasados (no perdidos) hace in mayor (que

in > out

el caso perfecto) para el mismo out

R/2

R/2

R/2

R/4

in

a.

R/2

out

out

out

R/3

in

R/2

in

R/2

c.

b.

Costos de congestion:
Mas trabajo (retransmisiones) para dado goodput
Retransmisiones innecesarias: el enlace transporta multiples copias de un paquete
Capa de transporte

3-100

Causas/costos de la congestion: escenario 3

Cuatro emisores
Rutas multisalto
Timeout / retransmisin

Host A

Q: que pasa cuando in y in

se incrementan?

in : datos originales

out

'in : datos originales, mas

datos retransmitidos
Buffers de enlace de
salida compartidos finito

Host B

Capa de transporte

3-101

Causas/costos de la congestion: escenario 3

H
o
s
t
A

o
u
t

H
o
s
t
B

Otro costo de la congestin:

Cuando un paquete es descartado, toda capacidad de
transmisin usada para dicho paquete fue desperdiciada

Capa de transporte

3-102

Enfoques para el control de congestionamiento

Dos enfoques para el control de congestionamiento:
Control de congestionamiento
extremo-extremo:

Control de congestionamiento
asistido por la red:

No hay retroalimentacin
explicita de la red
El congestionamiento se infiere
de las prdidas y retardos
observados por el sistema final
Es el enfoque tomado por TCP

Los enrutadores proveen

retroalimentacin a los sistemas
finales
Bit indicador de congestin
(SNA, DECbit, TCP/IP ECN,
ATM)
Tasa de transmisin explicita
a la cual debe transmitir el
emisor

Capa de transporte

3-103

Control de congestionamiento
TCP

Capa de transporte

3-104

Control de congestionamiento TCP : Detalles

Emisor limita la transmisin:

LastByteSent LastByteAcked
CongWin
Aproximadamente,

Tasa =

CongWin
Bytes/sec
RTT

CongWin es dinmica y funcin del

congestionamiento de red percibido

Cmo percibe el emisor el

congestionamiento?
loss event = timeout o 3 acks

duplicados
Emisor TCP reduce tasa
(CongWin) despues de loss
event
Tres mecanismos:
AIMD: Adittive Increment,
Multiplicative Decrement
slow start
conservative after timeout
events
Capa de transporte

3-105

Control de congestionamiento TCP:

incremento aditivo, decremento multiplicativo (AIMD)
Enfoque: incrementar tasa de transmisin (tamao de ventana),

verificando ancho de banda usable, hasta que ocurra prdida

Incremento aditivo: incrementar CongWin en 1 MSS cada RTT
hasta que se detecte prdida
Decremento multiplicativo: reducir CongWin a la mitad despues
de una prdida
c o n g e s tio n
w in d o w
2 4 K b y te s

Comportamiento de diente
de sierra: verificando
ancho de banda

1 6 K b y te s

8 K b y te s

tim e

Capa de transporte

3-106

TCP Slow Start

Cuando se inicia una

conexin, se establece
CongWin = 1 MSS

Ejemplo: MSS = 500 bytes &

RTT = 200 msec
Tasa inicial = 20 kbps

Cuando una conexin

comienza, incrementar la
tasa exponencialmente
hasta que ocurra la primera
prdida

Ancho de banda disponible

puede ser >> MSS/RTT

Es deseable escalar
rpidamente a una tasa
respetable
Capa de transporte

3-107

TCP Slow Start

Cuando una conexin

Duplicar CongWin cada

RTT
Se consigue incrementando
CongWin por cada ACK
recibido

RTT

comienza, incrementar la
tasa exponencialmente
hasta que ocurra la primera
prdida:

Host A

Host B
one segm
en

two segm
ents

four segm

ents

Resumen: tasa inicial es

baja pero escala

exponencialmente rpido

time
Capa de transporte

3-108

Refinamiento: infiriendo prdida

Despus de 3 ACKs duplicados:

CongWin se reduce a la
mitad
Luego la ventana crece
linealmente
Pero despus de un timeout:
CongWin se establece en 1
MSS;
Luego la ventana crece
exponencialmente hasta un
umbral, luego crece
linealmente

Filosofia:
3 ACKs duplicados indican

que la red puede entregar

algunos segmentos
Un timeout indica un
escenario de congestin
mas alarmante

Capa de transporte

3-109

Refinamiento
P: Cuando, debe el
crecimiento exponencial
pasar a ser lineal?
R: cuando CongWin sea
igual a de su valor
antes de un timeout.

Implementacin:
Umbral(Threshold ) variable
Ante una prdida, el umbral se iguala a de CongWin justo antes de
la prdida

Capa de transporte

3-110

Resumen: Control de congestionamientoTCP

Cuando CongWin esta por debajo del Threshold, el emisor

en fase slow-start, la ventana crece exponencialmente

Cuando CongWin esta por encima del Threshold, el emisor

esta en fase congestion-avoidance, la ventana crece

linealmente
Cuando ocurre triple ACK duplicado, el Threshold se iguala

a CongWin/2 y CongWin se iguala al Threshold

Cuando ocurre un timeout, el Threshold se iguala a

CongWin/2 y CongWin se iguala a 1 MSS

Capa de transporte

3-111

Control de congestionamiento de emisor TCP

Estado

Evento

Accin de Emisor TCP

Comentario

Slow Start
(SS)

ACK recibido por

datos previmente
no confirmados

CongWin = CongWin + MSS,

Si (CongWin > Threshold)
pasar a estado
Congestion
Avoidance

CongWin se duplica cada

RTT

Congestio
n
Avoidance
(CA)

ACK recibido por

datos previamente
no confirmados

CongWin = CongWin+MSS *
(MSS/CongWin)

Incremento aditivo: CongWin

se incrementa en 1 MSS
cada RTT

SS o CA

Prdida detectada
por tres ACKs
duplicados

Threshold = CongWin/2,
CongWin = Threshold,
pasar a estado Congestion
Avoidance

Recuperacin rpida.
Decremento multiplicativo:
CongWin no se reduce por
debajo de 1MSS

SS o CA

Timeout

Threshold = CongWin/2,
CongWin = 1 MSS,
pasar a estadoSlow Start

Slow start

SS o CA

ACK duplicado

Incrementar contador de ACK

duplicados para el segmento
que se esta confirmando

CongWin y Threshold no
cambian

Capa de transporte

3-112

Algoritmo de control de congestionamiento

Th = ?
CongWin = 1 MSS
/* slow start o incremento exponencial */
While (No Packet Loss & CongWin < Th) {
enviar CongWin segmentos TCP
por cada ACK incrementar CongWin en 1
}
/* congestion avoidance o incremento lineal */
While (No Packet Loss) {
enviar CongWin segmentos TCP
para CongWin ACKs, incrementar CongWin en 1
}
Th = CongWin/2
If (3 Dup ACKs) CongWing = Th;
If (timeout) CongWin=1;
Capa de transporte

3-113

Rendimiento TCP
Cual es el rendimiento promedio de TCP en funcin

del tamao de ventana y el RTT?

Ignore slow start

Sea W el tamao de la ventana cuando ocurre una perdida.
Cuando la ventana es W, el rendimiento es W/RTT
Justo despus de la perdida, la ventana cae a W/2 y el
rendimiento a W/2RTT.
Rendimiento promedio = 0.75W/RTT

Capa de transporte

3-114

TCP a futuro: TCP sobre lineas de alta velocidad

Por ejemplo: segmentos de 1500 bytes, RTT de 100ms,

se desea un rendimiento de 10Gbps

Se requiere una ventana de tamao W = 83,333
segmentos (in-flight)
Rendimiento en trminos de la tasa de perdida:

Con:

Capa de transporte

3-115

Equidad de TCP
Objetivo de equidad: si K sesiones TCP comparten el mismo
enlace con ancho de banda R, cada uno debe tener una tasa
promedio de R/K

Conexin TCP 1

Conexin TCP 2

Router con
capacidad R

Capa de transporte

3-116

Por qu TCP es equitativo?

Dos sesiones concurrentes:
Incremento aditivo genera una pendiente de 1 a medida se incrementa
Decremento multiplicativo disminuye el rendimiento proporcionalmente

Rendimiento de Conexin 2

Igual fraccin de ancho de banda

loss: decrementa ventana a la mitad

congestion avoidance: incremento aditivo
loss: decrementa ventana a la mitad
congestion avoidance: incremento aditivo

Rendimiento de Conexin 1

R
Capa de transporte

3-117

Equidad
Equidad y UDP

Equidad y conexiones TCP paralelas

Las aplicaciones

Nada prohbe a las aplicaciones

multimedia generalmente
no usan TCP

No desean ahogar la
tasa por el control de
congestionamiento

En su lugar usan UDP:

Bombean audio/video a
tasa constante, toleran
prdida de paquetes

de abrir conexiones paralelas

entre 2 hosts.
Los navegadores web lo hacen
Por ejemplo: un enlace de tasa R
que soporta 9 conexiones;

Una nueva aplicacin pide 1 TCP,

recibe una tasa de R/10
Una nueva aplicacin pide 11
TCPs, recibe R/2 !

Capa de transporte

3-118