TraceMetrics - Uma ferramenta para a obtenção de medidas de interesse no ns-3

Transcrição

1 972 Anais TraceMetrics - Uma ferramenta para a obtenção de medidas de interesse no ns-3 Luiz Felipe Z. Saggioro 1, Flavio B. Gonzaga 12, Reuel R. Ribeiro 1 1 Núcleo de Ciência da Computação Universidade Federal de Alfenas (UNIFAL-MG) Alfenas - MG, Brazil 2 Programa de Engenharia de Sistemas e Computação, COPPE Universidade Federal do Rio de Janeiro (UFRJ) Caixa Postal 68511, Rio de Janeiro - RJ, Brazil {a07022, fbgonzaga, reuel}@bcc.unifal-mg.edu.br Abstract. The simulation is a artefact widely used in research on Computer Networks. In this sense, one of the most popular simulators and open source is the Network Simulator 3 (ns-3). This paper proposes a tool called TraceMetrics which works together with the ns-3, performing statistical and performance analysis. The results show that the tool already offers a pretty wide range of metrics, and support protocols developed so far in the simulator. Resumo. A simulação é um artefato muito utilizado em pesquisas de Redes de Computadores. Nesse sentido, um dos simuladores mais populares e de licença livre é o Network Simulator 3 (ns-3). O presente trabalho propõe uma ferramenta chamada TraceMetrics que trabalha juntamente com o ns-3, realizando a análise estatística e de desempenho da simulação desenvolvida. Os resultados mostram que a ferramenta já oferece um leque consideravelmente amplo de métricas, bem como suporte aos protocolos desenvolvidos até o momento no simulador. 1. Introdução Simular um modelo probabilístico envolve gerar meios estocásticos para o modelo e então observar os resultados ao longo do tempo [Trivedi 2008]. A simulação de eventos discretos envolve o acompanhamento de algumas variáveis, geralmente ligadas a tempo e estado. Sempre que um evento ocorre, os valores das variáveis são alterados ou atualizados e são coletados os dados importantes para a simulação[ross 2006]. A ferramenta aqui proposta, denominada TraceMetrics tem como objetivo ser mais uma alternativa na obtenção de medidas de interesse em simulações realizadas no software Network Simulator 3 (ns-3) 1. Para calcular as medidas, a ferramenta TraceMetrics realiza a análise do arquivo trace (que será melhor detalhado na seção 3) e obtém, à partir dele, medidas de interesse usadas em pesquisa de Redes de Computadores. A escolha do ns-3 como base desse trabalho se deve ao fato do mesmo ser um novo simulador, mas que surge com algumas vantagens em relação ao já difundido ns-2 2,

2 XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 973 como: manipular nós com múltiplas interfaces de rede, detalhar mais o modelo , dentre outras[ns 3 project 2012]. A licença GNU GPLv2 segue como atrativo em ambos os simuladores. 2. Trabalhos relacionados, justificativa e motivação Quando o ns-3 foi lançado, o desenvolvimento de um framework estatístico para a realização da análise dos dados era ainda tido como uma proposta futura (mas já existente hoje). Nesse período, a principal contribuição foi a classe FlowMonitor [Carneiro et al. 2009]. Nesta seção serão detalhados ambos os trabalhos, além do diferencial do TraceMetrics FlowMonitor No FlowMonitor o tipo de análise executada vai contra a leitura de arquivo trace. Ao invés disso, o FlowMonitor deve ser instanciado na simulação, e todos os dados são coletados em tempo de execução. O FlowMonitor então manipula uma série de variáveis de soma, através das quais, ao término da simulação, as medidas podem ser obtidas. Por exemplo, para se calcular a média da variação de atraso: jitter = jittersum rxpackets 1 (1) onde: jittersum: Soma das variações de atraso para todos os pacotes recebidos no fluxo; rxpackets: Soma do número de pacotes recebido no fluxo. O FlowMonitor apresenta então duas vantagens principais: realizar uma análise rápida; necessitar de pouca alteração no script da simulação para funcionar. A sua principal desvantagem é não fornecer suporte para o cálculo de medidas que precisem do conhecimento de todos os pacotes armazenados, como por exemplo, a variância do atraso Framework Estatístico O Framework 3 trabalha basicamente com a manipulação de dois coletores de dados: um contador e um observer de min/max/avg/total. De forma semelhante ao FlowMonitor, o Framework em questão procura um melhor desempenho e evita trabalhar com arquivos trace. A desvantagem em comparação com o FlowMonitor está no fato de que ele requer mais alteração no código fonte do script da simulação. O Código Fonte 1, retirado da seção example da página dessa ferramenta, ilustra um pouco o tipo de modificação que precisa ser feita. Aqui, um contador está sendo anexado à camada WIFI MAC no nó 1. Code 1. Exemplo de uso do framework estatístico 1 P t r<p a c k e t C o u n t e r C a l c u l a t o r > t o t a l R x = 2 C r e a t e O b j e c t<p a c k e t C o u n t e r C a l c u l a t o r >() ; 3 t o t a l R x >SetKey ( "wifi-rx-frames" ) ; 4 Config : : Connect ( "/NodeList/1/DeviceList/*/$ns3::WifiNetDevice/Rx", 3

3 974 Anais 5 MakeCallback(& P a c k e t C o u n t e r C a l c u l a t o r : : FrameUpdate, 6 t o t a l R x ) ) ; 7 d a t a. A d d D a t a C a l c u l a t o r ( t o t a l R x ) ; 2.3. TraceMetrics - Justificativa e motivação A ferramenta TraceMetrics tem então como objetivo a análise do arquivo trace gerado pelo simulador para a obtenção das métricas. A desvantagem desse tipo de análise está justamente no desempenho, pois são necessários acessos a disco e armazenamento de informações em memória. Contudo, a principal vantagem está na flexibilidade, pois uma vez que se tem o registro de tudo o que aconteceu na simulação, pacote a pacote, podese calcular qualquer medida que se deseje. Outro fator positivo é que a única alteração necessária no código fonte da simulação é o acréscimo de linhas para indicar que se deseja gerar o arquivo trace no formato ascii. No exemplo, retirado da documentação do simulador 4, basta adicionar as duas seguintes linhas antes da chamada Simulator::Run () no código fonte para que toda a atividade ocorrida em todos os nós ponto-a-ponto da simulação em questão seja gravada. 1 A s c i i T r a c e H e l p e r a s c i i ; Code 2. Habilitar a geração de arquivo trace. 2 p o i n t T o P o i n t. E n a b l e A s c i i A l l ( a s c i i. C r e a t e F i l e S t r e a m ( "myfirst.tr" ) ) ; Assim, observa-se um tradeoff entre desempenho e quantidade de métricas calculadas. A Figura 1 exibe essa ideia. Desempenho FlowMonitor\ Framework TraceMetrics Métricas Figura 1. Comparação conceitual entre ferramentas. Para o ns-2 já existem algumas ferramentas que fazem esse tipo mais detalhado de análise [Salleh et al. 2006], mas para o ns-3, essa é ainda uma lacuna não preenchida. A ferramenta TraceMetrics, proposta nesse trabalho, pode ser obtida em: 3. Funcionalidades Conforme já citado, a ferramenta proposta trabalha analisando linha a linha do arquivo trace gerado pelo ns-3. Cada linha do arquivo possui a seguinte estrutura, que foi dividida para facilitar o entendimento: html 4

4 XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Code 3. Exemplo de linha do arquivo trace. 3 / NodeList / 0 / D e v i c e L i s t / 0 / $ns3 : : P o i n t T o P o i n t N e t D e v i c e / TxQueue / Enqueue 4 ns3 : : PppHeader ( 5 P o i n t to P o i n t P r o t o c o l : IP ( 0 x0021 ) ) 6 ns3 : : Ipv4Header ( 7 t o s 0 x0 t t l 64 i d 0 p r o t o c o l 17 o f f s e t 0 f l a g s [ none ] 8 l e n g t h : > ) 9 ns3 : : UdpHeader ( 10 l e n g t h : > 9 ) 11 Payload ( s i z e =1024) Onde: linha 1: mostra o tipo de evento que ocorreu. Segundo o manual do ns-3, os eventos podem ser de quatro tipos: +: um pacote foi colocado na fila da interface de transmissão; -: um pacote foi retirado da fila da interface de transmissão (tempo em que foi transmitido); d: um pacote foi descartado; r: um pacote foi recebido. Contudo, além desses quatro tipos, a equipe que desenvolve o TraceMetrics encontrou em arquivos traces resultantes de redes Wireless ou redes que utilizem a clsase Ipv4 L3 5 um quinto tipo: t. Nesse caso, não se observa eventos + ou - de fila. Apenas o evento t denotando o momento em que o pacote foi transmitido; linha 2: exibe o tempo em que o evento ocorreu. O arquivo é organizado de forma cronológica, de modo que ao se analisar duas linhas, a linha seguinte terá sempre o tempo maior ou igual a linha anterior; linha 3 em diante: apresentam os cabeçalhos do pacote em questão. Vale observar ainda na linha 3, /NodeList/0 indica que é o nó 0 quem está desempenhando a ação. Cada nó na rede será numerado de forma única. Onde se tem /DeviceList/0 indica que é a interface de rede 0. Em caso de mais de uma interface de rede em um mesmo nó, uma delas será identificada como 0, outra como a 1, e assim por diante. Outras informações que podem ser extraídas nessas linhas são os protocolos usados (PPP, IP e UDP), e informações de cada um, a exemplo dos endereços IP de origem e destino; Nas medidas em que o TraceMetrics oferece suporte, as mesmas foram divididas como sendo de dois tipos: Medidas calculadas por nó na simulação, e as calculadas por fluxo. O TraceMetrics possibilita assim o cálculo das seguintes métricas: html nó: Quantidade e tamanho médio dos pacotes enviados, recebidos e descartados; Quantidade de dados enviados, recebidos e descartados; Cálculo da Lei de Little [Gonzaga and Saggioro 2010]: Número médio de elementos no sistema (E[N]); Tempo médio de espera de cada elemento no sistema (E[W]); Média de pacotes enfileirados por segundo (λ); Throughput e Goodput; 5

5 976 Anais fluxo TCP: Atraso fim-a-fim por pacote, média e variância (Delay); IPDV (Inter-Packet Delay Variation) e PDV (Packet Delay Variation) 6 e respectivas variâncias; fluxo UDP: Análise de sequências de descarte de pacotes: em trabalhos de transmissões de tempo real, saber apenas a quantidade de pacotes descartados não é suficiente. Exemplo: vinte pacotes descartados aleatoriamente talvez não reflita em uma perda considerável da qualidade, mas se forem descartados em sequência, provavelmente terá um efeito indesejado 7. Quantidade x de vezes em que uma quantidade y de pacotes foi descartada em sequência durante a simulação. Esse raciocínio é apresentado na forma de uma distribuição de probabilidade; Para conexões UDP ainda não é possível calcular medidas relacionadas a atraso, pois o protocolo não possui um campo de número de sequência em seu cabeçalho que permita rastrear o pacote desde a sua origem até o destino. Quando se precisa dessa funcionalidade, uma alternativa é usar o protocolo RTP (Real Time Protocol) associado ao UDP. Contudo, o protocolo RTP está em fase de desenvolvimento no ns-3. Diagramas de classe da ferramenta (que ilustram mais detalhes de implementação) podem ser acessados em: Cálculos das métricas O primeiro desafio a ser superado para que as medidas possam ser calculadas (especialmente as que são fim-a-fim) é rastrear um pacote à medida que seus eventos são registrados. Para isso, foi definida uma assinatura à partir das informações do pacote. A chamada assinatura do pacote são informações que o torna único, e que não mudam mesmo à medida que ele passa pelos nós. A assinatura do pacote ficou então definida como sendo as informações da camada de rede pra frente, desconsiderando-se apenas o campo TTL do IP. A Figura 2 mostra um exemplo. r /NodeList/2/DeviceList/1/\$ns3::PointToPointNetDevice/MacRx ns3::ipv4header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 1645 protocol 17 offset (bytes) 0 flags [none] length: $>$ ) ns3::udpheader (length: $>$ 9) Payload (size=900) Figura 2. Pacote e assinatura destacada. Um cenário interessante acontece caso se esteja usando o TCP e aconteça uma retransmissão de um pacote perdido. A retransmissão originará um pacote semelhante ao anterior descartado, mas ainda de assinatura diferente. Isso porque o campo ID do cabeçalho IP será diferente. Para identificar que um pacote chegou no seu destino, duas condições precisam ser verdadeiras. O mesmo precisa aparecer em um evento r, e não pode aparecer na linha seguinte, uma vez que o ns-3 não considera atraso de processamento. Assim, se um pacote estiver passando por um roteador, por exemplo, ele aparecerá em pelo menos duas linhas consecutivas com o mesmo tempo. Uma com evento r e outra com evento +,

6 { XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 977 representando o recebimento no roteador, e a inserção do mesmo em alguma das interfaces de saída respectivamente. Em caso de recebimento no destino final, a linha com r não será sucedida por nenhum outro evento do mesmo pacote e com tempo igual, uma vez que o pacote não será enfileirado para ser repassado. A Figura 3 exibe a interpretação de uma sequência de eventos. atraso de fila recepção { recepção no roteador { {r > > > r atraso de propagação Figura 3. Interpretação de tempos e eventos no arquivo trace. Por fim, para que o TraceMetrics seja capaz de calcular corretamente o tamanho do pacote, cada protocolo que a ferramenta dá suporte precisou ter seu cabeçalho analisado, uma vez que nem todos os protocolos possuem um campo tamanho (length) em seu cabeçalho. Logo, protocolos que não trazem essa informação, precisam ter a mensagem analisada, e o seu respectivo tamanho obtido pela ferramenta. A lista de cabeçalhos suportados pode ser visualizada em: net/supportedprotocols. 4. Obtenção de resultados com a ferramenta Apenas como exemplo, foi criada uma topologia no ns-3 a fim de que as métricas fossem calculadas (e matematicamente verificadas). A Figura 4 mostra a topologia em questão. O tempo de simulação foi de segundos. No tempo 0 é criado um fluxo UDP com taxa CBR de 500 Kbps do nó 0 para o nó 3. No tempo 500 segundos é iniciada uma conexão TCP, com taxa de 450 Kbps do nó 1 para o nó 3. Acontecerá portanto uma ocupação de 95% em uma parte da simulação. As taxas contemplam apenas dados, desconsiderando cabeçalhos. Cada conexão envia pacotes com 1000 Bytes de dados mais overhead de cabeçalhos, que para UDP somam 30 Bytes (8 UDP + 20 IPv4 + 2 Point to Point), e para TCP somam 42 Bytes (20 TCP + 20 IPv4 + 2 Point to Point). O arquivo trace produzido ficou com 276,338 MBytes. A análise do mesmo pela ferramenta levou 1 minuto e 34 segundos. Figura 4. Topologia simulada. A Tabela 1 exibe alguns dos resultados obtidos pelo TraceMetrics.

7 978 Anais Tabela 1. Resultados por nó. nó E[N] E[W] λ Throughput(Kbps) Goodput(Kbps) Descartes 0 0,0000 0, , , , ,1268 0, , , , ,4166 0, , , , ,0000 0, ,3735 9,1975 0, Validação dos resultados Para verificar a corretude dos resultados obtidos, pode-se recorrer ao script de simulação. Configurado para fazer uma simulação de segundos, o ns-3 terminou a simulação no tempo de 1.000,64 segundos. Os fluxos TCP e UDP param de enviar dados no tempo Assim, o valor de λ que é a taxa média de chegada de pacotes, pode ser obtida no UDP (por não realizar controle de fluxo ou congestionamento), segundo a fórmula 2: λ = pcksec tmpstream tmpsimu (2) Onde: pcksec: taxa de pacotes enviados por segundo enquanto o fluxo UDP está ativo (que neste cenário é igual a 500Kbits resultando em 62,5 pacotes; 1.000Bytes tmpstream: tempo de duração do fluxo, que nesse cenário é igual a segundos; tmpsim: tempo de duração da simulação, que foi de 1.000,64 segundos. Aplicando o raciocínio, obtém-se como resultado uma taxa λ = 62,46, que conferindo com o valor obtido no fluxo UDP. Os valores obtidos nas colunas de Throughput e Goodput em todos os nós podem ser obtidos através de λ tampct, onde o tampct será de Bytes para Goodput. Para Throughput deve-se acrescentar a esse valor o tamanho dos cabeçalhos. Pode-se verificar também que a Lei de Little valida todas as linhas apresentadas na tabela, onde E[N] = λ E[W]. Pequenas diferenças na igualdade acontecem em virtude de se considerar apenas 4 casas decimais na tabela. Na ferramenta, a igualdade confere até a nona casa decimal para esse cenário Analisando a sequência de descartes do UDP exibida no relatório da ferramenta, pode-se constatar que dos 33 pacotes descartados pelo nó 2, 24 foram UDP (enquanto que os outros 9 TCP), e nenhum deles em sequência. Ao se verificar os dados da conexão TCP, descobriu-se que pacotes foram transmitidos, com os seguintes valores para atraso, PDV e IPDV: Atraso médio: 0,432572, Variância do atraso: 0,016130; PDV médio: 0,412572, Variância do PDV: 0,016130; IPDV médio: 1,662203E-7, Variância do IPDV: 2,483515E-5. Na Figura 5 (feita na ferramenta GnuPlot à partir dos dados obtidos no TraceMetrics) é feita uma análise do atraso fim-a-fim dos pacotes em função do tempo para o TCP. Verifica-se a redução do atraso em 9 pontos no gráfico, momentos nos quais houve o descarte, e a redução da taxa de TCP pela metade.

8 XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Atraso Atraso (s) Tempo (s) Figura 5. Atraso fim-a-fim. 5. Demonstração da Ferramenta No Salão de Ferramentas o TraceMetrics será apresentado com mais detalhes, onde mais alguns cenários com outros protocolos serão analisados, tais como Wireless e Ethernet. Como recurso será necessário um datashow para a apresentação. 6. Conclusões e trabalhos futuros O TraceMetrics se mostrou eficiente na análise do cenário gerado aqui, bem como nos exemplos do próprio ns-3, mostrando que possui potencial para auxiliar pesquisas nos mais diferentes níveis no ns-3. Como trabalhos futuros a equipe trabalha em duas frentes no momento: o desenvolvimento de gráficos através do Gnuplot 8, e a capacidade de construir a topologia à partir do arquivo trace (ou uma possível integração com o NetAnim 9 ). Referências Carneiro, G., Fortuna, P., and Ricardo, M. (2009). Flowmonitor - a network monitoring framework for thenetwork simulator 3 (ns-3). In Fourth International ICST Conference on Performance Evaluation Methodologies and Tools. Gonzaga, F. B. and Saggioro, L. F. (2010). Tracemetrics - uma ferramenta para a validação matemática de simuladores de redes de computadore. In 33th Congresso Nacional de Matemática Aplicada e Computacional. ns 3 project (2012). Tutorial. Technical report, release/3.13/tutorial-pt-br/ns-3-tutorial.pdf, acesso em 04/03/2012. Ross, S. M. (2006). Simulation. Academic Press, 4th edition. Salleh, A. U., Ishak, Z., Din, N. M., and Jamaludin, M. Z. (2006). Trace analyzer for ns-2. In 4th Student Conference on Research and Development. Trivedi, K. S. (2008). Probability and Statistics with Reliability, Queuing and Computer Science Applications. John Wiley & Sons, 2nd edition