A Avaliação de Desempenho

UTILIZANDO O NETWORK SIMULATOR PARA ANÁLISE DE SCRIPTS TCL

        

1 INTRODUÇÃO

        O Network Simulator é um simulador de eventos discreto resultante de um projeto conhecido como VINT (Virtual InterNetwork Testbed). É totalmente gratuito e com código fonte aberto. Este simulador oferece suporte à simulação de um grande número de tecnologias de rede (com e sem fio), diferentes cenários baseados nos protocolos TCP e UDP, diversas políticas de fila, caracterização de tráfego com diversas distribuições estatísticas e muito mais.

         A programação do NS é feita em duas linguagens: C++ para a estrutura básica (protocolos, agentes, etc) e OTCL (Object-oriented Tool Command Language) para uso como frontend. C++ é uma linguagem robusta para a manipulação de bytes, pacotes e para implementar algoritmos que rodem um grande conjunto de dados. Já o OTCL é uma linguagem interpretada, desenvolvida pelo MIT, com a qual serão escritas efetivamente as simulações.

        Uma simulação com o NS consiste basicamente de 5 etapas: Planejamento da simulação, definição dos nós, definição da ligação entre os nós (topologia), definição do tráfego de rede e análise de resultados.

2 O PROBLEMA

        A atividade proposta é a análise de um script do tipo TCL para simulação no NS. Neste script foram implementados 4 nós: n0, n1, n2 e n3. O nó n0 e o nó n1 enviam dados que são recebidos pelo nó n3 e que devem passar necessariamente pelo nó n2 conforme figura abaixo:

[pic 1]

Figura: Topologia da Simulação

         Foram definidos 3 links (ou enlaces) duplex, entre os nós. O enlace entre o nós n0 e n1 e o enlace entre os nós n1 e n2 têm velocidade de 1Mb/s com atraso de 10ms e Política de Fila do tipo DropTail (First In, First Out). Já o terceiro enlace, entre o nó n2 e n3 implementa uma Política de Fila do tipo SFQ (Stochastic Fair Queuing) e também utiliza velocidade de 1Mb/s.

        Para o tráfego de dados foi utilizado o protocolo UDP (User Datagram Protocol) nos nós emissores. Os dois emissores (nós 0 e 1) utilizam aplicações do tipo CBR (Constant Bit Rate), que geralmente são utilizadas por aplicações de streaming de áudio e vídeo. O nó n0 inicia o envio de dados em 0.5s e finaliza em 4.0s. Já o nó n1 envia dados em 1.0s e finaliza o envio em 4.5s. A aplicação é finalizada em 5s.

        O problema da topologia descrita é que os nós emissores (n1 e n2) compartilham um mesmo canal de velocidade igual (1Mb/s) após o nó 2, o que ocasiona um gargalo na rede, acumulando pacotes e a eventual perda de pacotes após o preenchimento total da fila.

3 SOLUÇÕES PROPOSTAS

        A proposta inicial adotada foi uma mudança de política de filas no link que conecta o nó n2 ao nó n3. As políticas de fila testadas foram a DTQ (Drop Tail Queue), RED (Random Early Detection), DRR (Deficit Round Robin) e FQ (Fair Queuing) foram utilizadas como tentativas de diminuir ou findar a perda de pacotes no link.

        As políticas DTQ, RED e DRR apresentaram resultados ineficazes. A FQ foi a única que diminuiu a perda de pacotes. Apesar da FQ não ser muito recomendada para aplicações de áudio e vídeo devido a seu alto delay, houve um atraso de 0.6s para o início da perda de pacotes. Utilizando o SFQ, havia perda de pacotes a partir de aproximadamente 1.2s após o início da simulação. Após a implementação do FQ, a perda de pacotes passou a acontecer a partir de 1.8s.

...