TCP sobre enlaces wireless Problemas y algunas posibles soluciones existentes

Transcripción

1 TCP sobre enlaces wireless Problemas y algunas posibles soluciones existentes Federico Rodríguez Teja rodrigue@fing.edu.uy Leonardo Vidal LeonardoVidal@adinet.com.uy Facultad de Ingeniería Universidad de la República Leonardo Alves lalves@adinet.com.uy Resumen El presente trabajo parte de una descripción general del protocolo TCP (Transmission Control Protocol) para proseguir con una descripción de aquellas implementaciones más extendidas indicando ventajas y desventajas de cada una de ellas. Posteriormente aborda los problemas a los que habrá que enfrentarse al implementar TCP sobre enlaces wireless y describe algunas de las posibles soluciones existentes brindando un mayor detalle de aquella que surge como la más adecuada. Para terminar, presenta algunas simulaciones realizadas que buscan determinar el comportamiento de algunos sabores de TCP. Palabras claves: TCP, wireless. 1. Introducción TCP [1, 2] es el protocolo de capa de Transporte más ampliamente utilizado en las redes de datos actuales. Brinda entrega confiable y ordenada de los datos, control de flujo y control de congestión, prestaciones que no posee IP [3] y que son requeridas por innumerables aplicaciones. TCP ofrece un servicio orientado a conexión, conociéndose al procedimiento de establecimiento de la conexión como three-way handshake. La entrega confiable se sustenta en el uso de un método de ARQ (Automatic Repeat request) con acknowledgments (ACKs) positivos, permitiéndose el envío de menos de un ACK por cada segmento de datos recibido, lo cual se conoce como delayed-ack [4]. Esto permite aumentar la eficiencia, tanto de la red como de los hosts. Por otro lado el protocolo habilita a que el ACK pueda ser enviado cuando existan datos que deban viajar en sentido inverso (técnica conocida como piggybacking) no permitiéndose una espera mayor a 500 ms. [2]. A los efectos de controlar la congestión, TCP plantea regular el tráfico generado en ambos extremos de la conexión [5]. Para ello, cada host utiliza como sensores del estado de la red, la pérdida de uno o más segmentos o la recepción de ACKs duplicados e infiere a partir de ello la congestión en la red, disminuyendo (en base a diferentes algoritmos como veremos más adelante) la cantidad de segmentos inyectados a la misma. El supuesto al que se asocia la pérdida de segmentos, es que la conexión TCP atraviesa una red congestionada, es aceptable en los enlaces cableados donde la tasa de error es mínima (del orden de 1x10-12 en el caso de enlaces de fibra óptica y 1x10-9 en el caso de UTP Cat.5), pero no se puede extender al caso de enlaces con tasas de errores mayores, del orden de 1x10-6 o peores (por ejemplo wireless), donde la probabilidad de pérdida de un segmento debido a problemas en el medio físico deja de ser despreciable. Los métodos propuestos para el control de congestión en una red se pueden agrupar en dos categorías en base a su forma de trabajo, congestion control (mecanismo reactivo) que buscan restituir la normalidad en los enlaces cuando se detecta congestión, y congestion avoidance (mecanismo proactivo) que buscan no llegar a una situación de congestión [6]. TCP implementa para su operación diferentes timers: retransmission, persist, keepalive, etc. Veremos en detalle el primero de ellos, conocido como RTT (retransmission timer) [24]. Con este timer se busca asegurar la entrega de datos frente al hecho de no tener ninguna realimentación desde el receptor de los datos. El RTO (retransmission timeout) es la duración de este timer. Un segmento no debe ser retransmitido hasta RTO después de su transmisión previa. La administración del RTT debería ser la siguiente: cada vez que se envía un segmento conteniendo datos, si no está corriendo se debe lanzar el timer; cuando todos los datos que salieron son ACKed, se debería apagar y cuando se recibe un ACK por nuevos datos se debería inicializar. La modificación de la ventana de congestión se realiza en función el valor del RTT, lo que puede considerarse Trabajo correspondiente el curso de Posgrado y Actualización Evaluación de performance en Redes de Telecomunicaciones,Instituto de Ingeniería Eléctrica, Facultad de Ingeniería, Universidad de la República, Marzo 2004

2 perjudicial en casos que este valor sea alto, haciendo más lenta la reacción del protocolo. El resto del documento se organiza de la siguiente forma: en la próxima parte describiremos algunos algoritmos de TCP que actuando de forma combinada buscan controlar la congestión; luego describiremos las diferentes implementaciones o sabores de TCP existentes; más adelante profundizaremos en los problemas de TCP en enlaces wireless para finalmente aportar algunas simulaciones y conclusiones respecto del impacto sobre la QoS, de tener una conexión TCP sobre enlaces wireless. 2. Control de Congestión de TCP El método utilizado por TCP para control de la congestión es el basado en la regulación del tráfico inyectado a la red. Esto supone que implementa funciones que le permiten estudiar cuándo es posible enviar más tráfico por el enlace, y cuándo se ha superado la capacidad del mismo y se debe disminuir la carga. TCP emplea 4 algoritmos relacionados entre sí a los efectos de efectuar el control de congestión [2, 5, 7, 8]. Ellos son conocidos con slow start, congestion avoidance, fast retransmit y fast recovery. Los algoritmos slow start y congestion avoidance, deben ser utilizados por la fuente TCP a los efectos de controlar la cantidad de tráfico inyectado en la red [2]. Para esto se cuenta con tres variables de estado del protocolo. Estas son cwnd (congestion window), que controla del lado de la fuente la cantidad de datos que se puede enviar sin haber recibido un ACK, rwnd (receiver s advertised window) que indica la cantidad de datos que puede recibir el destino y ssthresh (slow start threshold) que indica en que fase de control de congestión se encuentra el transmisor (slow start si es mayor que cwnd o congestion avoidance si es menor; de ser iguales, se puede utilizar cualquiera de los dos algoritmos). El mínimo de cwnd y rwnd gobierna la transmisión. El algoritmo slow start es utilizado al comienzo de una transmisión a los efectos de que TCP pueda testear la red y conocer su capacidad evitando congestionarla. También es utilizado en el momento de recuperación ante la pérdida de algún segmento, indicada por timeout. Luego del three-way handshake, el tamaño de la ventana inicial de envío (IW: initial window) debe ser menor o igual que 2 x SMSS 1 bytes y no mayor a dos segmentos. El valor de 1 SMSS (Sender Maximum Segment Size) es el tamaño máximo de segmento que la fuente puede transmitir y el cual se puede deducir del MTU (Maximum Transmit Unit), del Path MTU Discovery [9], a partir ssthresh debería ser lo más alto posible al comienzo (por ejemplo, igual a rwnd) y deberá reducirse en caso de congestión. Durante la fase slow start se aumenta cwnd en a lo sumo SMSS bytes por cada ACK recibido de datos nuevos entregados al receptor. Esta fase culmina cuando cwnd alcanza a ssthresh o cuando se detecta congestión. A partir de allí se inicia la fase de congestion avoidance donde cwnd se incrementa en un segmento por round-trip time (tiempo que transcurre entre que sale un segmento y llega el ACK asociado). Esta fase continua hasta que se alcanza la congestión nuevamente. Durante la fase de congestion avoindance, la actualización de la variable cwnd, se realiza con la siguiente fórmula: cwnd = cwnd + SMSS x SMSS / cwnd (1) calculándose cada vez que llega un ACK no duplicado. Cuando el transmisor detecta la pérdida de un segmento, a partir del timer de retransmisión, el valor de ssthresh debe pasar a ser: ssthresh = max (FS / 2, 2 x SMSS) (2) siendo FS (Flight Size) la cantidad de datos enviados pero aún no reconocidos o ACKed. Al mismo tiempo, cwnd no puede ser mayor que LW (Loss Window) que vale 1 segmento y sin importar el valor de IW. Se identifica con LW al tamaño de cwnd luego de detectar, a través del timer de retransmisión, una pérdida. Posteriormente se pasa a la fase de slow start hasta alcanzar el ssthresh y luego se seguirá con la fase congestion avoidance. Cuando se detecta la primera pérdida en una ventana de datos, mientras no se reparen todos los segmentos de dicha ventana, la cantidad de segmentos transmitidos en cada RTT no podrá ser mayor a la mitad de los segmentos salientes cuando la pérdida fue detectada. Luego que todos los segmentos fueran exitosamente retransmitidos, cwnd no podrá tomar un valor mayor a ssthresh y la fase siguiente será congestion avoidance. Pérdidas en dos ventanas de datos sucesivas o en retransmisiones indica congestión e implica que cwnd y ssthresh deben bajar dos veces. El receptor TCP debería enviar inmediatamente un ACK duplicado si recibe un segmento fuera de orden. Con ello busca informar al transmisor el número de del tamaño máximo aceptado por el receptor (RMSS: Receiver Maximum Segment Size) o en su defecto valdrá 536 bytes [2].

3 secuencia esperado. Las conclusiones a las que puede arribar el transmisor ante la llegada de ACK duplicados pueden ser varias. Primero, puede concluir que está ante la presencia de segmentos descartados; segundo, que por razones de tránsito en la red, los segmentos están llegando en desorden al receptor y tercero, que ocurre por duplicación de los segmentos o de los ACKs en la propia red. El receptor también debería enviar inmediatamente un ACK para aquel segmento que recibe y que se encuentra en el hueco del espacio de número de secuencia esperado de forma de colaborar con el transmisor [10]. El algoritmo fast retransmit debería ser utilizado para detectar y reparar pérdidas basado en la recepción de ACK duplicados. El algoritmo emplea la recepción de 3 ACK duplicados (4 ACKs idénticos) para concluir que un segmento se ha perdido. El transmisor envía el segmento que deduce se ha perdido sin esperar que expire el timer de retransmisión, sstresh toma el valor dado por la ecuación (2) y cwnd toma un valor dado por la ecuación: cwnd = ssthresh + 3 x SMSS (3) (lo que se conoce como inflado artificial de cwnd). Esto hace crecer cwnd en la cantidad de segmentos (ACK en este caso) que abandonaron la red. Un criterio similar seguirá por cada ACK duplicado recibido. Luego de ello, el algoritmo fast recovery gobierna la transmisión mientras no se reciban nuevos ACK duplicados. De ser posible (según los valores de cwnd y rwnd), se transmite un nuevo segmento y ante la llegada de un ACK de datos nuevos lleva el valor de cwnd al de ssthresh (lo que se conoce como desinflado de cwnd). El no pasar a la fase de slow start ante la pérdida del segmento se justifica en el hecho de que la llegada de ACK duplicado implica que quien lo envió recibió un segmento, por lo tanto, hay segmentos que están abandonando la red y por lo tanto dejan de consumir recursos en ella. Estos algoritmos no se comportan adecuadamente ante pérdidas múltiples en un single flight de segmentos [11] lo que motivó el desarrollo de un conjunto de implementaciones adicionales [10]. Para calcular el RTO actual, el transmisor mantiene 2 variables de estado llamadas SRTT (smothed round-trip time) y RTTVAR (round-trip time variation). Mientras no se calcule un RTT, el mismo debe valer como máximo 3 segundos. Cuando se calcula el primer RTT (R), las variables tomarán los siguientes valores: SRTT = R RTTVAR = R/2 RTO = SRTT + max (G, K x RTTVAR) donde K = 4 y G es la granularidad del reloj, medida en segundos. Para el siguiente cálculo de RTT (R') los nuevos valores de las variables serán: RTTVAR = (1 - β) x RTTVAR + β x SRTT - R' SRTT = (1 - α) x SRTT + α x R' donde los valores de α y β deberían ser 1/8 y 1/4 respectivamente. RTO = SRTT + max (G, K x RTTVAR) RTO no debería ser menor que 1 ni mayor que 60 segundos. La toma de las muestras RTT se debe realizar utilizando el algoritmo de Karn. Ello implica que no debe hacerse utilizando segmentos retransmitidos (salvo que se utilice la opción timestamp) y que en caso de expirar, se debería retransmitir el primer segmento no ACKed y efectuar un backoff, pasando RTO a valer el doble y lanzarlo nuevamente. Se debe realizar como mínimo una medida por round-trip time de forma de evitar el efecto de aliasing 2 [17] en el cálculo de RTO para el caso de ventanas de congestión grandes. 3. Implementaciones de TCP existentes TCP se basa en distintas implementaciones que se encuentran disponibles en los distintos sistemas operativos más que en una única especificación. A continuación presentaremos diferentes sabores de TCP implementados y testeados con cierta rigurosidad al momento de escribir este documento [6], a saber: Tahoe, Reno, New Reno, SACK, Net Reno y Vegas. 3.1 TCP Tahoe Surge en el año 1988 a iniciativa de V. Jacobson, y se conoce también por el nombre de BSD Network Release 1.0 (BNR1). Cuenta con los algoritmos slow start, congestion avoidance con un cálculo de round-trip time mejorado [7] respecto al criterio de cálculo original. Se le agregó posteriormente un proceso de fast retransmit. El sistema busca llegar a un estado de equilibrio basado en el principio de conservación de los paquetes en los enlaces, donde se establece que se envía un paquete 2 La estimación del RTT es un problema de procesamiento de señales donde el muestreo de la señal es menor que la rate de la misma por lo que es esperable que debamos convivir con cierto aliasing, mayor cuanto más grande sea la ventana.

4 a la red cada vez que verifica que un paquete ha abandonado la red. Se llega al estado de equilibrio por medio de pruebas que permiten inferir el ancho de banda disponible, y ajustando en función de ello el tamaño de cwnd. La mayor desventaja de esta implementación, es que cada vez que se pierde un segmento, se inicia nuevamente la etapa de slow start, la que tarda mucho tiempo para llegar a tasas de transmisión aceptables. 3.2 TCP Reno Surge en el año 1990 e inicialmente se implementó sobre el sistema operativo BSD. Se conoce también por el nombre de BSD Network Release 2.0 (BNR2). Es la versión más utilizada en nuestros días. La diferencia fundamental existente entre esta versión y la anterior es que cuando se detecta congestión, Tahoe modifica la variable cwnd llevándola a un segmento lo que implica ir a la fase de slow start, mientras que Reno la hace valer ssthresh quedando en la etapa de congestion avoidance implementando así un algoritmo de fast recovery. Esto permite que se recupere más rápidamente de congestión y errores en la red [12]. Está versión [17] además agrega Header prediction, que optimiza el protocolo basado en la afirmación que es más fácil para un host responder es este segmento el siguiente en la secuencia? que está este segmento dentro de la ventana?, y delayed acknowledgments, que realiza un ACK de un grupo de segmentos recibidos, en lugar de realizarlo para cada uno. La ventaja más destacable es el hecho de no pasar a la fase de slow start, cada vez que se produce la pérdida de un segmento, haciendo más recomendable en los enlaces de banda ancha. 3.3 TCP New Reno La mejora realizada en el TCP Reno, implica mejoras en pérdidas de segmentos aislados, pero no tiene ventajas en caso de pérdidas en sucesivos segmentos. Estas pérdidas son comunes en enlaces de alta velocidad, donde la pérdida en general contiene varios segmentos. La figura a continuación [6] muestra la pérdida de tres segmentos consecutivos y sus consecuencias; como puede verse, se pasa a la etapa de slow start: Si la opción SACK está permitida, el transmisor tiene la información necesaria para tomar decisiones inteligentes sobre las retransmisiones a realizar durante la fase de fast recovery. TCP New Reno, para el caso en que no se pueda utilizar SACK, implementa una modificación del algoritmo de fast recovery [10], que comienza al recibirse 3 ACK duplicados, almacenando en una variable recover el número de secuencia más alto transmitido, y en caso de recibirse ACK de todos los datos que salieron del transmisor incluso durante la fase de fast recovery o de darse un timeout en la retransmisión, pasa a la fase de congestion avoidance. Para comenzar una fase fast recovery no debe estarse en una fase fast recovery. Luego de la recepción de los tres ACK duplicados ssthresh toma el valor dado por la ecuación (2). Luego retransmite el segmento perdido y cwnd toma el valor dado por la ecuación (3). Un criterio similar seguirá por cada ACK duplicado recibido. De ser posible (según los valores de cwnd y rwnd), transmite un nuevo segmento. Ante la llegada de un ACK, puede suceder que sea un ACK a todos los datos, incluido el recover, lo que implica un reconocimiento de todos los segmentos enviados entre el que se perdió y la recepción del tercer ACK duplicado. Aquí cwnd puede tomar dos valores: cwnd = min (ssthresh, FS + SMSS) o cwnd = ssthresh (valor tomado al comienzo de la fase de fast recovery) (esto implica un desinflado de ventana ) Luego de esto se sale de la fase de fast recovery. Si el ACK no cubre todos los datos incluido el recover, se trata de un partial ACK, por lo que se retransmite el primer segmento no reconocido (uno solo) y se realiza un desinflado de ventana parcial que contemple los segmentos reconocidos y de forma que

5 cuando se salga del fast recovery aproximadamente sshthresh datos hayan abandonado la red. El transmisor sigue en la fase de fast recovery. Es posible aplicar técnicas más agresivas de retransmisión ante la llegada de un ACK parcial que impliquen la retransmisión de más de un segmento lo que podría ocasionar que se retransmitan segmentos innecesariamente. Podemos considerar dos variantes del New Reno, Impatient y Slow-but-Steady. En la primera, sólo se pone a cero el RTT luego del primer ACK parcial y de haber varios segmentos perdidos en la misma ventana, luego de vencido el timer se comienza la fase slow start [13]. En la segunda, se pone a cero el RTT luego de cada ACK parcial por lo que se puede retransmitir un segmento luego de cada round-trip time [14]. La ausencia de la opción SACK no permite inferir demasiada información en el momento de la recepción de un ACK duplicado. No se puede concluir cual o cuales fueron los segmentos que dispararon el duplicado, tampoco permite distinguir entre los casos en los cuales se generó debido a un paquete demorado o perdido o si se trata de un ACK a una retransmisión de un segmento que llegó a destino. Por lo tanto, pérdidas múltiples en una ventana pueden ocasionar múltiples e innecesarios fast retransmit. A los efectos de evitar múltiples fast retransmit se implementó un bugfix utilizando una nueva variable, denominada send_high que toma como valor inicial el número de secuencia de envío inicial y actualiza su valor luego de cada timeout de retransmisión al valor más alto transmitido. El transmisor puede, a través de esta variable, deducir que ha retransmitido segmentos innecesariamente de forma que no lo interprete como congestión. Cuando el transmisor recibe 3 ACK duplicados y no se encuentra en la fase fast recovery, chequea si esos ACK comprenden al send_high, de ser así, el ssthresh toma el valor dado por la ecuación (2), almacena el número de secuencia más alto transmitido en la variable recover y le da a cwnd el valor dado por la ecuación (3). En caso contrario, no realiza acción alguna. A pesar de que TCP New Reno es capaz de manejar múltiples pérdidas en una ventana, tiene la limitación de permitir solamente el envío de un segmento por roundtrip time. Esto no es muy aceptable en casos en que tanto el delay como el ancho de banda se incrementan. 3.4 TCP Selective ACK (SACK) La pérdida de múltiples segmentos de una ventana de datos puede ser catastrófica para el throughput de TCP. El uso del mecanismo denominado ACK acumulativo 3 ocasiona que el transmisor tome dos caminos, o espere un RTT para saber de segmentos perdidos o realice retransmisiones innecesarias que implicarán múltiples descartes. La opción SACK puede ayudar a sobrellevar estos inconvenientes. TCP SACK [15, 16] brinda un mecanismo para proporcionar más información sobre los segmentos que han sido recibidos correctamente y el transmisor puede conocer cuales son los segmentos que se han perdido. SACK es un campo opcional en el encabezado TCP, que es enviado cuando se reciben datos fuera de secuencia. Esta opción contiene una lista de los bloques contiguos y aislados de datos recibidos y guardados en cola, con la información necesaria para identificarlos (números de secuencia de 32 bits que ofician de bordes en los bloques). Por la definición del encabezado de TCP, no es posible especificar más de tres bloques. De esta forma el extremo transmisor consigue la información de los subsecuentes bloques no recibidos por el destinatario. Puede resultar conveniente el uso de esta técnica en conjunción con la técnica de Round Trip Time Measurement (RTTM) basada en timestamps [17] de forma de obtener más información sobre segmentos perdidos. La extensión SACK hace uso de dos opciones de TCP. La primera, SACK-permitted, está asociada a la habilitación de la opción SACK y se envía como 2 bytes y solamente en el segmento SYN. La segunda, es la opción en si misma. Que el transmisor haya enviado la opción SACKpermitted en el segmento SYN no implica que el receptor deba utilizarla al recibir bloques discontiguos. No debe usarlo si no lo recibió previamente en el momento del three-way handshake. De utilizarse, debería hacerlo mientras no se envía el ACK del número de secuencia más alto de los datos que están en su cola. Quien recibe el ACK con la opción de SACK debe almacenar esta información. Se asume que el transmisor tiene almacenados de forma ordenada los segmentos que necesitará transmitir. Una posible implementación es que cada segmento almacenado en el transmisor tenga asociada una flag SACKed que indique si dicho segmento ha sido incluido en la opción SACK. Los segmentos que 3 Los segmentos recibidos que no estén en el borde izquierdo de la ventana de recepción no serán reconocidos.

6 tengan dicha flag encendida escaparán a la retransmisión. Lo mismo ocurrirá con aquellos segmentos con número de secuencia mayor al máximo SACKed. Luego de un timeout de retransmisión, se deberían apagar todas las flags, y se debe retransmitir el segmento más a la izquierda de la ventana. De esta forma se maneja la información para el envío completando los bloques que faltan en la transmisión, y marca los bloques como retransmitidos. Si un bloque retransmitido se pierde entonces pasa a la fase de slow start. TCP SACK mejora TCP New Reno, ya que permite el manejo de segmentos perdidos en una misma ventana, en una forma más eficiente, permitiendo su retransmisión en un solo round-trip time. En el caso de TCP New Reno, el protocolo se enterará de los segmentos perdidos a medida que reciba los que le preceden. 3.5 TCP Net Reno (Network-sensitive Reno) El TCP Net Reno [18] es una mejora al protocolo TCP New Reno. Se buscó un conjunto de optimizaciones de TCP de forma de hacerlo más sensible a la red que mejore su performance, reduciendo los timeouts por retransmisión. En TCP Net Reno, un segmento es enviado para cada ACK duplicado recibido, antes que se dispare la fase de fast retransmit. Busca ser una mejora en el caso de ventanas de congestión pequeñas [25]. Supongamos que cwnd vale 3, si uno de los segmentos es descartado en la red, a lo sumo 2 ACK duplicados arribarán al transmisor (recordar que estos son generados cuando llegan segmentos fuera de orden), por lo tanto no se disparará la fase fast retransmit y el segmento perdido sólo se enviará nuevamente por timeout. Para ello se propone el algoritmo Limited Transmit. Este permite al transmisor, luego de recibir 2 ACK duplicados consecutivos, a enviar hasta 2 segmentos más allá de lo indicado por cwnd y en caso que rwnd lo permita. El tamaño de cwnd no debe cambiar. Este algoritmo respeta la conservación de los paquetes y puede ser el que motive el tercer ACK duplicado lo que hará que se inicie la fase fast retransmit. 3.6 TCP Vegas TCP Vegas [19] tiene grandes cambios en comparación con las primeras versiones de TCP. Utiliza tres técnicas para mejorar el throughput, y tratar de evitar la pérdida de segmentos. La primer mejora es en el algoritmo de estimación del round-trip time, a partir de registrar el momento de envío de cada segmento y el momento de recibir cada ACK. A partir de esto, si recibe un ACK y la diferencia de tiempos con su segmento correspondiente es mayor al timeout, se retransmite sin esperar a tener los 3 ACK duplicados. Cuando recibe un ACK no duplicado, si es el primero o segundo luego de una retransmisión, calcula el tiempo que hace que envió el tercer segmento en cuestión y de ser mayor que el round-trip time lo envía nuevamente. En segundo lugar TCP Vegas busca ser proactivo frente a la congestión y no reactivo como lo es Reno, que espera la pérdida de segmentos a los efectos de determinar el ancho de banda disponible en la red. Para ello calcula el throughput en la red, y la compara con el throughput esperado. Ello le permite determinar el flujo de datos extra que puede transitar por la red y calcular cual es el adecuado de forma de evitar llegar a la congestión. Esta es la fase congestion avoidance. Finalmente, la tercer técnica, busca evitar la congestión en la fase slow-start. Realiza crecimientos exponenciales de cwnd cada round-trip time alternados; entre ellos cwnd queda fija. Si la tasa de envíos lograda es menor que la esperada, durante un cierto lapso, se pasa a un modo de crecimiento lineal y no exponencial. 4. Problemas existentes en TCP sobre enlaces wireless En la presente sección, presentaremos algunos de los problemas existentes en la implementación de conexiones TCP sobre enlaces wireless. Los problemas existentes se basan en la incapacidad de TCP de discriminar cuándo la performance de la conexión ha disminuido debido a pérdidas en el enlace, común en las tecnologías wireless, y cuándo es debida a congestión en la red. El problema radica en que el transmisor no puede determinar con cierto grado de certeza qué ha motivado la pérdida de un segmento. Cuatro aspectos inherentes a redes wireless pueden afectar decisivamente la performance de TCP [46]. Por un lado, la bit error rate (BER) del medio físico, que como ya mencionamos, puede ser del orden de 1x10-6 o peor. En segundo lugar debemos considerar que el ancho de banda disponible es en general menor al disponible en medio cableados. Una tercer componente es la posible movilidad de los componentes de la red lo que puede implicar cambios importantes en los tiempos de entrega de los segmentos. Finalmente, es común que el protocolo de capa de Enlace y en particular de la sub-capa MAC así

7 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. A los efectos de fijar ideas podemos considerar como ejemplo de protocolo de sub-capa MAC a la familia de estándares de IEEE para Wireless Local Area Network (WLAN) [26, 27, 28, 29, 30]. En ellos se especifica que para el envío de cada trama de datos en el modo de operación Distributed Coordination Function (DCF) se emplee un método de control de acceso al medio denominado carrier sense multiple access with collision avoidance (CSMA/CA), protocolo que busca reducir la probabilidad de colisiones entre múltiples estaciones a través del evitado de las mismas. A los efectos de detectar portadora, además del mecanismo clásico de escucha del medio (detección física de portadora) se realiza una detección virtual de portadora utilizando four-way handshake, donde con dos tramas de control (RTS: Request To Send y CTS: Clear To Send) se reserva el medio, luego se envía la trama conteniendo los datos y posteriormente se espera una trama de control ACK que confirma su recepción. Lo anterior es una muestra clara del overhead involucrado, pero hasta aquí no hemos considerado la movilidad de las estaciones. Durante la misma, una estación móvil puede estar asociada a una estación base (BS) a través de la cual recibe las tramas que provienen por ejemplo de la red cableada y unos milisegundos después, deberá estar asociada a otra estación base a la cual la primera deberá enviar las tramas que tuviera almacenadas para dicha estación. 4.1 Propuestas de mejora al TCP existente sobre enlaces wireless Se puede afirmar que una propuesta de mejora al TCP existente, sobre enlaces wireless, debe reunir el siguiente conjunto de características deseables [31]: 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, si está al principio será un enlace first-hop, si está al final será last-hop y también puede estar en algún lugar intermedio, como se da por ejemplo en el caso de enlaces satelitales. 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. En el caso que las acciones sean tomadas por la capa de Transporte, se deberán hacer modificaciones en el código del TCP existente, lo cual puede llegar a ser un inconveniente. En contraposición a lo anterior, cabe señalar que algunas implementaciones contienen otro conjunto de características que no son deseables para nuestro caso de estudio y que corresponde hacer una descripción de las mismas para poder entender el motivo por el cual no son tenidas en cuenta en el presente análisis: Split (Indirect-TCP) [32]: cuando el camino completo de la conexión es dividido en una conexión cableada y una wireless y se corre TCP en forma independiente en cada conexión. Cuando la transmisión de un segmento se completa en una conexión, se le envía un ACK a la fuente y se transmite a la otra conexión. Podemos señalar como principales desventajas de esta implementación las siguientes: los ACKs recibidos por la fuente no significan que los segmentos hallan sido recibidos por el supuesto destinatario, la transmisión de datos no es confiable y por último, al correr TCP en forma independiente en ambas conexiones y a diferentes ritmos, el buffer de la BS puede incurrir en overflow. Global: si implementa cambios fuera de la red wireless. One-Way: si está diseñada preferentemente para el tráfico en una dirección. Last-Hop: si el algoritmo asume que el enlace wireless esta ubicado en el extremo final de la conexión TCP. Snooping: si se necesita leer en algún nodo intermedio información del encabezado TCP. Hiding: si presupone que existe un servicio de capa de enlace confiable y que sus protocolos de retransmisión resuelven el problema de la pérdida de tramas, ocultando el carácter lossy del enlace, hacia las capas superiores. La principal desventaja de las mejoras que usan esta

8 característica es que, no obstante se oculten las posibles pérdidas, pueden llegar a existir retransmisiones en ambas capas, capa de enlace y de transporte tratando de responder a los mismos eventos de pérdidas, causando interacciones muy indeseables [39,40,41,42,43,44]. En la siguiente tabla, se realiza un sumario de las principales propuestas de mejora existentes en la literatura. End-to-end Local Two-way Int.- Link Transparent Signaling Retransm. Prot I-TCP Partial ACK + + Control Connection Snoop ELN DDA CC Nota: Snoop y ELN fueron primero propuestas como soluciones One- Way, pero ellas pueden ser combinadas para brindar una solución Two- Way. Como puede observarse, la única propuesta que reúne todas las características deseables, es la última, Congestion Coherence (CC). A continuación se realiza una descripción funcional de algunas de las propuestas existentes haciendo particular hincapié en CC. En esta descripción no se exponen los protocolos I-TCP, Partial Acknowledgment y Control Connection porque no son protocolos end-to-end o local [31] Snoop El protocolo Snoop introduce un módulo en la BS, conocido como snoop agent, que memoriza y compara los segmentos de datos y los ACKs intercambiados con las estaciones móviles [33, 34]. De la comparación resultante, es capaz de determinar, que segmentos se perdieron en el enlace wireless y agenda una retransmisión local a nivel de capa de Enlace. A la vez, ACKs duplicados correspondientes a pérdidas wireless 4 son suprimidos para evitar disparar una retransmisión end-to-end desde el transmisor. A diferencia de otras propuestas, este protocolo busca descubrir la causa de la pérdida de los segmentos y tomar las acciones que considere pertinentes para prevenir reducciones innecesarias de la ventana de congestión del transmisor TCP Explicit Loss Notification (ELN) Este protocolo [35] busca mejorar de la performance de TCP, cuando la estación móvil es el transmisor TCP. Mediante él, se informa al transmisor TCP que ha ocurrido una pérdida debida a errores en el enlace wireless, de modo de excluir del control de congestión las retransmisiones desde el transmisor. Cuando el receptor o BS, reconoce que ha ocurrido una pérdida wireless, y lo informa al transmisor usando el bit ELN en el encabezado TCP 5. Para este protocolo, también es necesario la instalación de un snoop agent corriendo en la BS, que analiza todos los segmentos TCP que arriban a través del enlace wireless. Sin embargo, no los almacena ya que no realiza retransmisión alguna. ELN confecciona una lista de los huecos producidos en el espacio de secuencia. Para evitar, confundir un hueco producido por congestión en la BS con un hueco producido por una pérdida wireless, agrega un hueco a la lista cuando la cantidad de segmentos encolados en la interfaz de entrada de la BS, no es cercana al tamaño máximo de cola. Cuando arriban desde el receptor ACKs, especialmente ACKs duplicados, el agente en la BS consulta la lista de huecos y marca el bit ELN en el ACK, si corresponde a un segmento de la lista, antes de enviarlo hacia el transmisor. También actualiza la lista, borrando todos los huecos con número de secuencia menor al ACK actual ya que ellos corresponden a segmentos que han sido exitosamente recibidos. Cuando el transmisor advierte que le ha llegado un ACK con el bit ELN marcado, retransmite el segmento perdido y actualiza una variable llamada, eln_last_rxmit, que contiene información de cual fue la última retransmisión, pero no toma acción alguna de control de congestión. El transmisor, de esta forma se asegura de que cada segmento sea retransmitido a lo sumo una vez durante un round-trip time y no con cada ACK con ELN que reciba desde la BS Delayed Duplicate Acknowledgments (DDA) 4 Llamaremos a las pérdidas de paquetes causadas por errores de transmision en un medio wireless pérdidas wireless y a aquellas causadas por congestión en la red pérdidas por congestión. 5 Aún no está especificado el bit del encabezado TCP destinado a ELN.

9 Pensando en una futura retransmisión, DDA retarda el tercer ACK duplicado, asumiendo que se trata de una pérdida wireless y está siendo retransmitido [36]. En el caso de que dicho segmento no llegue luego de un cierto periodo, el receptor libera el ACK duplicado demorado para así disparar una retransmisión end-to-end. Requiere de modificaciones en la estación móvil y no distingue entre pérdida wireless y pérdida por congestión Explicit Congestion Notification (ECN) Existen en Internet algunos mecanismos (como RED: Random Early Detection [20]) donde se realiza la notificación de una congestión incipiente en lugar de descartar los paquetes. Esta implementación busca indicarlo utilizando para ello un campo de dos bits del encabezado IP denominado ECN [21], y compuesto por dos flags conocidas como ECT y CE 6. Cuando ambos puntas del protocolo de transporte son ECN-capable ello se indica por los códigos 10 y 01 que se identifican como ECN-Capable Transport (ECT), ECT(0) y ECT(1) respectivamente. Dichos valores son equivalentes y se pueden utilizar indistintamente incluso en una misma comunicación. El código 00 ( Not-ECT ) indica que se trata de un paquete que no está usando ECN y finalmente el código 11 es utilizado por los routers para indicar a ambos extremos de la conexión que se está experimentando una congestión incipiente. Debería indicarlo si, hubiera descartado el paquete en caso de no ser ECN-capable. Previo a realizarlo, debe confirmar que ambos extremos también son ECN-capable. Se estima que el descarte no debería ser necesario en una red full ECN-capable pero que seguirán existiendo en la transición a ella. Es conveniente que los routers no utilicen la información del tamaño instantáneo de la cola para informar de congestión a través del código 11. Los extremos de transporte deben reaccionar ante la presencia de congestión utilizando los mismos algoritmos de congestión que en caso de descarte de segmentos. El motivo de esto es que ECN se está incorporando gradualmente a las redes actuales. Algunos routers y equipos terminales aún no implementan ECN y esta medida ayuda a extender y uniformizar su utilización. Por otro lado, resulta conveniente que los extremos reaccionen ante esta información pero una sola vez por round-trip time. 6 El campo ECN está compuesto por los bits 6 y 7 del octeto TOS de IPv4 [22, 23], el cual se corresponde con el octeto Traffic Class de IPv6 [45]. En la fragmentación y reensamblado, se debe respetar la información sobre ECN que contengan los fragmentos, bastando que uno de los fragmentos traiga información de congestión para que se reconstruya el paquete con el código que trae dicho fragmento, salvo en caso que algún fragmento indique Not-ECT. En el caso concreto de TCP, tres nuevas funcionalidades son requeridas para que se soporte ECN: negociación durante el establecimiento de la conexión a los efectos de determinar si ambos extremos son ECNcapable, una flag ECN-Echo en el encabezado TCP a los efectos de que el receptor indique al transmisor que ha recibido un paquete con información de ECN y finalmente, una segunda flag Congestion Window Reduced (CWR) utilizada por el transmisor para indicarle al receptor que ha reducido su congestion window. Dichas flags (ECE y CWR) se representan por un bit cada una, utilizando para ello el campo Reservado de los bytes 13 y 14 del encabezado TCP y en particular, los bits más próximos a las flags ya definidas. Por lo tanto, en redes TCP/IP, ECN utiliza cuatro flags. Dos, ECT y CE, en el encabezado IP, destinadas a señalización entre routers y extremos de la conexión y dos, ECE y CWR, en el encabezado TCP, para señalización entre los extremos TCP. Ante la presencia de congestión en la red, una secuencia de eventos típica en una conexión TCP basada en ECN podría ser: a través del bit ECT de IP el transmisor indica que la entidad TCP es ECN-capable, el router que está experimentando congestión recibe estos paquetes y en lugar de descartarlos los marca a través del bit CE de IP, el receptor detecta esto y lo informa en el siguiente ACK utilizando el bit ECE de TCP, el transmisor recibe dicho ACK y reacciona como si el paquete hubiera sido descartado. Finalmente, el transmisor informa en el siguiente segmento, utilizando el bit CWR de TCP, que ha recibido el ECE y que ha actuado en consecuencia. En el momento del establecimiento de la conexión TCP, el envío de un segmento SYN con las flags ECE y CWR en 1 (segmento ECN-setup SYN ) indica que el transmisor es ECN-capable. Si el receptor responde con un segmento ACK con la flag ECE en 1 y la flag CWR en 0 (segmento ECN-setup SYN-ACK ) indicará que es ECN-capable. El receptor no debe enviarla si no recibió previamente un segmento ECN-setup SYN. El envío de segmentos ECN-setup SYN o ECN-setup SYN-ACK no obliga a que se envíen contenidos en paquetes con el bit ECT en 1. Un host no podrá enviar paquetes con el bit ECT en 1, a menos que haya enviado por lo menos un segmento ECN-setup SYN o ECN-

10 setup SYN-ACK y que haya recibido por lo menos un segmento ECN-setup SYN o ECN-setup SYN-ACK y no haya enviado algún segmento non-ecn-setup SYN-ACK o non-ecn-setup SYN-ACK. Por otro lado, los paquetes que llevan segmentos SYN o ACK no pueden llevar el bit ECT en 1. Es posible encontrar dispositivos intermedios (firewalls, intrusion detection system, etc.) que ante la llegada de un ECN-setup SYN lo descarten o devuelvan un segmento RST. Como paliativo a ello se puede optar que ante la recepción de dicho segmento se envíe un segmento SYN con las flags ECE y CWR en 0, eligiendo así no utilizar ECN. El hecho de que el segmento ECN-setup SYN-ACK lleve las flags ECE y CWR con valores 1 y 0 y no 1 1 como el segmento ECN-setup SYN que lo motivó, busca evitar potenciales deducciones falsas de ECNcapable que se podrían dar en aquellas implementaciones de TCP donde el campo Reservado del segmento SYN-ACK es simplemente una copia del recibido en el SYN. Los paquetes que contienen segmentos retransmitidos no deben llevar los códigos ECT(0) o ECT(1) y, por razones de seguridad (denial-of-service attack) el receptor debería ignorar la información ECN que contengan segmentos que están fuera de la ventana de recepción. Como mecanismo de control de congestión, ECN a demostrado ser más efectivo que el uso de segmentos perdidos para indicar el estado de congestión de la red. De esta forma se evitan dos cosas, por un lado, el descarte de segmentos y, por otro, las innecesarias retransmisiones Congestion Coherence (CC) Considera como supuesto previo que está implementado ECN 7 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 [31], 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. A continuación describiremos dos aspectos relevantes de Congestion Coherence que son, retransmisiones locales en capa de Enlace y detección de la causa de pérdida de paquetes 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 8. La máxima cantidad de retransmisiones para una trama fallida es configurable. 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 En esta sección nos tomaremos la libertad de referirnos siempre a segmentos, sin discriminar entre segmentos o paquetes, buscando una mejor comprensión del tema a costo de ser menos rigurosos en la terminología. 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, 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. 7 A pesar de que esta mejora requiere soporte ECN en todos los routers de la red cableada, se considera como local, pues ECN es un protocolo de mejora que es usado tanto en redes cableadas como wireless, de modo que vale la pena enfrentar dicho costo. 8 Cuando una trama es detectada como perdida, la capa de Enlace inserta la trama fallida en el frente de la cola de transmisión y lo trasmite cuando el medio esta disponible.

11 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. En [31] se podrá encontrar un detalle de los algoritmos de transmisión y recepción que implementan CC Comparación de Performances De la comparación resultante entre TCP básico con retransmisiones, ECN, Snoop 9, DDA y CC, se concluye [31] que la propuesta de mejora que obtiene los niveles mas elevados de performance es Congestion Coherence (CC). Algunos de los aspectos a resaltar son: CC realiza un manejo excelente de la ventana de congestión, evitando innecesarias reducciones, retransmisiones end-to-end y timeouts ya que la mayoría de las pérdidas por congestión son evitadas mediante el uso de ECN. También hace un uso muy eficiente de la cola del enlace cuello de botella manteniéndola casi siempre llena. El parámetro más interesante e importante para medir la performance de un enlace es el goodput, o en su defecto el throughput 10. El mejor goodput es el logrado por la propuesta CC, para toda packet error rate (PER) y en particular para valores altos de la misma, como son los que se registran en los enlaces wireless. 5. Escenarios de simulación Para las simulaciones realizadas se utilizó la herramienta Network Simulator ns2 [37] versión Para su visualización en sistemas operativos Windows se recurrió a la aplicación Cygwin [38]. Para el estudio se propone un modelo simple que busque sacar conclusiones sobre el problema planteado, tratando de no agregarle complejidades que pudieran modificar el objetivo inicial. El modelo de simulación propuesto presenta cinco nodos (mostrado en la figura), donde el enlace del n0-n1, será el que se caracterice tipo wireless. Se agregó un flujo UDP entre los nodos n4 y n5, a los efectos de generar jitter en el enlace n0-n1, pero buscando (empíricamente) que no genere pérdidas. 9 En el caso, en que el transmisor sea un host móvil inyectando datos sobre un enlace wireless, configuración First-hop, se ha reemplazado Snoop protocol por ELN protocol. 10 La diferencia entre el throughput y el goodput es que este último no considera las retransmisiones.

12 El estudio se realizó sobre un flujo TCP implementado entre los nodos n2 y n3 generando tráfico FTP durante 50 segundos, sobre distintos tipos de TCP: Reno, NewReno, Sack y Vegas. 5.1 Características del enlace n0-n1 (tipo wireless) Para caracterizar el enlace n0-n1 como wireless, se agregó al mismo las propiedades con que cuenta un enlace de este tipo, ya presentadas en el punto 4. A continuación se presenta la configuración realizada para el enlace mencionado Capacidad del enlace Se configuró una capacidad de 2Mb buscando una velocidad sensiblemente inferior a la de los enlaces cableados actuales Tasa de error del canal Para la simulación de un canal con una tasa de error alta, se utilizó el módulo ErrorModel de ns2, que permite generar errores en un enlace. Se define en el modelo de simulación la variable lrate, que representa la probabilidad de error en un segmento que transita por el enlace. Se seleccionó una tasa de error de 1x10-3, lo que implica un error cada mil segmentos enviados Retardo del enlace n0-n1 Se le configuró un retardo base de 30 mseg. El flujo UDP entre n4 y n5 se configuró con los siguientes parámetros: Tamaño del paquete: 500 bytes Tiempo de actividad: 90 mseg. Tiempo de inactividad: 2500 mseg. El agente UDP tiene una fuente de tráfico exponencial, empleando el agente Exponential de ns2. A continuación se presenta un gráfico que indica el flujo UDP generado Desconexiones La simulación de desconexiones se realizó a través de la inserción de retardos, lo que puede asociarse a desconexiones por un lapso pequeño. 5.2 Simulaciones realizadas Se tomó como base la red presentada anteriormente, y la experiencia realizada consistió en variar el módulo TCP del simulador, para estudiar posteriormente el comportamiento para los diferentes sabores de TCP. Los agentes de TCP utilizados y simulados en la arquitectura presentada fueron los siguientes: Reno, que implementa un TCP Reno. Newreno, que implementa un TCP NewReno. Sack1, que implementa un TCP SACK; para este caso se modificó el agente receptor del flujo, ya que la lógica del funcionamiento del SACK, busca informar al extremo origen del flujo las fallas en la recepción de información, lo que requiere lógica en el receptor. Para el receptor se utilizó Sack1. Vegas, que implementa un TCP Vegas. Exceptuando el caso del TCP SACK, para todos los demás, del lado del receptor, se utilizó un agente Sink. Para cada una de las simulaciones se registraron las siguientes variables: Cantidad total de bytes enviados. Goodput del enlace, considerando muestras de.01 seg. Tamaño de la ventana TCP, considerando muestras cada 0.01 seg. RTT del TCP, considerando muestras cada 0.01 seg. Cantidad de ACKs duplicados. 5.3 Resultados obtenidos

13 A continuación se presentan los resultados obtenidos y algunas observaciones que se desprenden de los mismos. Se agregan además los gráficos más relevantes obtenidos con la herramienta Xgraph [37] Cantidad total de bytes enviados El detalle para cada una de las implementaciones de TCP simuladas es: TCP Bytes enviados Reno New Reno SACK Vegas Nota: los resultados están redondeados a la cuarta cifra. De estos resultados se desprende que el sabor de TCP que rinde mejor en el enlace mostrado, es Vegas, mientras que el rendimiento decrece con el siguiente orden, TCP NewReno, TCP Sack, y por último TCP Reno. Se puede decir, en términos generales, que los TCP Vegas y NewReno tiene un rendimiento superior Goodput promedio El goodput de las distintas implementaciones TCP, en general, se encuentra alrededor de los 4 Kbps, y puede verse que el aumento del RTT del enlace provoca una baja en la transmisión de información. La siguiente figura muestra el comportamiento típico observado al simular las diferentes implementaciones Comparación de goodput de distintos TCP Si bien el comportamiento fue similar en todos los casos, se visualizan picos y valles que generan la diferencia entre los diferentes sabores de TCP respecto a la cantidad total de bytes enviados. A continuación se presentan los casos de TCP Vegas (el de mejor performance), y el segundo, NewReno. Como puede verse en las gráficas presentadas, el goodput promedio es similar, pero el TCP Vegas tiene picos menos pronunciados y valles menos extensos que el TCP NewReno, lo que muestra que el protocolo es más estable. TCP Vegas tiene máximos de 3500 bytes, mientras que TCP NewReno llega a tener de 8000 bytes Relación entre RTT y tamaño de ventana del TCP El tamaño de la ventana puede verse está inversamente relacionado con la duración del RTT. Esto se desprende de las gráficas obtenidas luego de la simulación. A continuación se presenta para el caso de TCP Reno, pero este síntoma se encuentra en todos los sabores de TCP probados. Se muestra el gráfico RTT y tamaño de ventana (cwnd) respectivamente.

14 Se realizó una simulación eliminando el flujo UDP que genera jitter, y se visualizó en las gráficas que la recepción de ACKs duplicados se repite en forma similar, por lo que se descartó una relación entre los mismos. Este flujo genera solamente variación en el retardo del enlace, y no se vieron consecuencias adicionales. A continuación se muestra la gráfica de ACKs duplicados recibidos en la simulación TCP Vegas Observaciones sobre el RTT en TCP Vegas El valor del tamaño de la ventana TCP (cwnd), influye directamente sobre el goodput, mejorando el mismo cuanto mayor sea la ventana cwnd. La siguiente gráfica muestra para el caso de TCP Reno. En el análisis previo de los distintos sabores de TCP (punto 3.6), se menciona que TCP Vegas mejora el calculo del RTT, lo que se traduce en una mejor performance del protocolo. Esta observación puede verificarse visualizando la gráfica de RTT en TCP Vegas y comparándola con la presentada anteriormente de TCP Reno. En la misma puede verse que al producirse una baja en el tamaño de la ventana (cwnd), disminuye el goodput Análisis interferencia del flujo UDP en la prueba 6. Conclusiones

15 TCP asocia la pérdida de segmentos a congestión en la red, lo que no siempre es válido en redes wireless. La solución a este problema requiere de implementarle mejoras al TCP de forma que tenga una buena performance en redes wireless pero sin olvidar que actualmente constituye el 85% del tráfico en Internet. De las soluciones para TCP en redes wireless, la conocida como CC (Congestion Coherence) se presenta como la más adecuada, lo cual debería ser verificado en próximos estudios que incluyan simulaciones. Según las simulaciones realizadas la implementación Vegas de TCP es, de las versiones existentes para redes wired, la que mejor se adapta a redes wireless. Basamos la afirmación anterior en el hecho de su buen cálculo del RTT. 7. Referencias [1] John Postel, RFC 793: Transmission Control Protocol, September 1981 [2] R. Braden, RFC 1122: Requirements for Internet Hosts Communications Layers, October 1989 [3] Jon Postel, RFC 791: Internet Protocol, September 1981 [4] David Clark, RFC 813: Window and Acknowledgment Strategy in TCP, Julio 1982 [5] M. Allman, V. Paxson and W. Stevens, RFC 2581: TCP Congestion Control, April 1999 [6] Chunlei Liu, Wireless Network Enhancement Using Congestion Coherence, Faster Congestion Feedback, Media Access Control and AAL2 Voice Trunking Dissertation, The Ohio State University, 2001 [7] V. Jacobson, Congestion Avoidance and Control, Computer Communication Review, vol. 18, no. 4, pp , August 1988 [8] V. Jacobson, Modified TCP Congestion Avoidance Algorithm, end2end-interest mailing list, April 1990 [9] J. Mogul and S. Deering, RFC1191: Path MTU Discovery, November 1990 [10] S. Floyd and T. Henderson, RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm, April 1999 [11]K. Fall and S. Floyd, Simulation-based Comparisons of Tahoe, Reno and SACK TCP, Computer Communication Review, July 1996 [12] W. Stevens, RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January 1997 [13] Sally Floyd, Revisions to RFC 2001, Presentation to the TCPIMPL Working Group, August 1998 [14] Kevin Fall and Sally Floyd, Simulation-based Comparisons of Tahoe, Reno and SACK TCP, Computer Communication Review, July 1996 [15] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, RFC 2018: TCP Selective Acknowledgment Options, October 1996 [16] M. Mathis, J. Mahdavi, S. Floyd and M. Podolsky, RFC 2883: An Extension to the Selective Acknowlegdment (SACK) Option for TCP, July 2000 [17] V. Jacobson, R. Braden and D. Borman, RFC 1323: TCP Extensions for High Performance, May 1992 [18] Dong Ling and H.T.Kung, TCP Fast Recovery Strategies: Analysis and Improvements, 1998 [19] L. Brakmo, S. O Malley and L. Peterson, TCP Vegas: New Techniques for Congestion Detection and Avoidance, 1994 [20] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski and L. Zhang, RFC 2309: Recommendations on Queue Management and Congestion Avoidance in the Internet, April 1998 [21] K. Ramakrishnan, S. Floyd and D. Black, RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP, September 2001 [22] K. Nichols, S. Blake, F. Baker and D. Black, RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998

16 [23] S. Brander and V. Paxson, BCP 2780: IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers, March 2000 [24] V. Paxson and M. Allman, RFC 2988: Computting TCP s Retransmission Timer, November 2000 [25] M. Allman, H. Balakrishnan and S. Floyd, RFC 3042: Enhancing TCP's Loss Recovery Using Limited Transmit Computting TCP s Retransmission Timer, January 2001 [26] ANSI/IEEE Std , Part 11: Wireless LAN Medium Access Control (MAC) and Physical (PHY) Layer Specifications, 1999 Edition [27] ANSI/IEEE Std a, Part 11: Wireless LAN Medium Access Control (MAC) and Physical (PHY) Layer Specifications High-speed Physical Layer in the 5 GHz Band, 1999 Edition [28] ANSI/IEEE Std b, Part 11: Wireless LAN Medium Access Control (MAC) and Physical (PHY) Layer Specifications High-speed Physical Layer in the 2.4 GHz Band, 1999 Edition [29] ANSI/IEEE Std b, Part 11: Wireless LAN Medium Access Control (MAC) and Physical (PHY) Layer Specifications Amendment 2: High-speed Physical Layer in the 2.4 GHz Band Corrigendum 1, November 2001 [30] ANSI/IEEE Std g, Part 11: Wireless LAN Medium Access Control (MAC) and Physical (PHY) Layer Specifications Amendment 4: Further Higher- Speed Physical Layer Extension in the 2.4 GHz Band, 2003 Edition [31] Chunlei Liu and Raj Jain, Approaches of wireless TCP enhancement and a new proposal based on congestion coherence, the 36th Hawaii International Conference on System Sciences, Quality of Service in Mobile and Wireless Network minitrack, Big Island, Hawaii, January 5 9, 2003 [32] A. Bakre and B. R. Badrinath, I-TCP: Indirect TCP for mobile hosts, 15 th International Conference on Distributed Computing Systems, 1995 [33] H. Balakrishnan, S. Seshan, and R. H. Katz; Improving reliable transport and handoff performance in cellular wireless networks; Wireless Networks, 1, 4, pp , February 1995 [34] H. Balakrishnan, S. Seshan, E. Amir and R. H. Katz, Improving TCP/IP Performance over Wireless Networks, Mobicom 95, November 1995 [35] H. Balakrishnan and R. H. Katz, Explicit Loss Notification and Wireless Web Performance, IEEE Globecom Internet Mini-Conference, Sydney, Australia, November 1998 [36] N. H. Vaidya, M. Mehta, C. Perkins, G. Montenegro, Delayed duplicate acknowledgements: a TCP unaware approach to improve performance of TCP over wireless, Technical Report , Computer Science Dept., Texas A&M University, February 1999 [37] The Network Simulator ns-2, Information Sciences Institute [38] Linux-like environment for Windows [39] G. Xylomenos, Multi Service Link Layers: An approach to enhancing internet performance over wireless links, PhD dissertation at University of California, San Diego, 1999 [40] P. Bhagwat, P. Bhattacharya, A. Krishna, S. K. Tripathi, Using channel state dependent packet scheduling to improve TCP throughput over wireless LANs, ACM/Baltzer Wireless Networks Journal, Vol. 3, No. 1, January 1997 [41] D. A. Eckhardt, P. Steenkiste, Improving wireless LAN performance via adaptive local error control, Proceedings of IEEE ICNP 98, 1998 [42] R. Ludwig, A. Konrad, A. D. Joseph, Optimizing the end-to-end performance of reliable flows over wireless links, pp ,Proceedings of ACM/ IEEE Mobicom 99 [43] M. Meyer, TCP Performance over GPRS, Proceedings of IEEE WCNC 99 [44] R. Ludwig and M. Meyer, RFC 3522 The Eifel Detection Algorithm for TCP, April 2003 [45] S.Deering and R. Hinden, RFC 2460: Internet Protocol Version 6 (IPv6) Specification, December 1998 [46] Lefevre, F. and Vivier, G. - "Understanding TCP's behavior over wireless links", Communications and Vehicular Technology, 2000 SCVT-200. [47] Nachiket Deshpande, TCP Extensions for Wireless Networks, Ohio State University, CIS788-99, 1999