UNIVERSIDAD ANDINA DEL CUSCO

FACULTAD DE INGENIERIAS Y ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

TEMA:

“WANEM y Protocolos de Control de Congestionamiento VENO-WESTWOOD”

CURSO: Redes y Comunicación de Datos II

DOCENTE: Ing. Edwin Carrasco Poblete.

ALUMNOS:

● Hancco Cruz, Nair Estefani

● Ticona Huaman, Jhon Andree

CUSCO - PERÚ

2019

PRESENTACIÓN
Mediante el presente trabajo buscamos dar a conocer los diversos algoritmos que
se presentan en cuanto al control de congestión, teniendo ya diversos algoritmos en
este caso consideraremos a dos que son Veno y Westwood, veremos las
características que estos algoritmos presentan de igual manera veremos las
diferencias y similitudes que presentan en cuanto a ancho de banda, velocidad y
rendimiento, para todo ello incluiremos algunas pruebas y por último la
experimentación la cual nos permitirá dar una conclusión mucho más acertada en
cuanto a estos algoritmos para determinar cuál es el mejor.
 INTRODUCCIÓN

Los algoritmos de control de congestionamiento son parte importante del protocolo

de transporte TCP debido a que regulan la pérdida de paquetes de tal forma que la
información sea transmitida de la forma más fiable posible.

WestWood aporta notables mejoras en el control de congestión en redes

inalámbricas, estimando la banda disponible para reducir oportunamente la Ventana
de Congestión cuando se verifica una congestión, por otro lado Veno reduce su
ventana a la mitad de su valor actual, si no es así, el protocolo deduce que la
pérdida de paquetes no se relaciona con congestión

En este trabajo se evaluó el desempeño respecto al RTT (Round Trip Time),

Window Scaling, el Throughput y el comportamiento del RTO (Retransmission Time-
Out) de los algoritmos de control de congestionamiento, WestWood y Veno.

Se presentan gráficos que fueron capturados con Wireshark que es un programa de

código abierto que permite analizar paquetes de datos en una red para encontrar
problemas, para desarrollar software y protocolos, y también como herramienta
educativa. WireShark captura el tráfico de una red y analiza los paquetes.
 ÍNDICE
Presentación
Introducción
Marco teórico
Protocolo TCP
Documentación de las implementaciones TCP que se evaluarán
Wanem
Diseño experimental
Descripción de escenario de pruebas
Especificación de equipos utilizados
Configuración del servidor
Configuración del cliente
Configuración de Wanem Formatos para la captura de datos
Experimentación
Tabulación de resultados de cada prueba
Explicación de resultados
Discusión de resultados
Conclusiones
Referencias
 CAPÍTULO I

1. MARCO TEÓRICO:

1.1. PROTOCOLO TCP

TCP es uno de los protocolos en internet, especificado en el RFC 793, es un

protocolo de transporte orientado por conexión que envía datos como un flujo de
bytes sin estructura, Usando los números de secuencia y los mensajes de
reconocimiento, el TCP puede proporcionar un nodo de envío con la información de
entrega sobre los paquetes transmitidos a un nodo de destino. La unidad base de
transferencia se denomina segmento, de tamaño máximo el denominado MSS
(Maximum Segment Size), expresado en octetos. Este protocolo permite ser más
complejo, fiable y orientado a la conexión, permite que dos máquinas que están
comunicadas, controlen el estado de la transmisión el cual garantiza que los datos
entregados a su destino no presenten errores y estén en el mismo orden que se
transmitió. Proporciona el servicio de comunicación aplicando los siguientes
mecanismos:

Transferencia de datos: Transmite un flujo continuo de bytes a través del sistema

de internet, la aplicación no debe preocuparse por dividir los datos en bloques
básicos o datagramas, TCP lo que hace es agrupar los bytes en segmentos TCP,
que son entregados al módulo ip para ser transmitidos al destino. TCP busca
segmentar los datos, además de poder saber cuándo bloquear y cuando enviar los
datos. A veces las aplicaciones necesitan estar seguras de que todos los datos que
habían entregado al módulo TCP han sido transmitidos, para ello se define una
función “push” (entrega inmediata) para así conocer que los datos transmitidos son
realmente entregados.

Fiabilidad: TCP debe poder recuperar los datos que se puedan corromper,
dupliquen, pierdan o se entreguen en desorden durante el proceso de
comunicación, esto se consigue asignando un número de secuencia a cada byte
transmitido y exigiendo un ACK (reconocimiento), si, no se recibe un ACK antes que
el temporizador expire, los datos se retransmitirá, el receptor utiliza números de
secuencia para así poder ordenar correctamente cada segmento que pueda haber
llegado desordenados y para eliminar segmentos duplicados.
Control de flujo: TCP es un protocolo que brinda al receptor el medio para poder
controlar la cantidad de datos enviados por el emisor, obligando a este retrasar la
transmisión cuando el receptor envía un ACK hacia el emisor, que indica el número
de bytes que puede recibir de acuerdo a su buffer interno, este mecanismo se
conoce como “Mecanismo de ventana deslizante”.

Multiplexación: TCP permite que dentro de un mismo host se pueda realizar

simultáneamente comunicaciones entre diferentes procesos, ya que TCP
proporciona una serie de direcciones o puertos dentro de cada host, esto se
concatena con las direcciones de red y de host de la capa de comunicación de
internet formando lo que se conoce como un “socket”.

Comunicación orientada a la conexión: Los mecanismos que usa TCP para

proporcionar fiabilidad, control de flujo, control de congestión, requiere que el
protocolo inicialice y mantenga en buffer cierta información sobre el estado del flujo
de datos, cuando todos estos indicadores se combinan surge el nombre de
“conexión”. Cada conexión está identificada por un par de “sockets” que identifica a
los dos extremos de la comunicación. Cuando dos procesos quieren comunicarse,
primero debe establecerse una conexión, y cuando la comunicación se ha
completado, la conexión se cierra liberando recursos.

Full Dúplex: TCP proporciona que el flujo de datos concurrente en ambas

direcciones.

Prioridad y seguridad: TCP permite dentro de sus aplicaciones indicar el nivel de

seguridad y prioridad de su comunicación.

1.2.DOCUMENTACIÓN DE LAS IMPLEMENTACIONES TCP QUE SE

EVALUARÁN

Existen varias versiones del protocolo TCP las cuales utilizan una estrategia de
control de la congestión multi-faceta, cada versión tiene diferente comportamiento
pues estos difieren en la manera de cómo es que detectan y reaccionan ante la
pérdida de paquetes.

1.2.1. Westwood
Westwood es un algoritmo de control de congestionamiento TCP basado en el
ancho de banda end-to-end estimado. Este estimado es obtenido filtrando los ACK
retornantes y es usado para cambiar adaptativamente el valor de las ventanas de
control cuando se presentan problemas de congestión.

Westwood es una modificación hecha al algoritmo New Reno únicamente del lado
de quien envía los paquetes con la intención de manejar mejor mayores tiempos de
demora en envió de paquetes a través de banda ancha.

Algoritmo de Westwood

El algoritmo Westwood está basado en la estimación del ancho de banda end-to-

end disponible durante la conexión TCP. Este estimado es obtenido del filtrado del
flujo de paquetes ACK retornantes y es usado para cambiar el valor de las ventanas
de control cuando la congestión es experimentada. En particular cuando 3
DUPACKs (duplicate ack nowledgenment) son recibidos, la ventana de congestión
(cwind) y el slow start threeshold (ssthresh) toman el valor del ancho de banda
estimado (BWE) por el menor RTT obtenido; cuando un timeout ocurre el ssthresh
toma su valor anterior y la cwnd toma el valor de uno.

En resumen:
· ACK recibido:
o Cwnd se incrementa en función al algoritmo reno
o El BWE estimado es calculado
· 3 DUPACKS recibidos:
o ssthresh=max⁡(2, (BWE*RTTmin) / (seg_size)
o cwnd=ssthresh
· Timeout:
o ssthresh=max⁡(2, (BWE*RTTmin) / (seg_size)
o cwnd=1
Pseudo Codigo:
3 DUPACKs Recibidos:
if (n DUPACKs are received)
ssthresh = (BWE * RTTmin)/seg_size;
if (cwin > ssthresh) /* congestion avoid. */
cwin = ssthresh;
endif
 end if
· Time Out
if (coarse timeout expires)
ssthresh = (BWE * RTTmin)/seg_size;
if (ssthresh < 2)
ssthresh = 2;
endif;
cwin = 1;

end if

1.2.2. Veno

Veno es módulo de control de congestionamiento para mejorar el desempeño de

TCP sobre redes inalámbricas. Es un mejoramiento sobre el algoritmo Reno usando
el estimado del estado de conexión basado en TCP Vegas.

Veno reduce la reducción “ciega” de la ventana TCP sin importar la causa de la

pérdida de paquetes. Esta versión de TCP distingue entre una pérdida cualquiera
(non-congestion state) y una pérdida por congestión (congestion state).
Dependiendo también de esta diferencia refina el ajuste de la ventana de
congestión.

En un entorno inalámbrico, la pérdida de paquete es a causa de ruido y errores de

link. Como Veno es lo suficientemente inteligente para diferenciarlos, evita el RTT
base para cambiarlos de tiempo en tiempo y así la conexión puede permanecer más
tiempo en la región operativa.

Algoritmo de Veno:
· Pérdida de Paquete para retransmisión rápida (3 DUPACKs recibidos)
if (DIFF*BaseRTT < β)
ssthresh =;
else if ssthresh = cwndloss /2 ;
· Time Out
o Ssthresh= cwndloss /2;
o Se pasa al estado slow start
· Rendimiento de Veno
 ·
Figura 1. Rendimiento de TCP Veno Control de Congestionamiento.

1.2.3. WANem

WANem es una herramienta para simular todo tipo de redes, simula el

comportamiento de una WAN dentro de una LAN y así poder ir a los clientes o
integrar entornos de una manera más real. Nos permite también crear una Máquina
Virtual que hará de “electrónica de red” intermedia entre dos nodos, dándonos así la
facilidad de simular todo tipo de entornos dentro de una red, se podrá simular y
obtener datos de típicos microcortes, pérdidas de paquetes, etc.

Para usar Wanem se debe contar con el appliance de código abierto WANem, el
cual es un LiveCD Knoppix de libre distribución que nos permite emular tantos
enlaces WAN que deseemos con sus diferentes características.

WANem permite que el equipo de desarrollo de aplicaciones para configurar una

puerta de enlace de aplicación transparente que puede ser utilizado para simular las
características WAN como retardo de red, pérdida de paquetes, la corrupción de
paquetes, desconexiones, paquetes de reordenamiento, Jitter, etc.WANem puede
ser utilizado para simular de área amplia condiciones de la red para el tráfico de
datos / voz y es liberado bajo la licencia GPL v2 ampliamente aceptable. por lo tanto
WANem proporciona la emulación de las características de red de área extensa y
por lo tanto permite que las aplicaciones de datos / voz a ensayar en un entorno
realista WAN antes de que se mueven en la producción a un coste asequible.
 Figura 2. Interfaz WANem.

CAPÍTULO II

2. DISEÑO EXPERIMENTAL

2.1.DESCRIPCIÓN DE ESCENARIO DE PRUEBAS

El escenario de pruebas se centra en el análisis y entendimiento de los algoritmos

de control de congestionamiento de TCP los propuestos para el grupo en este caso,
WestWood y Veno. Donde se tiene la existencia de una máquina servidor una
máquina cliente y una máquina que simule la WAN mediante WANem.

Figura 3. Descripción gráfica del cómo opera WANem.

La prueba se desarrolló generando una transmisión tipo NFS con archivos de

tamaño de 100MB y 500MB.

2.2.ESPECIFICACIÓN DE EQUIPOS UTILIZADOS

Para el desarrollo de la simulación y estudio de los algoritmos de control de

congestión de TCP se utilizaron 3 máquinas (PC) la instalación y funcionamiento de
máquinas virtuales dentro de estas, a su vez la utilización de 2 cables de tipo
cruzado categoría 5. Se requirió la instalación de Debian en su última versión
estable, el liveCD de WANem beta 3.0 y una máquina adicional Windows para
capturar los datos.

2.3. CONFIGURACIÓN DEL SERVIDOR

2.3.1. Instalación del servicio VSFTP.

Figura 4. Instalación del servicio VSFTP.

2.3.2. Instalación de NFS

Instalación de los paquetes NFS con los comandos.

2.3.3. Configuramos TCP

Se configura en esta dirección según el protocolo de control de congestión, para

verificar el protocolo de control de congestionamiento activo en Debian utilizamos el
comando:

2.3.4. Configuración de IP

Configuramos al servidor con la IP 4.0.0.2, mask 255.0.0.0 y gateway 4.0.0.1 con el

comando nano /etc/network/interfaces.
2.3.5. CONFIGURACIÓN DEL SERVICIO DE TRANSFERENCIA DE ARCHIVOS

A. Configuración del servidor NFS, se creará una carpeta llamada compartir/

con el comando mkdir /home/andree/compartir, en dicha dirección.

B. De ahí con el siguiente nano /etc/exports y luego se restaura el servicio de

NFS, con el comando /etc/init.d/nfs-kernel-server restart

C. En el comando nos aparecerá un archivo en el cual se editará por el

comando nano /etc/exports, en donde se colocara la dirección del archivo
creado, se colocará el ip de cliente con los siguientes parámetros para luego
poder guardarlos.

D. La carpeta compartir/ nos permitirá ser el repositorio creado por NFS para
compartir archivos entre máquinas.

2.3.6. PRUEBAS

PING y TRACEROUTE al cliente para verificar si está pasando por WANem:

2.3.7. Creación del archivo de 100 y 500 MB

Se crea 2 archivos y luego se reseteara el servicio nfs-kernel-server.

2.4. CONFIGURACIÓN DEL CLIENTE

2.4.1. Instalación del servicio VSFTP

Figura 5. Instalación del servicio VSFTP.

2.4.2. Instalación de NFS

Instalación de los paquetes NFS con los comandos.

2.4.3. Configuramos TCP

Se configura en esta dirección según el protocolo de control de congestión, para

verificar el protocolo de control de congestionamiento activo en Debian utilizamos el
comando:
En el caso del cliente se debe modificar el protocolo de control de congestión a los 2
propuestos los cuales son VENO y WESTWOOD respectivamente para cada una de
las 4 transferencias hechas.

2.4.4. Configuración de IP

Configuramos al servidor con la IP 5.0.0.2, mask 255.0.0.0 y gateway 5.0.0.1 con el

comando nano /etc/network/interfaces.

2.4.5. CONFIGURACIÓN DEL SERVICIO DE TRANSFERENCIA DE ARCHIVOS

A. Configuración del servidor NFS, se creará una carpeta llamada compartir-

cliente con el comando mkdir /home/andree/compartir-cliente, en dicha
dirección.
B. De ahí con el siguiente nano /etc/exports y luego se restaura el servicio de
NFS, con el comando /etc/init.d/nfs-kernel-server restart.
C. La carpeta compartir-cliente/ nos permitirá ser el repositorio creado por NFS
para compartir archivos entre máquinas.
D. Una vez creada la carpeta receptora de los archivos compartidos se montara
la dirección para poder visualizar los archivos que están en la carpeta con
NFS, se realiza con el siguiente comando, mount -t nfs
4.0.0.2:/home/andree/conpartir /home/andree/compartir-cliente/.
 E. Una vez montada hacemos un ls dentro de la dirección de
/home/andree/compartir-cliente/ y nos mostrará los 2 archivos.

F. Para poder realizar las pruebas de transferencia se tendrá que copiar y pegar
los archivos en una dirección dentro del disco del cliente, en este caso lo
copiamos al escritorio, con el comando cp (100MB.txt/500MB.txt)
/home/andree/Escritorio/.

G. Por último se tendrá que capturar los datos con Wireshark.

Figura 6. Wireshark.

2.5. Configuración de WANem

Se creo una maquina virtual linux para WANem y se procedió a habilitar 2

adaptadores de red, para el servidor linux y el cliente linux respectivamente.

La configuración del WANem se realizó con las siguientes características:

2.5.1. Configuración de los puertos

se agrego y configuro los 2 adaptadores de red.

Figura 7. Crear WANem y habilitar 2 puertos, Cliente y Servidor.

2.5.2. Configuración de los Network Connection

En Auto eth0 y Auto eth1 respectivamente, para el servidor la IP: 4.0.0.1, MASK:
255.0.0.0 y para el cliente la IP: 5.0.0.1, MASK: 255.0.0.0.

Figura 8. Configuración de Auto eth0 y Auto eth1 respectivamente.

2.5.3. Configuración de WANem

Delay Time (ms) =144, Jitter(ms)=6, Loss(%)=5, para el cliente en el puerto eth1.
 Figura 9. Configuración de delay time (ms), Loss(%) y jitter(ms).

2.5.4. Verificación de conexión con el cliente y servidor

Se realizó PING a los 2 ordenadores CLIENTE y SERVIDOR.

Figura 10. PING a los puertos de servidor y cliente.

CAPÍTULO III

3. Experimentación

3.1. Tabulación y explicación de resultados de cada prueba

3.1.1. VENO 100 MB

Resultados wireshark:

Window scaling:

Throughput:

RTT(ROUND-TRIP-TIME):
Tiempo y cantidad transportada:

RTO(Retransmission time-out):

Gráfico de RTO:
Paquete 122897 (2400s = 57)
Archivo en la ruta /home/andree/Escritorio/

3.1.2. VENO 500 MB

Resultados wireshark:

Window scaling:

Throughput:
RTT:

Tiempo y cantidad transportada:

RTO:
Gráfico de RTO:

Paquete 508139 (9960s = 17)

Archivo en la ruta /home/andree/Escritorio/

3.1.3. westwood 100MB

Resultados wireshark:

Window scaling:

Throughput:
RTT:

Tiempo y cantidad transportada:

RTO:
Gráfico de RTO:
Archivo en la ruta /home/andree/Escritorio/

3.1.4. westwood 500MB

Window scaling:
Throughput:

RTT:
Tiempo y cantidad transportada:

RTO:
Gráfico de RTO:

Archivo en la ruta /home/andree/Escritorio/

CAPÍTULO IV

4. DISCUSIÓN DE RESULTADOS

Siendo un versión más reciente que ha de RENO y otra de uso común, controla
los parámetros mejor, ayudando a la transmisión y calidad general de navegar
por internet. Uno de los algoritmos más justos y más eficientes hasta la fecha.

CONCLUSIONES

-Westwood al igual que TCP Reno no puede distinguir si la pérdida del paquete se
debe a una congestión del enlace o a un error puntual causado por un aumento
súbito del BER debido a la atenuación puntual de la señal del enlace.

-El comportamiento de la variante TCP westwood puede aumentar el rendimiento

del protocolo TCP ante un entorno ruidoso como puede ser un enlace satélite sujeto
a condiciones atmosféricas adversas respecto a TCP Reno

-Veno es la combinación de dos TCP opuestos(Reno y Vegas)esta unión es para

intentar evitar falsas pérdidas por congestión en redes móviles.
BIBLIOGRAFÍA

● Agulló, D., Guerra, M. C., Silva, F., & Vivanco, R. (2012). Seguridad e
integridad de la transferencia de datos.
● Cardwell,N & Yuchung,C.(2017). BBR: Congestion-Based Congestion
Control. Communications of the ACM, 60, 58-66. Marzo 15,2018, De
https://cacm.acm.org/magazines/2017/2/212428-bbr-congestion-based-
congestion-control/fulltext Base de datos.
● Cardwell,N. (2017). Control de congestión BBR. Recuperado Marzo 12,2018,
de Corporación Google Sitio web: https://tools.ietf.org/html/draft-cardwell-
iccrg-bbr-congestion-control-00#section-4
● Cardwell,N. (2017). El control de congestión TCP BBR llega a GCP: su
Internet se hizo más rápido. Recuperado Marzo 12,2018, de Google Sitio
web: https://cloudplatform.googleblog.com/2017/07/TCP-BBR-congestion-
control-comes-to-GCP-your-Internet-just-got-faster.html