Bloque III: El nivel de transporte

Tema 8: Retransmisiones y
temporizadores en TCP
 ndice
Bloque III: El nivel de transporte
Tema 8: Retransmisiones y temporizadores en TCP
Retransmisiones
Control de congestin
Algoritmo para evitar la congestin
Algoritmo de recuperacin y retransmisin rpida
Temporizadores
Temporizador de persistencia
Temporizador de keepalive

Referencias
Captulo 3 de Redes de Computadores: Un enfoque
descendente basdado en Internet. James F. Kurose, Keith
W. Ross. Addison Wesley, 2 edicin. 2003.
Captulos 21, 22 y 23 de TCP/IP Illustrated, Volume 1: The
Protocols, W. Richard Stevens, Addison Wesley, 1994.

RC - Bloque III - Tema 8 2

 Retransmisiones en TCP
TCP proporciona un servicio fiable sobre un protocolo no fiable
(IP) Se pueden perder datos y/o ACKs.
Solucin Esperar un tiempo la llegada del ACK (utilizando un
temporizador) y si no se recibe, se retransmite el segmento.
Problema: el RTT (Round Trip Time) es variable
Cmo se determina el intervalo de timeout?
Con qu frecuencia se producen retransmisiones?
Exponential backoff Si no se recibe el ACK la
primera retransmisin ocurrir entre 1 y 15 segundos
(ticks 500 milisegundos).
Las siguientes retransmisiones se duplica el tiempo: 3, 6,
12, 24, 48 y a partir de ah 64 segundos.
Se finalizan las retransmisiones despus de N intentos
(normalmente, entre 5-10 minutos).

RC - Bloque III - Tema 8 3

 Estimacin del RTT
Resulta fundamental para la estrategia de timeout y retransmisiones de
TCP el medir el RTT para la conexin, para as variar el timeout.
Problema: no hay una asignacin uno-a-uno entre segmento y
asentimiento
Slo se mide el RTT para un segmento simultneamente.
Su confirmacin puede venir en un ACK acumulado
estimacin ligeramente superior
Se utiliza un estimador a partir de la media y la desviacin tpica de
los retardos medidos (estimador de Jacobson).
La estimacin se basa en ticks de reloj (p.e. 500 milisegundos)
y no en tiempos absolutos.
Problema de ambigedad en la retransmisin:
Al producirse una retransmisin (por timeout), es imposible
saber si el ACK recibido es el correspondiente al segmento
original o al retransmitido.
Solucin Algoritmo de Karn:
Ante el problema de ambigedad en la retransmisin NO
deben usarse medidas de segmentos retransmitidos para estos
clculos.

RC - Bloque III - Tema 8 4

 Control de congestin
Dos posibilidades para perder paquete:
Saturacin en un router
Error en el paquete (probabilidad mucho menor
del 1%)
Se asume que cuando se cuando se pierde un
paquete es debido a que al menos un router
saturado.
Se utilizan dos indicadores para identificar un
problema de congestin (prdida de un paquete):
Ha vencido un timeout de retransmisin
Se han recibido ACKs duplicados

RC - Bloque III - Tema 8 5

 Control de congestin: Ejemplo
Cliente:1111 Servidor:discard
43 6401:6 889 51
657 (2 5
56) ac
k1 ack 45
61 53
45
6657:6
913 (2 ack
56) ac
46
6913:7
169 (2 k 1 ( pe 6 401 56
7169:7 5 6) ack rdido) ack 256 bytes
48 425 (2 1 57 58
a la aplicacin
5 6
50
7425:7
681 (2
6) ack
1 c k6
56) ac a
k1
7681:7 60 (guardar 256 bytes)
52 937 (2
56) ac
k1 6 657
ack 657 61 (guardar 256 bytes)
7937:8 k 6
54 193 (2 a c 7 62 (guardar 256 bytes)
8193:8
56) ac
k1 6 65
55 449 (2
56) ac ack 7 (guardar 256 bytes)
k1 6 65 64
57 8449:8
705 (2 ack
56) ac (guardar 256 bytes)
k1
8705:8 6 657 65
59 961 (2
56) ac ack 57 66 (guardar 256 bytes)
k1 k 66
a c

RC - Bloque III - Tema 8 6

 Control de congestin: Ejemplo
60
54 61
7
55 665 62
57 ack
64 (guardar 256 bytes)
657
59 8705:8961 ack
6
(256)
ack 1 6 657 65 (guardar 256 bytes)
6 657 ack 657
ack 6 66 (guardar 256 bytes)
ack
k 6 657 68 (guardar 256 bytes)
ac
6 657
ack 70 (guardar 256 bytes)
6657:6
63 913 (2
56) ac 6 657
k 1 (re
tx.) ack

2304 bytes
8 72
n 588 a la aplicacin
8961:9 i
67 217 (2 96 1, w
56) ac 8
k1 ack
69 9217:9
473 (2
56) ac
k1
71 9473:9
729 (2
56) ac
k1

RC - Bloque III - Tema 8 7

 Congestin: Ejemplo
Cuando el receptor recibe un segmento con mayor nmero de
secuencia transmite el ACK del byte que espera recibir.
Almacena los datos en espera de poder entregarlos en
orden.
Cuando el transmisor recibe el tercer ACK duplicado (1 2 se
admiten como posible desorden causado por la red) sobre el
mismo nmero de secuencia supone que se ha perdido slo
ese segmento.
Retransmite el segmento perdido y contina la transmisin
Algoritmo de recuperacin y retransmisin rpida
El receptor, al recibir el segmento perdido puede reordenar los
segmentos, entregar todos los datos recibidos al usuario y
asentirlos al transmisor.

RC - Bloque III - Tema 8 8

 Algoritmo para evitar la congestin
Es un control de flujo que se impone el propio
transmisor para evitar la congestin, frente a la
ventana anunciada por el receptor para evitar la
saturacin del mismo.
Se implementa conjuntamente con el algoritmo de
inicio lento.
Utiliza dos variables en bytes:
cwnd: ventana de congestin
ssthres: umbral de inicio lento

RC - Bloque III - Tema 8 9

 Algoritmo para evitar la congestin
1. Inicializacin:
cwnd = 1 segmento (en funcin del MSS)
ssthresh = 65535 bytes
2. TCP no podr enviar ms del mnimo de la ventana del receptor (win)
y la ventana de congestin (cwnd).
3. Cuando se produce congestin (el timeout expira o se reciben tres
ACKs repetidos) ssthresh = de la ventana activa
Ventana activa = min(win, cwnd)
Valor mnimo de ssthresh es siempre de 2 segmentos.
Adems, si es por timeout cwnd = 1 segmento
4. Cada vez que llega un ACK, se actualiza cwnd:
a) Si cwnd <= ssthresh Algoritmo de inicio lento (aumento
exponencial).
cwnd = cwnd + tamao segmento
b) Si cwnd > ssthresh Se aumenta cwnd en una cantidad nunca
superior a un segmento (aumento lineal). Se aplica la siguiente
frmula:
tamao segmento 2 tamao segmento
cwnd = cwnd + +
cwnd 8

RC - Bloque III - Tema 8 10

 Algoritmo para evitar la congestin
44 Algoritmo para evitar la
40
congestin

36
Ventana de congestin (KiloBytes)

32
ssthresh (32 KB)
28

24

20

16
Algoritmo de inicio
lento
12

0
0 1 2 3 4 5 6 7 8 9 10 11 12
Nmero de envo
RC - Bloque III - Tema 8 11
 Recuperacin y retransmisin rpida
Modificaciones sobre el algoritmo para evitar la congestin
propuestas por Jacobson (1990).
Requisitos: cada vez que TCP recibe un segmento fuera de
orden Genera un ACK (repetido) sin retardarlo.
Si se reciben uno o dos ACKs repetidos Se asume que los
segmentos se reciben desordenados.
Si se reciben tres o ms ACKs repetidos Se asume que se
ha perdido un segmento y se retransmite el supuesto segmento
perdido sin esperar a que venza el timeout (Algoritmo de
retransmisin rpida).
A continuacin se aplica el algoritmo de control de congestin y
no el algoritmo de inicio lento (Algoritmo de recuperacin
rpida).

RC - Bloque III - Tema 8 12

 Recuperacin y retransmisin rpida
3. Si se detecta congestin por recibir tres ACKs repetidos:
ssthresh = cwnd
Se retransmite el segmento perdido
cwnd = ssthresh + 3 segmentos
4. Cada vez que llega un ACK:
a) Cada vez que se recibe otro ACK duplicado:
cwnd = cwnd + 1 segmento
Se transmite si lo permite cwnd
b) Cuando se recibe un ACK que confirma datos nuevos (
la retransmisin se ha recibido):
cwnd = ssthresh (del paso 1)
Se reduce la tasa de transmisin a la mitad del valor
que tena cuando se produjo el fallo.

RC - Bloque III - Tema 8 13

 Control de congestin: Ejemplo
En primer lugar se ver el establecimiento de conexin y como
se inicializan los valores de cwnd y ssthresh.
Adems, en esta conexin se produce una prdida en el primer
SYN, y esto afecta directamente a los valores iniciales de cwnd
y ssthresh:
cwnd = 256 bytes
ssthresh = 512 bytes

Accin Variable
Segm. #
Enviar Recibir Observaciones cwnd ssthresh
Inicializacin 256 65535
SYN
Timeout 256 512
SYN
SYN, ACK
ACK
RC - Bloque III - Tema 8 14
 Control de congestin: Ejemplo
Accin Variable
Segm. #
Enviar Recibir Observaciones cwnd ssthresh

1 1:257

2 ACK 257 Alg. inicio lento 512 512

3 257:513

4 513:769

5 ACK 513 Alg. inicio lento 768 512

6 769:1025

7 1025:1281

8 ACK 769 Alg. evitar cong. 885 512

9 1281:1537

10 ACK 1025 Alg. evitar cong. 991 512

RC - Bloque III - Tema 8 15

 Control de congestin: Ejemplo
Accin Variable
Segm. #
Enviar Recibir Observaciones cwnd ssthresh

58 ACK 6657 ACK nuevo 2426 512

59 8705:8961

60 ACK 6657 ACK repetido 1 2426 512

61 ACK 6657 ACK repetido 2 2426 512

62 ACK 6657 ACK repetido 3 1792 1024

63 6657:6913 Retransmisin

64 ACK 6657 ACK repetido 4 2048 1024

65 ACK 6657 ACK repetido 5 2304 1024

66 ACK 6657 ACK repetido 6 2560 1024

67 8961:9217

RC - Bloque III - Tema 8 16

 Control de congestin: Ejemplo
Accin Variable
Segm. #
Enviar Recibir Observaciones cwnd ssthresh

68 ACK 6657 ACK repetido 7 2816 1024

69 9217:9473

70 ACK 6657 ACK repetido 8 3072 1024

71 9473:9729

72 ACK 8961 ACK nuevo 1280 1024

RC - Bloque III - Tema 8 17

 TCP: Temporizadores
TCP gestiona 4 temporizadores diferentes con cada
conexin:
Un temporizador de retransmisiones: se utiliza
cuando se espera un ACK del otro extremo.
Un temporizador de persistencia: mantiene la
informacin del tamao de ventana, incluso si el
otro extremo cierra su ventana de recepcin.
Un temporizador de keepalive: dectecta cuando
el otro extremo se reinicializa o est cado.
El temporizador 2MSL: mide el tiempo que la
conexin est en el estado TIME-WAIT.

RC - Bloque III - Tema 8 18

 Temporizador de persistencia
Emisor rpido, receptor lento

Cliente:1111 Servidor:8888
SYN 13281:1328
1 1(0)
win 4096, <MSS
1024>
4 5 8 2 7 : 4 5827(0) 2
SYN 102 4>
9 6 , < M SS
40
3 ACK 1, win
ACK 1, win 4096
4 PSH 1:1025 (1024) A
CK 1, win 4096
5 PSH 1025:2049 (102
4) ACK 1, win 4096
6 PSH 2049:3073 (102
4) ACK 1, win 4096
7 PSH 3073:4097 (102
Segmento de
4) ACK 1, win 4096
actualizacin
de ventana ACK 4097, win 0 8
6
ACK 4097, win 409 9

RC - Bloque III - Tema 8 19

 Temporizador de persistencia
Emisor rpido, receptor lento (continuacin)

Cliente:1111 Servidor:8888

10 PSH 4097:5121 (1024) ACK 1, win

4096
11 PSH 5121:6145 (1024) ACK
1, win 4096
12 PSH 6 1 45:7169 (1024) ACK
1, win 4096
Segmento de 13 FIN, PSH 7 169:8193 (1024) AC
K 1, win 4096
actualizacin
de ventana ACK 8194, win 0 14
6
ACK 8194, win 409 15
94, win 4096
FIN 1:1 (0) ACK 81
16

17 ACK 2, win 4096

RC - Bloque III - Tema 8 20

 Temporizador de persistencia
Qu ocurre si se pierde el ACK del segmento 9?
El cliente est esperando que el servidor le
actualice el tamao de ventana.
El servidor ha actualizado la ventana y est
esperando que le lleguen nuevos datos del
servidor.
Se entra en una situacin de abrazo mortal.
Para arreglarlo TCP, despus de un tiempo sin que
se abra la ventana, pregunta peridicamente si la
ventana se ha actualizado utilizando unos segmentos
especiales denominados: window probes.
Los window probes no son ms que segmentos de
un byte utilizados para comprobar si realmente la
ventana se ha modificado o no.

RC - Bloque III - Tema 8 21

 Temporizador de persistencia
Cliente:1111 Servidor:8888
1 PSH 1:1025 (1024) A
CK 1, win 4096
2 PSH 1025:2049 (102
4) ACK 1, win 4096
3 PSH 2049:3073 (102
4) ACK 1, win 4096
4 PSH 3073:4097 (1024) ACK
1, win 4096

ACK 4097, win 0 5

6 4097:4098 (1) ACK 1

, win 4096

window probe ACK 4097, win 0 7

8 4097:4098 (1) ACK 1

, win 4096
ACK 4097, win 0 9

10 4097:4098 (1) ACK 1

, win 4096
ACK 4097, win 0 11

RC - Bloque III - Tema 8 22

 Temporizador de persistencia
El temporizador de persistencia se activar en los siguientes
intervalos: 5, 6, 12, 24, 48, 60, 60, segundos.
Este temporizador se basa en el exponential backoff, pero
limitado entre 5 y 60 segundos.
Los window probes contienen 1 byte datos (n secuencia 4097):
TCP permite enviar un byte de datos por encima del tamao
de la ventana.
El ACK del receptor NO asiente el byte del window probe
(ACK 4097) Este byte se contina retransmitiendo.
Cundo se para la transmisin de window probes? Nunca, se
continan transmitiendo a intervalos de 60 segundos hasta que:
El receptor abre la ventana.
Se cierra la conexin por las aplicaciones.

RC - Bloque III - Tema 8 23

 Sndrome de la ventana tonta
El control de flujo de TCP puede provocar que se
intercambien pequeas cantidades de datos, en
lugar de esperar y enviar un segmento completo.
Causas:
La aplicacin receptora consume los datos muy
lentamente
La aplicacin emisora produce los datos muy
lentamente
En cualquier caso, los datos se envan con
segmentos muy pequeos:
Uso ineficiente del ancho de banda
Incremento del procesamiento por parte de TCP

RC - Bloque III - Tema 8 24

 Sndrome de la ventana tonta
Por ejemplo, la aplicacin
Buffer receptor lleno
1 byte libre
Enviar segmento de
Cab.
actualizacin de ventana
Cab. Recepcin del nuevo byte
Buffer receptor lleno
RC - Bloque III - Tema 8
recupera los datos
lentamente:
1. El buffer del TCP receptor
se llena
2. El TCP receptor notifica al
emisor que su ventana est
cerrada
3. La aplicacin receptora lee
un byte
4. El TCP receptor enva un
ACK al emisor para
anunciarle que dispone de
un byte libre
5. El TCP emisor enva un
segmento con un byte de
datos
6. Volvemos al punto 1
25
 Solucin de Clark (RFC 813)
Solucin de Clark: no enviar notificaciones de
ventana pequeas (p.e. 1 byte).
En cambio, cerrar la ventana completamente hasta
que:
Hay espacio para un segmento entero (MSS)
Se ha liberado la mitad del espacio del buffer del
receptor (para buffers muy pequeos)
La solucin de Clark y el algortimo de Nagle son
complementarios:
Algoritmo de Nagle: el emisor acumula datos
hasta que hay suficientes datos para enviar.
Solucin de Clark: el receptor consume datos
hasta que se ha liberado espacio suficiente en el
buffer para ser notificado
RC - Bloque III - Tema 8 26
 Temporizador de keepalive
En una conexin TCP sin intercambio de datos, no se produce
ningn intercambio de paquetes (polling).
Esto puede plantear problemas en situaciones de fallos del
cliente (cadas, cliente inalcanzable o reinicializaciones).
Para solucionar esto se encuentra el temporizador de keepalive
(aunque no es parte del RFC de TCP).
Tiene sentido en aplicaciones servidor que pueden liberar
recursos si el cliente no est realmente conectado.
Funcionamiento: despus de 2 horas de inactividad, el servidor
enviar un segmento sonda (similar al window probe).
Segmento sonda: segmento de un byte, correspondiente al
ltimo byte enviado.

RC - Bloque III - Tema 8 27

 Temporizador de keepalive
El cliente puede estar en uno de estos cuatro estados:
1. El cliente est levantado, funcionando y es alcanzable El
cliente responder correctamente al servidor y ste reinicia
el timeout a 2 horas
Tambin se reinicia el timeout si se produce
intercambio de datos
2. El host cliente se encuentra cado y an est cado o
reiniciazndose El servidor no obtendr respuesta y lo
reintentar 10 veces, en intervalos de 75 segundos (si no
recibe respuesta se cierra la conexin).
3. El host cliente se ha cado y se ha inicializado El cliente
responder con un segmento de reset y el servidor cerrar
la conexin.
4. El cliente est levantado y funcionando, pero no es
alcanzable Este caso es idntico al 2, y el servidor es
incapaz de diferenciarlos.

RC - Bloque III - Tema 8 28

 Temporizador de keepalive
Caso 1: cliente OK
Cliente:1111 Servidor:echo
1 PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK 2

3
ACK 14

2 horas
segmento sonda 4
13:13 (1) ACK 14
5 ACK 14

2 horas
6
13:13 (1) ACK 14
7 ACK 14

RC - Bloque III - Tema 8 29

 Temporizador de keepalive
Caso 2: cliente cado
Cliente:1111 Servidor:echo
1 PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK 2

3
ACK 14

2 horas
4
13:13 (1) ACK 14
5
13:13 (1) ACK 14
6
13:13 (1) ACK 14
Cada 75
segmentos sonda 7 segundos
13:13 (1) ACK 14
8
13:13 (1) ACK 14

RC - Bloque III - Tema 8 30

 Temporizador de keepalive
Caso 3: cliente cado y reiniciado

Cliente:1111 Servidor:echo
1 PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK 2

3
ACK 14

Cliente se apaga y
2 horas
vuelve a encender 4
13:13 (1) ACK 14
RST 14:14 (0) ACK 1
4
segmento sonda

RC - Bloque III - Tema 8 31

 Temporizador de keepalive
Caso 4: cliente inalcanzable (= caso 2)

Cliente:1111 Servidor:echo
1 PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK 2

3
ACK 14

2 horas
4
13:13 (1) ACK 14
5
13:13 (1) ACK 14
6
13:13 (1) ACK 14
Cada 75
segmentos sonda 7 segundos
13:13 (1) ACK 14
8
13:13 (1) ACK 14

RC - Bloque III - Tema 8 32