TCP MÓVIL

TCP Móvil TCP (Protocolo de control de transmisión) Protocolo confiable orientado a la conexión que permite que una corriente de bytes de una máquina se entregue sin errores en otra máquina de la interred. Su funcionamiento se ha optimado para las redes en las que la causa de pérdida de paquetes es la congestión. Actualmente, los usuarios de Internet requieren acceder a este servicio a través del enlace radio para poder disponer de él desde cualquier lugar. No obstante, TCP no funciona correctamente en entornos radio en los que las pérdidas de paquetes son debidas a altas tasas de error en bit BER.

TCP Móvil Los servicios de transmisión de datos en redes móviles constituyen uno de los sectores de las telecomunicaciones destinado a experimentar mayor auge en los próximos años. Razones principales: La reducción en el tamaño y precio de los ordenadores portátiles ha extendido su uso. La aparición de la  tarjeta PCMCIA ha sido determinante en el desarrollo de módems compactos de muy reducido tamaño que facilitan el intercambio de datos en entornos móviles. La utilización de aplicaciones como correo electrónico, la transferencia de ficheros, el acceso remoto y el acceso a la Web, ya sea desde tierra, mar o aire. Estas utilizan el protocolo TCP.

TCP Móvil Un 80 % del tráfico total en las redes de área extendida corresponde a paquetes TCP.   Los protocolos del modelo TCP/IP fueron diseñados para ser utilizados en redes compuestas por ordenadores fijos y, no se había planteado la posibilidad de que tuvieran que enfrentarse a un nuevo entorno, como es el canal radio móvil. Al determinar si es viable ofrecer servicios basados en redes móviles, se deben analizar las posibilidades de acoplamiento del protocolo a este enlace de comunicación.

TCP Móvil Ahora bien, en los entornos móviles las pérdidas de paquetes son muy frecuentes debido a las altas tasas de error y a las desconexiones temporales. Casi todas las implementaciones de TCP suponen que las terminaciones de temporización ocurren por congestionamiento, no por paquetes perdidos. En consecuencia al terminar un temporizador, el TCP disminuye su velocidad y envía con menor ímpetu. Lo que pretende es reducir la carga y aliviar el congestionamiento.   Los entornos móviles son muy poco confiables, pierden paquetes todo el tiempo. Lo adecuado para el manejo de paquetes perdidos es reenviarlos lo más pronto posible. El reducir la velocidad empeora las cosas.

Ejemplo: Sí se pierde 20% de todos los paquetes, entonces cuando el transmisor envía 100 paquetes/seg, el rendimiento es de 80 paquetes/seg. Si el transmisor reduce su velocidad a 50 paquetes/seg, el rendimiento cae a 40 paquetes/seg. Cuando el transmisor no sabe qué clase de red se trata es difícil tomar la decisión de reducir o acelerar la velocidad de transmisión.

Con frecuencia, la trayectoria del transmisor al receptor no es homogénea. Lo primeros 1000 km podrían ser a través de una red alambrada y el último km inalámbrico. Por lo que es más difícil la decisión correcta en el caso de una terminación de temporización, ya que importa el lugar donde ocurrió el problema.

TCP indirecto TCP indirecto, es la división de la conexión TCP en dos conexiones distintas. La primera conexión va del transmisor a la estación base. La segunda va de la estación base al receptor. La estación base simplemente copia paquetes entre las conexiones en ambas direcciones.

La ventaja es que ahora ambas conexiones son homogéneas. Las terminaciones de temporización de la primera conexión puede reducir la velocidad del transmisor, y las terminaciones de la segunda pueden acelerarla. La desventaja es que se viola la semántica del TCP. La recepción de un reconocimiento en el transmisor no significa que el receptor recibió el segmento, sino que la estación base lo recibió.

Solución propuesta por Balakrishnan Hace modificaciones al código de capa de red de la estación base.  Agrega un agente espía que observa y pone en caché los segmentos TCP que van al host móvil y los acuses de recibo que regresa de él. Cuando el agente espía ve un segmento TCP que sale al host móvil, pero no ve el regreso de un acuse de recibo antes de que su temporizador termine, simplemente retransmite ese segmento, sin indicar al origen que lo está haciendo.   El agente también genera retransmisión cuando ve acuses de recibo duplicados del host móvil, lo que significa que fallo algo en el host. Estos acuse se descartan en el lugar, para evitar que el origen los malinterprete como señal del congestionamiento.

Una desventaja de este es que si el enlace inalámbrico tiene muchas perdidas, el origen puede terminar de temporizar esperando un acuse de recibo e invocar el algoritmo de congestionamiento. Con el TCP indirecto, el algoritmo de control de congestionamiento nunca iniciará hasta que realmente haya un congestionamiento en la parte alambrada de la red.

  El documento de Balakrishnan, también sugiere una solución al problema de segmentos perdidos que se originan en el host móvil. Al notar una estación base un hueco en los números de secuencia de entrada, genera una solicitud de repetición selectiva de los bytes faltantes usando una opción TCP.

TCP EN EL ENTORNO MOVIL La arquitectura de protocolos TCP/IP fue diseñada para operar en redes fijas en las que las tasas de error en bit o BER (Bit Error Rate) eran altas. Más adelante, la evolución de las redes fijas, en la que el principla problema es la congestión, y no los errores, provocó la evolución de estos protocolos para su buen funcionamiento en situaciones de congestión. Actualmente en entornos móviles la principal causa de pérdidas de datos es la alta BER del canal. Diferentes efectos nocivos en el enlace móvil resultan en ráfagas de error que inciden negativamente en el rendimiento del protocolo de transporte. Dichos efectos son los principales responsables de la dificil adaptación del protocolo TCP en enlaces móviles

Errores deterministas vs. Ráfagas de error Las ráfagas de error se han modelado mediante el modelo de Fritchman. Las rágagas de error degradan en mayor medida el comportamineto que los errores deterministas. En cualquier caso, en precencia de errores, la degradación en el comportamineto del protocolo debe ser evaluado. Por ejemplo: Si tenemos una trasmisión de 100 Kb/s con MTU de 296 bytes y sin comprención de cabecera TCP/IP, el throughput obtenido en precencia de errores determiniastas es de 830 bytes/s y en precencia de ráfaags de error es de 720 bytes/s. Concluyendo, los mecanismos que recuperan de las situaciones de congestión no son los mas adecuados cuando existen errores en rafaga.

COMPRESIÓN VAN JACOBSON En los canales móviles el ancho de banda esta limitado, el echo de optimar su uso es un requerimento importante. Una forma de reducir el ancho de banda utilizado es reducir las cabeceras de los protocolos de red mediante el algoritmo Van Jacobson. A continuación veremos algunas ventajas de la comprensión de cabeceras

Ventajas: La reducción en el tiempo de respuesta de la aplicaciones interactivas. Independiza el tamaño del segmento y el throughput alcanzable para un conección. Reduce la Probabilidad de Perdida de Paquetes y optimiza a si mismo el ancho de banda. La comprensiónde cabeceras de Van Jacobson es apropiada para TCP/IP sobre enlaces moviles.

Transferencia ftp sin errores

Transferencia ftp con errores En el caso de tener errores, la compresión de Van Jacobson debe estudiarse detalladamente. Mientras este método reduce la PrbPP, el método en sí crea una dependencia entre cada segmento y el anterior. Esta dependencia supone un incremento subjetivo de la PrbPP, ya que la pérdida de un segmento produce la pérdida de toda la ventana de transmisión del TCP.

Transferencia ftp con errores

Transferencia ftp con errores Además, como que en caso de errores la compresión de cabeceras provoca la retransmisión de toda la ventana de transmisión, su tamaño es un aspecto determinante en el “throughput” del TCP cuando éstos ocurren. Este parámetro tiene dos efectos:

Transferencia ftp con errores Los paquetes perdidos son detectados por el emisor con la expiración del RTO, y su valor se incrementa al hacerlo la ventana de transmisión cuando el tiempo de transmisión es apreciable (el cual depende de la velocidad del enlace). Por ejemplo, si la MTU del enlace es de 296 bytes, y la velocidad efectiva es de 960 bytes/s, el RTT (Round Trip Time) es de alrededor 360 mseg, y el RTO de 430 msec.

Transferencia ftp con errores Con estos valores, el valor apropiado del tiempo máximo de transmisión para esta conexión es de 2 segmentos. No obstante, la mayoría de implementaciones TCP usan un valor superior para el máximo de la ventana de transmisión (este es el caso de la implementación que hemos usado), lo que significa que los paquetes se almacenan en el puerto de salida. Por lo tanto, el RTT (y en consecuencia el RTO) incrementa. La figura 9 representa la evolución del RTT y del RTO para una conexión TCP/IP/PPP. En consecuencia, si RTO aumenta en caso de errores las pausas en la comunicación también lo hacen, y el rendimiento del protocolo TCP se degrada.

Transferencia ftp con errores

Transferencia ftp con errores En segundo lugar, uno o más errores por ventana de transmisión implica la retransmisión de todos los paquetes no confirmados. El último aspecto importante en los efectos de la compresión de cabeceras es que el tamaño de la ventana de transmisión cuando los errores se producen depende de la BER del canal.   Por lo tanto, existe un compromiso entre la BER y el tamaño de la ventana: Si la BER crece: * el “throughput” disminuye * el tamaño de la ventana es pequeño, y por lo tanto los efectos negativos de la compresión de cabeceras de Van Jacobson son menos relevantes.

Transferencia ftp con errores Finalmente, en caso de tener errores en ráfaga el uso de la compresión de cabeceras no degrada el rendimiento del protocolo, ya que al usar la compresión un error simple provoca la retransmisión de todos los segmentos de la ventana de transmisión. La figura 10 muestra los bytes retransmitidos para la transferencia de la figura 8 para errores deterministas. Puede apreciarse que a medida que la BER aumenta, la BER efectiva es menor en el caso de tener compresión (el número de bytes retransmitidos es inferior o se mantiene). Esto es debido a que pueden existir varios errores en la misma ventana de transmisión, y con solamente uno ya se provoca la retransmisión de toda la ventana.

Transferencia ftp con errores

INFLUENCIA DEL TAMAÑO DE PAQUETE TCP

INFLUENCIA DEL TAMAÑO DE PAQUETE TCP Sin errores (canal ideal), el “throughput” incrementa a medida que la MTU también lo hace. Éste es el “throughput” máximo que puede alcanzarse para la conexión. Además, el “throughput” disminuye al incrementar la BER, independientemente de la MTU, ya que el número de retransmisiones es más importante y hay más pausas en la comunicación y además son de más larga duración. También, a medida que la MTU se incrementa, el RTO crece ya que el tiempo de transmisión de los segmentos así lo hace también.

INFLUENCIA DEL TAMAÑO DE PAQUETE TCP

CONCLUSIONES El protocolo TCP/IP al operar sobre redes móviles sufre degradaciones significantes del rendimiento debido a las altas tasas de error. Las causas principales son los objetivos de diseño del protocolo, que están orientados a solucionar las situaciones de congestión de las redes fijas. Cuando se producen errores, el TCP reacciona contra ellos frenado la inyección de tráfico a la red. Esta reacción es apropiada en redes fijas, pero no en redes móviles, ya que la conexión se mantiene inactiva durante periodos de tiempo (pausa en la comunicación), esperando que la supuesta congestión desaparezca, evitando la recuperación rápida de la transmisión.

CONCLUSIONES Además, los valores de RTO son críticos ya que ellos determinan la duración de las pausa en la comunicación debidas a los errores. Esto es especialmente evidente en redes móviles de área extendida en la que los valores de RTO son altos debido al entrelazado y a las bajas velocidades de transmisión.

CONCLUSIONES La utilización de un método de compresión de cabeceras TCP/IP podría tener efectos positivos para comunicaciones a través del canal móvil. La reducción en el tamaño del paquete Reduce el tiempo de respuesta de las aplicaciones interactivas Reduce la probabilidad de error de paquete Incrementa la eficiencia del ancho de banda disponible

CONCLUSIONES Como consecuencia de lo anterior, incorporamos el algoritmo de compresión de cabeceras con el objetivo de determinar sus efectos sobre este tipo de entornos. Los resultados obtenidos muestran que la implementación actual del algoritmo no está recomendada para canales con alta tasa de error en bit, ya que cada error provoca la retransmisión de todos los segmentos de la ventana de transmisión del TCP. Además, el tamaño de la ventana de transmisión en el momento en que se producen errores determina el “throughput” de la conexión. Deben estudiarse tanto el tiempo requerido para detectar cada error como el tiempo que el TCP tarda en recuperarse de las pérdidas (retransmitiendo los segmentos afectados).

CONCLUSIONES El estudio del tamaño del segmento TCP concluye con el hecho de que su valor es determinante para la eficiencia del TCP. El tamaño de segmento que resulta ser óptimo sobre enlaces móviles depende principalmente de tres factores: La relación entre los datos útiles y los de control El ancho de banda necesario para las retransmisiones Las pausas en la comunicación para la recuperación de los errores