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

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

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

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

Control de congestin: Ejemplo

Cliente:1111
43
45
46
48
50
52
54
55
57
59

6401:6
657 (2
56) ac
k1
6657:6
913 (2
56) ac
6913:7
k 1 ( pe
169 (2
rdido)
5
6) ack
7169:7
1
425 (2
5
6) ack
7425:7
1
681 (2
56) ac
k1
7681:7
937 (2
56) ac
k1
7937:8
193 (2
56) ac
8193:8
k1
449 (2
56) ac
k1
8449:8
705 (2
56) ac
k1
8705:8
961 (2
56) ac
k1

RC - Bloque III - Tema 8

Servidor:discard
89
8
5
ack 45
61
ack
401
6
ack
57
6
k6
c
a

51

58

256 bytes
a la aplicacin

657
6
ack 657
6
k
c
a
7
65
6
ack
7
65
6
ack
657
6
ack 57
66
k
c
a

60

(guardar 256 bytes)

61

(guardar 256 bytes)

62

(guardar 256 bytes)

64

(guardar 256 bytes)

65

(guardar 256 bytes)

66

(guardar 256 bytes)

53
56

Control de congestin: Ejemplo

57

55

54

ack

60

7
665

657
6
ack
657
6
ack 657
6
ack

59 8705:8961
(256)
ack 1
657
6
k
ac
657
6
k
ac
63

67
69
71

6657:6
913 (2
56) ac
k 1 (re
tx.)

8961:9
217 (2
56) ac
k1
9217:9
473 (2
56) ac
k1
9473:9
729 (2
56) ac
k1

RC - Bloque III - Tema 8

61

8
ack

657
6
ack
657
6
ack

96

8
588
n
i
1, w

62
64

(guardar 256 bytes)

65

(guardar 256 bytes)

66
68

(guardar 256 bytes)

(guardar 256 bytes)

70

(guardar 256 bytes)

72

2304 bytes
a la aplicacin

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

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

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 +
+
8
cwnd
RC - Bloque III - Tema 8

10

Algoritmo para evitar la congestin

Algoritmo para evitar la
congestin

44

Ventana de congestin (KiloBytes)

40
36

32

ssthresh (32 KB)

28
24

20

Algoritmo de inicio
lento

16
12
8
4
0
0

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

Segm. #

Accin
Enviar

Recibir

Variable
Observaciones

cwnd

ssthresh

Inicializacin

256

65535

Timeout

256

512

SYN
SYN
SYN, ACK
ACK
RC - Bloque III - Tema 8

14

Control de congestin: Ejemplo

Accin
Segm. #
1

Enviar

Recibir

Observaciones

cwnd

ssthresh

ACK 257

Alg. inicio lento

512

512

ACK 513

Alg. inicio lento

768

512

ACK 769

Alg. evitar cong.

885

512

ACK 1025

Alg. evitar cong.

991

512

1:257

2
3

257:513

513:769

5
6

769:1025

1025:1281

8
9

Variable

1281:1537

10
RC - Bloque III - Tema 8

15

Control de congestin: Ejemplo

Accin
Segm. #

Enviar

Variable

Recibir

Observaciones

cwnd

ssthresh

ACK 6657

ACK nuevo

2426

512

60

ACK 6657

ACK repetido 1

2426

512

61

ACK 6657

ACK repetido 2

2426

512

62

ACK 6657

ACK repetido 3

1792

1024

58
59

63

8705:8961

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
Segm. #

Enviar

68
69

Recibir

Observaciones

cwnd

ssthresh

ACK 6657

ACK repetido 7

2816

1024

ACK 6657

ACK repetido 8

3072

1024

ACK 8961

ACK nuevo

1280

1024

9217:9473

70
71

Variable

9473:9729

72

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
1

3
4
5
6
Segmento de
actualizacin
de ventana

RC - Bloque III - Tema 8

Servidor:8888

SYN 13281:1328
1(0)
win 4096, <MSS
1024>
2
5827(0)
4
:
7
2
8
5
4
SYN
102 4>
S
S
M
<
,
6
9
40
ACK 1, win
ACK 1, win 4096
PSH 1:1025 (1024) A
CK 1, win 4096
PSH 1025:2049 (102
4) ACK 1, win 4096
PSH 2049:3073 (102
4) ACK 1, win 4096
PSH 3073:4097 (102
4) ACK 1, win 4096

ACK 4097, win 0

6
ACK 4097, win 409

8
9

19

Temporizador de persistencia
Emisor rpido, receptor lento (continuacin)
Cliente:1111

Segmento de
actualizacin
de ventana

Servidor:8888

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

4096
11 PSH 5121:6145 (1024) ACK
1, win 4096
P
S
H
6
1
45:7169 (1024) ACK
12

1, win 4096
F
IN
,
P
S
H
7
169:8193 (1024) AC
13
K 1, win 4096
ACK 8194, win 0
6
ACK 8194, win 409
94, win 4096
FIN 1:1 (0) ACK 81
17

RC - Bloque III - Tema 8

14
15
16

ACK 2, win 4096

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

PSH 1:1025 (1024) A

CK 1, win 4096
PSH 1025:2049 (102
4) ACK 1, win 4096
PSH 2049:3073 (102
4) ACK 1, win 4096
4 PSH 3073:4097 (1024) ACK
1, win 4096
1
2
3

ACK 4097, win 0

6

window probe
8

10

RC - Bloque III - Tema 8

4097:4098 (1) ACK 1

, win 4096
ACK 4097, win 0

4097:4098 (1) ACK 1

, win 4096
ACK 4097, win 0

4097:4098 (1) ACK 1

, win 4096
ACK 4097, win 0

11

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

Buffer receptor lleno

1 byte libre

Cab.

Enviar segmento de
actualizacin de ventana

Cab.

Recepcin del nuevo byte

Por ejemplo, la aplicacin

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

Buffer receptor lleno

RC - Bloque III - Tema 8

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
1

segmento sonda
5

PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK

Servidor:echo
2

ACK 14

13:13 (1) ACK 14

ACK 14

2 horas

2 horas

7
RC - Bloque III - Tema 8

13:13 (1) ACK 14

ACK 14

29

Temporizador de keepalive
Caso 2: cliente cado
Cliente:1111
1

segmentos sonda

RC - Bloque III - Tema 8

PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK

Servidor:echo
2

ACK 14

13:13 (1) ACK 14

13:13 (1) ACK 14
13:13 (1) ACK 14
13:13 (1) ACK 14
13:13 (1) ACK 14

2 horas

5
6
7

Cada 75
segundos

30

Temporizador de keepalive
Caso 3: cliente cado y reiniciado
Cliente:1111
1

3
Cliente se apaga y
vuelve a encender

segmento sonda

RC - Bloque III - Tema 8

PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK

Servidor:echo
2

ACK 14

13:13 (1) ACK 14

2 horas

RST 14:14 (0) ACK 1

4

31

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

segmentos sonda

RC - Bloque III - Tema 8

PSH 1:14 (13) ACK 1

14
PSH 1:14 (13) ACK

Servidor:echo
2

ACK 14

13:13 (1) ACK 14

13:13 (1) ACK 14
13:13 (1) ACK 14
13:13 (1) ACK 14
13:13 (1) ACK 14

2 horas

5
6
7

Cada 75
segundos

32