Vous êtes sur la page 1sur 6

Sistemas Telem aticos I Control de ujo y control de congesti on en TCP

Universidad Rey Juan Carlos Curso 2007/2008


Resumen Estos ejercicios est an orientados a entender el funcionamiento del control de ujo y control de congesti on en TCP. Nota: Al cargar cada una de las capturas, es necesario ordenar los paquetes por su marca de tiempo, pulsando en la pesta na Time, de esta forma podremos analizar lo que ha ocurrido ordenadamente siguiendo el eje temporal.

1.

Slow Start en el inicio de la conexi on

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 env a el cliente al servidor, y a continuaci on muestra en Wireshark el diagrama Time-Sequence Graph (tcptrace) mediante el men u StatisticsTCP Stream GraphTime-Sequence Graph (tcptrace). Observa la gr aca de la captura, y cada uno de los segmentos. Explica c omo afecta Slow Start el env o de nuevos segmentos en el inicio de la conexi on. Soluci on: La gr aca de tcptrace proporciona una visi on general de lo que est a pasando con la conexi on, pero para analizar el detalle, es necesario recurrir al contenido de los paquetes capturados.

En Slow Start al comienzo de una conexi on TCP, el comportamiento de la conexi on sigue las normas descritas en la transparencia 8 del chero 2-congestion-tcp.pdf de teor a. Si nos jamos en la gr aca mostrada por Wireshark, nunca se llegan a enviar tantos datos como el valor dado por la ventana de control de ujo ya que en este caso est a limitando la ventana de control de congesti on. El comportamiento a observar es la variaci on de la ventana de control de congesti on: permite enviar un nuevo segmento (de MSS) por cada ACK recibido. Al observar la captura, podemos ver que se env an inicialmente 3 segmentos con datos (instante 1 aprox 1.0) , recibidos sus ACKs podr amos enviar hasta 6 segmentos y se env an 6 segmentos con datos (instante aprox 2.0), al recibir sus ACKs podr amos enviar hasta 12 segmentos y se env an 7 segmentos (instante 3.1 aprox), al recibir sus ACKs se podr an enviar hasta 19 segmentos y se env an 11 y as sucesivamente. Se observa la rapidez con la que asciende la ventana de control de congesti on en Slow Start.

2.

Timeout

En este experimento se observa el comportamiento del mecanismo de TCP tras un timeout. Carga en Wireshark la captura ss-timeout.cap. Selecciona el primer segmento que env a el cliente al servidor, y a continuaci on muestra en Wireshark el diagrama Time-Sequence Graph (tcptrace) mediante el men u StatisticsTCP Stream GraphTime-Sequence Graph (tcptrace). 1. Observa la captura y explica c omo afecta Slow Start al env o de nuevos segmentos al inicio de la conexi on. Soluci on: En el inicio de la conexi on, TCP se encuentra en Slow Start, el comportamiento a observar es la variaci on de la ventana de control de congesti on: permite enviar un nuevo segmento (de MSS) por cada ACK recibido. Al observar la captura, se env an 2 segmentos con datos (instante aprox 1.5), al recibirse los 2 ACKs se permite enviar hasta
Todos los instantes que se referencian en este documento se reeren a las marcas de tiempo relativas que aparecen en las capturas.
1

4 segmentos y se env an 4 segmentos (instante aprox 2.5), al recibirse los 4 ACKs se permite enviar hasta 8 segmentos y se env an 6 segmentos (instante aprox 3.5). 2. Estudia el comportamiento tras el timeout. Analiza tanto la gr aca como cada uno de los segmentos. Explica qu e diferencia aprecias respecto al comportamiento al inicio de la conexi on. Soluci on: Hay una retransmisi on por timeout del segmento con n umero de secuencia 8689 (instante aprox 7.9). En ese momento iniciamos de nuevo Slow-Start con valor de threshold igual a 4, ve ase la transparencia 10 del chero 2-congestion-tcp.pdf de teor a. Al recibir el ACK de la retransmisi on del segmento 8689, la ventana de control de congesti on pasa a valer 2 y se retransmiten 2 segmentos. Al recibir los ACKs de estas dos retransmisiones se env an 4 segmentos y pasamos del modo Slow Start a Additive Increase ya que hemos llegado al threshold, v ease comportamiento de este modo en la transparencia 10 del chero 2-congestion-tcp.pdf de teor a, donde los incrementos de la ventana de control de congesti on son mucho m as lentos que en Slow Start.

3.

Fast Retransmit / Fast Recovery

En este experimento se observa el comportamiento de TCP tras la recepci on de 3 ACKs duplicados. Carga en wireshark la traza fr-fr.cap2 . 1. Cu antas retransmisiones debidas a timeout se observan en la traza? Identica en qu e instante se producen. Soluci on: Al ordenar la captura de segmentos por su marca de tiempo se puede ver que todas las retransmisiones que aparecen son debidas a ACK duplicados y no a vencimiento de timeout. Por tanto, la respuesta es ninguna retransmisi on es debida a timeout.
2

./fr-fr.cap

Aunque en Wireshark se interpreta que el paquete 114 se retransmite por timeout y no por fast retransmit, si se ordena la captura por tiempo se comprueba que anteriormente se han recibido 3 ACKs duplicados por ese mismo n umero de secuencia 68969. Por este motivo, se considera que todas las retransmisiones son debidas a ACKs duplicados o lo que es lo mismo, a fast retransmit. 2. Cu antas retransmisiones debidas a Fast Retransmit se observan en la traza? Identica en qu e instante se producen. Soluci on: Hay 4 retransmisiones por fast retransmit, los segmentos con n umero: 46, 114, 173 y 215. 3. Observa la primera ocasi on en la que se produce Fast Retransmit. Comprueba cu antos paquetes se env an despu es de haber recibido el primer ACK nuevo. Relaciona este valor con el valor que ten a la ventana de congesti on cuando ocurri o Fast Retransmit. Soluci on: La ventana de congesti on vale alrededor de 16 segmentos antes de fast retransmit. Por tanto, cuando se produce fast retransmit, se calcula el threshold que vale aproximadamente 8 segmentos. Despu es de fast retransmit, en el segmento n umero 62 se recibe el ACK acumulativo de la retransmisi on y la ventana de control de congesti on pasa a valer el threshold, pudi endose enviar hasta 8 segmentos. En la gura se observa que se env an 6. 4. Despu es de enviar el paquete retransmitido en la primera ocasi on en que se produce Fast Retransmit, se env an nuevos segmentos antes de recibir ACKs. Cu antos? Por qu e? Soluci on: 4. Porque todav a lo permite la ventana de congesti on. 5. Observa la segunda ocasi on en la que se produce Fast Retransmit. Comprueba cu antos paquetes se env an despu es de haber recibido el primer ACK nuevo. Relaciona este valor con el valor que ten a la ventana de congesti on cuando ocurri o Fast Retransmit. Soluci on: La ventana de congesti on vale alrededor de 11 segmentos. Despu es de recibir el ACK (segmento 121) del 4

segmento que se hab a enviado como retransmisi on r apida, la ventana de control de congesti on pasa a valer aproximadamente 5 segmentos. En la gr aca se observa que se env an 5 segmentos. 6. Despu es de enviar el paquete retransmitido en la segunda ocasi on en que se produce Fast Retransmit, se env an nuevos segmentos antes de recibir ACKs. Cu antos? Por qu e? Soluci on: 2. Porque lo permite la ventana de congesti on.

4.

Ventana anunciada

En este experimento se observa c omo se comporta TCP atendiendo al valor de ventana anunciada. Carga en wireshark la captura sondas.cap. Selecciona el primer segmento que env a el cliente al servidor, y a continuaci on muestra en Wireshark el diagrama Time-Sequence Graph (tcptrace) mediante el men u StatisticsTCP Stream GraphTime-Sequence Graph (tcptrace). Observa la captura y comprueba el comportamiento de la ventana anunciada a partir del segmento 43. Localiza en la traza anuncios de ventana 0 enviados por el servidor al cliente. Observa las sondas de ventana que env a el cliente en ese periodo. Explica el comportamiento de TCP entre los segmentos 43 y 87. Soluci on: En la captura se observa que a partir de segmento n umero 43 la ventana anunciada va disminuyendo. En el segmento 41 la ventana anunciada es 44888 a partir del n umero de secuencia 22177 (como m aximo se permite enviar hasta el byte n umero 67064). En el segmento 43 la ventana anunciada es 36200 a partir del n umero de secuencia 30865 (como m aximo se permite enviar hasta el byte 67064). En el segmento n umero 51 la ventana anunciada es 34752 a partir del n umero de secuencia 32313 (como m aximo se permite enviar hasta el byte 67064). Y as sucesivamente hasta el segmento 79 donde se anuncia una ventana 4344 a partir del n umero de secuencia 67065 (como m aximo se permite enviar hasta el byte 71408).

En el segmento n umero 80 se anuncia una ventana 0 a partir del n umero de secuencia 71409. Debido a que el u ltimo segmento enviado es el n umero 78 donde se enviaron los n umeros de secuencia desde 69961 hasta 71408, ya no se pueden enviar m as datos hasta que no se anuncie un valor de ventana mayor. Lo que ha ocurrido es que la aplicaci on receptora no est a leyendo los datos y por tanto, la capa TCP en el lado receptor ha llenado por completo su buer de recepci on y no tiene capacidad para almacenar m as datos. En el segmento 81 el lado emisor env a una sonda de ventana para que el receptor pueda contestar con un valor de ventana que le permita enviar m as datos. La sonda de ventana no env a datos nuevos (no puede), repite el env o del u ltimo byte, el byte n umero 71408. La ventana se abre en el segmento n umero 84, donde se anuncia un valor de ventana 2896 a partir del n umero de secuencia 71409. Este evento coincidir a con que la aplicaci on ha comenzado a leer los datos que TCP ten a almacenados en su buer de recepci on. El emisor ahora puede enviar dos nuevos segmentos (el l mite para el env o de datos en este momento no lo establece la ventana de control de congesti on sino la ventana de control de ujo). A partir del segmento 87 el valor de la ventana anunciado va aumentando, permitiendo que el emisor pueda enviar m as datos.