protocolos de transporte en redes inalámbricas luis lópez fernández 2006

Protocolos de transporte en redes

inalámbricas

Luis López Fernández

2006

ContenidosContenidos

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

Servicios y redes 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

Redes inalámbricasRedes 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

Redes inalámbricas Cont.Redes inalámbricas Cont.

•Redes inalámbricas con un solo salto

Host MóvilMobile Host

MH

Núcleo (guiado) de la redSalto

inalámbrico

•Redes inalámbricas con múltiples saltos

Host FijoFixed Host

FH

Estación BaseBase Station

BS

TCP/IP en redes inalámbricasTCP/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 Guiados Enlaces Inalámbricos

Medio Muy uniforme Depende de condiciones externas

BER Baja/muy baja Elevada

MAC Sencillo, basado en Complejo, colisiones no siempre detectables.

detección de colisiones Multiplexación (frecuencia, tiempo, códigos)

Bw Elevado/muy elevado Limitado, a repartir entre muchos

Retardo Velocidad de la luz Velocidad 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?

TCP/IP en redes inalámbricas Cont.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


1. Introducción




Repaso de TCP: Formato del segmentoRepaso 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 = <RTT> + 4D

•<RTT> = a·<RTT> + (1-a)·RTT

•D = b·D + (1-b)·|<RTT> - 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 origen Puerto de destino

Número de secuencia

Número de confirmación de recepción (ACK)

Longitud cabecera

TCP

URG

ACK

PSH

RST

SYN

FIN

Tamaño ventana

Suma Comprobación Apuntador urgente

Opciones (0 o más palabras de 32 bits)

Datos (opcional)

TCP Avanzado: SACKsTCP 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 | +--------+--------+--------+--------+

TCP Avanzado: SACKs Cont.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| | |

AC

K

Números de secuencia crecientesVentana del Receptor

Left E

dg

e (B1)

Rig

ht E

dg

e (B1)

Left E

dg

e (B2)

Rig

ht E

dg

e (B2)

Rig

ht E

dg

e (B3)

Left E

dg

e (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

TCP Avanzado: SACKs Cont.TCP Avanzado: SACKs Cont.

Comparación TCP SACKs con TCP “normal” a través de un ejemplo:R

TT

RT

O

S1

S3S2

S4

ACK1

ACK1

S2S3

RT

T

RT

O

S1

S3S2

S4

ACK1

ACK1-SACK(1-2, 4-5)

S2S3

TCP Avanzado: ECNTCP 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.)

TCP Avanzado: ECN Cont.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(ECE)

TCP(CWR)

TCP(CWR)

Se activa control de congestión

como si hubiese un triple ACK


1. Introducción




Problemas para TCP en las redes de un solo saltoProblemas 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

Soluciones basadas en “partir” la conexiónSoluciones 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 redSalto

inalámbricoFH

BS

Conexión TCP 1 Conexión TCP 2

Soluciones basadas en “partir” la conexión Cont.Soluciones basadas en “partir” la conexión Cont.

HostMóvil

HostFijo

Estaciónbase

RT

O

HostMóvil

HostFijo

Estaciónbase

RT

O

ACK

ACK

ACK

RT

O

ACK

ACK

Solución con TCP “normal” Solución con TCP de conexión partida

Soluciones basadas en “partir” la conexión Cont.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)

Soluciones basadas en la introducción de un proxySoluciones 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 BSMH

•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

SNOOPSNOOP

MH FHBS

To

ut

ACK

ACK

To

ut

RT

O

MH FHBS

Desde BS hacia MH Desde MH hacia BS

SACK

ACK

ACK

SNOOP Cont.SNOOP Cont.

Ventajas


•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

Soluciones basadas en modificar el nivel de enlaceSoluciones 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

AIRMAILAIRMAIL

Ventajas


•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

Soluciones basadas en la filosofía extremo-a-extremoSoluciones 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 BSMH•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


1. Introducción




TCP en MANETsTCP 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

Problemas debidos a errores de canalProblemas 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

Efectos de contención en el acceso al medioEfectos 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 R1TO R TEE1

R1

Efectos producidos por la movilidadEfectos 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 HostRuta original

Ruta final

Enlace que se rompe

Efectos producidos por rutado multitrayectoEfectos 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

TCP en MANETs: soluciones con retroalimentaciónTCP 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.

TCP en MANETs: soluciones sin retroalimentaciónTCP 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

Comentarios y referenciasComentarios 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)

protocolos de transporte en redes inalámbricas luis lópez fernández 2006

Documents