Existen varios
estudios dedicados al análisis de aspectos relacionados con el comportamiento
de TCP en los entornos móviles En ellos se pone de manifiesto el bajo
rendimiento del protocolo en diferentes entornos inalámbricos y se proponen
estrategias para mejorarlo. A continuación, se resumen algunos protocolos que
se han propuesto para mejorar el comportamiento del protocolo TCP en enlaces
inalámbricos.
• Protocolos de
Nivel de Enlace: Aparecen varias propuestas en la bibliografía de protocolos
para dar fiabilidad al nivel de enlace. Éstos utilizan básicamente dos
técnicas: la corrección de errores utilizando técnicas tipo Forward Error
Correction (FEC); y la retransmisión como respuesta a mensajes tipo Automatic
Request Repeat (ARQ). Entre estas soluciones se encuentra CDMA, TDMA y AIRMAIL.
Estos protocolos intentan esconder las pérdidas a TCP, no obstante, estas
soluciones no aseguran que se resuelvan los errores satisfactoriamente. Por lo
tanto, pueden interaccionar los mecanismos propios de TCP con los de
recuperación a nivel de enlace (tales como temporizadores de retransmisión y
reconocimientos duplicados), produciéndose retransmisiones a nivel de
transporte de paquetes que pueden haber sido retransmitidos previamente por los
mecanismos de nivel de enlace.
Mecanismos
de Solución:
• Protocolos
con conexión partida: Son aquellos que dividen en dos partes la conexión TCP
establecida, independizando la parte fija de la parte móvil. En estas
soluciones se rompe la semántica extrema a extremo de TCP. En la parte móvil se
define un protocolo específico. En [YaB94] se proponen dos protocolos, en uno
se usa TCP y en el otro se usa un protocolo de repetición selectiva sobre UDP.
El estudio del impacto de traspasos en ambas soluciones concluye en que no se
obtiene mejora en el segundo de los casos. Otro estudio [BPS97] presenta una
optimización de retransmisión selectiva en TCP con el que sí que se obtienen
mejoras significativas en entornos erróneos. En [BaB95, BaB97] se presenta el
protocolo Indirect-TCP. Éste utiliza el protocolo TCP estándar en ambas
conexiones (la de la parte fija y la de la parte móvil).
Los
inconvenientes de esta solución son los inherentes al propio protocolo TCP en
entornos móviles, ya que la interacción de los mecanismos contra la congestión
interfiere de la misma forma. Finalmente, M-TCP, presentado en [BrS97] divide
la conexión fija y móvil sin perder la semántica extrema a extremo de TCP. Esta
propuesta es adecuada para solucionar los problemas de las desconexiones
temporales debido a la movilidad, más que al efecto de los errores.
• Protocolo
“snoop” [BSK95]: Ésta es una solución híbrida entre las dos anteriores. Está
diseñado para mejorar el comportamiento del protocolo en los casos de
transferencia de datos de fijo a móvil (para el caso inverso deben añadirse
mecanismos de reconocimiento negativo). Este protocolo introduce un módulo en
la estación base, de forma que monitoriza la conexión TCP en ambas direcciones
y guarda en “cache” los segmentos que han sido enviados y que no han sido
reconocidos todavía. Si el agente detecta reconocimientos duplicados, éste los
elimina y retransmite el paquete. De esta forma, la fuente TCP no detecta la
pérdida del segmento.
Algunos
inconvenientes de este protocolo son la memoria necesaria para el almacenaje de
los paquetes y la complicación de la gestión de traspasos. No obstante, los más
importantes son, por una parte, el hecho de que los reconocimientos deben
seguir el mismo camino que los datos (sería el caso de varios enlaces móviles
en la topología de la red o en topologías asimétricas).
• Protocolos de
Notificación explícita: Basado en diferenciar las pérdidas debidas a congestión
o a errores. Una vez diferenciadas, se notifica al emisor que las pérdidas son
debidas a una causa o a la otra, y se actúa en consecuencia. En [BKV97] se
presenta el esquema Explicit Bad State Notification (EBSN), que se basa en la
notificación de estados de error en caso de que no se reciban reconocimientos
durante un cierto tiempo. Con este método se evitan, básicamente, los
inconvenientes del algoritmo debackoff exponencial tras periodos de desconexión
o altas tasas de error.
No hay comentarios:
Publicar un comentario