Académique Documents
Professionnel Documents
Culture Documents
Redes de
Computadores
Captulo 3
Capa de Transporte
Nota acerca de las transparencias del curso:
Estas transparencias estn basadas en el sitio web que acompaa el libro y
han sido modificadas por los docentes del curso.
Computer Networking:
A Top Down Approach
4th edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2007.
3-1
multiplexacin/demultiplexacin
transferencia de datos
confiable
control de flujo
control de congestin
orientado a conexin
TCP: transporte orientado a
conexin
control de congestin de
TCP
3-2
Captulo 3: agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-3
Protocolos y servicios de
transporte
application
transport
network
data link
physical
g
lo
a
ic
le
nd
n
-e
d
s
an
tr
rt
po
application
transport
network
data link
physical
3-4
Analoga familiar:
Capa de transporte:
procesos = nios
Los dispositivos
intermedios (routers por
ejemplo), implementan
protocolos de capa de
transporte y de capa de
aplicacin?
Mensajes de aplicacin =
3-5
Protocolos de la capa de
Transporte de Internet
confiable, entrega en
orden: TCP
servicios no disponibles:
garantas de retardo
garantas de ancho de
banda
data link
physical
rt
po
En relacin al mejor
esfuerzo de IP, poco
aporta
network
data link
physicalnetwork
s
an
tr
nd
ordenada: UDP
-e
nd
no confiable, entrega no
network
data link
physical
le
network
data link
physical
a
ic
control de congestin
control de flujo
establecimiento de la
conexin
g
lo
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
3-6
Captulo 3: agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-7
Multiplexacin/Demultiplexacin
Multiplexacin en el host transmisor
= proceso
P3
P1
P1
aplicacin
transporte
P2
P4
aplicacin
transporte
red
red
enlace
enlace
enlace
fsica
fsica
fsica
host 1
host 2
host 3
3-8
32 bits
# puerto origen # puerto destino
otros campos
del encabezado
datos de
aplicacin
(mensaje)
Formato del segmento TCP/UDP
3-9
http://www.iana.org/assignments/port-numbers
Int. Redes de Computadores - Capa de Transporte
3-10
Demultiplexacin no orientada a
conexin
Crear
puerto:
Cuando el
segmento UDP:
host recibe el
Chequea el nmero de
puerto destino en el
segmento
Dirige el segmento UDP al
socket con dicho nmero
de puerto
Datagramas IP con
diferentes direcciones
IP origen y/o nmeros de
puerto origen dirigidos al
mismo socket
socket completamente
identificado por la dupla:
UDP
3-11
client
IP: A
P1
P1
P3
SP: 6428
SP: 6428
DP: 9157
DP: 5775
SP: 9157
SP: 5775
DP: 6428
DP: 6428
server
IP: C
client
IP: B
3-12
El
Socket TCP
El
direccin IP origen
nmero puerto origen
direccin IP destino
nmero puerto destino
tienen diferentes
sockets para cada
cliente que se conecta
3-13
P4
P5
P2
P6
P1P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157
client
IP: A
DP: 80
S-IP: A
D-IP: C
SP: 9157
server
IP: C
DP: 80
S-IP: B
D-IP: C
client
IP: B
3-14
P2
P4
P1P3
SP: 5775
DP: 80
S-IP: B
D-IP: C
SP: 9157
client
IP: A
DP: 80
S-IP: A
D-IP: C
SP: 9157
server
IP: C
DP: 80
S-IP: B
D-IP: C
client
IP: B
3-15
Port scanning
Es relativamente sencillo conocer qu aplicaciones estn
end systems
http://insecure.org/nmap
Si detectamos algn
3-16
Captulo 3: agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-17
Internet esqueltico
Servicio best effort; los
segmentos UDP podran:
perderse
entregarse fuera de orden
a la aplicacin
no orientado a conexin:
no hay handshaking UDP
entre el sender y el
receiver
3-18
UDP: ms
frecuentemente utilizado
para aplicaciones de
streaming multimedia
tolerante a las
prdidas
sensible a la rate
32 bits
Longitud, en
bytes del
segmento
UDP,
incluyendo
source port #
dest port #
longitud
checksum
header
datos de Aplicacin
(mensaje)
3-19
El checksum de UDP
Objetivo: detectar errores (p.e., bits cambiados) en el
segmento transmitido
Sender:
Receiver:
3-20
10
Captulo 3: agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-21
Principios de la transferencia de
datos confiable
networking !
3-22
11
Principios de la transferencia de
datos confiable
networking !
3-23
Principios de la transferencia de
datos confiable
3-24
12
deliver_data(): llamado
por rdt para entregar los
datos hacia arriba
send
side
receive
side
receiver
3-25
estado
1
evento
acciones
estado
2
3-26
13
rdt1.0:
confiable
Esperar
llamada
de arriba
rdt_send(data)
Esperar
llamada
de abajo
packet = make_pkt(data)
udt_send(packet)
sender
rdt_rcv(packet)
extract (packet,data)
deliver_data(data)
receiver
Int. Redes de Computadores - Capa de Transporte
3-27
Protocolos ARQ
Implica la presencia de reconocimientos positivos
3-28
14
Protocolos ARQ
Qu capacidades precisan estos protocolos?
Deteccin de errores
Retransmisin
clases
3-29
3-30
15
Esperar
por ACK
o NAK
receiver
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Esperar
llamada de
abajo
sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Int. Redes de Computadores - Capa de Transporte
3-31
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Esperar
llamada de
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Int. Redes de Computadores - Capa de Transporte
3-32
16
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Esperar
llamada de
abajo
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
Int. Redes de Computadores - Capa de Transporte
3-33
ACK/NAK est
corrupto?
el emisor no sabe qu ha
ocurrido en el receptor !
No puede simplemente
retransmitir:
posibles duplicados
el receptor debe saber
distinguirlos
Manejando duplicados:
el emisor retransmite el
paquete actual si el
ACK/NAK est corrupto
el emisor agrega un nmero
de secuencia a cada
paquete
el receptor descarta el
paquete duplicado (no lo
entrega hacia arriba)
Los ACK/NAK no llevan
nmeros de secuencia
Por qu?
3-34
17
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)
Esperar
ACK o
NAK 0
Esperar
llamada 0
de arriba
Esperar
llamada 1 de
arriba
Esperar
ACK o
NAK 1
udt_send(sndpkt)
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
Int. Redes de Computadores - Capa de Transporte
3-35
Esperar
0 de
abajo
Esperar
1 de
abajo
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
3-36
18
rdt2.1: discusin
Emisor:
nmero de secuencia
agregado al paquete
dos nmeros de seq.
(0,1) es suficiente?
debe chequear si el
ACK/NAK recibido
est corrupto
Receptor:
debe chequear si el
paquete recibido est
duplicado
nota: el receptor no
puede saber si el
ltimo ACK/NAK se
recibi OK en el
transmisor
3-37
solamente ACKs
recibido OK
actual
3-38
19
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
Esperar
llamada 0
de abajo
fragmento
de la FSM
del emisor
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
fragmento
de la FSM
del receptor
3-1
suma de comprobacin,
nros. de secuencia,
ACKs y retransmisiones
nos ayudan, pero no lo
suficiente
3-2
rdt3.0: emisor
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
Esperar por
llamada 0 de
arriba
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
stop_timer
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
Esperar
por
ACK1
Esperar
por
ACK0
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
Esperar por
llamada 1
de arriba
rdt_rcv(rcvpkt)
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
3-3
3-4
rdt3.0 en accin
rdt3.0 en accin
3-5
Performance de rdt3.0
rdt3.0 funciona, pero su
performance no es buena
bits
t transmitir = L = 8000
= 8 s
9
R
10 bps
un paquete
3-6
receiver
RTT
emisor =
L/R
.008
= 30.008
RTT + L / R
= 0.00027
3-7
Pipelined protocols
Pipelining: el emisor permite el envo de mltiples paquetes
a ser reconocidos
3-8
Pipelining: incremento de la
utilizacin
sender
receiver
sender
Incremento de la utilizacin
por un factor de 3!
3*L/R
RTT + L / R
.024
30.008
= 0.0008
3-9
Pipelining Protocols
Go-back-N: titulares
El transmisor puede tener
No enva el ACK de un
paquete si hay un hueco
El transmisor tiene un
viejo no-ACKed
Si el timer vence,
retransmite todos los
paquetes no-ACKed
Int. Redes de Computadoras - Capa de transporte
3-10
Go-Back-N
Emisor:
3-11
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[nextseqnum-1])
3-12
Esperar
expectedseqnum=1
sndpkt = make_pkt(0,ACK,chksum)
rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
&& hasseqnum(rcvpkt,expectedseqnum)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
3-13
3-14
GBN en
accin
Selective Repeat
el receptor enva ACKs
individualmente para
3-15
3-16
Selective repeat
emisor
datos desde arriba:
timeout(n):
ACK(n) en [sendbase,sendbase+N]:
marcar al paquete n como
receptor
paq. n en [rcvbase, rcvbase+N-1]
enviar ACK(n)
fuera de orden: buffer
en orden: entregar
recibido
pkt n en [rcvbase-N,rcvbase-1]
ACK(n)
si n es el paquete ms
en otro caso:
ignorar
Int. Redes de Computadoras - Capa de transporte
3-17
3-18
Repeticin selectiva:
el dilema
Ejemplo:
seq #s: 0, 1, 2, 3
Tamao de ventana = 3
receiver no hay
diferencias en los dos
escenarios!
en (a) incorrectamente
se pasan datos
duplicados como
nuevos
para el
P: Qu relacin debe
haber entre seq # size
y el tamao de
ventana?
3-19
Mecanismos de transferencia
confiable: resumen
Suma de comprobacin
Temporizador
Nmero de secuencia
Reconocimiento
Reconocimiento negativo
Ventana deslizante
3-20
10
Agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-1
mayo del 74
septiembre del 81
RFC 793: Especificacin de TCP
octubre del 89
RFC 1122: Requerimientos para los hosts de Internet
mayo del 92
RFC 1323: Extensiones a TCP
octubre del 96
RFC 2018: Selective ACK
Int. Redes de Computadores - Capa de transporte
3-2
diciembre del 98
RFC 2460: TCP con IPv6
abril del 99
RFC 2581: Control de congestin de TCP
junio del 00
RFC 2873: Interaccin de TCP y IP (bits de precedencia)
3-3
un sender, un receiver
entre end systems
servicio de datos
confiable:
socket
door
El control de congestin y el
control de flujo de TCP
definen el tamao de
ventana
application
reads data
TCP
send buffer
TCP
receive buffer
segment
size
orientado a conexin:
pipelined:
no alineado a bordes de
mensajes
full duplex
handshaking (intercambio
de mensajes de control)
inicializa el estado del
sender y del receiver
previo al intercambio de
datos
flujo controlado:
socket
door
el sender no abruma al
receiver
3-4
source port #
Contando de a
bytes de datos
(no segmentos!)
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
Receive window
nmero de
bytes que el
receptor est
dispuesto a
aceptar
Internet
checksum
(como en UDP)
Datos de
aplicacin
(longitud
variable)
Int. Redes de Computadores - Capa de transporte
3-5
ACKs:
Host A
byte stream
El
Usuario
escribe
C
host ACKs
recepcin
del C
devuelto
Seq=4
2, AC
K=79,
d
Host B
atos =
C
host ACKs
recepcin de
= C
C,
datos
=43,
K
devolviendo
C
A
79,
Seq=
C
Seq=4
3, ACK
=80
tiempo
3-6
desde la transmisin de un
segmento hasta la recepcin de
su ACK
ignorando retransmisiones
mayor al RTT
demasiado corto:
timeout prematuro
retransmisiones
innecesarias
demasiado largo: lenta
reaccin a prdida de
un segmento
MuestraRTT
3-7
exponencialmente
3-8
RTT (milliseconds)
300
250
200
150
100
1
15
22
29
36
43
50
57
64
71
78
85
92
99
106
time (seconnds)
SampleRTT
Estimated RTT
3-9
EstimacinRTT:
DesvRTT = (1-)* DesvRTT +
* |MuestraRTT-EstimacinRTT|
(tpicamente, = 0.25)
Entonces se establece el intervalo de timeout:
IntervaloTimeout = EstimacinRTT + 4 * DesvRTT
Int. Redes de Computadores - Capa de transporte
3-10
Agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-11
Las retransmisiones
eventos timeout
ACKs duplicados
Inicialmente
consideramos un
transmisor TCP
simplificado:
3-12
nmero de secuencia
El nmero de sec. es el
nmero del primer byte
de datos en el segmento
lanza timer si ya no
estaba corriendo (pensar
al timer asociado al
segmento ms viejo noACKed)
Intervalo de expiracin:
timeout:
Retransmite el
timeout
Re-lanza el
timer
Ack recibido:
Si reconoce segmentos
no reconocidos antes
Actualiza la informacin
de segmentos
reconocidos
lanza el timer si hay
segmentos no-ACKed
IntervaloTimeout
Int. Redes de Computadores - Capa de transporte
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event)
event: data received from application above
create TCP segment with sequence number NextSeqNum
if (timer currently not running)
start timer
pass segment to IP
NextSeqNum = NextSeqNum + length(data)
event: timer timeout
retransmit not-yet-acknowledged segment with
smallest sequence number
start timer
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
} /* end of loop forever */
3-13
Emisor
TCP
(simplificado)
Comentario:
SendBase-1: last
cumulatively
acked byte
Ejemplo:
SendBase-1 = 51;
y= 83, entonces el
receptor busca
83+ ;
y > SendBase,
Nuevos datos son
ACKed
3-14
Seq=92 timeout
ACK
datos
=100
loss
Seq=9
2, 8 b
ytes d
e
Sendbase
= 100
SendBase
= 120
datos
=100
ACK
SendBase
= 100
SendBase
= 120
tiempo
escenario de prdida de ACK
Host B
Seq=9
2, 8 b
ytes d
e dato
Seq=
s
100,
20 by
tes d
e dat
os
0
10
K=
120
AC ACK=
Seq=9
2, 8 b
ytes d
e
Seq=92 timeout
Seq=9
2, 8 b
ytes d
e
timeout
Host A
Host B
tiempo
datos
20
K=1
AC
timeout prematuro
3-15
Host B
timeout
Seq=9
2, 8 b
ytes d
e
datos
Seq=1
=100
00, 20
ACK
bytes
de da
tos
loss
=120
ACK
SendBase
= 120
time
Escenario ACK acumulativo
Int. Redes de Computadores - Capa de transporte
3-16
3-17
Fast Retransmit
El perodo de
timeout
generalmente es largo:
Detectar segmentos
El sender frecuentemente
enva varios segmentos de
manera consecutiva
Si el segmento se pierde,
podremos recibir varios
ACKs duplicados
Si el
3-18
Host A
Host B
timeout
re-en
vo de
l
2 o seg
mento
tiempo
Figure 3.37 Re-enviando un segmento despus del triple ACK duplicado
Int. Redes de Computadores - Capa de transporte
3-19
fast retransmit
3-20
10
Agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-21
Control de flujo
El emisor no debe
desbordar el buffer del
receptor transmitiendo muy
rpido demasiados datos
Servicio de
El proceso de aplicacin
equiparacin de
velocidad: adecuar la
velocidad de envo con
la velocidad de
drenado del buffer
por parte de la
aplicacin del receptor
3-22
11
espacio disponible en su
buffer, incluyendo el valor
de RcvWindow en los
segmentos
El emisor limita los datos
no-ACKed a RcvWindow
garantiza no desbordar el
buffer del receptor
buffer
buffer
3-23
Agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-24
12
receptor de TCP
establecen una conexin
antes de intercambiar
segmentos de datos
inicializa variables de TCP:
nros. de sec.
buffers, informacin de
control de flujo (p.e.
RcvWindow)
cliente: quien inicia la
conexin
Socket clientSocket = new
Socket("hostname","port
number");
cliente
Socket connectionSocket =
welcomeSocket.accept();
3-25
cliente
cerrar
cerrar
FIN
timed wait
FIN
ACK
servidor
ACK
cerrada
Int. Redes de Computadores - Capa de transporte
3-26
13
cliente
cerrar
servidor
FIN
ACK
timed wait
modificaciones, puede
manejar FINs simultneos.
cerrar
FIN
ACK
cerrada
cerrada
Int. Redes de Computadores - Capa de transporte
3-27
3-28
14
Algunos comentarios ms
Bandera RST (Reset)
Segmento SYN a un puerto TCP
Segmento SYNACK
Segmento RST
Nada
Mensaje UDP a puerto que no est escuchando
Puedo recibir mensaje ICMP
3-29
15
Agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-1
3-2
recursos de la red
Los recursos son utilizado por paquetes
posteriormente descartados
Retransmisiones
Pobre asignacin de recursos
Un problema importante!
3-3
Perspectiva histrica
Congestion avoidance y
control Van Jacobson &
Michael Karels November,
1988
Si se respeta el principio de
conservacin de los paquetes,
la congestin debera ser la
excepcin y no la regla
Dicho principio dice que para
una conexin establecida y en
equilibrio, un nuevo paquete
no puede ser introd. en la red
antes que otro paquete salga
de ella.
En equilibrio: conexin estable
con una ventana completa inflight
3-4
Causas/costos de la congestin:
escenario 1
senders, 2
receivers
1 router, buffers
Host A
out
in : original data
unlimited shared
output link buffers
Host B
infinitos
sin
retransmisiones
Cuando hay
congestin,
tenemos grandes
retardos
mximo
throughput
alcanzable
3-5
Causas/costos de la congestin:
escenario 2
1 router,
el
buffers finitos
out
in : original data
'in : original data, plus
retransmitted data
Host B
3-6
Causas/costos de la congestin:
escenario 2
(goodput)
=
out
in
retransmisin perfecta slo cuando hay prdidas:
siempre:
> out
in
La retransmisin de paquetes retrasados (no perdidos) hace
in
mayor (respecto al caso perfecto) para el mismo
out
R/2
R/2
R/2
in
out
out
out
R/3
R/2
in
a.
R/4
R/2
b.
in
R/2
c.
costos de la congestin:
ms trabajo (retransmisiones) para un goodput dado
Retransmisiones innecesarias: los enlaces llevan mltiples copias
Int. Redes de Computadores - Capa de transporte
de los paquetes
3-7
Causas/costos de la congestin:
escenario 3
senders
caminos multihop
timeout/retransmit
4
P: Qu ocurre si in y
aumentan?
in
Host A
in : original data
out
Host B
3-8
Causas/costos de la congestin:
escenario 3
H
o
s
t
A
o
u
t
H
o
s
t
B
3-9
Aproximaciones al control de
congestin (1/2)
Objetivo: estrangular al emisor para asegurar que la
carga en la
red es razonable
Dos estrategias posibles
Entre extremos
3-10
Aproximaciones al control de
congestin (2/2)
Objetivo: estrangular al emisor para asegurar que la
carga en la
red es razonable
Asistida por la red
Indirecta
Marcando un campo en algn paquete
Involucra RTTs
Explicit Congestion Notification (ECN) RFCs 3168 y 3540 y
http://www.icir.org/floyd/ecn.html
3-11
Aclaracin
Si el emisor y el receptor de la conexin
3-12
Agenda
3.1 Servicios de la
capa de transporte
3.2 Multiplexacin y
demultiplexacin
3.3 Transporte no
orientado a conexin:
UDP
3.4 Principios de la
transferencia de datos
confiable
3.5 Transporte
orientado a conexin:
TCP
de congestin
3.7 Control de
congestin de TCP
3-13
emisor:
LastByteSent-LastByteAcked
min {CongWin, RcvWin}
Sin mucha rigurosidad,
tasa =
CongWin
bytes/sec
RTT
La CongWin es dinmica;
funcin de la congestin de la
red percibida por el emisor
Cmo percibe
la congestin el emisor?
evento de prdida =
timeout o 3 ACKs
duplicados
El emisor TCP reduce la
tasa (CongWin) despus de
de un evento de prdida
Cuatro algoritmos:
slow start
congestion avoidance
fast retransmit
fast recovery
3-14
comienza,
CongWin = 1 MSS
El ancho de banda
Cuando la conexin
comienza, se incrementa
la velocidad
exponencialmente (no
linealmente) hasta el
primer evento de
prdida
Es deseable que
rpidamente lleguemos a
una velocidad respetable
Int. Redes de Computadores - Capa de transporte
3-15
La CongWin se incrementa
en a lo sumo SMSS bytes
por cada ACK nuevo
recibido (conservacin de
los paquetes)
Host A
RTT
comienza, se incrementa la
velocidad exponencialmente
hasta el primer evento de
prdida
Host B
one segm
ent
two segm
ents
four segm
ents
Resumen: la velocidad
time
Int. Redes de Computadores - Capa de transporte
3-16
ACKs duplicados:
CongWin se baja a la
mitad
Luego la ventana crece
linealmente, en 1
SMSS por RTT
Pero, luego de un evento
timeout:
CongWin vale 1 MSS;
La ventana crece
exponencialmente hasta
un umbral, y luego,
linealmente
Filosofa:
3 ACKs duplicados
3-17
P: Cundo debera el
incremento
exponencial
cambiar a lineal?
R: Cuando CongWin
alcanza la mitad de
su valor previo al
timeout.
Refinamiento
Implementacin:
Variable
Threshold
Threshold es fijado a
3-18
New Reno
Proactivos
Vegas
3-19
Comportamiento de
diente de sierra:
Probando en busca
de ancho de banda
16 Kbytes
8 Kbytes
time
time
3-20
10
Cuando ocurre un
3-21
Evento
Comentario
Slow Start
(SS)
Recepcin
de ACK para
datos
previamente
no-ACKed
Congestion
Avoidance
(CA)
Recepcin
de ACK para
datos
previamente
no-ACKed
CongWin = CongWin +
MSS x (MSS/CongWin)
Incremento aditivo.
Aumento de CongWin en 1
MSS por cada RTT
SS or CA
Evento de
prdida
detectado:
Triple ACK
duplicado
Threshold = CongWin/2,
CongWin = Threshold
pasa a estado Congestion
Avoidance
Fast recovery,
implementando
disminucin multiplicativa.
CongWin no puede ser
menor a 1 MSS.
SS or CA
Timeout
Threshold = CongWin/2,
CongWin = 1 MSS,
pasa a estado Slow Start
SS or CA
ACK
duplicado
CongWin y Threshold no
cambian
3-22
11
3-23
Cul es el
3-24
12
throughput
1.22 MSS
RTT L
aprox. L = 2 x 10-10 o sea, una prdida cada 5 x 10 9
velocidad
3-25
TCP Imparcialidad
Objetivo de la imparcialidad: si K sesiones TCP
comparten el mismo enlace cuello de botella de
ancho de banda R, cada uno debera tener una
tasa promedio de R/K
Conexin TCP 1
Router
cuello de botella
Conexin TCP 2 con capacidad R
3-26
13
Throughput de la
conexin 2
n l a
i de nd
ac a ba
liz et
ti l de
U om p o
c nch
a
Throughput de la
conexin 1
R
Int. Redes de Computadores - Capa de transporte
3-27
Imparcialidad (ms)
Imparcialidad y UDP
Las aplicaciones multimedia
frecuentemente no utilizan
TCP
rea de investigacin
TCP friendly
Protocolos de control de
congestin
Imparcialidad y conexiones
TCP paralelas
nada impide a una aplicacin
basada en TCP abrir varias
conexiones TCP paralelas entre
2 hosts.
Los web browsers hacen sto
Ejemplo: enlace de tasa R
soportando 9 conexiones;
3-28
14
Captulo 3: Resumen
principios detrs de los
servicios de la capa de
transporte:
Multiplexacin,
demultiplexacin
Transferencia de datos
Lo que se viene:
confiable
dejamos el borde
Control de flujo
(capas de aplicacin
Control de congestin
y de transporte)
Instanciacin e
nos metemos en el
implementacin en Internet
core de la red
UDP
TCP
Int. Redes de Computadores - Capa de transporte 3-29
15