Sistemas Telematicos

Practica 5: Control de Congestion en TCP

Departamento de Sistemas Telematicos y Computacion (GSyC)

Marzo de 2011

Resumen

En esta practica se aprende el funcionamiento de los mecanismos de control de flujo y control de congestion deTCP.

Nota: Al cargar cada una de las capturas en Wireshark, es necesario ordenar los paquetes por su marca detiempo, pulsando en la pestana Time, de esta forma podremos analizar lo que ha ocurrido ordenadamente siguiendoel eje temporal.

1. Slow Start en el inicio de la conexion

En este experimento se observa el comportamiento del mecanismo de TCP arranque lento (Slow Start).

Carga en Wireshark la captura slow-start.cap. Selecciona el primer segmento que enva el cliente al servi-dor, y a continuacion muestra en Wireshark el diagrama de la conexion mediante el menu: StatisticsTCP StreamGraphTime-Sequence Graph (tcptrace) medskip

Observa la grafica de la captura, y cada uno de los segmentos. Explica como afecta Slow Start el envo de nuevossegmentos en el inicio de la conexion.

2. Control de Congestion tras Timeout

En este experimento se observa el comportamiento del mecanismo de control de congestion de TCP tras un timeout.

Carga en Wireshark la captura ss-timeout.cap. Selecciona el primer segmento que enva el cliente al servi-dor, y a continuacion muestra en Wireshark el diagrama de la conexion mediante el menu: StatisticsTCP StreamGraphTime-Sequence Graph (tcptrace)

1. Observa la captura y explica como afecta Slow Start al envo de nuevos segmentos al inicio de la conexion.

2. Estudia el comportamiento tras el timeout. Analiza tanto la grafica como cada uno de los segmentos. Explicaque diferencia aprecias respecto al comportamiento al inicio de la conexion.

3. Fast Retransmit / Fast Recovery

En este experimento se observa el comportamiento de TCP tras la recepcion de 3 ACKs duplicados. Carga enwireshark la captura fr-fr.cap y ordena los paquetes de la captura segun la columna Time.

Para identificar si una retransmision es debida a Fast Retransmit comprueba las siguientes condiciones:

a) Anteriormente a la retransmision hay 4 ACKs (1 + 3 duplicados) o mas sobre el numero de secuencia que seesta retransmitiendo

b) Se envan mas datos nuevos despues de realizar la retransmision y antes de recibir su ACK.

Wireshark interpreta los segmentos TCP de las capturas e identifica si una retransmision es debida a Timeout oFast Retransmit. Sin embargo, a veces la captura no esta bien ordenada segun el eje temporal y las interpretacionesque hace Wireshark no son correctas. Por este motivo para saber por que se produce una retransmision es necesarioanalizar las condiciones descritas anteriormente.

Observando la captura fr-fr.cap responde a las siguientes preguntas:

1

1. Cuantas retransmisiones debidas a timeout se observan en la traza? Identifica en que instante se producen.

2. Cuantas retransmisiones debidas a Fast Retransmit se observan en la traza? Identifica en que instante se pro-ducen.

3. Observa la primera ocasion en la que se produce Fast Retransmit. Comprueba cuantos paquetes se envan despuesde haber recibido el primer ACK nuevo. Relaciona este valor con el valor que tena la ventana de congestioncuando ocurrio Fast Retransmit.

4. Despues de enviar el paquete retransmitido en la primera ocasion en que se produce Fast Retransmit, se envannuevos segmentos antes de recibir ACKs. Cuantos? Por que?

4. Control de Congestion y sondas de ventana

En este experimento se observa como se comporta TCP atendiendo al valor de ventana anunciada.

Carga en wireshark la captura sondas.cap.

Observa la captura y comprueba el comportamiento de la ventana anunciada a partir del segmento 43.

1. Localiza en la traza anuncios de ventana 0 enviados por el servidor al cliente. Observa las sondas de ventana queenva el cliente en ese periodo.

2. Explica el comportamiento de TCP entre los segmentos 43 y 87.

3. Indica en que modo de control de congestion se encuentra la conexion TCP en los siguientes puntos:

Antes del segmento 43.

Entre el segmento 43 y 87

Despues del segmento 87

5. Estados de una conexion TCP

Descomprime el escenario estadosTCP-lab.tgz y arranca las maquinas.

5.1. Establecimiento de la conexion

Una aplicacion que funciona como servidor TCP, se programa para que pueda aceptar conexiones. Hasta que hayaalguna conexion de algun cliente la aplicacion servidor TCP se encontrara en estado LISTEN y cambiara de estado enel momento en que el cliente se conecte:

1. Ejecuta tcpdump en r1 en su interfaz eth0, no es necesario que guardes la captura en un fichero, especifica quesolo capture el trafico TCP de la siguiente forma:

tcpdump -i eth0 tcp

Ensancha la ventana de r1 todo lo que puedas para ver cada segmento capturado en una lnea. Para interpretarla salida de tcpdump utiliza la informacion de la figura 1, al final del enunciado.

2. Arranca una aplicacion servidor TCP que espere conexiones en el puerto 7777 en pc2 utilizando las herramientasnetem, de la siguiente forma:

nc -l -p 7777 &

3. Para ver en que estado se encuentra la conexion TCP en el lado del servidor utiliza el comando netstat de lasiguiente forma en pc2:

watch -n 0.5 netstat -nat

El comando watch permite ejecutar repetidamente el comando que se escriba a continuacion, en este caso netstat.La opcion -n de watch permite especificar cada cuanto tiempo se repite la ejecucion, en este caso, cada 0.5segundos.

2

4. Coloca en la pantalla las ventanas de los terminales de pc1 y pc2 para que puedas visualizarlas simultaneamente.

5. Indica en que estado se encuentra el servidor antes de arrancar el cliente.

6. Lanza en pc1 una aplicacion cliente TCP que se conecte al servidor de pc2:

nc 12.0.0.2 7777

7. Indica que estados atraviesa el servidor hasta que el cliente se encuentra conectado 1.

8. Observa en el trafico capturado en r1 como se han intercambiado los 3 segmentos del establecimiento de laconexion.

9. Apunta el valor de la ventana anunciada por el servidor.

10. Interrumpe la ejecucion del comando watch en pc2 con Ctrl+C y trae a primer plano de ejecucion el comandonc en pc2, para ello ejecuta fg.

5.2. Intercambio de datos

Desde pc1 podemos escribir tantos datos como queramos por la entrada estandar para enviar a pc2. Vamos acomprobar que los datos que enva pc1 a pc2 se quedan almacenados en el buffer de entrada de pc2 hasta que laaplicacion los lea:

1. Si has interrumpido la ejecucion de tcpdump en r1 en su interfaz eth0, vuelve a lanzarlo.

2. Deten la ejecucion de nc en el lado servidor con Ctrl+z, esto provocara que la ejecucion del servidor quede parada(pero no finalizada) y por tanto no realizara ninguna operacion mas, en particular, no leera la informacion quereciba de TCP.

3. Ejecuta en el lado servidor de nuevo el comando netstat de la siguiente forma:

watch -n 0.5 netstat -nat

4. En el proceso nc del cliente en pc1 introduce una cadena de caracteres larga por la entrada estandar (por ejemplopulsa un rato la tecla de alguna letra hasta que aparezcan 2 lneas de esa letra por pantalla y despues pulsala tecla enter). Esta cadena de caracteres se recibira en la implementacion de TCP en el lado servidor, pero laaplicacion no leera estos datos porque se encuentra detenida.

5. Visualiza que los datos se han quedado almacenados en el buffer de entrada (Recv-Q) del lado servidor. Explicael valor de Recv-Q teniendo en cuenta que has pulsado mas caracteres para enviar en el cliente.

6. Observa que es lo que esta ocurriendo con la captura de trafico de r1.

7. Interrumpe con Ctrl+c la ejecucion de netstat en el lado servidor. Trae a primer plano la ejecucion de nc enpc2 y la ejecucion de la aplicacion servidor continuara. Observaras como la aplicacion servidor ha ledo los datosdel buffer de entrada y los ha mostrado en la pantalla.

5.3. Finalizacion de la conexion

Para ver los estados por los que atraviesa el servidor cuando el cliente cierra la conexion, ejecuta las siguientesinstrucciones:

1. Si has interrumpido la ejecucion de tcpdump en r1 en su interfaz eth0, vuelve a lanzarlo.

2. Interrumpe la ejecucion del cliente en pc1 con Ctrl+c. La aplicacion cliente mandara un segmento con el flagFIN activado.

3. El servidor nc esta programado para terminar si el cliente le manda un segmento con el flag FIN activado, poreste motivo, la aplicacion nc en pc2 finaliza la conexion mandando su segmento FIN+ACK. Cuando el servidorrecibe el ultimo ACK de pc1 da por terminada la comunicacion y finaliza su ejecucion.

1Hemos anadido retardos a la interfaz de pc1 para que puedas visualizar esta transicion entre estados ya que el cambio de estado seproduce muy rapidamente y no lo podras apreciar.

3

4. En pc1 aunque la aplicacion ha terminado, los recursos de la conexion TCP tardan un tiempo en liberarse y siejecutas en pc1:

watch -n 0.5 netstat -nat

observaras que la conexion TCP tarda un tiempo en liberarse y fjate en el estado en el que se encuentra. Porque se mantiene tanto tiempo en este estado?

5. En pc2 la aplicacion ha terminado y se han liberado inmediatamente los recursos de la conexion TCP. Si ejecutasen pc2:

watch -n 0.5 netstat -nat

observaras que hay no hay conexiones. Piensa por que sucede esto.

4

Fla

g

SY

N

x:y

(z)

x:

N

me

ro d

e s

ecu

en

cia

in

icia

l re

al

y:

x+

z

z:

N

me

ro d

e b

yte

s d

e d

ato

s e

nvia

do

s

Fla

g

FIN

Ta

ma

o

de

ve

nta

na

an

un

cia

da

x:y

(z)

x:

N

me

ro d

e s

ecu

en

cia

rela

tivo

de

l p

rim

er

byte

de

dato

s d

el se

gm

en

to

y:

x+

z

z:

N

me

ro d

e b

yte

s d

e d

ato

s e

nvia

do

s N

m

ero

de

ase

ntim

ien

to,

sig

uie

nte

n

de

se

cu

en

cia

qu

e e

sp

ero

re

cib

ir

IP1

.pu

ert

o1

> I

P2

.pu

ert

o2

IP

1.p

ue

rto

1:

orig

en

IP2

.pu

ert

o2

: d

estin

o

Es

tab

lec

imie

nto

de

la

co

ne

xi

n

Fin

ali

za

ci

n d

e l

a c

on

ex

in

Figura 1: Conexion TCP utilizando tcpdump

5