Protocolos de transporte en redes inalámbricas Luis López Fernández 2006.

Presentación del tema: "Protocolos de transporte en redes inalámbricas Luis López Fernández 2006."— Transcripción de la presentación:

1 Protocolos de transporte en redes inalámbricas Luis López Fernández 2006

2 Contenidos 1. Introducción 2. Funcionalidades avanzadas en TCP 3. TCP en redes con un solo salto inalámbrico 4. TCP en redes con múltiples saltos inalámbricos

3 Contenidos 1. Introducción 2. Funcionalidades avanzadas en TCP 3. TCP en redes con un solo salto inalámbrico 4. TCP en redes con múltiples saltos inalámbricos

4 Servicios y redes Servicio: Conjunto de facilidades y garantías proporcionadas por un sistema En las redes de hoy en día, se demandan servicios con gran Ancho de banda Movilidad Ubicuidad Ancho de banda: Se relaciona con la cantidad de información que es posible transmitir por unidad de tiempo Movilidad: Se relaciona con que el servicio se provea sobre un terminar que está en movimiento Ubicuidad: Se relaciona con que el servicio se provea independientemente de la localización geográfica del terminal La provisión de servicios con gran Movilidad y Ubicuidad se logra a través del uso de redes inalámbricas

5 Redes inalámbricas Red inalámbrica: Red de telecomunicaciones en la que alguno de los enlaces se basa en la transmisión por un medio no guiado (p.e. aire, vacío) Las redes inalámbricas se clasifican en: Redes con un solo salto inalámbrico (one-hop) Un solo salto inalámbrico es necesario para alcanzar el núcleo de la red El enlace inalámbrico suele estar asociado al acceso El núcleo de la red es guiado Una comunicación atraviesa, a lo sumo, dos enlaces inalámbricos Ejemplos: Redes 2G, 3G, WiFi LANs, etc Redes con múltiples saltos inalámbricos (multi-hop) El núcleo de la red posee (exclusivamente) enlaces inalámbricos Una comunicación atraviesa múltiples enlaces inalámbricos Ejemplos: Ad-Hoc WiFi, MANETs (Mobile Adhoc NETworks), redes de sensores, etc

6 Redes inalámbricas Cont. Redes inalámbricas con un solo salto Host Móvil Mobile Host MH Núcleo (guiado) de la red Salto inalámbrico Redes inalámbricas con múltiples saltos Host Fijo Fixed Host FH Estación Base Base Station BS

7 TCP/IP en redes inalámbricas Los protocolos TCP/IP están en la base de las tecnologías de Internet IP y (sobre todo) TCP fueron diseñados para las tecnologías (guiadas) de los 70/80 Hoy en día, las redes inalámbricas son mucho más populares ¿Cómo afecta la transmisión inalámbrica a TCP/IP? Comparamos la transmisión por medio guiado e inalámbrico Enlaces GuiadosEnlaces Inalámbricos MedioMuy uniformeDepende de condiciones externas BERBaja/muy bajaElevada MACSencillo, basado enComplejo, colisiones no siempre detectables. detección de colisionesMultiplexación (frecuencia, tiempo, códigos) BwElevado/muy elevadoLimitado, a repartir entre muchos RetardoVelocidad de la luzVelocidad de la luz Estas diferencias tendrán un claro impacto en los niveles Físico y de Enlace, pero ¿tendrán impacto en los niveles superiores?

8 TCP/IP en redes inalámbricas Cont. Suposiciones que fundamentan IP Existe un nivel de enlace que provee un servicio (no necesariamente fiable) de envío de paquetes entre dos extremos que comparten un mecanismo de enlace Existe un camino de enlaces que parte del emisor y alcanza al receptor Existe un mecanismo algorítmico que permite localizar el citado camino El uso de redes inalámbricas puede afectar al protocolo IP a la hora de calcular las rutas apropiadas para un paquete Suposiciones que fundamentan TCP Existe un nivel de red que provee un servicio (no necesariamente fiable) de envío de segmentos entre dos nodos de una red El RTT tiene “cierta uniformidad” (para el cálculo del RTO) Pérdida de segmentos implica congestión El uso de redes inalámbricas puede alterar seriamente las prestaciones de TCP en presencia de pérdidas de paquetes

9 Contenidos 1. Introducción 2. Funcionalidades avanzadas en TCP 3. TCP en redes con un solo salto inalámbrico 4. TCP en redes con múltiples saltos inalámbricos

10 Repaso de TCP: Formato del segmento Mecanismos básicos en TCP TCP es de extremo a extremo Multiplexación de procesos Números de puerto Detección y recuperación de pérdidas Nº Seq + ACK + RTO (Jacobson) Backoff exponencial (Karn) RTO = + 4D = a· + (1-a)·RTT D = b·D + (1-b)·| - RTT| Control de flujo Ventana de emisión controlada por receptor Control de congestión Pérdidas  Congestión Control de congestión a través de ventana 32 bits Puerto de origenPuerto de destino Número de secuencia Número de confirmación de recepción (ACK) Longitud cabecera TCP URGURG ACKACK PSHPSH RSTRST SYNSYN FINFIN Tamaño ventana Suma ComprobaciónApuntador urgente Opciones (0 o más palabras de 32 bits) Datos (opcional)

11 TCP Avanzado: SACKs RFC 2018: TCP Selectie Acknowledgement Options Idea básica: Anunciar qué segmentos hay que retransmitir con los ACKs duplicados Funcionamiento: Al establecer la conexión, las entidades negocian el soporte SACKs para la misma SACK Permitted option (2 bytes, solo en paquetes SYN) +---------+---------+ | Kind=4 | Length=2| +---------+---------+ Si ambas soportan SACK, se incluye la opción SACK +--------+--------+ | Kind=5 | Length | +--------+--------+--------+--------+ | Left Edge of 1st Block | +--------+--------+--------+--------+ | Right Edge of 1st Block | +--------+--------+--------+--------+ |... | +--------+--------+--------+--------+ | Left Edge of nth Block | +--------+--------+--------+--------+ | Right Edge of nth Block | +--------+--------+--------+--------+

12 TCP Avanzado: SACKs Cont. Los bloques de la opción SACK indican datos contiguos recibidos Se pueden enviar hasta 4 bloques (3 si se una la opción de TCP Timestamp) Ejemplo: |D|D|D| | | | | | | | |D|D|D|D|D| | |D|D| | | | |D|D|D| | | ACK Números de secuencia crecientes Ventana del Receptor Left Edge (B1) Right Edge (B1) Left Edge (B2) Right Edge (B2) Right Edge (B3) Left Edge (B3) Ventaja: Se pueden retransmitir más de un segmento por RTO Ventaja: No hace falta esperar un RTO para retransmitir un segmento adicional Nota: El número de segmentos que se pueden retransmitir depende del estado en el que se encuentren los algoritmos de control de congestión

13 TCP Avanzado: SACKs Cont. Comparación TCP SACKs con TCP “normal” a través de un ejemplo: RTT RTO S1 S3 S2 S4 ACK1 S2 S3 RTT RTO S1 S3 S2 S4 ACK1 ACK1-SACK(1-2, 4-5) S2 S3

14 TCP Avanzado: ECN RFC 3168: Explicit Congestion Notification Idea básica: Los routers informan explícitamente a sobre la congestión al emisor Funcionamiento: En IP, se reservan los bits 6 y 7 del campo TOS Bit ECT: Indica que el emisor de un paquete soporta ECN Bit CE: Indica que un router ha detectado congestión (Congestion Experienced) En TCP, se usan 2 bits de la parte “reservada para usos futuros” Bit ECE: El receptor avisa al emisor sobre la presencia de un CE Bit CWR: El emisor avisa al receptor de que ha recibido y procesado un CE Este mecanismo permite que un emisor TCP “detecte” la presencia de congestión independientemente de que haya, o no, pérdida de paquetes Usando ECN, es posible que haya pérdidas o que se agoten RTOs sin que el emisor tenga necesidad de “activar” los algoritmos de control de congestión Usando ECN el emisor puede “atajar” la congestión antes de que los efectos de esta se hagan explícitos (pérdida de paquetes, aumento de latencias, etc.)

15 TCP Avanzado: ECN Cont. Proceso de detección de congestión usando ECN mediante un ejemplo: TCP Entidad A Router con congestión TCP Entidad B IP(ECT) IP(CE) TCP(ECE) TCP(CWR) Se activa control de congestión como si hubiese un triple ACK

16 Contenidos 1. Introducción 2. Funcionalidades avanzadas en TCP 3. TCP en redes con un solo salto inalámbrico 4. TCP en redes con múltiples saltos inalámbricos

17 Problemas para TCP en las redes de un solo salto Errores de transmisión Debidos a problemas de multi-trayecto, desvanecimiento, interferencias, etc. Producen pérdidas de paquetes en el acceso del emisor (agotamiento de RTO) TCP reacciona invocando slow-start (reducción de ventana de congestión a 1 MSS) Handoffs Debidos a cambios de celda producidos por la movilidad de los terminales Producen desconexiones temporales que se traducen en pérdidas de paquetes Tcp reacciona invocando slow-start (reducción de ventana de congestión a 1 MSS) Se sugieren 4 categorías de soluciones para estos problemas Soluciones basadas en “partir” la conexión Soluciones basadas en la introducción de un proxy Soluciones basadas en modificar el nivel de enlace Soluciones basadas en la filosofía extremo a extremo

18 Soluciones basadas en “partir” la conexión Problema: si se pierde un paquete en el “salto inalámbrico”, hay que esperar un RTO completo para poder retransmitirlo Solución: La conexión entre los dos extremos se divide en dos conexiones Una del terminal móvil a la estación base (RTT y RTO muy bajos) Una de la estación base al terminal fijo (Pérdidas sólo debidas a congestión) MH Núcleo (guiado) de la red Salto inalámbrico FH BS Conexión TCP 1 Conexión TCP 2

19 Soluciones basadas en “partir” la conexión Cont. Host Móvil Host Fijo Estación base RTO Host Móvil Host Fijo Estación base RTO ACK RTO ACK Solución con TCP “normal” Solución con TCP de conexión partida

20 Soluciones basadas en “partir” la conexión Cont. Indirect-TCP (I-TCP) es un protocolo basado en “partir” la conexión Ventajas Produce una mejora de las prestaciones al minimizar los efectos de las pérdidas en el enlace inalámbrico Permite que el terminal y la estación de base hablen un “TCP simplificado” Problemas Rompe la filosofía extremo-a-extremo de TCP No garantiza la “entrega fiable” (podemos recibir los ACKs de datos en el emisor sin que estos hayan sido recibidos de manera correcta en el destinatario) Dificulta alcanzar direcciones IP remotas (modificaciones de TCP o conocimiento explícito de la presencia de dos conexiones) Dificulta enormemente la realización de handoffs No evita que se activen los algoritmos de control de congestión sobre la conexión MH-BS (a no ser que se modifique ese TCP)

21 Soluciones basadas en la introducción de un proxy Problema: si se pierde un paquete en el “salto inalámbrico”, hay que esperar un RTO completo para poder retransmitirlo Solución: En la estación base, añadimos un proxy que “escucha” los paquetes que van/vienen hacia/desde el enlace inalámbrico y actúa de manera “inteligente”. Intuitivamente, se puede entender como un “nivel de enlace” que “sabe hacer cosas del nivel de transporte” La solución más popular es SNOOP En sentido BS  MH Almacena los paquetes que pasan desde BS hacia MH y lanza un temporizador Escucha los ACKs que pasan desde MH hacia BS, cuando un paquete es asentido, se detiene su temporizador Si se agota un temporizador, BS retransmite el paquete Se filtran los ACKs duplicados procedentes de la MS (retransmisión posible) En sentido MH  BS MH debe soportar (y usar) TCP SACKs Cuando BS detecta “agujeros” en los datos, se envían los SACKs pertienentes que fuercen la retransmisión de los segmentos implicados Handoffs Se gestionan haciendo que las BSs “cercanas” a una MS formen un grupo multicast sobre el que se difunde toda la información de estado

22 SNOOP MHFHBS Tout ACK Tout RTO MHFHBS Desde BS hacia MH Desde MH hacia BS SACK ACK

23 SNOOP Cont. Ventajas Produce una mejora de las prestaciones al minimizar los efectos de las pérdidas en el enlace inalámbrico No requiere la modificación de TCP en ninguno de los terminales Es transparente para los terminales No altera la semántica de TCP Problemas Rompe la filosofía extremo-a-extremo de TCP Rompe e aislamiento por encapsulación de los modelos en capas (¿Qué ocurre si se usa IPSec y la cabecera TCP va cifrada?) El mantenimiento de estados para los handoffs es muy pesado

24 Soluciones basadas en modificar el nivel de enlace Problema: si se pierde un paquete en el “salto inalámbrico”, hay que esperar un RTO completo para poder retransmitirlo Solución: El nivel de enlace implementa un protocolo fiable Hay múltiples soluciones, una de las más populares es AIRMAIL Se usan dos técnicas para dotar de fiabilidad al protocolo de enlace Forward Error Correction (FEC) Consiste en añadir información redundante sobre los paquetes de forma que sea posible recuperarlos incluso cuando se han producido errores en la recepción de algunos bits Cuanto más información redundante, más errores se pueden recuperar y menos retransmisiones serán necesarias Cuanto más información redundante, menor ancho de banda estará disponible Automatic Repeat Request (ARQ) Consiste en que cuando el receptor detecta un paquete con errores irrecuperables, envía de forma instantánea una solicitud de retransmisión de los mismos

25 AIRMAIL Ventajas Produce una mejora de las prestaciones al minimizar los efectos de las pérdidas en el enlace inalámbrico No requiere la modificación de TCP en ninguno de los terminales Respeta la filosofía de los modelos en capas Respeta la filosofía extremo-a-extremo de TCP Problemas Puede alterar el cáculo de RTTs y RTOs en TCP No evita que aparezcan pérdidas en handoffs o bajo desconexiones temporales Se ha comprobado que este tipo de técnicas solo producen mejoras en las prestaciones de TCP cuando la tasa de errores en la recepción de paquetes está por encima de un determinado umbral

26 Soluciones basadas en la filosofía extremo-a-extremo Problema: los handoffs y los desvanecimientos hacen que el enlace inalámbrico se pueda perder temporalmente, con la consiguiente pérdida de paquetes Solución: El Host Móvil puede “predecir” cuando el enlace va a perderse, justo antes de que eso ocurra tomas las medidas oportunas para que esto no afecte al comportamiento de TCP Hay múltiples soluciones, una de las más populares es Freeze-TCP, que se puede utilizar para mejorar la calidad en el enlace BS  MH MH detecta una desconexión inminente al “ver” una caida de potencia MH envía de forma inmediata un ACK al FH anunciando una ventana de tamaño cero FH recibe el ACK y “congela” su estado (RTOs incluidos) FH envía periódicamente sondas para averiguar el estado de MH Las sondas son enviadas siguiendo un backoff exponencial. Por este motivo es posible que la conexión se haya restablecido, pero que tardemos mucho tiempo en notarlo Para evitar prolongar ese tiempo, cuando la conexión se restablece, MH envía tres ACKs duplicados, obligándole a entrar en un estado de Retransmisión Rápida Ventaja: Mejora las prestaciones de TCP sin necesidad de modificar los nodos intermedios Inconveniente: Requiere modificar TCP en MH Inconveniente: Todo depende de lo bien/mal que se “predigan” las desconexiones

27 Contenidos 1. Introducción 2. Funcionalidades avanzadas en TCP 3. TCP en redes con un solo salto inalámbrico 4. TCP en redes con múltiples saltos inalámbricos

28 TCP en MANETs Hemos visto que las redes con un solo salto presentan serios problemas para TCP Las redes inalámbricas multisalto suelen tomar la forma de MANETs MANET: Mobile Ad Hoc NETwork En las MANETs tanto los terminales como los nodos de conmutación son móviles En las MANETs un paquete debe atravesar varios enlaces inalámbricos En las MANETs las rutas de conmutación se construyen de manera dinámica Es de esperar que en MANETs, los problemas sean aún mayores Los problemas que aparecen se pueden clasificar en 4 categorías Errores de canal Efectos de contención en el acceso al medio Efectos producidos por la mobilidad de los nodos de conmutación Efectos producidos por rutado mutitrayecto

29 Problemas debidos a errores de canal Causa: Ruido electromagnético, interferencia, desvanecimiento, etc. Consecuencia: Los bits que componen un paquete se reciben de forma errónea Efecto en TCP: Los paquetes se pierden, se agotan RTOs, se activan los mecanismos de control de congestión, las prestaciones se deterioran enormemente Soluciones: Las vistas para redes de un solo salto

30 Efectos de contención en el acceso al medio Causa: Los mecanismos MAC no evitan la aparición de colisiones ni el reparto injusto de los recursos de transmisión Consecuencia: Los paquetes se pierden o tardan mucho tiempo en ser transmitidos Efecto en TCP: Los paquetes se pierden, se agotan RTOs, se activan los mecanismos de control de congestión, las prestaciones se deterioran enormemente Soluciones: Modificar los mecanismos MAC Ejemplos de problemas: Terminal Oculto: Un nodo que está en rango de interferencia con el receptor, pero fuera de rango de sensibilidad (detección de colisiones) del emisor. El TO produce colisiones con los paquetes del emisor Terminal Expuesto: Un nodo que está en rango de sensibilidad del emisor, pero fuera de rango de interferencia del receptor. El TE no puede emitir sus paquetes, aunque no molestarían a nadie. E1 R1 TO RTE E1 R1

31 Efectos producidos por la movilidad Causa: Los nodos de conmutación están en movimiento Consecuencia: Las rutas se rompen, hay que encontrar otras Efecto en TCP: Mientras se encuentra una nueva ruta o se resuelve un partición de red, se agotan RTOs, se activan los mecanismos de control de congestión, las prestaciones se deterioran enormemente Soluciones: “congelar” las entidades TCP mientras el problema persiste Movimiento de Host Ruta original Ruta final Enlace que se rompe

32 Efectos producidos por rutado multitrayecto Causa: Los paquetes viajan por rutas diferentes Consecuencia: Los paquetes se desordenan y tienen latencias poco uniformes Efecto en TCP: Se reciben ACKs suplicados, se activan los mecanismos de control de congestión, las prestaciones se deterioran Soluciones: Utilizar ECN como único mecanismo para detectar la congestión Ruta 1 Ruta 2

33 TCP en MANETs: soluciones con retroalimentación La retroalimentación (feedback) consiste en que la red “informa” a las entidades TCO sobre el estado de la misma (congestión, ruptura de rutas, etc) Las entidades TCP pueden “conocer” con mayor precisión el estado de la red y actuar en consecuencia gracias a esa retroalimentación Ejemplos de retroalimentación ECN para informar de presencia de congestión (evita usar pérdidas de paquetes) ICMP “Destination Unreachable” para avisar de ruptura de rutas Ejemplos de protocolos que se basan en retroalimentación TCP-F (TCP-Feedback): Cuando se detecta un fallo en una ruta, se informa de manera expícita al emisor. Este “congela” el estado de la conexión hasta que se recibe una notificación explícita de que la ruta ha sido restablecida TCP-ELFN (TCP-Explicit Link Failure Notification): Se notifica la ruptura de una ruta, pero es el emisor es que se ocupa de averiguar cuando la ruta se ha establecido enviando sondas periódicas ATCP (Ad hoc TCP): Utiliza mecanismos estándar de notificación: ECN, ICMP, etc. Es compatible con “TCPs normales”. Sólo realiza control de congestión mediante ECN, “cogela” el estado si una ruta se rompe. Problemas: Todos requieres modificaciones sobre TCP y soporte, por parte de las infraestructuras de red, de los mecanismos de retroalimentación.

34 TCP en MANETs: soluciones sin retroalimentación Se basan en modificar el comportamiento de TCP, pero manteniendo la filosofía extremo-a-extremo (sin necesidad de alterar los elementos de red) Las mejoras que se consiguen son modestas (pasar del 10% al 20% y similar) Existen varias aproximaciones, pero las ideas básicas son: Garantizar que el tamaño de la ventana de congestión permanece moderado de forma que no se fuerza a la red a entrar en congestión (bw delay product) Tratar de detectar “cambios en la topología de rutado” (por ejemplo, a través de paquetes que llegan fuera de orden) y “suavizar” el control de congestión en ese caso No utilizar back-off exponencial cuando se pierde un paquete, de este modo las prestaciones no se degradan de “manera extrema” Algunos protocolos que utilizan estas (o similares) ideas son: Adaptive Congestion Window Limit Setting TCP-DOOR Fixed RTO etc

35 Comentarios y referencias Comentarios y reflexiones ¿Qué tienen que ver los problemas del nivel de transporte con los problemas del nivel de enlace en redes inalámbricas ? ¿Qué tienen que ver los problemas del nivel de transporte con los problemas del nivel de red en redes inalámbricas ? ¿Por qué crees que las soluciones con retroalimentación ofrecen mejores prestaciones que las soluciones extremo-a-extremo puras? Trata de averiguar cuáles son las prestaciones reales de TCP en las redes inalámbricas que hemos visto en este tema Referencias Xiang Chen, Hongqiang Zhai, Jianfeng Wang and Yuguang Fang. A Survey on Improving TCP Performance over Wireless Networks (Disponible en http://citeseer.ist.psu.edu/chen05survey.html) Nunca desprecies el poder de Wikipedia (http://www.wikipedia.org) Nunca desprecies el poder de Google (http://www.google.com) Nunca desprecies el poder de Google Scholar (http://scholar.google.com)

36