Grupo 1

De CURE - Informática
Revisión del 12:18 24 sep 2011 de Victor (discusión | contribuciones) (Monografía)
Saltar a: navegación, buscar

Aquí escribiremos una propuesta de documentación.


Documentación - Taller de Redes Inalámbricas

Autores:

  • Emiliano Desantis
  • Fernando Tajes
  • Victor Alem

Docentes:

  • Pablo Belzarena
  • Federico Larroca
  • Pablo Archimowicz


Caracteristicas relevantes de las redes 802.11 que se deben comprender con respecto al problema de TCP sobre este tipo de redes

El IEEE 802.11 capa MAC cubre tres áreas funcionales: la entrega de datos confiables, control de acceso al medio, y la seguridad. A nosotros nos interesa las 2 primeras áreas:

Entrega de datos confiable

Al igual que con cualquier red inalámbrica, una LAN inalámbrica mediante el estándar IEEE 802.11 está sujeta a una falta de fiabilidad considerable. Ruido, interferencia, y otros efectos de propagación dan como resultado una pérdida importante de paquetes. Incluso con la utilización de códigos para la corrección de errores, una importante cantidad de tramas no van a ser recibidas con éxito. Esta situación puede ser tratada por los mecanismos de seguridad a un nivel de capa, como por ejemplo TCP. Sin embargo, temporizadores utilizados para la retransmisión en las capas superiores generalmente andan por el orden de los segundos. Por lo tanto, es más eficiente hacer frente a los errores en el nivel MAC. Para ello, IEEE 802.11 incluye un protocolo de intercambio de paquetes (ARQ). Cuando una estación recibe una trama de datos desde otra estación, se devuelve un reconocimiento (ACK) para la estación origen. Este cambio se trata como una unidad atómica, para no ser interrumpido por una transmisión de cualquier otra estación. Si la fuente no recibe un ACK dentro de un período corto de tiempo, ya sea porque su trama de datos está dañada o porque el ACK estaba dañado, la fuente retransmite la trama. Por lo tanto, el mecanismo de transferencia de datos básico en IEEE 802.11 implica un intercambio de dos tramas. Para mejorar aún más la fiabilidad, se puede hacer un intercambio de cuatro tramas, en este esquema, el emisor envia una trama request to send (RTS) , y el receptor de dicha trama responde con un clear to send(CTS). Después de recibir el CTS, la fuente transmite la trama de datos y el destino responde con el ACK correspondiente. Con este esquema las estaciones que están en el rango del emisor como del receptor se abstienen de transmitir. El RTS/CTS es una función necesaria de la capa MAC, igualmente puede ser desactivada según la circunstancias.

Control de Acceso al Medio

En el estándar 802.11 define dos funciones para el acceso al medio: la Función de Coordinación Distribuida(DCF, Distributes Coordination Function) y la Función de Coordinación Puntual(PCF, Point Coordination Function). La primera es de implementación obligatoria mientras que la segunda es optativa. DCF es un mecanismo basado en contención, por ejemplo las estaciones compiten por el uso del medio inalámbrico, y permite la transmisión asíncrona de paquetes. Este modo puede utilizarse en cualquier tipo de topología, por ejemplo en redes ad hoc y en redes de infraestructura. Por su parte, PCF implementa un modo de transmisión sin contención y proporciona una transmisión síncrona a través de un acceso basado en sondeo(polling). La utilización de PCF requiere de un coordinador(PC, Point Coordinator) que gestione el uso del medio compartido,

normalmente implementado en el punto de acceso, debido a esto, PCF sólo se utiliza en redes de infraestructura. En este caso se alternan períodos de contención y períodos libres de contención, usándose los primeros para el modo PCF y las segundas para el modo DCF.

Características relevantes de TCP que se deben entender para analizar su desempeño sobre redes inalámbricas

El mecanismo Slow-Start

Este es el mecanismo que se suele utilizar para “levantar” desde cero una conexión TCP por lo que se trata de un algoritmo bastante agresivo. Aumenta el tamaño de la ventana de congestión cada vez que recibe un reconocimiento de un paquete, con el objetivo de alcanzar lo antes posible el tamaño de ventana óptimo. El algoritmo de Slow Start empieza con una fase de crecimiento exponencial donde cada RTT se incrementa la ventana de congestión , por cada reconocimiento recibido se aumenta en 1 MSS el tamaño de la ventana de congestión. Podemos ver entonces que en el mecanismo de Slow Start el crecimiento de la ventana es exponencial en RTT y lineal en ACK. La fase de Slow Start durará hasta que la ventana de congestión alcance el valor del umbral de Slow Start. Una vez se alcance este valor se pasará al estado de Congestion Avoidance donde a fin de reducir la congestión el crecimiento en cada RTT pasará a ser lineal. Cuando se detecte una pérdida de paquete (por timeout) el umbral se divide por dos y el algoritmo se reinicia volviendo la ventana a su valor inicial.

El mecanismo Congestion Avoidance

El objetivo del mecanismo de Congestion Avoidance de TCP es como bien dice su nombre el de evitar la congestión durante una sesión TCP. Para ello cuando la ventana de congestión supere el umbral de Slow Start entraremos en este estado y por cada reconocimiento recibido se aumentará la ventana de congestión. En este estado cuando se detecte una pérdida de paquete (por timeout) al igual que para Slow Start se dividirá el umbral por dos y la ventana vuelve a su valor inicial, comenzando otra vez la fase de Slow Start.

Mecanismos Fast Rentransmit y Fast Recovery

En las primeras implementaciones de TCP y al realizar el control de congestión los investigadores se dieron cuenta que al producirse una pérdida de un paquete se perdía mucho tiempo hasta que se agotara el RTO. Debido a esto se agregó a TCP un nuevo mecanismo llamado Retransmisión Rápida (Fast Retransmit). Cada vez que llega un paquete al receptor, éste responde con un ACK, aún cuando el número de secuencia ha sido reconocido. Entonces, cuando un paquete llega fuera de orden, es decir, TCP no puede reconocer el dato que contiene el paquete porque datos anteriores aún no han llegado, TCP reenvía el mismo ACK que envió la última vez. Esta segunda transmisión del mismo ACK se denomina ACK duplicado. Cuando el lado transmisor ve el ACK duplicado, sabe que el otro lado ha recibido un paquete fuera de orden, lo que le sugiere que un paquete enviado con anterioridad se perdió. Como es posible que el paquete no se haya perdido sino que únicamente se haya retrasado a la práctica se considera que habrá una pérdida cuando se reciban hasta 3 ACKs duplicados. Así pues con este método se podrá detectar cuando se haya producido una pérdida antes de que expire el RTO. Cuando un emisor reciba 3 ACKs duplicados responderá con la inmediata retransmisión del paquete que se ha perdido. Finalmente es posible introducir una nueva mejora llamada Recuperación Rápida (Fast Recovery). Si detectamos pérdida por ACKs duplicados no volvemos a la fase de Slow Start, en su lugar la ventana de congestión pasa a ser la mitad de cuando se detectó la pérdida; y además el umbral de Slow Start pasa a ser:

ssthresh = max (FS / 2 , 2 x MSS) (3.3)

donde FS (Flight Size) = Cantidad de datos enviados pero aún no reconocidos A su vez hasta que no se reconozca el paquete retransmitido, por cada ACK repetido que llegue aumentaremos en un MSS la ventana y podremos mandar un nuevo paquete (si la ventana efectiva lo permite). De esta forma seguimos haciendo Fast Retransmit hasta que el paquete perdido llegue a su destino. Si no siguiéramos enviando nuevos paquetes, vencería el timeout y durante ese rato se habría vaciado el canal creando ineficiencia.

Problemas de TCP en wireless

La base de estos problemas esta en que TCP no esta capacitado para diferenciar cuando el rendimiento de la conexión ha bajado debido a perdidas de enlace( o capa física), y cuando es debido a una red congestionada. En conclusión el transmisor no puede saber con seguridad a que es debida la perdida de un segmento. Cuatro de los aspectos mas importantes y que influyen mas en la performance de las redes inalámbricas son:

  • El BER(Bit Error Rate) que es un error causado por la capa fisica.
  • El ancho de banda del cual disponemos es menor al de las redes cableadas.
  • Otro aspecto importante a considerar es la movilidad de los componentes de la red.
  • 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.


Algunas soluciones propuestas para remediar estos problemas

Para solucionar todos estos aspectos las características que debería tener una implementación de TCP para redes wireless serian las iguientes:

  • End-to-end: los segmentos son reconocidos solamente luego de haber sido recibidos por el destinatario final.
  • Local: implementa cambios solamente sobre los componentes de red wireless, como puede ser en las estaciones base y en las estaciones móviles.
  • Two-Way: está diseñada para tráfico en ambas direcciones, desde la red cableada hacia el host móvil y viceversa, suponiendo que el mismo tiene intensidades similares.
  • Intermediate-Link: el algoritmo no asume una ubicación predeterminada del enlace wireless. Es decir, el mismo puede estar en cualquier lugar de la conexión.
  • Transparent: no necesita leer información del encabezado TCP en algún nodo intermedio.
  • Signaling: detecta y reporta la causa de la pérdida de los segmentos a las capas superiores, para tomar las acciones de recuperación apropiadas para evitar retransmisiones indeseables.

Nos centraremos en CC (Congestion Coherence) debido a que es el que cumple con todas las caracteristicas necesarias que se necesitan para la implementación de TCP en redes wireless.

Congestion Coherence (CC)

Considera como supuesto previo que está implementado ECN(Explicit Congestion Notification) sobre la red cableada. Si bien esta mejora es local, es aplicable a un amplio espectro de configuraciones de redes y escenarios de tráfico. Congestion Coherence, usa un esquema basado en la coherencia de la congestión entre paquetes consecutivos apuntando a determinar la causa de la pérdida de los paquetes. Emplea retransmisiones locales a nivel de capa de Enlace.

Aspectos relevantes:

Retransmisiones locales en capa de Enlace

Todas las tramas trasmitidas en el enlace wireless son localmente reconocidas antes de ser borradas en el buffer del emisor. Las tramas que no son reconocidas o son negativamente reconocidas luego de expirado un timer serán retransmitidas. Las retransmisiones de las tramas fallidas, tienen mayor prioridad que las nuevas tramas. Esto es importante para reducir el retardo de las tramas retransmitidas y minimizar la chance de disparo de retransmisiones end-to-end desde el transmisor. Una manera de implementar la mayor prioridad es usar la estrategia insert from front. La capa de enlace puede tanto retransmitir persistentemente o detenerse luego de que se alcanza una cantidad máxima de retransmisiones.

Detección de la causa de pérdida de los segmentos

De modo de distinguir entre errores de transmisión y aquellos debidos a congestión, el receptor wireless necesita un mecanismo para detectar la causa de la pérdida de los segmentos. Segmentos fuera de orden indican segmentos perdidos. Ambas pérdidas(1), wireless y por congestión, causan

segmentos fuera de orden y crean huecos en el espacio de secuencia, pero sus consecuencias son diferentes. La manera de determinar la causa de la pérdida de los segmentos está basada en la observación de que la congestión no ocurre y desaparece repentinamente. Antes de que la misma se torne tan severa al punto que un segmento tenga que ser desechado, algunos segmentos deben ser marcados por ECN como congestion experienced. Similarmente, luego de que un segmento es desechado, la congestión no desaparece inmediatamente. El tamaño de la cola decae gradualmente y algunos segmentos son marcados. En el tiempo que transcurre entre que un segmento no se marca y entre que un segmento es desechado, algunos segmentos deberán ser marcados. Como resultado, las pérdidas por congestión están normalmente precedidas y seguidas por segmentos marcados. Llamamos a este fenómeno congestion coherence del marcado ECN. Los segmentos adyacentes de un segmento perdido definen el coherence context. Podemos definir al contexto coherente de un paquete n como el conjunto formado por los paquetes {n-1, n+1, n+2}. Un segmento perdido será considerado como una situación de pérdidas por congestión si algún segmento en su contexto coherente esta marcado por ECN. En este caso, la estación móvil responde a través de ACK duplicados para disparar la fase de fast retransmit. En contraste a la situación de pérdida por congestión, la ocurrencia de errores de transmisión (típicos en enlaces wireless) y por lo tanto la no presencia de segmentos marcados debería evitar que se evolucione a la fase de fast retransmit. Si algún segmento en el contexto coherente esta marcado por ECN, es necesario tomar acciones para controlar la congestión reduciendo la tasa de transmisión de TCP. La probabilidad de tener una pérdida por congestión sin un paquete marcado en el contexto coherente es muy pequeña. Así es que entonces, cuando en dicho contexto existen segmentos que no están marcados, la estación móvil mantiene el reconocimiento duplicado hasta que sea recibido el paquete retransmitido. La misma idea puede ser aplicada al caso de un emisor wireless. Cuando este recibe reconocimientos duplicados, chequea si existe en el contexto coherente algún ECN-Echo. En caso afirmativo, dichos reconocimientos estarían causados por pérdidas por congestión, de modo que el emisor invoca el control de congestión. En caso contrario, el emisor ignora los ACK duplicados hasta que tenga éxito la retransmisión local.

Referencias: