TCP/IP En Las Redes Móviles

TCP/IP, proporciona unos mecanismo para soportar los enrutamientos y ubicaciones de hosts por medio de direcciones IP estáticas; es decir para que un equipo sea encontrado en la red (Internet) debe tener siempre su dirección IP. Ahora, cuando se requiere que equipos se conecten a otras redes es necesario reconfigurar su dirección a una nueva del estilo de la nueva red donde se encuentra conectado.

TCP/IP en las redes móviles

1. El problema de movilidad con TCP.

Los problemas existentes se basan en la incapacidad de TCP de discriminar cuándo la performance de la conexión ha disminuido debido a pérdidas en el enlace, común en las tecnologías wireless, y cuándo es debida a congestión en la red. El problema radica en que el transmisor no puede determinar con cierto grado de certeza qué ha motivado la pérdida de un segmento.

Cuatro aspectos inherentes a redes Wireless pueden afectar decisivamente la performance de TCP.

Por un lado, el bit de error rate (BER) del medio físico, que como ya mencionamos, puede ser del orden de 1×10-6 o peor. En segundo lugar debemos considerar que el ancho de banda disponible es en general menor al disponible en medio cableados. Una tercer componente es la posible movilidad de los componentes de la red lo que puede implicar cambios importantes en los tiempos de entrega de los segmentos. Finalmente, es común que el protocolo de capa de Enlace y en particular de la sub-capa MAC así como el protocolo de enrutamiento utilizado implique necesariamente tener un overhead asociado a la movilidad y al aumento en la probabilidad de pérdida de tramas o paquetes.

A los efectos de fijar ideas podemos considerar como ejemplo de protocolo de sub-capa MAC a la familia de estándares de IEEE para Wireless Local Area Network (WLAN) [26, 27, 28, 29, 30]. En ellos se especifica que para el envío de cada trama de datos en el modo de operación Distributed

Coordination Function (DCF) se emplee un método de control de acceso al medio denominado carrier sense multiple access with collision avoidance (CSMA/CA), protocolo que busca reducir la probabilidad de colisiones entre múltiples estaciones a través del evitado de las mismas. A los efectos de detectar portadora, además del mecanismo clásico de “escucha del medio” (detección física de portadora) se realiza una detección virtual de portadora utilizando four-way handshake, donde con dos tramas de control (RTS: Request To Send y CTS: Clear To Send) se reserva el medio, luego se envía latrama conteniendo los datos y posteriormente se espera una trama de control ACK que confirma su recepción.

2. Control de congestión con TCP.

El método utilizado por TCP para control de la congestión es el basado en la regulación del tráfico inyectado a la red. Esto supone que implementa funciones que le permiten estudiar cuándo es posible enviar más tráfico por el enlace, y cuándo se ha superado la capacidad del mismo y se debe disminuir la carga.

TCP emplea 4 algoritmos relacionados entre sí a los efectos de efectuar el control de congestión. Ellos son conocidos con slow start, congestion avoidance, fast retransmit y fast recovery.
Los algoritmos slow start y congestion avoidance, deben ser utilizados por la fuente TCP a los efectos de controlar la cantidad de tráfico inyectado en la red. Para esto se cuenta con tres variables de estado del protocolo. Estas son cwnd (congestion Windows), que controla del lado de la fuente la cantidad de datos que se puede enviar sin haber recibido un ACK, rwnd (receiver’s advertised window) que indica la cantidad de datos que puede recibir el destino y ssthresh (slow start threshold) que indica en qué fase de control de congestión se encuentra el transmisor (slow start si es mayor que cwnd o congestion avoidance si es menor; de ser iguales, se puede utilizar cualquiera de los dos algoritmos). El mínimo de cwnd y rwnd gobierna la transmisión. El algoritmo slow start es utilizado al comienzo de una transmisión a los efectos de que TCP pueda testear la red y conocer su capacidad evitando congestionarla. También es utilizado en el momento de recuperación ante la pérdida de algún segmento, indicada por timeout. Luego del three-way handshake, el tamaño de la ventana inicial de envío (IW: initial Windows) debe ser menor o igual que 2 x SMSS1 bytes y no mayor a dos segmentos. El valor de ssthresh debería ser lo más alto posible al comienzo (por ejemplo, igual a rwnd) y deberá reducirse en caso de congestión. Durante la fase slow start se aumenta cwnd en a lo sumo SMSS bytes por cada ACK recibido de datos nuevos entregados al receptor. Esta fase culmina cuando cwnd alcanza a ssthresh o cuando se detecta congestión.

A partir de allí se inicia la fase de congestion avoidance donde cwnd se incrementa en un segmento por round-trip time (tiempo que transcurre entre que sale un segmento y llega el ACK asociado).

Esta fase continúa hasta que se alcanza la congestión nuevamente.

Durante la fase de congestion avoindance, la actualización de la variable cwnd, se realiza con la siguiente fórmula:
cwnd = cwnd + SMSS x SMSS / cwnd

Calculándose cada vez que llega un ACK no duplicado.

Cuando el transmisor detecta la pérdida de un segmento, a partir del timer de retransmisión, el valor de ssthresh debe pasar a ser:ssthresh = max (FS / 2, 2 x SMSS)

Siendo FS (Flight Size) la cantidad de datos enviados pero aún no reconocidos o ACKed. Al mismo tiempo, cwnd no puede ser mayor que LW (Loss Window) que vale 1 segmento y sin importar el valor de IW. Se identifica con LW al tamaño de cwnd luego de detectar, a través del timer de retransmisión, una pérdida.

3. Control de flujo en TCP.

El protocolo de control de transmisiones (TCP) utiliza una ventana deslizante para controlar el flujo.

Antes de ajustar cualquier valor de TCP/IP, debe entender cómo funciona la ventana deslizante de TCP.

LA ventana deslizante de TCP determina el número de bytes no reconocidos, x, que un sistema puede enviar a otro. El valor de x está determinado por dos factores:

El tamaño del búfer de envío del sistema remitente

El tamaño y espacio disponible del búfer de recepción del sistema receptor

El sistema remitente no puede enviar un número de bytes superior al espacio disponible en el búfer de recepción del sistema receptor. Hasta que el sistema receptor no indique que ha recibido todos los bytes del búfer de envío actual, el TCP del sistema remitente no podrá enviar más datos.

En el sistema receptor, TCP almacena los datos recibidos en un búfer de recepción. TCP informa de la recepción de los datos y anuncia (comunica) una nueva ventana de recepción al sistema remitente. La ventana de recepción representa el número de bytes disponibles en el búfer de recepción. Si el búfer de recepción está lleno, el sistema receptor anuncia un tamaño de ventana igual a cero y el sistema remitente no podrá seguir enviando datos. Una vez que la aplicación receptora recupera los datos del búfer de recepción, el sistema receptor podrá responder con un tamaño de ventana igual a la cantidad de datos leídos. A continuación, el TCP de sistema remitente podrá reanudar el envío de datos.

El espacio disponible en el búfer de recepción depende de la rapidez con la que la aplicación receptora lea los datos en el búfer. TCP guarda los datos en el búfer de recepción hasta que la aplicación receptora los lea en dicho búfer. Una vez que la aplicación receptora ha leído los datos, el espacio queda disponible para nuevos datos. La cantidad de espacio libre del búfer se comunica al sistema remitente, como se describe en el párrafo anterior.