Detalles del funcionamiento de las conexiones TCP

Como TCP usa un servicio de baja calidad y no fiable para realizar las transmisiones (el servicio de IP), se requiere emplear mecanismos complejos para la apertura y para el cierre de las conexiones con el objetivo de evitar que algo pueda fallar [16]. De all´ı que las conexiones de TCP se compongan en 3 fases: Primero, una fase para la apertura de la conexi´on; luego, viene propiamente la fase de transferencia de los datos; y finalmente, la fase de cierre de la conexi´on (V´ease la Figura 2.13). Para explicar el funcionamiento

2.11 Protocolo de Control de Transmisi´on (Transmission Control Protocol o TCP) 34

de una conexi´on TCP, vamos a utilizar el esquema Cliente-Servidor. Este modelo consta de dos nodos participantes, un nodo activo (el cliente) que env´ıa solicitudes a nodo un pasivo (el servidor), el cual est´a a la espera de atender las solicitudes que le llegan.

Figura 2.13: Fases de una conexi´on TCP

2.11.3.1 Apertura de la conexi´on

En esta fase inicial se trabaja con el protocolo “three-way handshake”, donde en tres pasos (mediante 3 segmentos TCP) se logra establecer la conexi´on entre los dos nodos [15]. A continuaci´on se explican estos pasos.

2.11 Protocolo de Control de Transmisi´on (Transmission Control Protocol o TCP) 35

1. Petici´on de la conexi´on: El cliente env´ıa un segmento de petici´on de conexi´on (segmento SYN) al servidor.

2. Confirmaci´on de la conexi´on: El servidor env´ıa una respuesta (con un segmento SYN) con el n´umero de secuencia inicial que utilizar´a, y el reconocimiento ACK con el n´umero de secuencia inicial que envi´o el cliente m´as 1 [15].

3. Reconocimiento de la conexi´on: El cliente reconoce el SYN y responde con un segmento ACK.

Los dos paquetes SYN emitidos (en los pasos 1 y 2), son para que ambos extremos se pongan de acuerdo en cuanto a los n´umeros de secuencia iniciales para la transmisi´on de los datos, uno para cada direcci´on en el canal. Estos n´umeros se asignan aleatoriamente, no reutiliz´andose durante un tiempo adecuado, con el fin de evitar que se confundan segmentos de otras conexiones [16]. Luego de estos 3 pasos se puede decir que la conexi´on ya se ha establecido (V´ease la Figura 2.13).

2.11.3.2 Transferencia de datos

Despu´es de que la conexi´on es establecida, ya se pueden comenzar a realizar la transferencia de los flujos de datos. Para garantizar la fiabilidad se utilizan mecanismos de retransmisi´on de paquetes (en caso de da˜nados o perdidos), y de verificaci´on de segmentos duplicados. Cuando se recibe un segmento con errores, TCP lo descarta y env´ıa un ACK con el mismo n´umero que hab´ıan enviado anteriormente (ACK duplicado) para indicarle al emisor que le vuelva a transmitir ese segmento. Si los segmentos llegan desordenados TCP los ordena para entreg´arselos a la aplicaci´on. En caso de que haya paquetes duplicados, los elimina [15].

Para facilitar todo esto, cada vez que TCP env´ıa un segmento, le coloca el n´umero del primer byte (respecto al flujo completo) del segmento en el encabezado, el cual le permite al receptor identificar el segmento recibido. Luego de enviar cierta cantidad de paquetes, el emisor espera un acuse de recibo (un ACK), el cual le indica que todos los paquetes reconocidos por el n´umero de ACK ya fueron recibidos correctamente

2.11 Protocolo de Control de Transmisi´on (Transmission Control Protocol o TCP) 36

(principio de reconocimiento acumulativo). No se env´ıan reconocimientos negativos, de forma que si el ACK no llega durante cierto tiempo prefijado, puede indicar al emisor que se perdi´o el segmento o el ACK, o que el segmento se da˜n´o durante la transmisi´on, en cuyo caso el emisor retransmite los segmentos [35] [16].

En la Figura 2.13, se muestra la transferencia de datos, en el caso que el cliente est´e descargando un archivo del servidor, por ello los paquetes de data van en direcci´on Servidor-Cliente, mientras que los ACKs van en la direcci´on opuesta.

2.11.3.3 Cierre de la conexi´on

Al terminar la transferencia de la informaci´on, TCP utiliza otro protocolo para el cierre de la conexi´on. Este protocolo es muy cuidadoso, ya que es necesario asegurarse que la conexi´on se cierre completamente (en ambos extremos) para evitar que se desperdicien recursos de la red, como memoria por TCBs ocupados innecesariamente. Aun as´ı, existe el riesgo de que las conexiones queden medio abiertas, por lo que TCP utiliza temporizadores, que le indican a cada nodo que si no recibe un segmento durante un tiempo establecido, la conexi´on se cierra en ese extremo [16].

El cierre de la conexi´on comienza cuando el cliente env´ıa un segmento con el campo FIN activado, y con un n´umero de secuencia (x). El servidor env´ıa una confirmaci´on con el n´umero de secuencia recibido del cliente m´as uno (x+1). El servidor env´ıa al cliente un segmento TCP con el campo FIN activado y con otro n´umero de secuencia. El cliente env´ıa un ACK como confirmaci´on, con el n´umero de secuencia recibido m´as 1 [15].

2.11.4

Control de Congesti´on en TCP

El objetivo de TCP es transmitir lo m´as r´apido posible sin congestionar la red. Por ello, con el fin de controlar la congesti´on, TCP utiliza alternamente dos algoritmos que determinan la tasa de emisi´on de los paquetes: el “Slow Start” y el “Congestion

2.11 Protocolo de Control de Transmisi´on (Transmission Control Protocol o TCP) 37

Avoidance” [18].

En Slow Start: Se incrementa la tasa de emisi´on r´apidamente al inicio de la conexi´on o despu´es de un “timeout”. Ese incremento se realiza de forma exponencial.

En Congestion Avoidance: Se incrementa la emisi´on de los paquetes de datos m´as lentamente en comparaci´on con el algoritmo anterior. De una forma pseudo-lineal.

Figura 2.14: Slow Start Vs Congestion Avoidance

En la Figura 2.14 se muestra como se alterna el uso de estos algoritmos durante una transmisi´on de TCP. All´ı se puede ver la variaci´on de la ventana de congesti´on a medida que avanza el tiempo en unidades de RTTs (Round Trip Time). La ventana de congesti´on es una variable que indica la cantidad de paquetes de data que puede enviar sin recibir el ACK correspondiente teniendo en cuenta la congesti´on de la red percibida. Un RTT es el tiempo transcurrido desde que se env´ıa un segmento hasta que llega su reconocimiento.

La diferencia en el crecimiento de la tasa emisi´on de paquetes durante el uso de estos algoritmos, se puede ver claramente en la Figura 2.15, donde la zona sombreada

2.11 Protocolo de Control de Transmisi´on (Transmission Control Protocol o TCP) 38

en verde es el per´ıodo donde est´a activado el algoritmo “Slow Start” (crecimiento de tasa de env´ıo exponencial) y la zona sombreada en amarillo es el per´ıodo donde est´a activado el algoritmo “Congestion Avoidance” (crecimiento de tasa se env´ıo lineal).

Figura 2.15: Emisi´on de paquetes en el tiempo con Slow Start y Congestion Avoidance

2.11.5

Control de flujo

TCP es un protocolo d´uplex, donde los extremos trabajan como receptor y emisor de forma simult´anea. Cada uno de ellos tiene 2 b´uferes con espacio limitado para los paquetes principales (uno para los segmentos que llegan, y otro para los que esperan ser enviados) y otro b´ufer para colocar copias de los segmentos que se han enviado pero no se ha recibido su respectivo ACK. Es por ello, que TCP provee este mecanismo, en el que el nodo receptor le indica al nodo emisor la cantidad de datos que puede enviarle dependiendo de su disponibilidad en las colas. La idea es que cada extremo pueda controlar la cantidad de datos que le env´ıa el extremo contrario. En cada paquete enviado, el nodo informa el tama˜no de su ventana (en bytes) en un campo del encabezado segmento [16] [35] [15].

2.11 Protocolo de Control de Transmisi´on (Transmission Control Protocol o TCP) 39

El tama˜no real de la ventana, la tasa de env´ıo, se define como el menor valor de ventana entre el percibido por la congesti´on de la red (conseguida por el control de congesti´on) y el anunciado por el receptor (obtenida por el control de flujo).

Cap´ıtulo 3

Dise˜no

El modelo que se desarroll´o tuvo como base la pol´ıtica dDDA, explicada en la Secci´on 2.9.3.2. El nombre asignado a esta nueva pol´ıtica fue rDDA (random delayed BwReq handling - DDA). El dise˜no de esta estructura fue concebido con dos premisas. La primera es que, mediante una estructura de lista circular de colas se requiere dar adaptabilidad al sistema para repartir adecuadamente el procesamiento de los BwReqs a lo largo de las tramas tanto para inducir una demora beneficiosa como para hacerlo escalable. La segunda, es que se introduce la posibilidad del manejo de la prioridad en la gesti´on de BwReqs mientras se respeta la equidad entre los flujos. A continuaci´on se detalla mejor esta nueva pol´ıtica.

3.1

Modelo de Gesti´on de Ancho de Banda con

Retardo Aleatorio

Este modelo consiste en hacer que la demora del procesamiento de BwReqs definido en la pol´ıtica dDDA, sea variable y aleatoria. De esta manera, los BwReqs deber´an esperar ser procesados dentro de un n´umero de tramas dado por un valor aleatorio (λi), que es generado al momento de llegar este paquete a la BS. El procesamiento

consta de obtener el valor de la cantidad de ancho de banda (AdB) solicitado en el BwReq, para actualizar la tabla de percepci´on en la entrada correspondiente a la SS