UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

NOMBRE: Cecilia Elizabeth Sánchez Macas

Paralelo: “A”

REDES y SISTEMAS DISTRIBUIDOS

ESTADO DEL ARTE: CHAT - RENO

TCP SOBRE ENLACES WIRELESS: PROBLEMAS Y ALGUNAS POSIBLES SOLUCIONES EXISTENTES

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.

1. Introducción
 TCP (Transmisión Control Protocol). - es un protocolo orientado a conexión y
confiable a nivel de capa de transporte. Fue diseñado específicamente para
proporcionar una corriente de Bytes en forma confiable a través de Internet. La
misma se diferencia de una red simple ya que sus distintas partes pueden tener
altos grados de diferencia en lo que respecta a topologías, anchos de banda,
retardos, tamaños de paquetes y otros parámetros. TCP fue concebido con el
propósito de adaptarse dinámicamente a los cambios en Internet,
presentándose robusto ante diversos tipos de fallas de la misma.[1]

2. Control de congestión 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.

3. Implementación de TCP existente

TCP se basa en distintas implementaciones que se encuentran disponibles en los
distintos sistemas operativos más que en una única especificación.
 TCP Tahoc. - 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 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 a la red cada vez que verifica que un
paquete ha abandonado la red.
 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.[1]

4. Simulaciones realizadas
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. Conclusiones
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[1]

JTCP: una implementación de TCP orientada a la evaluación de técnicas de

control de congestión

TCP es un protocolo ampliamente difundido en la Internet. Gran parte del tráfico de la

Internet, proviene de aplicaciones que lo utilizan. Esta característica indica la
importancia de la tasa a la cual TCP introduce sus datos en la red. La tasa de envío debe
adaptarse a las necesidades de la aplicación, sin saturar la red. El envío de datos a tasas
que no se adapten a las condiciones de la red podría hacerla colapsar. Desde que fue
definido, el protocolo TCP ha sido adaptado exitosamente para cumplir con sus
objetivos de lograr un uso eficiente de la red y ofrecer un servicio adecuado a los
usuarios.[2]

1. Introducción
 El nivel de transporte en el modelo TCP/IP cumple un rol importante en dos
aspectos: la adaptación del servicio provisto por IP a las aplicaciones, y el control de
la tasa de datos que éstas introducen en la red. Este último aspecto, de poco peso
en los comienzos de la Internet debido a su reducido tamaño, resulta en la
actualidad de vital importancia para posibilitar el funcionamiento de la red TCP
(Transfer Control Protocol) ofrece un servicio de transferencia de datos confiable y
orientado a la conexión, lo cual lo hace apto para aplicaciones que requieren
transferencias de datos de cierto volumen y sin errores. [3]
2. Evolución del control de congestión en TCP
TCP es un protocolo de nivel transporte que se originó junto con la arquitectura que
lleva su nombre (TCP/IP). Una característica que debe destacarse de TCP es que ha
sobrevivido hasta la actualidad sin modificaciones en su diseño, adaptándose a
cambios significativos en su medioambiente de operación a través de sucesivas
mejoras en sus mecanismos.
3. Objetivo, alcances y limitaciones
El objetivo principal de este trabajo es el desarrollo de una versión de TCP (a la que
denominamos JTCP), tal como se definió en el RFC 793 , a la cual pueda
incorporársele, de manera simple y modular, la funcionalidad (relativa a control de
congestión) de las diferentes versiones existentes de TCP (Tahoe, Reno, etc), De esta
manera será posible evaluar el comportamiento de diferentes alternativas para el
control de congestión en condiciones reales, es decir, comunicando las dos partes
del protocolo a través de la Internet. De igual manera, es posible incorporar
modificaciones a estos mecanismos ya existentes y desarrollar nuevas heurísticas,
las cuales podrán ser codificadas y agregadas a JTCP sin mayor esfuerzo, para
finalmente ser evaluadas en su ambiente real de operación.
4. Aspectos de importancia en el mecanismo de control de congestión de TCP
El objetivo de los mecanismos de control de congestión de TCP es ofrecer a la
aplicación el mayor ancho de banda posible, sin interferir con otros protocolos que
hacen uso de la red, ni saturar a ésta con exceso de información.

Podemos distinguir los siguientes mecanismos

 Mecanismos que permitan alcanzar en el menor tiempo posible y sin riesgo
de saturar a la red, la tasa máxima posible de envío (slow start y congestion
avoidance)
 Un método para calcular la máxima tasa de envío, sin saturar al receptor
(ventana deslizante de tamaño variable). Reacción rápida ante pérdidas de
bloques, antes de recurrir a los mecanismos de retransmisión (fast
retransmit)
 Método para regular el tráfico después de la detección de una pérdida,
hasta la normalización de la situación (fast recovery).
 Una manera de evitar sobrecargar la red con confirmaciones (ACKs) para
los bytes bien recibidos, pero que sin embargo no incurra en demoras tales
que originen retransmisiones innecesarias (algoritmo de retraso de
confirmaciones).
 Una manera de detectar la información enviada que no ha sido recibida por
el receptor, y retransmitirla (mecanismos de retransmisión).
 Un método para estimar el tiempo de ida y vuelta de los segmentos entre
los dos hosts involucrados en la conexión TCP. Un método que permita
estimar, en base al tiempo de ida y vuelta, el tiempo máximo de espera para
una retransmisión.
  Protección contra el envío de caracteres aislados o la actualización de
ventana en pequeñas cantidades de caracteres, lo cual produciría el envío
de segmentos con muy poca información (algoritmos silly window
syndrome, y de Nagle).

6. Estado actual, conclusiones y continuación del trabajo

JTCP constituye el primer paso en un proyecto cuyo objetivo final es la investigación
relacionada con el control de congestión en TCP. Los objetivos finales son la evaluación
de los mecanismos de control de congestión existentes en TCP, y la implementación de
nuevas heurísticas que permitan mejorar y adaptar TCP a nuevos medios de
comunicación y/o nuevos requerimientos de las aplicaciones.

El objetivo fijado para esta primera etapa, el desarrollo de un TCP portable con un diseño
que permite introducir fácilmente nuevos mecanismos, ha sido alcanzado
satisfactoriamente con el desarrollo de JTCP.

El lenguaje utilizado, Java, seleccionado en principio por razones de portabilidad,

demostró ser efectivo para este proyecto, tanto por razones de performance como por
características tales como manejo de threads de ejecución y soporte para timers. Es de
destacar que debido a la información de carácter general contenida en el RFC 793, fue
necesario recurrir a implementaciones “reales” en ciertas ocasiones[15]. Sin embargo,
estas últimas sólo fueron de utilidad para comprender los mecanismos de TCP, ya que
el código, contrariamente al de esta implementación, presenta una complejidad
considerable debido a la necesidad de lograr un proceso eficiente y a su interacción con
el sistema operativo

Explorando posibles mejoras de protocolo TCP en redes móviles

Introducción
TCP [1] es un protocolo orientado a la conexión, seguro y el más utilizado en la capa de
transporte. Soporta la mayoría de las aplicaciones más populares de internet.
Este protocolo fue desarrollado y posteriormente optimizado para redes cableadas, lo
que implica que la perdida de paquetes se debe casi con exclusividad a la congestión en
la red, suponiendo una tasa de error de bits, en tránsito, prácticamente inexistente.[4]

Dentro de las implementaciones de TCP existentes, se destacan:

 TCP Tahoe: Posee los algoritmos de slow start y congestion avoidance y
posteriormente se le agrego el algoritmo de fast retransmit. La principal
desventaja de esta implementación es que cada vez que se pierde un segmento,
comienza nuevamente con el algoritmo de slow start, lo que demora demasiado
el retorno al valor de las tasas anteriores.
 TCP Reno: Cuando se detecta congestión, el TCP Tahoe reduce la ventana de
congestión a un segmento lo que dispara el algoritmo de slow start, mientras
que TCP Reno dispara el algoritmo de Fast Recovery, reenviando el paquete
perdido y reduce el umbral a la mitad, evitando disparar el algoritmo de slow
start. Cuando recibe un nuevo ACK, sale de fast rocovery y dispara el algoritmo
de congestión avoidance. Esto permite que se recupere más rápido de la
congestión.
 TCP New Reno: La optimización en esta versión de TCP mejora la pérdida
individual y aislada de segmentos pero no mejora las pérdidas en segmentos
sucesivos. La diferencia con el TCP Reno es que cuando se está en la etapa de
fast recovery, el arribo de uno nuevo ACK no hace que se salga de esta, hasta
 que todos 178 los segmentos pendientes de confirmar antes del disparo del
algoritmo tengan su acuse de recibo. De esta forma un ACK parcial implica que
el segmento siguiente se perdió y debe ser retransmitido.[4]

Líneas de Investigación, Desarrollo e Innovación

El protocolo TCP es claramente el más utilizado en sistemas de transmisión

sobre redes de datos. Sin embargo, la evolución de los sistemas de
comunicaciones ha generado una serie de variantes en las cuales se mezclan
sistemas cableados con wireless, o sencillamente redes wireless con nodos de
mucha movilidad.

Esta combinación ha dado origen a nuevos problemas basados

fundamentalmente en la enorme diferencia de tasa de errores que
normalmente estos dos sistemas tienen, más los problemas típicos de
desconexión de las redes wireless. Estos problemas han puesto en un verdadero
aprieto a la versión original del protocolo TCP, el cual ha sido modificado,
generado 180 distintas versiones que tienden a dotar de estabilidad a este
protocolo bajo las distintas variantes de conexionado.

En este contexto, diferentes grupos de investigación siguen proponiendo

distintas modificaciones o técnicas que tienen a mejorar las condiciones de
comunicación. Sin embargo, es muy dificultoso llegar a una solución general
debido a la heterogeneidad de las topologías, las variantes de los sistemas de
comunicación y particularmente los diferentes requerimientos que existen
sobre los distintos tipos de redes de datos [4]

Resultados y Objetivos
Si bien el presente proyecto aún no ha registrado un grado de avance que
permita mostrar resultados, el análisis de las soluciones existentes posibilita
inferir que las constantes modificaciones del protocolo TCP para mejorar su
rendimiento en medios wireless, plantea la seria posibilidad de desarrollar un
nuevo protocolo que ataque de cero la problemática.

En tal sentido las soluciones existentes del protocolo TCP que contempla una
reacción proactiva, parece ser la más adecuada. Por ello las soluciones
propuestas por protocolos como el TCP Vegas y RED (Random Early Detection),
que reaccionan variando la ventana de congestión en función de prever el
estado de congestión de la red analizando el RTT de cada paquete o variando el
descarte de tramas en función del estado del buffer de retransmisión, parecen
ser un buen punto de partida en desarrollos que se adapten a las exigentes
demandas de las redes wireless. [4]

Bibliografía

[1] L. Vidal and L. Alves, “TCP sobre enlaces wireless Problemas y algunas posibles soluciones
 existentes.”
[2] A. Díaz, J. C. Gonzales, and M. E. Ruiz, “IMPLANTATION OF A SYSTEM ERP IN AN
ORGANIZATION.”
[3] G. Rigotti, “JTCP: una implementación de TCP orientada a la evaluación de técnicas de
control de congestión.”
[4] D. R. Rodríguez, H. Carlos, A. Talay, and L. Marrone, “Explorando posibles mejoras de
protocolo TCP en redes móviles.”