Sei sulla pagina 1di 17

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/237236848

TCP sobre enlaces wireless Problemas y algunas posibles soluciones existentes

Article

CITATION READS

1 152

2 authors:

Leonardo Vidal Leonardo Alves


Universidad de la República de Uruguay Universidad de la República de Uruguay
5 PUBLICATIONS   21 CITATIONS    1 PUBLICATION   1 CITATION   

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Leonardo Vidal on 22 June 2015.

The user has requested enhancement of the downloaded file.


TCP sobre enlaces wireless
Problemas y algunas posibles soluciones existentes
Federico Rodríguez Teja Leonardo Vidal Leonardo Alves
rodrigue@fing.edu.uy LeonardoVidal@adinet.com.uy lalves@adinet.com.uy

Facultad de Ingeniería – Universidad de la República

Resumen congestión en la red, disminuyendo (en base a diferentes


algoritmos como veremos más adelante) la cantidad de
El presente trabajo parte de una descripción general segmentos inyectados a la misma.
del protocolo TCP (Transmission Control Protocol) para
proseguir con una descripción de aquellas El supuesto al que se asocia la pérdida de segmentos,
implementaciones más extendidas indicando ventajas y es que la conexión TCP atraviesa una red congestionada,
desventajas de cada una de ellas. Posteriormente aborda es aceptable en los enlaces cableados donde la tasa de
los problemas a los que habrá que enfrentarse al error es mínima (del orden de 1x10-12 en el caso de
implementar TCP sobre enlaces wireless y describe enlaces de fibra óptica y 1x10-9 en el caso de UTP Cat.5),
algunas de las posibles soluciones existentes brindando pero no se puede extender al caso de enlaces con tasas de
un mayor detalle de aquella que surge como la más errores mayores, del orden de 1x10-6 o peores (por
adecuada. Para terminar, presenta algunas simulaciones ejemplo wireless), donde la probabilidad de pérdida de un
realizadas que buscan determinar el comportamiento de segmento debido a problemas en el medio físico deja de
algunos sabores de TCP. ser despreciable.

Palabras claves: TCP, wireless. 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
1. Introducción reactivo) que buscan restituir la normalidad en los enlaces
cuando se detecta congestión, y congestion avoidance
TCP [1, 2] es el protocolo de capa de Transporte más (mecanismo proactivo) que buscan no llegar a una
ampliamente utilizado en las redes de datos actuales. situación de congestión [6].
Brinda entrega confiable y ordenada de los datos, control
de flujo y control de congestión, prestaciones que no TCP implementa para su operación diferentes timers:
posee IP [3] y que son requeridas por innumerables retransmission, persist, keepalive, etc. Veremos en detalle
aplicaciones. TCP ofrece un servicio orientado a el primero de ellos, conocido como RTT (retransmission
conexión, conociéndose al procedimiento de timer) [24]. Con este timer se busca asegurar la entrega de
establecimiento de la conexión como three-way datos frente al hecho de no tener ninguna realimentación
handshake. La entrega confiable se sustenta en el uso de desde el receptor de los datos. El RTO (retransmission
un método de ARQ (Automatic Repeat reQuest) con timeout) es la duración de este timer. Un segmento no
acknowledgments (ACKs) positivos, permitiéndose el debe ser retransmitido hasta RTO después de su
envío de menos de un ACK por cada segmento de datos transmisión previa.
recibido, lo cual se conoce como delayed-ACK [4]. Esto
permite aumentar la eficiencia, tanto de la red como de La administración del RTT debería ser la siguiente:
los hosts. Por otro lado el protocolo habilita a que el ACK cada vez que se envía un segmento conteniendo datos, si
pueda ser enviado cuando existan datos que deban viajar no está corriendo se debe lanzar el timer; cuando todos
en sentido inverso (técnica conocida como piggybacking) los datos que salieron son ACKed, se debería apagar y
no permitiéndose una espera mayor a 500 ms. [2]. A los cuando se recibe un ACK por nuevos datos se debería
efectos de controlar la congestión, TCP plantea regular el inicializar.
tráfico generado en ambos extremos de la conexión [5].
Para ello, cada host utiliza como “sensores” del estado de La modificación de la ventana de congestión se realiza
la red, la pérdida de uno o más segmentos o la recepción en función el valor del RTT, lo que puede considerarse
de ACKs duplicados e infiere a partir de ello la

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
perjudicial en casos que este valor sea alto, haciendo más ssthresh debería ser lo más alto posible al comienzo (por
lenta la reacción del protocolo. ejemplo, igual a rwnd) y deberá reducirse en caso de
congestión. Durante la fase slow start se aumenta cwnd en
El resto del documento se organiza de la siguiente a lo sumo SMSS bytes por cada ACK recibido de datos
forma: en la próxima parte describiremos algunos nuevos entregados al receptor. Esta fase culmina cuando
algoritmos de TCP que actuando de forma combinada cwnd alcanza a ssthresh o cuando se detecta congestión.
buscan controlar la congestión; luego describiremos las A partir de allí se inicia la fase de congestion avoidance
diferentes implementaciones o “sabores” de TCP donde cwnd se incrementa en un segmento por round-trip
existentes; más adelante profundizaremos en los time (tiempo que transcurre entre que sale un segmento y
problemas de TCP en enlaces wireless para finalmente llega el ACK asociado). Esta fase continua hasta que se
aportar algunas simulaciones y conclusiones respecto del alcanza la congestión nuevamente.
impacto sobre la QoS, de tener una conexión TCP sobre
enlaces wireless. Durante la fase de congestion avoindance, la
actualización de la variable cwnd, se realiza con la
2. Control de Congestión de TCP siguiente fórmula:

El método utilizado por TCP para control de la cwnd = cwnd + SMSS x SMSS / cwnd (1)
congestión es el basado en la regulación del tráfico
inyectado a la red. Esto supone que implementa funciones calculándose cada vez que llega un ACK no
que le permiten estudiar cuándo es posible enviar más duplicado.
tráfico por el enlace, y cuándo se ha superado la
capacidad del mismo y se debe disminuir la carga. Cuando el transmisor detecta la pérdida de un
segmento, a partir del timer de retransmisión, el valor de
TCP emplea 4 algoritmos relacionados entre sí a los ssthresh debe pasar a ser:
efectos de efectuar el control de congestión [2, 5, 7, 8].
Ellos son conocidos con slow start, congestion ssthresh = max (FS / 2, 2 x SMSS) (2)
avoidance, fast retransmit y fast recovery.
siendo FS (Flight Size) la cantidad de datos enviados
Los algoritmos slow start y congestion avoidance, pero aún no reconocidos o ACKed. Al mismo tiempo,
deben ser utilizados por la fuente TCP a los efectos de cwnd no puede ser mayor que LW (Loss Window) que
controlar la cantidad de tráfico inyectado en la red [2]. vale 1 segmento y sin importar el valor de IW. Se
Para esto se cuenta con tres variables de estado del identifica con LW al tamaño de cwnd luego de detectar, a
protocolo. Estas son cwnd (congestion window), que través del timer de retransmisión, una pérdida.
controla del lado de la fuente la cantidad de datos que se Posteriormente se pasa a la fase de slow start hasta
puede enviar sin haber recibido un ACK, rwnd (receiver’s alcanzar el ssthresh y luego se seguirá con la fase
advertised window) que indica la cantidad de datos que congestion avoidance.
puede recibir el destino y ssthresh (slow start threshold)
que indica en que fase de control de congestión se Cuando se detecta la primera pérdida en una ventana
encuentra el transmisor (slow start si es mayor que cwnd de datos, mientras no se reparen todos los segmentos de
o congestion avoidance si es menor; de ser iguales, se dicha ventana, la cantidad de segmentos transmitidos en
puede utilizar cualquiera de los dos algoritmos). El cada RTT no podrá ser mayor a la mitad de los segmentos
mínimo de cwnd y rwnd gobierna la transmisión. El salientes cuando la pérdida fue detectada. Luego que
algoritmo slow start es utilizado al comienzo de una todos los segmentos fueran exitosamente retransmitidos,
transmisión a los efectos de que TCP pueda testear la red cwnd no podrá tomar un valor mayor a ssthresh y la fase
y conocer su capacidad evitando congestionarla. También siguiente será congestion avoidance. Pérdidas en dos
es utilizado en el momento de recuperación ante la ventanas de datos sucesivas o en retransmisiones indica
pérdida de algún segmento, indicada por timeout. Luego congestión e implica que cwnd y ssthresh deben bajar dos
del three-way handshake, el tamaño de la ventana inicial veces.
de envío (IW: initial window) debe ser menor o igual que
2 x SMSS1 bytes y no mayor a dos segmentos. El valor de 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
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 del tamaño máximo aceptado por el receptor (RMSS: Receiver
MTU (Maximum Transmit Unit), del Path MTU Discovery [9], a partir Maximum Segment Size) o en su defecto valdrá 536 bytes [2].
secuencia esperado. Las conclusiones a las que puede donde K = 4 y G es la granularidad del reloj, medida
arribar el transmisor ante la llegada de ACK duplicados en segundos.
pueden ser varias. Primero, puede concluir que está ante
la presencia de segmentos descartados; segundo, que por Para el siguiente cálculo de RTT (R') los nuevos
razones de tránsito en la red, los segmentos están valores de las variables serán:
llegando en desorden al receptor y tercero, que ocurre por
duplicación de los segmentos o de los ACKs en la propia RTTVAR = (1 - β) x RTTVAR + β x |SRTT - R'|
red. El receptor también debería enviar inmediatamente SRTT = (1 - α) x SRTT + α x R'
un ACK para aquel segmento que recibe y que se donde los valores de α y β deberían ser 1/8 y 1/4
encuentra en el hueco del espacio de número de secuencia respectivamente.
esperado de forma de colaborar con el transmisor [10]. RTO = SRTT + max (G, K x RTTVAR)

El algoritmo fast retransmit debería ser utilizado para RTO no debería ser menor que 1 ni mayor que 60
detectar y reparar pérdidas basado en la recepción de segundos.
ACK duplicados. El algoritmo emplea la recepción de 3
ACK duplicados (4 ACKs idénticos) para concluir que un La toma de las muestras RTT se debe realizar
segmento se ha perdido. El transmisor envía el segmento utilizando el algoritmo de Karn. Ello implica que no debe
que deduce se ha perdido sin esperar que expire el timer hacerse utilizando segmentos retransmitidos (salvo que se
de retransmisión, sstresh toma el valor dado por la utilice la opción timestamp) y que en caso de expirar, se
ecuación (2) y cwnd toma un valor dado por la ecuación: debería retransmitir el primer segmento no ACKed y
efectuar un backoff, pasando RTO a valer el doble y
cwnd = ssthresh + 3 x SMSS (3) lanzarlo nuevamente. Se debe realizar como mínimo una
(lo que se conoce como inflado artificial de cwnd). medida por round-trip time de forma de evitar el efecto de
aliasing2 [17] en el cálculo de RTO para el caso de
Esto hace crecer cwnd en la cantidad de segmentos ventanas de congestión grandes.
(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
3. Implementaciones de TCP existentes
mientras no se reciban nuevos ACK duplicados. De ser
TCP se basa en distintas implementaciones que se
posible (según los valores de cwnd y rwnd), se transmite
encuentran disponibles en los distintos sistemas
un nuevo segmento y ante la llegada de un ACK de datos
operativos más que en una única especificación.
nuevos lleva el valor de cwnd al de ssthresh (lo que se
conoce como desinflado de cwnd) . El no pasar a la fase
A continuación presentaremos diferentes “sabores” de
de slow start ante la pérdida del segmento se justifica en
TCP implementados y testeados con cierta rigurosidad al
el hecho de que la llegada de ACK duplicado implica que
momento de escribir este documento [6], a saber: Tahoe,
quien lo envió recibió un segmento, por lo tanto, hay
Reno, New Reno, SACK, Net Reno y Vegas.
segmentos que están abandonando la red y por lo tanto
dejan de consumir recursos en ella.
3.1 TCP Tahoe
Estos algoritmos no se comportan adecuadamente ante
pérdidas múltiples en un “single flight” de segmentos [11] Surge en el año 1988 a iniciativa de V. Jacobson, y se
lo que motivó el desarrollo de un conjunto de conoce también por el nombre de BSD Network Release
implementaciones adicionales [10]. 1.0 (BNR1). Cuenta con los algoritmos slow start,
congestion avoidance con un cálculo de round-trip time
Para calcular el RTO actual, el transmisor mantiene 2 mejorado [7] respecto al criterio de cálculo original. Se le
variables de estado llamadas SRTT (smothed round-trip agregó posteriormente un proceso de fast retransmit.
time) y RTTVAR (round-trip time variation). Mientras
no se calcule un RTT, el mismo debe valer como máximo El sistema busca llegar a un estado de equilibrio
3 segundos. Cuando se calcula el primer RTT (R), las basado en el principio de “conservación de los paquetes”
variables tomarán los siguientes valores: en los enlaces, donde se establece que se envía un paquete

SRTT = R
2
RTTVAR = R/2 La estimación del RTT es un problema de procesamiento de señales
RTO = SRTT + max (G, K x RTTVAR) 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.
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ó Si la opción SACK está permitida, el transmisor tiene
sobre el sistema operativo BSD. Se conoce también por el la información necesaria para tomar decisiones
nombre de BSD Network Release 2.0 (BNR2). Es la inteligentes sobre las retransmisiones a realizar durante la
versión más utilizada en nuestros días. fase de fast recovery.

La diferencia fundamental existente entre esta versión TCP New Reno, para el caso en que no se pueda
y la anterior es que cuando se detecta congestión, Tahoe utilizar SACK, implementa una modificación del
modifica la variable cwnd llevándola a un segmento lo algoritmo de fast recovery [10], que comienza al recibirse
que implica ir a la fase de slow start, mientras que Reno 3 ACK duplicados, almacenando en una variable
la hace valer ssthresh¸ quedando en la etapa de “recover” el número de secuencia más alto transmitido, y
congestion avoidance implementando así un algoritmo de en caso de recibirse ACK de todos los datos que salieron
fast recovery. Esto permite que se recupere más del transmisor incluso durante la fase de fast recovery o
rápidamente de congestión y errores en la red [12]. de darse un timeout en la retransmisión, pasa a la fase de
congestion avoidance.
Está versión [17] además agrega Header prediction,
que optimiza el protocolo basado en la afirmación que es Para comenzar una fase fast recovery no debe estarse
más fácil para un host responder “¿es este segmento el en una fase fast recovery. Luego de la recepción de los
siguiente en la secuencia?” que “¿está este segmento tres ACK duplicados ssthresh toma el valor dado por la
dentro de la ventana?”, y delayed acknowledgments, ecuación (2). Luego retransmite el segmento perdido y
que realiza un ACK de un grupo de segmentos recibidos, cwnd toma el valor dado por la ecuación (3). Un criterio
en lugar de realizarlo para cada uno. similar seguirá por cada ACK duplicado recibido. De ser
posible (según los valores de cwnd y rwnd), transmite un
La ventaja más destacable es el hecho de no pasar a la nuevo segmento. Ante la llegada de un ACK, puede
fase de slow start, cada vez que se produce la pérdida de suceder que sea un ACK a todos los datos, incluido el
un segmento, haciendo más recomendable en los enlaces recover, lo que implica un reconocimiento de todos los
de banda ancha. segmentos enviados entre el que se perdió y la recepción
del tercer ACK duplicado. Aquí cwnd puede tomar dos
3.3 TCP New Reno valores:

La mejora realizada en el TCP Reno, implica mejoras cwnd = min (ssthresh, FS + SMSS)
en pérdidas de segmentos aislados, pero no tiene ventajas o cwnd = ssthresh (valor tomado al comienzo de la
en caso de pérdidas en sucesivos segmentos. Estas fase de fast recovery)
pérdidas son comunes en enlaces de alta velocidad, donde (esto implica un “desinflado de ventana”)
la pérdida en general contiene varios segmentos.
Luego de esto se sale de la fase de fast recovery.
La figura a continuación [6] muestra la pérdida de tres
segmentos consecutivos y sus consecuencias; como puede Si el ACK no cubre todos los datos incluido el
verse, se pasa a la etapa de slow start: 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
cuando se salga del fast recovery aproximadamente 3.4 TCP Selective ACK (SACK)
sshthresh datos hayan abandonado la red. El transmisor
sigue en la fase de fast recovery. La pérdida de múltiples segmentos de una ventana de
datos puede ser catastrófica para el throughput de TCP.
Es posible aplicar técnicas más agresivas de El uso del mecanismo denominado ACK acumulativo3
retransmisión ante la llegada de un ACK parcial que ocasiona que el transmisor tome dos caminos, o espere un
impliquen la retransmisión de más de un segmento lo que RTT para saber de segmentos perdidos o realice
podría ocasionar que se retransmitan segmentos retransmisiones innecesarias que implicarán múltiples
innecesariamente. descartes. La opción SACK puede ayudar a sobrellevar
estos inconvenientes.
Podemos considerar dos variantes del New Reno,
Impatient y Slow-but-Steady. En la primera, sólo se pone TCP SACK [15, 16] brinda un mecanismo para
a cero el RTT luego del primer ACK parcial y de haber proporcionar más información sobre los segmentos que
varios segmentos perdidos en la misma ventana, luego de han sido recibidos correctamente y el transmisor puede
vencido el timer se comienza la fase slow start [13]. En la conocer cuales son los segmentos que se han perdido.
segunda, se pone a cero el RTT luego de cada ACK SACK es un campo opcional en el encabezado TCP, que
parcial por lo que se puede retransmitir un segmento es enviado cuando se reciben datos fuera de secuencia.
luego de cada round-trip time [14]. Esta opción contiene una lista de los bloques contiguos y
aislados de datos recibidos y guardados en cola, con la
La ausencia de la opción SACK no permite inferir información necesaria para identificarlos (números de
demasiada información en el momento de la recepción de secuencia de 32 bits que ofician de “bordes” en los
un ACK duplicado. No se puede concluir cual o cuales bloques). Por la definición del encabezado de TCP, no es
fueron los segmentos que dispararon el duplicado, posible especificar más de tres bloques. De esta forma el
tampoco permite distinguir entre los casos en los cuales extremo transmisor consigue la información de los
se generó debido a un paquete demorado o perdido o si se subsecuentes bloques no recibidos por el destinatario.
trata de un ACK a una retransmisión de un segmento que Puede resultar conveniente el uso de esta técnica en
llegó a destino. Por lo tanto, pérdidas múltiples en una conjunción con la técnica de Round Trip Time
ventana pueden ocasionar múltiples e innecesarios fast Measurement (RTTM) basada en timestamps [17] de
retransmit. forma de obtener más información sobre segmentos
perdidos.
A los efectos de evitar múltiples fast retransmit se
implementó un bugfix utilizando una nueva variable, La extensión SACK hace uso de dos opciones de
denominada “send_high” que toma como valor inicial el TCP. La primera, SACK-permitted, está asociada a la
número de secuencia de envío inicial y actualiza su valor habilitación de la opción SACK y se envía como 2 bytes
luego de cada timeout de retransmisión al valor más alto y solamente en el segmento SYN. La segunda, es la
transmitido. El transmisor puede, a través de esta opción en si misma.
variable, deducir que ha retransmitido segmentos
innecesariamente de forma que no lo interprete como Que el transmisor haya enviado la opción SACK-
congestión. Cuando el transmisor recibe 3 ACK permitted en el segmento SYN no implica que el receptor
duplicados y no se encuentra en la fase fast recovery, deba utilizarla al recibir bloques discontiguos. No debe
chequea si esos ACK comprenden al send_high, de ser usarlo si no lo recibió previamente en el momento del
así, el ssthresh toma el valor dado por la ecuación (2), three-way handshake. De utilizarse, debería hacerlo
almacena el número de secuencia más alto transmitido en mientras no se envía el ACK del número de secuencia
la variable recover y le da a cwnd el valor dado por la más alto de los datos que están en su cola.
ecuación (3). En caso contrario, no realiza acción alguna.
Quien recibe el ACK con la opción de SACK debe
A pesar de que TCP New Reno es capaz de manejar almacenar esta información. Se asume que el transmisor
múltiples pérdidas en una ventana, tiene la limitación de tiene almacenados de forma ordenada los segmentos que
permitir solamente el envío de un segmento por round- necesitará transmitir. Una posible implementación es que
trip time. Esto no es muy aceptable en casos en que tanto cada segmento almacenado en el transmisor tenga
el delay como el ancho de banda se incrementan. 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.
tengan dicha flag encendida “escaparán” a la La primer mejora es en el algoritmo de estimación del
retransmisión. Lo mismo ocurrirá con aquellos segmentos round-trip time, a partir de registrar el momento de envío
con número de secuencia mayor al máximo SACKed. de cada segmento y el momento de recibir cada ACK. A
partir de esto, si recibe un ACK y la diferencia de tiempos
Luego de un timeout de retransmisión, se deberían con su segmento correspondiente es mayor al timeout, se
apagar todas las flags, y se debe retransmitir el segmento retransmite sin esperar a tener los 3 ACK duplicados.
más a la izquierda de la ventana. Cuando recibe un ACK no duplicado, si es el primero o
segundo luego de una retransmisión, calcula el tiempo
De esta forma se maneja la información para el envío que hace que envió el tercer segmento en cuestión y de
completando los bloques que faltan en la transmisión, y ser mayor que el round-trip time lo envía nuevamente.
marca los bloques como retransmitidos. Si un bloque
retransmitido se pierde entonces pasa a la fase de slow En segundo lugar TCP Vegas busca ser proactivo
start. frente a la congestión y no reactivo como lo es Reno, que
espera la pérdida de segmentos a los efectos de
TCP SACK mejora TCP New Reno, ya que permite el determinar el ancho de banda disponible en la red. Para
manejo de segmentos perdidos en una misma ventana, en ello calcula el throughput en la red, y la compara con el
una forma más eficiente, permitiendo su retransmisión en throughput esperado. Ello le permite determinar el flujo
un solo round-trip time. En el caso de TCP New Reno, el de datos extra que puede transitar por la red y calcular
protocolo se enterará de los segmentos perdidos a medida cual es el adecuado de forma de evitar llegar a la
que reciba los que le preceden. congestión. Esta es la fase congestion avoidance.

3.5 TCP Net Reno (Network-sensitive Finalmente, la tercer técnica, busca evitar la
congestión en la fase slow-start. Realiza crecimientos
Reno) exponenciales de cwnd cada round-trip time alternados;
entre ellos cwnd queda fija. Si la tasa de envíos lograda es
El TCP Net Reno [18] es una mejora al protocolo TCP menor que la esperada, durante un cierto lapso, se pasa a
New Reno. Se buscó un conjunto de optimizaciones de un modo de crecimiento lineal y no exponencial.
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 4. Problemas existentes en TCP sobre
para cada ACK duplicado recibido, antes que se dispare enlaces wireless
la fase de fast retransmit. Busca ser una mejora en el caso
de ventanas de congestión pequeñas [25]. Supongamos En la presente sección, presentaremos algunos de los
que cwnd vale 3, si uno de los segmentos es descartado en problemas existentes en la implementación de conexiones
la red, a lo sumo 2 ACK duplicados arribarán al TCP sobre enlaces wireless.
transmisor (recordar que estos son generados cuando
llegan segmentos fuera de orden), por lo tanto no se Los problemas existentes se basan en la incapacidad
disparará la fase fast retransmit y el segmento perdido de TCP de discriminar cuándo la performance de la
sólo se enviará nuevamente por timeout. Para ello se conexión ha disminuido debido a pérdidas en el enlace,
propone el algoritmo Limited Transmit. Este permite al común en las tecnologías wireless, y cuándo es debida a
transmisor, luego de recibir 2 ACK duplicados congestión en la red. El problema radica en que el
consecutivos, a enviar hasta 2 segmentos más allá de lo transmisor no puede determinar con cierto grado de
indicado por cwnd y en caso que rwnd lo permita. El certeza qué ha motivado la pérdida de un segmento.
tamaño de cwnd no debe cambiar. Este algoritmo respeta
la “conservación de los paquetes” y puede ser el que Cuatro aspectos inherentes a redes wireless pueden
motive el tercer ACK duplicado lo que hará que se inicie afectar decisivamente la performance de TCP [46]. Por
la fase fast retransmit. un lado, la bit error rate (BER) del medio físico, que
como ya mencionamos, puede ser del orden de 1x10-6 o
3.6 TCP Vegas peor. En segundo lugar debemos considerar que el ancho
de banda disponible es en general menor al disponible en
TCP Vegas [19] tiene grandes cambios en medio cableados. Una tercer componente es la posible
comparación con las primeras versiones de TCP. Utiliza movilidad de los componentes de la red lo que puede
tres técnicas para mejorar el throughput, y tratar de evitar implicar cambios importantes en los tiempos de entrega
la pérdida de segmentos. de los segmentos. Finalmente, es común que el protocolo
de capa de Enlace y en particular de la sub-capa MAC así
como el protocolo de enrutamiento utilizado implique mismo puede estar en cualquier lugar de la conexión, si
necesariamente tener un overhead asociado a la está al principio será un enlace first-hop, si está al final
movilidad y al aumento en la probabilidad de pérdida de será last-hop y también puede estar en algún lugar
tramas o paquetes. intermedio, como se da por ejemplo en el caso de enlaces
satelitales.
A los efectos de fijar ideas podemos considerar como
ejemplo de protocolo de sub-capa MAC a la familia de Transparent: no necesita leer información del
estándares de IEEE para Wireless Local Area Network encabezado TCP en algún nodo intermedio.
(WLAN) [26, 27, 28, 29, 30]. En ellos se especifica que
para el envío de cada trama de datos en el modo de Signaling: detecta y reporta la causa de la pérdida de
operación Distributed Coordination Function (DCF) se los segmentos a las capas superiores, para tomar las
emplee un método de control de acceso al medio acciones de recuperación apropiadas para evitar
denominado carrier sense multiple access with collision retransmisiones indeseables. En el caso que las acciones
avoidance (CSMA/CA), protocolo que busca reducir la sean tomadas por la capa de Transporte, se deberán hacer
probabilidad de colisiones entre múltiples estaciones a modificaciones en el código del TCP existente, lo cual
través del evitado de las mismas. A los efectos de detectar puede llegar a ser un inconveniente.
portadora, además del mecanismo clásico de “escucha del
medio” (detección física de portadora) se realiza una En contraposición a lo anterior, cabe señalar que
detección virtual de portadora utilizando four-way algunas implementaciones contienen otro conjunto de
handshake, donde con dos tramas de control (RTS: características que no son deseables para nuestro caso de
Request To Send y CTS: Clear To Send) se reserva el estudio y que corresponde hacer una descripción de las
medio, luego se envía la trama conteniendo los datos y mismas para poder entender el motivo por el cual no son
posteriormente se espera una trama de control ACK que tenidas en cuenta en el presente análisis:
confirma su recepción. Lo anterior es una muestra clara
del overhead involucrado, pero hasta aquí no hemos Split (Indirect-TCP) [32]: cuando el camino completo
considerado la movilidad de las estaciones. Durante la de la conexión es dividido en una conexión cableada y
misma, una estación móvil puede estar asociada a una una wireless y se corre TCP en forma independiente en
estación base (BS) a través de la cual recibe las tramas cada conexión. Cuando la transmisión de un segmento se
que provienen por ejemplo de la red cableada y unos completa en una conexión, se le envía un ACK a la fuente
milisegundos después, deberá estar asociada a otra y se transmite a la otra conexión. Podemos señalar como
estación base a la cual la primera deberá enviar las tramas principales desventajas de esta implementación las
que tuviera almacenadas para dicha estación. siguientes: los ACKs recibidos por la fuente no significan
que los segmentos hallan sido recibidos por el supuesto
4.1 Propuestas de mejora al TCP existente destinatario, la transmisión de datos no es confiable y por
sobre enlaces wireless último, al correr TCP en forma independiente en ambas
conexiones y a diferentes ritmos, el buffer de la BS puede
Se puede afirmar que una propuesta de mejora al TCP incurrir en overflow.
existente, sobre enlaces wireless, debe reunir el siguiente
conjunto de características deseables [31]: Global: si implementa cambios fuera de la red
wireless.
End-to-end: los segmentos son reconocidos solamente
luego de haber sido recibidos por el destinatario final. One-Way: si está diseñada preferentemente para el
tráfico en una dirección.
Local: implementa cambios solamente sobre los
componentes de red wireless, como puede ser en las Last-Hop: si el algoritmo asume que el enlace wireless
estaciones base y en las estaciones móviles. esta ubicado en el extremo final de la conexión TCP.

Two-Way: está diseñada para tráfico en ambas Snooping: si se necesita leer en algún nodo intermedio
direcciones, desde la red cableada hacia el host móvil y información del encabezado TCP.
viceversa, suponiendo que el mismo tiene intensidades
similares. Hiding: si presupone que existe un servicio de capa de
enlace confiable y que sus protocolos de retransmisión
Intermediate-Link: el algoritmo no asume una resuelven el problema de la pérdida de tramas, ocultando
ubicación predeterminada del enlace wireless. Es decir, el el carácter lossy del enlace, hacia las capas superiores. La
principal desventaja de las mejoras que usan esta
característica es que, no obstante se oculten las posibles reducciones innecesarias de la ventana de congestión del
pérdidas, pueden llegar a existir retransmisiones en ambas transmisor TCP.
capas, capa de enlace y de transporte tratando de
responder a los mismos eventos de pérdidas, causando 4.1.2 Explicit Loss Notification (ELN)
interacciones muy indeseables [39,40,41,42,43,44].

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

4
Llamaremos a las pérdidas de paquetes causadas por errores de
transmision en un medio wireless ”pérdidas wireless” y a aquellas
5
causadas por congestión en la red “ pérdidas por congestión”. Aún no está especificado el bit del encabezado TCP destinado a ELN.
Pensando en una futura retransmisión, DDA retarda el En la fragmentación y reensamblado, se debe respetar
tercer ACK duplicado, asumiendo que se trata de una la información sobre ECN que contengan los fragmentos,
pérdida wireless y está siendo retransmitido [36]. En el bastando que uno de los fragmentos traiga información de
caso de que dicho segmento no llegue luego de un cierto congestión para que se reconstruya el paquete con el
periodo, el receptor libera el ACK duplicado demorado código que trae dicho fragmento, salvo en caso que algún
para así disparar una retransmisión end-to-end. Requiere fragmento indique “Not-ECT”.
de modificaciones en la estación móvil y no distingue
entre pérdida wireless y pérdida por congestión. En el caso concreto de TCP, tres nuevas
funcionalidades son requeridas para que se soporte ECN:
4.1.4 Explicit Congestion Notification negociación durante el establecimiento de la conexión a
los efectos de determinar si ambos extremos son “ECN-
(ECN) capable”, una flag “ECN-Echo” en el encabezado TCP a
los efectos de que el receptor indique al transmisor que ha
Existen en Internet algunos mecanismos (como RED: recibido un paquete con información de ECN y
Random Early Detection [20]) donde se realiza la finalmente, una segunda flag “Congestion Window
notificación de una congestión incipiente en lugar de Reduced” (CWR) utilizada por el transmisor para
descartar los paquetes. Esta implementación busca indicarle al receptor que ha reducido su congestion
indicarlo utilizando para ello un campo de dos bits del window. Dichas flags (ECE y CWR) se representan por
encabezado IP denominado ECN [21], y compuesto por un bit cada una, utilizando para ello el campo Reservado
dos flags conocidas como ECT y CE6. Cuando ambos de los bytes 13 y 14 del encabezado TCP y en particular,
puntas del protocolo de transporte son “ECN-capable” los bits más próximos a las flags ya definidas.
ello se indica por los códigos ‘10’ y ‘01’ que se
identifican como “ECN-Capable Transport” (ECT), Por lo tanto, en redes TCP/IP, ECN utiliza cuatro
ECT(0) y ECT(1) respectivamente. Dichos valores son flags. Dos, ECT y CE, en el encabezado IP, destinadas a
equivalentes y se pueden utilizar indistintamente incluso señalización entre routers y extremos de la conexión y
en una misma comunicación. El código ‘00’ (“Not-ECT”) dos, ECE y CWR, en el encabezado TCP, para
indica que se trata de un paquete que no está usando ECN señalización entre los extremos TCP.
y finalmente el código ‘11’ es utilizado por los routers
para indicar a ambos extremos de la conexión que se está Ante la presencia de congestión en la red, una
experimentando una congestión incipiente. Debería secuencia de eventos típica en una conexión TCP basada
indicarlo si, hubiera descartado el paquete en caso de no en ECN podría ser: a través del bit ECT de IP el
ser “ECN-capable”. Previo a realizarlo, debe confirmar transmisor indica que la entidad TCP es “ECN-capable”,
que ambos extremos también son “ECN-capable”. Se el router que está experimentando congestión recibe estos
estima que el descarte no debería ser necesario en una red paquetes y en lugar de descartarlos los marca a través del
“full ECN-capable” pero que seguirán existiendo en la bit CE de IP, el receptor detecta esto y lo informa en el
transición a ella. Es conveniente que los routers no siguiente ACK utilizando el bit ECE de TCP, el
utilicen la información del tamaño instantáneo de la cola transmisor recibe dicho ACK y reacciona como si el
para informar de congestión a través del código ‘11’. paquete hubiera sido descartado. Finalmente, el
transmisor informa en el siguiente segmento, utilizando el
Los extremos de transporte deben reaccionar ante la bit CWR de TCP, que ha recibido el ECE y que ha
presencia de congestión utilizando los mismos algoritmos actuado en consecuencia.
de congestión que en caso de descarte de segmentos. El
motivo de esto es que ECN se está incorporando En el momento del establecimiento de la conexión
gradualmente a las redes actuales. Algunos routers y TCP, el envío de un segmento SYN con las flags ECE y
equipos terminales aún no implementan ECN y esta CWR en ‘1’ (segmento “ECN-setup SYN”) indica que el
medida ayuda a extender y uniformizar su utilización. Por transmisor es “ECN-capable”. Si el receptor responde con
otro lado, resulta conveniente que los extremos un segmento ACK con la flag ECE en ‘1’ y la flag CWR
reaccionen ante esta información pero una sola vez por en ‘0’ (segmento “ECN-setup SYN-ACK”) indicará que
round-trip time. 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
6
paquetes con el bit ECT en ‘1’. Un host no podrá enviar
El campo ECN está compuesto por los bits 6 y 7 del octeto TOS de paquetes con el bit ECT en ‘1’, a menos que haya enviado
IPv4 [22, 23], el cual se corresponde con el octeto Traffic Class de IPv6
[45].
por lo menos un segmento “ECN-setup SYN” o “ECN-
setup SYN-ACK” y que haya recibido por lo menos un retransmisiones locales en capa de Enlace y detección de
segmento “ECN-setup SYN” o “ECN-setup SYN-ACK” la causa de pérdida de paquetes.
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’.
4.1.5.1 Retransmisiones locales en capa de
Enlace
Es posible encontrar dispositivos intermedios
(firewalls, intrusion detection system, etc.) que ante la Todas las tramas trasmitidas en el enlace wireless son
llegada de un “ECN-setup SYN” lo descarten o localmente reconocidas antes de ser borradas en el buffer
devuelvan un segmento RST. Como paliativo a ello se del emisor. Las tramas que no son reconocidas o son
puede optar que ante la recepción de dicho segmento se negativamente reconocidas luego de expirado un timer
envíe un segmento SYN con las flags ECE y CWR en ‘0’, serán retransmitidas. Las retransmisiones de las tramas
eligiendo así no utilizar ECN. fallidas, tienen mayor prioridad que las nuevas tramas.
Esto es importante para reducir el retardo de las tramas
El hecho de que el segmento “ECN-setup SYN-ACK” retransmitidas y minimizar la chance de disparo de
lleve las flags ECE y CWR con valores ‘1’ y ‘0’ y no ‘1’ retransmisiones end-to-end desde el transmisor. Una
‘1’ como el segmento “ECN-setup SYN” que lo motivó, manera de implementar la mayor prioridad es usar la
busca evitar potenciales deducciones falsas de “ECN- estrategia insert from front8. La máxima cantidad de
capable” que se podrían dar en aquellas retransmisiones para una trama fallida es configurable. La
implementaciones de TCP donde el campo Reservado del capa de enlace puede tanto retransmitir persistentemente o
segmento SYN-ACK es simplemente una copia del detenerse luego de que se alcanza una cantidad máxima
recibido en el SYN. de retransmisiones.

Los paquetes que contienen segmentos retransmitidos 4.1.5.2 Detección de la causa de pérdida de
no deben llevar los códigos ECT(0) o ECT(1) y, por los segmentos
razones de seguridad (denial-of-service attack) el receptor
debería ignorar la información ECN que contengan En esta sección nos tomaremos la libertad de
segmentos que están fuera de la ventana de recepción. referirnos siempre a segmentos, sin discriminar entre
segmentos o paquetes, buscando una mejor comprensión
Como mecanismo de control de congestión, ECN a del tema a costo de ser menos rigurosos en la
demostrado ser más efectivo que el uso de segmentos terminología.
perdidos para indicar el estado de congestión de la red.
De esta forma se evitan dos cosas, por un lado, el descarte De modo de distinguir entre errores de transmisión y
de segmentos y, por otro, las innecesarias aquellos debidos a congestión, el receptor wireless
retransmisiones. necesita un mecanismo para detectar la causa de la
pérdida de los segmentos. Segmentos fuera de orden
4.1.5 Congestion Coherence (CC) indican segmentos perdidos. Ambas pérdidas, wireless y
por congestión, causan segmentos fuera de orden y crean
Considera como supuesto previo que está huecos en el espacio de secuencia, pero sus consecuencias
implementado ECN7 sobre la red cableada. Si bien esta son diferentes.
mejora es local, es aplicable a un amplio espectro de
configuraciones de redes y escenarios de tráfico. La manera de determinar la causa de la pérdida de los
Congestion Coherence [31], usa un esquema basado en la segmentos está basada en la observación de que la
coherencia de la congestión entre paquetes consecutivos congestión no ocurre y desaparece repentinamente. Antes
apuntando a determinar la causa de la pérdida de los de que la misma se torne tan severa al punto que un
paquetes. Emplea retransmisiones locales a nivel de capa segmento tenga que ser desechado, algunos segmentos
de Enlace. A continuación describiremos dos aspectos deben ser marcados por ECN como congestion
relevantes de Congestion Coherence que son, 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
8
de la red cableada, se considera como local, pues ECN es un protocolo Cuando una trama es detectada como perdida, la capa de Enlace
de mejora que es usado tanto en redes cableadas como wireless, de modo inserta la trama fallida en el frente de la cola de transmisión y lo trasmite
que vale la pena enfrentar dicho costo. cuando el medio esta disponible.
El tamaño de la cola decae gradualmente y algunos De la comparación resultante entre TCP básico con
segmentos son marcados. retransmisiones, ECN, Snoop 9, DDA y CC, se concluye
[31] que la propuesta de mejora que obtiene los niveles
En el tiempo que transcurre entre que un segmento no mas elevados de performance es Congestion Coherence
se marca y entre que un segmento es desechado, algunos (CC).
segmentos deberán ser marcados.
Algunos de los aspectos a resaltar son: CC realiza un
Como resultado, las pérdidas por congestión están manejo excelente de la ventana de congestión, evitando
normalmente precedidas y seguidas por segmentos innecesarias reducciones, retransmisiones end-to-end y
marcados. Llamamos a este fenómeno congestion timeouts ya que la mayoría de las pérdidas por congestión
coherence del marcado ECN. son evitadas mediante el uso de ECN. También hace un
uso muy eficiente de la cola del enlace cuello de botella
Los segmentos adyacentes de un segmento perdido manteniéndola casi siempre llena.
definen el coherence context. Podemos definir al contexto
coherente de un paquete n como el conjunto formado por El parámetro más interesante e importante para medir
los paquetes {n-1, n+1, n+2}. Un segmento perdido será la performance de un enlace es el goodput, o en su
considerado como una situación de pérdidas por defecto el throughput 10.
congestión si algún segmento en su contexto coherente
esta marcado por ECN. En este caso, la estación móvil El mejor goodput es el logrado por la propuesta CC,
responde a través de ACK duplicados para disparar la para toda packet error rate (PER) y en particular para
fase de fast retransmit. En contraste a la situación de valores altos de la misma, como son los que se registran
pérdida por congestión, la ocurrencia de errores de en los enlaces wireless.
transmisión (típicos en enlaces wireless) y por lo tanto la
no presencia de segmentos marcados debería evitar que se 5. Escenarios de simulación
evolucione a la fase de fast retransmit. Si algún segmento
en el contexto coherente esta marcado por ECN, es Para las simulaciones realizadas se utilizó la
necesario tomar acciones para controlar la congestión herramienta Network Simulator ns2 [37] versión 2.26.
reduciendo la tasa de transmisión de TCP. La
Para su visualización en sistemas operativos Windows
probabilidad de tener una pérdida por congestión sin un
se recurrió a la aplicación Cygwin [38].
paquete marcado en el contexto coherente es muy
pequeña. Así es que entonces, cuando en dicho contexto
Para el estudio se propone un modelo simple que
existen segmentos que no están marcados, la estación
busque sacar conclusiones sobre el problema planteado,
móvil mantiene el reconocimiento duplicado hasta que
tratando de no agregarle complejidades que pudieran
sea recibido el paquete retransmitido.
modificar el objetivo inicial.
La misma idea puede ser aplicada al caso de un emisor
El modelo de simulación propuesto presenta cinco
wireless. Cuando este recibe reconocimientos duplicados,
nodos (mostrado en la figura), donde el enlace del n0-n1,
chequea si existe en el contexto coherente algún ECN-
será el que se caracterice tipo wireless.
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. Se agregó un flujo UDP entre los nodos n4 y n5, a los
efectos de generar jitter en el enlace n0-n1, pero
4.1.6 Comparación de Performances 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.
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 5.1.4 Desconexiones
enlace de este tipo, ya presentadas en el punto 4.
La simulación de desconexiones se realizó a través de
A continuación se presenta la configuración realizada la inserción de retardos, lo que puede asociarse a
para el enlace mencionado. desconexiones por un lapso pequeño.

5.1.1 Capacidad del enlace 5.2 Simulaciones realizadas


Se configuró una capacidad de 2Mb buscando una Se tomó como base la red presentada anteriormente, y
velocidad sensiblemente inferior a la de los enlaces la experiencia realizada consistió en variar el módulo
cableados actuales. TCP del simulador, para estudiar posteriormente el
comportamiento para los diferentes “sabores” de TCP.
5.1.2 Tasa de error del canal
Los agentes de TCP utilizados y simulados en la
Para la simulación de un canal con una tasa de error arquitectura presentada fueron los siguientes:
alta, se utilizó el módulo ErrorModel de ns2, que permite
generar errores en un enlace. Se define en el modelo de • Reno, que implementa un TCP Reno.
simulación la variable lrate, que representa la • Newreno, que implementa un TCP NewReno.
probabilidad de error en un segmento que transita por el • Sack1, que implementa un TCP SACK; para
enlace. este caso se modificó el agente receptor del
flujo, ya que la lógica del funcionamiento del
Se seleccionó una tasa de error de 1x10-3, lo que SACK, busca informar al extremo origen del
implica un error cada mil segmentos enviados. flujo las fallas en la recepción de
información, lo que requiere lógica en el
5.1.3 Retardo del enlace n0-n1 receptor. Para el receptor se utilizó “Sack1”.
• Vegas, que implementa un TCP Vegas.
Se le configuró un retardo base de 30 mseg. El flujo
UDP entre n4 y n5 se configuró con los siguientes Exceptuando el caso del TCP SACK, para todos los
parámetros: demás, del lado del receptor, se utilizó un agente ”Sink”.

• Tamaño del paquete: 500 bytes Para cada una de las simulaciones se registraron las
• Tiempo de actividad: 90 mseg. siguientes variables:
• Tiempo de inactividad: 2500 mseg.
• Cantidad total de bytes enviados.
El agente UDP tiene una fuente de tráfico • Goodput del enlace, considerando muestras
exponencial, empleando el agente Exponential de ns2. A de .01 seg.
continuación se presenta un gráfico que indica el flujo • Tamaño de la ventana TCP, considerando
UDP generado. muestras cada 0.01 seg.
• RTT del TCP, considerando muestras cada
0.01 seg.
• Cantidad de ACKs duplicados.

5.3 Resultados obtenidos


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].

5.3.1 Cantidad total de bytes enviados


El detalle para cada una de las implementaciones de
TCP simuladas es:

TCP Bytes enviados


Reno 37.761.000
New Reno 44.454.000
SACK 42.229.000
Vegas 47.868.000
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.

5.3.2 Goodput promedio


El goodput de las distintas implementaciones TCP, en Como puede verse en las gráficas presentadas, el
general, se encuentra alrededor de los 4 Kbps, y puede goodput promedio es similar, pero el TCP Vegas tiene
verse que el aumento del RTT del enlace provoca una picos menos pronunciados y valles menos extensos que el
baja en la transmisión de información. La siguiente figura TCP NewReno, lo que muestra que el protocolo es más
muestra el comportamiento típico observado al simular estable. TCP Vegas tiene máximos de 3500 bytes,
las diferentes implementaciones. mientras que TCP NewReno llega a tener de 8000 bytes.

5.3.3 Comparación de goodput de distintos 5.3.4 Relación entre RTT y tamaño de


TCP ventana del TCP

Si bien el comportamiento fue similar en todos los El tamaño de la ventana puede verse está
casos, se visualizan picos y valles que generan la inversamente relacionado con la duración del RTT. Esto
diferencia entre los diferentes sabores de TCP respecto a se desprende de las gráficas obtenidas luego de la
la cantidad total de bytes enviados. simulación.

A continuación se presentan los casos de TCP Vegas A continuación se presenta para el caso de TCP Reno,
(el de mejor performance), y el segundo, NewReno. 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.
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.

5.3.6 Observaciones sobre el RTT en TCP


Vegas
El valor del tamaño de la ventana TCP (cwnd), influye En el análisis previo de los distintos “sabores” de TCP
directamente sobre el goodput, mejorando el mismo (punto 3.6), se menciona que TCP Vegas mejora el
cuanto mayor sea la ventana cwnd. La siguiente gráfica calculo del RTT, lo que se traduce en una mejor
muestra para el caso de TCP Reno. 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.

5.3.5 Análisis interferencia del flujo UDP en


la prueba
6. Conclusiones
[10] S. Floyd and T. Henderson, RFC 2582: The
TCP asocia la pérdida de segmentos a congestión en la NewReno Modification to TCP's Fast Recovery
red, lo que no siempre es válido en redes wireless. La Algorithm, April 1999
solución a este problema requiere de implementarle
mejoras al TCP de forma que tenga una buena [11]K. Fall and S. Floyd, Simulation-based
performance en redes wireless pero sin olvidar que Comparisons of Tahoe, Reno and SACK TCP, Computer
actualmente constituye el 85% del tráfico en Internet. Communication Review, July 1996

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

[24] V. Paxson and M. Allman, RFC 2988: [35] H. Balakrishnan and R. H. Katz, Explicit Loss
Computting TCP’s Retransmission Timer, November Notification and Wireless Web Performance, IEEE
2000 Globecom Internet Mini-Conference, Sydney, Australia,
November 1998
[25] M. Allman, H. Balakrishnan and S. Floyd, RFC
3042: Enhancing TCP's Loss Recovery Using Limited [36] N. H. Vaidya, M. Mehta, C. Perkins, G.
Transmit Computting TCP’s Retransmission Timer, Montenegro, Delayed duplicate acknowledgements: a
January 2001 TCP unaware approach to improve performance of TCP
over wireless, Technical Report 99-003, Computer
[26] ANSI/IEEE Std 802.11, Part 11: Wireless LAN Science Dept., Texas A&M University, February 1999
Medium Access Control (MAC) and Physical (PHY) [37] http://www.isi.edu/nsnam/. The Network
Layer Specifications, 1999 Edition Simulator – ns-2, Information Sciences Institute

[27] ANSI/IEEE Std 802.11a, Part 11: Wireless LAN [38] http://www.cygwin.com. Linux-like environment
Medium Access Control (MAC) and Physical (PHY) for Windows
Layer Specifications – High-speed Physical Layer in the 5
GHz Band, 1999 Edition [39] G. Xylomenos, Multi Service Link Layers: An
approach to enhancing internet performance over wireless
[28] ANSI/IEEE Std 802.11b, Part 11: Wireless LAN links, PhD dissertation at University of California, San
Medium Access Control (MAC) and Physical (PHY) Diego, 1999
Layer Specifications – High-speed Physical Layer in the
2.4 GHz Band, 1999 Edition [40] P. Bhagwat, P. Bhattacharya, A. Krishna, S. K.
Tripathi, Using channel state dependent packet
[29] ANSI/IEEE Std 802.11b, Part 11: Wireless LAN scheduling to improve TCP throughput over wireless
Medium Access Control (MAC) and Physical (PHY) LANs, ACM/Baltzer Wireless Networks Journal, Vol. 3,
Layer Specifications – Amendment 2: High-speed No. 1, January 1997
Physical Layer in the 2.4 GHz Band – Corrigendum 1,
November 2001 [41] D. A. Eckhardt, P. Steenkiste, Improving wireless
[30] ANSI/IEEE Std 802.11g, Part 11: Wireless LAN LAN performance via adaptive local error control,
Medium Access Control (MAC) and Physical (PHY) Proceedings of IEEE ICNP 98, 1998
Layer Specifications Amendment 4: Further Higher-
Speed Physical Layer Extension in the 2.4 GHz Band, [42] R. Ludwig, A. Konrad, A. D. Joseph, Optimizing
2003 Edition the end-to-end performance of reliable flows over
wireless links, pp. 113-119,Proceedings of ACM/ IEEE
[31] Chunlei Liu and Raj Jain, Approaches of wireless Mobicom 99
TCP enhancement and a new proposal based on
congestion coherence, the 36th Hawaii International [43] M. Meyer, TCP Performance over GPRS,
Conference on System Sciences, Quality of Service in Proceedings of IEEE WCNC 99
Mobile and Wireless Network minitrack, Big Island,
Hawaii, January 5–9, 2003 [44] R. Ludwig and M. Meyer, RFC 3522 The Eifel
Detection Algorithm for TCP, April 2003
[32] A. Bakre and B. R. Badrinath, I-TCP: Indirect [45] S.Deering and R. Hinden, RFC 2460: Internet
TCP for mobile hosts, 15th International Conference on Protocol Version 6 (IPv6) Specification, December 1998
Distributed Computing Systems, 1995
[46] Lefevre, F. and Vivier, G. - "Understanding
[33] H. Balakrishnan, S. Seshan, and R. H. Katz; TCP's behavior over wireless links", Communications and
Improving reliable transport and handoff performance in Vehicular Technology, 2000 SCVT-200.
cellular wireless networks; Wireless Networks, 1, 4, pp.
469 – 481, February 1995 [47] Nachiket Deshpande, TCP Extensions for
Wireless Networks, Ohio State University, CIS788-99,
1999

View publication stats