DIFERENCIAÇÃO DE FLUXO NO ROTEAMENTO DE TRÁFEGO DA INTERNET

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO DEPARTAMENTO DE ENGENHARIA ELÉTRICA PROJETO DE GRADUAÇÃO DIFERENCIAÇÃO DE FLUXO NO ROTEAMENTO DE TRÁFEGO DA INTERNET SALIM SUHET MUSSI VITÓRIA ES DEZEMBRO/2008

2 SALIM SUHET MUSSI DIFERENCIAÇÃO DE FLUXO NO ROTEAMENTO DE TRÁFEGO DA INTERNET Parte manuscrita do Projeto de Graduação do aluno Salim Suhet Mussi, apresentado ao Departamento de Engenharia Elétrica do Centro Tecnológico da Universidade Federal do Espírito Santo, para obtenção do grau de Engenheiro Eletricista. VITÓRIA ES DEZEMBRO/2008

3 SALIM SUHET MUSSI DIFERENCIAÇÃO DE FLUXOS NO ROTEAMENTO DE TRÁFEGO DA INTERNET COMISSÃO EXAMINADORA: Prof. Dr. Moisés Renato Nunes Ribeiro Orientador Prof. Dr. Marcelo Eduardo Vieira Segatto Examinador Prof. Dr Magnos Martinello Examinador Vitória ES, 12, Dezembro, 2008.

4

5 DEDICATÓRIA À minha família e amigos. I

6 AGRADECIMENTOS Agradeço a meus pais, principais incentivadores dos meus estudos. Aos irmãos, Amin e Jamili, e demais familiares, afinal, a família é a base para a vida. Não poderia deixar de lembrar, dos companheiros de estágio e colegas, Rafael e Leonardo, grandes responsáveis por hoje me interessar por softwares livres, além de serem as pessoas que me ajudaram nos momentos de dificuldades com estes sistemas. Ainda neste contexto agradeço ao amigo Lucas, quem me socorreu nas duvidas em programação. Agradecimentos especiais a todos amigos, com quem pude compartilhar aflições e alegrias durante todo esse tempo de universidade. Não poderia deixar de agradecer ao professor Moisés, pela atenção e por possibilitar a realização deste trabalho. Por fim, agradeço a equipe do PoP ES / RNP pelo apoio e disponibilização do espaço físico e das máquinas utilizadas nos testes. II

7 LISTA DE FIGURAS FIGURA 1: PROPRIEDADES DO ELEMENTO TEE...14 FIGURA 2: CONEXÃO ENTRE OS ELEMENTOS...15 FIGURA 3: EXEMPLO DA LINGUAGEM CLICK...16 FIGURA 4: EXEMPLO DE DEFINIÇÃO DE CLASSE NA LINGUAGEM CLICK...17 FIGURA 5: EXEMPLO DE P.D.F. DE PARETO...21 FIGURA 6: ESTRUTURA DO NÚMERO DE SEQÜÊNCIA...24 FIGURA 7: REDE DE TESTE...26 FIGURA 8: ROTEADOR IP COM FILA DROPTAIL, FIFO...28 FIGURA 9: DIFERENCIADOR DE FLUXOS NO CLICK...30 FIGURA 10: FLUXO CAPTURADO NO ROTEADOR PELO MÉTODO INTERNO DE MEDIDAS...32 FIGURA 11: FLUXO CAPTURADO COM ROTEADOR LIMITADO À 1 MBPS...33 FIGURA 12:GERAÇÃO DE TRÁFEGO CONCORRENTE NO SERVIDOR FTP...34 FIGURA 13: DISTRIBUIÇÃO DE ARQUIVOS NO DISCO...35 FIGURA 14: CABEÇALHO TCP...36 FIGURA 15: AMOSTRAGEM PROPORCIONAL...38 FIGURA 16: HISTOGRAMA DOS ARQUIVOS TRANSMITIDOS VIA FTP...39 FIGURA 17: DISTRIBUIÇÕES DE PROBABILIDADES...40 FIGURA 18: COMPARAÇÃO DO TÉRMINO DOS FLUXOS NOS ROTEADORES...41 FIGURA 19: DETALHES DA COMPARAÇÃO DO TERMINO DOS FLUXOS. 41 FIGURA 20:TEMPO MÉDIO DE FIM DOS FLUXOS PARA POLÍTICA DROPTAIL...42 III

8 FIGURA 21: TEMPO MÉDIO DE FIM DOS FLUXOS PARA POLÍTICA RUN2C PRIOSCHED...43 FIGURA 22: TEMPO MÉDIO DE FIM DOS FLUXOS PARA POLÍTICA RUN2C ROUNDROBIN...43 FIGURA 23: COMPARAÇÃO DOS TEMPOS MÉDIOS DE TRANSFERÊNCIA DE ARQUIVOS...44 FIGURA 24: VARIÂNCIA DOS TEMPOS MÉDIOS DOS ARQUIVOS...45 FIGURA 25: COMPARAÇÃO DOS DESVIOS PADRÃO...46 FIGURA 26: FINALIZAÇÃO DOS FLUXOS SEM LIMITAÇÃO DE BANDA...47 FIGURA 27: DETALHES DAS FINALIZAÇÕES DOS FLUXOS SEM LIMITAÇÃO DE BANDA...47 FIGURA 28: TEMPOS MÉDIOS DE FIM DOS FLUXOS SEM LIMITAÇÃO DE BANDA...48 FIGURA 29: VARIÂNCIA DOS TEMPOS MÉDIOS SEM LIMITAÇÃO DE BANDA...48 FIGURA 30: DESVIO PADRÃO DOS TEMPOS MÉDIOS SEM LIMITAÇÃO DE BANDA...49 IV

9 LISTA DE TABELA TABELA 1: COMPARAÇÃO DE TAXAS CONTABILIZADAS, VAZÃO MÁXIMA DO ROTEADOR...32 TABELA 2: COMPARAÇÃO DAS TAXAS OBTIDAS COM ROTEADOR LIMITADO À 1 MBPS...33 V

10 SIMBOLOGIA Corcel máquina do PoP ES/RNP utilizada nos experimentos Landau máquina do PoP ES/RNP utilizada nos experimentos P III Pentium terceira geração. Sinca máquina do PoP ES/RNP utilizada nos experimentos VI

11 GLOSSÁRIO ARP Address Resolution Protocol b Bit B Byte Broadcast Sistema de envio de mensagens em que é transmitido o mesmo conteúdo para todos os receptores pertencentes a uma determinada rede Checksum Soma de controle de erro do pacote DMA Direct Memory Access DropTail Política de fila FIFO FIFO First in first out FTP File Transfer Protocol. Flag um sinal que indica uma condição ou status em particular Gateway Ponto onde uma rede se liga a outras redes ICMP Internet Control Message Protocol IP Internet Protocol ISN Inicial Sequence Number kpps Milhares de pacotes por segundo MAC Media Access Control Mbps Milhões de bits por segundo MTU Maximum Transmission Unit NIC Network Interface Card PIN Possible Inicial Number RED Random Early Detection TCP Transmission Control Protocol TTL Time To Live VII

12 SUMÁRIO DEDICATÓRIA...I AGRADECIMENTOS...II LISTA DE FIGURAS...III LISTA DE TABELA...V SIMBOLOGIA...VI GLOSSÁRIO...VII SUMÁRIO...VIII RESUMO...X 1 INTRODUÇÃO ARQUITETURA CLICK Introdução Elementos Conexões Linguagem Instalação das configurações Conclusões DIFERENCIAÇÃO DE FLUXOS Introdução O tráfego da Internet O escalonador RuN2C Implementação do escalonador Determinação dos limiares Conclusões METODOLOGIA Introdução Ambiente de testes...26 VIII

13 4.2 Roteador CLICK O roteador simples Roteador com Escalonador Coleta de estatísticas Vazão do Roteador Testes com tráfego real Base de arquivos Geração dos números de seqüência no SO Conclusão EXPERIMENTOS E RESULTADOS Introdução Base de arquivos amostrada Fluxos por tempo Tempo médio e variância de termino dos fluxos Experimentos sem limitação de banda Conclusão CONCLUSÕES...51 APÊNDICE A...52 APÊNDICE B...59 APÊNDICE C...62 REFERÊNCIAS BIBLIOGRÁFICAS...66 IX

14 RESUMO O projeto consiste em um estudo, implementação e validação de diferenciação entre fluxos longos e curtos em roteadores, através de uma política de fila, que vise melhor aproveitamento de banda e sua distribuição mais justa entre usuários. O mecanismo de diferenciação de fluxos em duas filas utilizado foi o Run2C e os roteadores foram implementados via software em computador, utilizando se a arquitetura modular CLICK. Obteve se resultados de diminuição do tempo médio de transferência dos fluxos curtos em até 34% com diminuição do desvio padrão em 87.94%. X

15 11 1 INTRODUÇÃO Com a convergência das redes para a estrutura óptica, vem acontecendo um crescimento muito maior da taxa de transmissão em relação ao crescimento da capacidade de processamento do roteamento eletrônico. Por isso, muitos esforços estão sendo direcionados para aumentar tal capacidade de processamento, ou na direção de técnicas de tratamento mais eficiente do tráfego. Cabe destacar ainda, nesse contexto, os desafios apresentados pelas exigências por qualidade de serviço (QoS) apresentadas por aplicações que demandam grande volume de tráfego. Novas técnicas de formatação de dados estão sendo desenvolvidas a fim de prover grande capacidade de transmissão com baixo processamento eletrônico, baixas perdas e pequenos atrasos. Uma dessas técnicas é a priorização de fluxos curtos em roteadores [3]. A maior parte das interações dos usuários com uma rede ou com aplicações que funcionam através de uma rede consiste quase que inteiramente de conexões curtas, ou conexões curtas seguidas de transferências longas. Assim, parece razoável que a rede tente diminuir o tempo de transferência das transações curtas e em contrapartida pode se incrementar o tempo das longas, já que estas não necessitam tanto da atenção do usuário. Um resultado clássico da Teoria das Filas diz que a política SRPT, Shortest Remaining Processing Time, é capaz de reduzir a média de latência dos fluxos [4]. Na internet a maior parte das conexões que visam interatividade é de curta duração. No entanto, uma menor parte das conexões, as de aplicações de transferência de arquivos, é longa e responsável pela maior parte do volume de dados transferidos. Se políticas que favoreçam as conexões curtas forem implementadas na Internet, o tempo médio no sistema pode ser reduzido. Mais ainda, a percepção do usuário seria sensívelmente melhorada em função da aceleração das conexões resultantes da sua interação com a rede.

16 12 Propomos nesse trabalho o estudo, implementação e validação de técnicas de diferenciação de fluxos em sessões TCP. A plataforma CLICK [1] [5] será utilizada para a implementação física do roteador.

17 13 2 ARQUITETURA CLICK Neste capítulo será mostrado os conceitos, a linguagem de configuração, o uso do CLICK Router para implementação de roteadores em PC. 2.1 Introdução A tecnologia CLICK se baseia em uma arquitetura flexível e modular de software para criar e encaminhar pacotes. Com ela é possível criar roteadores, switches, hubs, entre outros elementos de uma rede IP utilizando como base um computador pessoal. Diversos aspectos da arquitetura CLICK foram inspirados diretamente por propriedades dos roteadores[6][13]. Um exemplo disso é que a passagem de pacotes ao longo de uma conexão pode ser iniciada tanto pela extremidade da fonte (pacote é empurrado ) quanto pela extremidade de destino (pacote é puxado ), modelando a maior parte dos padrões de fluxo de pacotes em roteadores[1]. Há duas formas de se utilizar o software CLICK: como aplicação a nível de usuário, ou como módulo do kernel Linux. Este assunto será melhor tratado na seção 2.5. A elaboração dos dispositivos de rede na arquitetura CLICK se dá através de módulos processadores de pacotes denominados elementos. 2.2 Elementos Um elemento CLICK representa uma unidade de processamento do dispositivo de rede. Representa, também, uma computação simples, tal como, decrementar o campo TTL do pacote a ser roteado a um novo nó da rede. Toda ação executada pelo software CLICK é encapsulada em um elemento. Para a construção de um roteador utilizando a tecnologia CLICK é necessária uma coletânea de elementos, que serão interconectados através de uma linguagem visual de configuração.

18 14 Assim, para expandir a arquitetura para suportar novas funções de roteamento, tais como novos protocolos, basta modificar os elementos já existentes ou criar novos elementos. As propriedades mais importantes de um elemento são: Classe do elemento: cada elemento pertence a uma classe específica que indicará o código a ser executado no processamento de um pacote, assim como a função de iniciação do elemento e seu formato de dados. Portas: Um elemento pode ter portas de entrada e saída em qualquer número, inclusive nenhuma. Toda conexão, entre os elementos, vai de uma porta de saída de um elemento até a porta de entrada em outro. Para que se possa iniciar uma configuração todas as portas dos elementos devem estar conectadas. String de configuração: é opcional e pode conter argumentos de configuração que são iniciados junto com a configuração do roteador. Muitas classes de elementos utilizam estes argumentos para realizar um ajuste fino no comportamento de um elemento. Interface: Cada elemento suporta uma ou mais interfaces. Todo elemento suporta a interface de transferência de pacotes, mas os elementos podem criar e exportar interfaces adicionais arbitrárias; por exemplo, uma fila pode exportar uma interface que relate seu comprimento. Handler: É possível ao usuário verificar parâmetros e contadores do roteador instalado, similarmente ao roteadores comerciais, através destes handlers. Quando uma configuração de roteador é instalada esses parâmetros são acessíveis em arquivos ASCII em um diretório criado dinamicamente com todas as instâncias dos elementos descritas na configuração. Assim, basta realizar um cat no arquivo do handler desejado, como por exemplo, para saber a ocupação de uma fila basta utilizar o comando cat /click/queue/length no terminal da máquina onde é instalado o roteador.

19 15 Figura 1: Propriedades do elemento Tee 2.3 Conexões Os elementos CLICK suportam dois tipos de conexões, chamados de empurra e puxa. Numa conexão do tipo empurra o elemento fonte inicia a transferência passando os pacotes a um elemento de destino. Isto corresponde à maneira com que os pacotes se movem na maioria dos roteadores por software. Já na conexão do tipo puxa, o elemento de destino inicia a transferência pedindo por um pacote. Há elementos que possuem portas agnósticas, que se comportam como do tipo empurra ou puxa dependendo do elemento a que está conectada. As conexões são descritas na linguagem visual de configuração como uma seta, >, que liga a porta de saída de um elemento a de entrada em outro. Em nossos diagramas de configuração, as portas pretas são do tipo empurra e as brancas do tipo puxa. As portas agnósticas são mostradas como tipo empurra ou puxa com margem dupla. A Figura 2 indica como o sistema empurra e puxa funciona. O elemento Null indica portas agnósticas. Figura 2: Conexão entre os elementos

20 16 O processamento do tipo empurra é apropriado quando pacotes não solicitados chegam ao roteador CLICK, como por exemplo, os que vêm da placa de rede. Esses pacotes devem ser tratados pelo roteador assim que chegam, mesmo que isto seja apenas enfileirarmos um após o outro. Já as conexões do tipo puxa são necessárias quando as tarefas do roteador necessitam controlar o sincronismo de execução. O roteador só pode enviar um pacote quando o dispositivo estiver pronto. 2.4 Linguagem A linguagem de configuração CLICK é simples e visual, completamente declarativa, além de orientada a objeto. As declarações instanciam os elementos e as conexões dizem como eles são conectados. Esta linguagem é bastante simples de se aprender a partir de um exemplo. Figura 3: Exemplo da linguagem CLICK Quando um elemento é inserido sem uma declaração, o software o instancia com uma declaração padrão que é do formato Classe@número, por exemplo, Counter@1. A linguagem apresenta ainda um mecanismo de abstração chamado de elementos compostos que permite ao usuário definir suas próprias classes. Um elemento composto é um fragmento da configuração do roteador. No momento de iniciação do roteador, cada elemento composto se transforma simplesmente numa coleção correspondente de elementos. Um exemplo deste mecanismo é mostrado na Figura 4.

21 17 Figura 4: Exemplo de definição de classe na linguagem CLICK 2.5 Instalação das configurações Os arquivos de configuração do CLICK são executadas sobre um driver que implementa várias facilidades para todos os elementos. Existem dois drivers: o driver user level, que executa como uma aplicação a nível de usuário, e um driver Linux kernel, o linux module, que executa como um módulo do kernel Linux. O user level é útil para depuração e execução de testes repetitivos; ele pode receber pacotes da rede usando mecanismos do sistema operacional através de bibliotecas originalmente programadas para sniffers. Entretanto, este driver, não se previne da pilha de rede do sistema operacional para encaminhar um pacote. Já o driver a nível de kernel, linuxmodule, substitui completamente a pilha de rede do SO, transformando um computador pessoal convencional num roteador, alcançando alto desempenho[13].

22 Conclusões Neste capítulo apresentou se um pouco sobre a teoria do software CLICK, introduzindo os conceitos da linguagem de configuração de roteadores na plataforma, permitindo, assim, que o leitor possa escrever configurações básicas, desde que tenha a lista dos elementos em mãos. Essa documentação pode ser encontrada na lista de referencia [5] deste trabalho. Além disso, pode se perceber que o ambiente CLICK, devido a sua modularidade, oferece acesso a pesquisa e desenvolvimento no mundo dos roteadores, que nos roteadores comercias é praticamente impossível devido às licenças de uso do hardware e softwares e seu elevado custo. É importante salientar que a instalação da plataforma requer conhecimento na plataforma Unix ou Unix like, já que para o uso efetivo de todas as funções é necessário recompilar o kernel do sistema operacional aplicando o patch fornecido junto do software.

23 19 3 DIFERENCIAÇÃO DE FLUXOS Neste capítulo será abordado a caracterização do tráfego da internet, bem como o mecanismo de diferenciação e priorização de fluxos utilizado neste trabalho. Este mecanismo é denominado RuN2C (do inglês, Running Number 2 Class) e se baseia na manutenção de duas fila: uma para fluxos curtos e outra para os demais. A classificação dos fluxos utiliza o número de seqüência dos pacotes e se dá de forma que não é necessária a manutenção de estados anteriores das sessões, stateless. 3.1 Introdução Antigas implementações do protocolo TCP iniciavam as sessões já injetando múltiplos segmentos de dados na rede, até o limite do tamanho da janela anunciada pelo receptor. Ao passo que isto não acarreta problemas entre dois nós na mesma LAN, se existem roteadores e enlaces de baixa velocidade entre a origem e destino problemas podem surgir. Algum roteador intermediário, que não consiga tratar todo o tráfego recebido, pode ficar sem espaço em seu buffer ou aplicar alguma política de descarte de pacotes. O algoritmo para evitar isto é chamado de slow start. Seu mecanismo é baseado na observação de que a taxa a que novos pacotes devem ser injetados na rede deve ser a mesma em que as confirmações (ACK) são enviadas pelo outro lado[7]. Ao mesmo tempo que este mecanismo evita o descarte de pacotes causado pela inundação da rede com múltiplos nós, ele dificulta que conexões curtas consigam altas taxas de transferência numa rede com concorrência com fluxos longos, nas quais já foram alcançadas altas taxas ocupando a maior parte dos recursos disponíveis na rede. Assim, um dos pontos essenciais na comutação de pacotes, é garantir alocação de recurso de maneira justa para qualquer tipo de aplicação. A cada dia se faz mais necessária a garantia de qualidade de serviço para aplicações em tempo real, como VoIP e videoconferência. Além destes últimos, há também aplicações em tempo não

24 20 real, que estabelecem sessões TCP e que necessitam de baixa média e baixa variância do atraso a fim de garantir controle dos fluxos[8]. Entende se como justiça na alocação de recursos o fato de que fluxos longos não atrapalhem a maior parte das aplicações numa rede IP, que, em sua maioria, são realizadas através de conexões curtas[4], ou, também, que os atrasos experienciados pelas sessões sejam proporcionais a suas durações. 3.2 O tráfego da Internet O tráfego da Internet é caracterizado por uma altíssima variabilidade. Neste tipo de tráfego, a maioria dos eventos (conexões) tem curta duração. Porém, conexões maiores podem ocorrer. São justamente estas conexões as maiores responsáveis pelos efeitos danosos ao tráfego causado por essa variabilidade. Este tipo de tráfego pode ser bem modelado por uma distribuição cauda pesada (heavy tail) que ao contrário das distribuições, como a exponencial, utilizadas anteriormente para modelar o tráfego de telefonia, não despreza a probabilidade destas conexões maiores acontecerem [3]. Em uma distribuição cauda pesada, a probabilidade de uma variável aleatória Y ser maior que x decresce cx α com o aumento de x, onde α é o parâmetro da distribuição. Pesquisas mostram que as conexões que populam a Internet seguem um distribuição com parâmetro α 1.2 [12], isto é a duração das conexões do tráfego de dados na Internet tem variância infinita, o que implica que podem existir conexões de durações altíssimas. Esta distribuição também é especificada pela variável aleatória t, e truncada, a partir de um valor mínimo (t min ) e de um valor máximo (t max ) desta variável. A função de densidade de probabilidade, p T (t), p.d.f., de Pareto é dada por (1): p T t = {0, t min 1 1 r t, 1 t t min t min t t max, onde r= t min t max (1)

25 21 A partir da equação (1), pode se encontra a média para o primeiro momento, E[T], para o k ésimo momento, E[T k ] e a variância, Var[T] = E[T²] E [T]², dada pelas equações (2), (3), (4) a seguir: E [T ] = tmin t max t pt t dt = E [T k t max ] = tmin t k p T t dt = k t k min Var [T ] = E [T 2 ] E [T ] 2 1 t 1 k 1 r min (2) 1 r k 1 r (3) 1 r = t 2 [ min 1 r 2 1 r r 1 2 ] (4) 1 1 r Um exemplo da distribuição de densidade de probabilidade do tempo de duração das conexões a um servidor é mostrada na Figura 5. Para esta p.d.f utilizou se t min = 50 s, t max = 1750 s, α = 1.2. Figura 5: Exemplo de p.d.f. de Pareto

26 O escalonador RuN2C As aplicações TCP reagem ao congestionamento e às perdas em uma rede com reduzindo o tamanho de suas janelas com certa fluidez, quer através de rápidos processos de retransmissão dos pacotes perdidos[11] ou retransmissão após o timeout. Para conexões curtas, o que implica em pequenas janelas, a perda é normalmente detectada após o tempo limite, timeout, e, provavelmente, também após todos os dados já terem sido transmitidos. Como resultado disto, a retransmissão após este tempo limite em conexões curtas não é muito eficaz em reduzir o tráfego global e em estabilizar a rede. Para isto, propõe se a utilização de um mecanismo de diferenciação entre os fluxos de curta e longa duração em redes de internet que tome decisões a partir de um limiar e que não necessite da gerência do estado das conexões. Tal mecanismo teria a vantagem de ser passível de implementação em diferentes partes da rede: na rede de acesso, na rede de backbone, ou mais interessantemente na parte de recepção de uma rede de acesso. Outra vantagem seria a não exigência de acordos prévios entre os provedores para ser usada pelas redes interconectadas. O mecanismo de diferenciação RuN2C (do inglês, Running Number 2 Class) é uma implementação sobre redes TCP/IP de um escalonador de tráfego que processa duas classes de prioridades no qual os pacotes são classificados como baixa ou alta prioridade de acordo com o número de Bytes transmitidos numa sessão TCP. Este mecanismo produz um importante aumento de desempenho quando comparado a outros mecanismos de priorização de fluxos curtos, enquanto trata os fluxos longos como a corrente implementação do TCP faz [4]. Em contrapartida é necessário que os possíveis números de seqüência iniciais, sejam igualmente espaçados no intervalo de 1 à 2³² 1, mas que não sejam tão distantes que não se permita que sejam iniciados de forma suficientemente aleatória. Assim, se faz necessária uma pequena adequação no protocolo TCP/IP no que se refere a geração destes números de seqüência. Esta adequação poderia se dar de maneira gradual, uma vez que os fluxos não priorizados são tradados de acordo com a implementação

27 corrente do TCP. A forma de geração destes números será tratada na seção 3.4 a seguir Implementação do escalonador Na implementação proposta, os roteadores devem ser capazes de classificar os pacotes de uma conexão TCP sem manter um histórico de eventos anteriores. Para isto, os roteadores infiram o número de bytes servidos à uma conexão somente pelo o número de seqüência[4]. O número de seqüência é incrementado de um pacote para outro de acordo com o número de bytes do segmento de dados do pacote transferido. O valor inicial deste número é escolhido aleatoriamente quando uma conexão TCP é estabelecida. Esta escolha aleatória é realizada, pois se todas as conexões fossem iniciadas com o mesmo número de seqüência, introduziria se a possibilidade de segmentos de diferentes conexões fossem confundidos possibilitando, por exemplo, o seqüestro de conexões via IP spoofing. Assim, a cada conexão é gerado um novo ISN (Número de Seqüência Inicial, do Inglês, Initial Sequence Number), e estes normalmente eles não são os mesmos [10]. Para delimitação do número do seqüência inicial são utilizados os 10 bits mais significativos deste campo, simbolizado pelo segmento R mostrado na Figura 6, além dos 10 bits menos significativos do mesmo, sendo possível assim a geração de 2 20 = 1 milhão de possíveis números iniciais garantindo a aleatoriedade do mesmo. Os bits menos significativos podem ser utilizados sem prejuízos ao limiar já que são calculados a partir do tamanho máximo dos segmentos, MSS, Maximum Segment Size, igual a 1460 Bytes, log 2 (MSS=1460) 10 bits. Os demais bits do campo devem ser iniciados com 0, zero, quando a conexão TCP é estabelecida Determinação dos limiares O limiar de separação entre as duas classes de prioridade deve ser escolhido de forma a que fluxos curtos se beneficiem do mecanismo de diferenciação. Porém deve

28 24 se manter a carga de alta prioridade baixa a fim de que fluxos longos não sejam muito prejudicados. Para uma solução que satisfaça esse compromisso é importante ressaltar dois fatos. Em primeiro lugar, deve se considerar que os fluxos TCP curtos são propensos à timeouts após a perda de um pacote. O impacto disto é extremamente relevante para o tempo de resposta deste tipo de fluxos, uma vez que o mínimo tempo para timeout é de 1 segundo [11]. Para evitar este impacto, deve se dar prioridade a estes fluxos antes que o congestionamento da janela TCP atinja 3 ou 4 pacotes, o que ocorre, por exemplo, se são transmitidos 8 pacotes, totalizando um limiar de aproximadamente 12kBytes, para um MSS igual a 1460 kbytes. O outro ponto é que se os fluxos TCP são descritos por uma distribuição caudapesada, os fluxos abaixo de 8 pacotes representam um significante número do total dos fluxos TCP, mas uma pequena porção da carga total. Assim, ao se dar prioridade a estes fluxos, os fluxos longos não são prejudicados. Figura 6: Estrutura do número de seqüência Limitando se, assim, um limiar de 12kBytes, o número de bits, TH, necessários do campo de seqüência é: log 2 (12x1024) 14 bits. Esses bits estão localizados na porção menos significativa do número de seqüência. Sendo R, o seguimento utilizado na geração de um possível número de seqüência inicial, o segmento L será os 8 bits seguintes ao TH. Após a transferência de 2²² bits 4 MBytes, o que contabiliza aproximadamente 2800 pacotes, o número de seqüência passa a poder coincidir com um novo número gerado. No pior caso, isto poderia induzir uma probabilidade de taxa de erro de 3.6x10 4, o que é insignificante em relação à atual taxa de perda de pacotes na Internet [4].

29 Conclusões Neste capítulo introduziu se os principais conceitos, vantagens e limitações do mecanismo de diferenciação de fluxos em duas filas de diferentes prioridades e escalonamento de tráfego, Run2C, a ser utilizado e comparado com uma política de fila única DropTail. Atentou se para a necessidade de adequação do protocolo TCP na geração dos números de seqüência iniciais, que no entanto poderia ser feita de maneira gradual, uma vez que os fluxos não priorizados são tratados de acordo com a corrente implementação do protocolo TCP/IP, não limitando assim a implantação deste mecanismo em roteadores a serem instalados nas redes atuais.

30 26 4 METODOLOGIA 4.1 Introdução Este capítulo trata do ambiente de testes, da implementação do roteador CLICK comparando a política de fila DropTail, fila FIFO (primeiro a entrar, primeiro a sair, do inglês First In, Frist Out), a políticas de fila com diferenciação de fluxos longos e curtos e da coleta de estatísticas para validação dos modelos propostos. Utilizaremos apenas o driver linux module do CLICK a fim de conseguir o máximo desempenho possível, e minimizar os efeitos do escalonamento de tarefas do sistema operacional Ambiente de testes Os testes deste trabalho realizaram se no Ponto de Presença Espírito Santo da RNP, Rede Nacional de Ensino e Pesquisa, com três computadores COMPAQ Presario série 7000, cedidos para este fim. Os computadores possuem a configuração padrão: processador Intel Pentium III, 933MHz, NIC PCI 10/100 com clock 33MHz, e 512MBytes de memória RAM 133MHz. Na máquina Corcel, onde será instalado o roteador modular CLICK foi instalado mais uma placa PCI de rede além de mais 256MBytes de memória RAM totalizando 768MBytes. Para a montagem da rede, decidiu se interconectar os computadores diretamente um nos outros, com cabos cruzados, para melhor precisão nas medidas. Figura 7: Rede de teste

31 Nestas redes a máquina onde está instalado o roteador é denominada corcel, e as estações de trabalho são denominadas landau e sinca Roteador CLICK Os roteadores CLICK foram configurados a partir do roteador básico apresentado no Projeto de Graduação de André M. C. Campos[1], a partir do qual foram feitas as modificações necessárias a este trabalho. Dentre elas a retirada do Proxy ARP, e a configuração de novas políticas de fila na saída das interfaces de rede. O código de configuração dos roteadores na linguagem CLICK será apresentado no Apêndice A por poder parecer demasiadamente extenso ao leitor com pouca experiência com o software. Juntamente a ele, há um glossário de elementos CLICK no Apêndice C. Em função da pequena rede montada para testes, utilizou se um roteador apenas com duas interfaces, será apresentada a configuração deste roteador com duas portas. Nota se que para extensão deste roteador, basta copiar duplicar os módulos configurados para a nova interface a ser conectada O roteador simples Este roteador, mostrado na Figura 8, foi configurado para tarefas de roteamento por IP que envolvam somente informações locais e se encaixem naturalmente na estrutura CLICK. Um pacote chega através de uma interface pelo elemento FromDevice(eth0) e é diretamente classificado, em pacotes ARP Queriers, ARP Responses, e pacotes IP. Cada tipo de pacote segue um rumo. Os pacotes ARP Queries são encaminhados ao ARPResponder, elemento que se encarrega de responder as requisições ARP pela interface que o pacote foi recebido. Os pacotes de respostas ARP são encaminhados ao Linux, e aos elementos ARPQueriers do roteador, que salvam estas informações em suas tabelas ARPs, caso o requisição tenha sido realizado por eles. Por fim, os pacotes IPs são marcados e encaminhados para o roteamento.

32 Dentro das tarefas de roteamento estão localizadas as função de verificar se o 28 Figura 8: Roteador IP com fila DropTail, FIFO

33 29 Uma anotação é um pedaço de informação colocada no cabeçalho do pacote, mas não faz parte dos dados do pacote; a própria estrutura de pacotes do Linux, sk_buff, fornece 48 B de espaço para anotações. As anotações usadas no roteador IP incluem: Destination IP Address, que são utilizadas para elementos que lidam com o IP de destino, ao invés de utilizar a informação do campo do cabeçalho; Paint, que marca o pacote afim de informar ao roteador se este pacote está saindo pela mesma interface que chegou; Link level broadcast flag, que é configurada pelo elemento FromDevice nos pacotes que chegam como broadcast em nível de link, afim de descartar tais pacotes quando estiverem a ponto de serem enviados a uma outra interface; além da anotação Fix IP Source flag, que é utilizada para encaminhar o pacote de erro ICMP com o endereço IP fonte da interface que este é emitido. Depois de totalmente roteado, o pacote é enviado ao elemento ARPQuerier, que realiza quase todas as funcionalidades do protocolo ARP. Este elemento é quem faz a requisição dos endereços físicos, MACs, mantém uma tabela com essas informações e se encarrega das tarefas de inclusão destes endereços fixos nos pacotes a serem encaminhados. Por fim, o pacote vai para uma fila única, DropTail e é enviado a interface pelo elemento ToDevice Roteador com Escalonador Para implementação de um roteador que priorize as conexões curtas no CLICK, foi adicionada uma segunda porta de saída ao elemento ARPQuerier. Quando esta saída é adicionada, os pacotes IP são encaminhados à primeira saída, e pacotes do protocolo ARP à outra, possibilitando inclusão dos pacotes do último tipo na mesma fila com prioridades do pacotes TCP de fluxos curtos. Isto proporciona ganhos uma vez que enquanto não são obtidas as respostas às requisições ARP os pacotes são salvos e não são encaminhados.

34 30 Figura 9: Diferenciador de fluxos no CLICK Para a classificação dos pacotes IP incluiu se o elemento IPClassifier que pode ser configurado para separar pacotes do protocolo TCP de acordo com o número de seqüência. Este elemento utiliza o mesmo padrão do software Linux TCPDump [15]. Nesta configuração, ao número de seqüência, situado nos bytes de 5 a 8 do cabeçalho TCP, aplica se uma máscara ocultando os 10 bits do campo R, mostrado anteriormente na Figura 6. Em seguida compara se o resultado com o limiar de 14 bits. A string de configuração é tcp[4:4] & 0xFFC003FF < 0x Os pacotes que obedecem a configuração são destinados a uma interface e os demais à outra. As filas são finalmente ligadas a um escalonador de prioridades que é encarregado de encaminhar os pacotes à interface. Serão utilizados neste trabalho dois elementos CLICK de escalonamento: RoundRobinSched: é um elemento do tipo puxa, com uma saída e zero ou mais entradas. Este elemento faz o escalonamento do tráfego transmitindo seqüencialmente um pacote de cada entrada. Se uma entrada acabou de ser servida ele busca o próximo pacote na fila da entrada seguinte.

35 RoundRobinSched utiliza se de um mecanismo de notificação para não servir filas vazias. 31 PrioSched: também é um elemento do tipo puxa, com uma saída e zero ou mais entradas. Diferente do anterior, este elemento faz o escalonamento estrito de prioridade, dando preferência sempre a sua primeira entrada. Quando não há mais pacotes na fila conectada a esta entrada ele passa para a fila seguinte. Assim, como o anterior, possui mecanismo de notificação para não servir filas vazias. 4.3 Coleta de estatísticas Logo que o arquivo de configuração do roteador é instalado, um diretório /click é criado dinamicamente. Como citado na seção 2.2, dentro deste são também criados outros diretórios, um para cada elemento instanciado, onde os handlers deste elemento estão localizados. Isto se tornou interessante a partir do momento em que uma rotina pode de tempo em tempo coletar estes valores e salvar em um arquivo, formando um log de informação do roteador em tempo de execução. Escolheu se programar um método de coleta de estatísticas interno ao roteador utilizando se Python devido as facilidades oferecidas pela linguagem de programação. Um exemplo é mostrado no Apêndice B. Entretanto, se fez necessário que este método de coleta de estatísticas internas ao roteador fosse validado, já que não se sabia se o esta rotina seria escalonado vezes suficientes no SO para manter uma base de informações concisa. Para tal, mediu se a vazão do roteador, utilizando se a topologia de rede mostrada na Figura 7 na seção Para o teste de vazão utilizou se o Iperf, renomado programa em distribuições Linux para medições de banda em enlaces, como uma fonte externa de injeção e medição de tráfego na rede. Estas medidas quando comparadas com as obtidas pelo método de medidas interno comprovariam a validade do método de coleta.

36 Vazão do Roteador Realizou se experiências de quatro gerações de tráfego seguidas, com duração de dez segundos cada, com fluxos TCP à 100Mbps. Para cada geração foi calculada a taxa média e comparada com os resultados obtidos pelo Iperf. O fluxo capturado na interface do roteador pelo método interno de medidas é mostrado na Figura 10. Nota se que mesmo instalando o roteador como módulo do kernel os efeitos de escalonamento de tarefas do sistema operacional aparecem, resultando nos pontos em que a contagem de bits vai a zero dentro dos dez segundos de injeção de tráfego. Figura 10: Fluxo capturado no roteador pelo método interno de medidas Com o log gerado, pode calcular a banda em cada fluxo e compará lo com a medida do Iperf. Os resultados obtidos, apesar de se notar uma pequena diferença nos valores, mostram se coerentes e são apresentados na Tabela 1. O principal motivo desta diferença é a precisão na escolha dos limites de tempo para o cálculo da banda, realizado manualmente. Comparação de taxas contabilizadas o Iperf e pelo método de coleta interno Injeção de tráfego Taxas do Iperf (Mbps) Taxas calculadas (Mbps) Tabela 1: Comparação de taxas contabilizadas, vazão máxima do roteador

37 33 Também foi medida a vazão do roteador quando junto das interfaces era instalado um elemento de controle de taxa, o BandwidthShaper, limitando a taxa no roteador em 1 Mbps. Figura 11: Fluxo capturado com roteador limitado à 1 Mbps Obteve se resultados também positivos quando a taxa é limitada. A comparação das estatísticas do Iperf e as estatísticas coletadas internamente ao roteador são mostradas na Tabela 2. Comparação de taxas contabilizadas o Iperf e pelo método de coleta interno Injeção de tráfego Taxas do Iperf (kbps) Taxas calculadas (kbps) Tabela 2: Comparação das taxas obtidas com roteador limitado à 1 Mbps 4.4 Testes com tráfego real Para se aproximar o máximo possível da condição de uso real dos roteadores, notou se que o Iperf, apesar de eficiente para medição de banda dos enlaces, não era suficiente para injeção de tráfego real. Com o Iperf, apesar de se poder transmitir arquivos reais ao invés de tráfego sintético, não se obteve certeza se a implementação do TCP para transmissão de arquivos no software, era a implementação padrão do SO,

38 34 já que diversos parâmetros, tais como, o tamanho da janela TCP podem ser passados na iniciação do programa. Assim, optou se pela instalação de um servidor FTP (Protocolo de Transferência de Arquivos, do inglês File Transfer Protocol) em uma das redes a serem roteadas. Na outra rede, a execução de uma rotina na qual múltiplas threads de transmissão de arquivos são geradas provê concorrência entre arquivos de diferentes tamanhos na rede até o servidor. Além disso, esta rotina marca os tempos de início e de transmissão destes arquivos importantes para futura comparação. Esta rotina é mostrada do Apêncide B. Figura 12:Geração de tráfego concorrente no servidor FTP Ao se transmitir múltiplos arquivos simultaneamente para o servidor é possível que este não consiga tratar todo o tráfego recebido levando ao enfileiramento destes datagramas recebidos em um buffer por cada sessão no servidor. Quando isto ocorre, o receptor diminui o tamanho da janela de recepção anunciada, resultando na redução do tráfego que o emissor irá injetar na conexão. Se este buffer se esgota, o tamanho da janela é anunciado como zero, voltando a subir apenas quando o servidor tratar os pacotes recebidos [7]. Para avaliarmos o desempenho de cada política de escalonamento de tráfego temos que garantir, então, que o gargalo seja o roteador e não o servidor FTP. Assim, adicionaremos antes de cada elemento de saída todevice do roteador um elemento limitador de banda chamado BandwidthShaper, configurado para taxa de 1Mbps. Além disso, para compararmos mecanismos com duas filas com uma única fila, evitaremos possíveis descartes de pacotes tornando estas filas grandes o suficiente. O tamanho adotado foi de pacotes.

39 Base de arquivos Visando uma base de arquivos com a qual se pudesse simular um backup, mapeou se os arquivos dentro de um computador. Como era de se esperar, a distribuição destes arquivos mostra uma concentração alta de arquivos pequenos, abaixo de 100 kbytes. Estes arquivos apesar da grande quantidade, representam uma pequena faixa do volume de dados total. Na Figura 13 é apresentado o histograma dos arquivos do disco de um usuário doméstico comum. Nota se que este histograma foi limitado a arquivos maiores de 1 kbytes e menores que 4 MBytes. Figura 13: Distribuição de arquivos no disco O limite inferior se fez necessário pois, assim como na distribuição de Pareto, onde o número de arquivos tende a infinito quando o tamanho tende a zero, o número de arquivos do sistema inferiores a 1 kbytes ultrapassa 40000, tornando impossível a visualização das faixas superiores. Já o limite superior de 4MBytes foi adotado devido ao limiar superior dos fluxos longos, 22 bits do número de seqüência, a partir do qual, o fluxos retorna a condição de prioridade.

40 Geração dos números de seqüência no SO Como citado anteriormente para que a política de diferenciação de fluxos e escalonamento de tráfego via Run2C funcione adequadamente é necessário que uma adaptação na geração dos números de seqüência seja realizada. Esta adaptação deve se dar principalmente na máquina cliente FTP. Figura 14: Cabeçalho TCP O número de seqüência do pacote atual é o número de seqüência do pacote transmitido anteriormente incrementado do número de bytes transferidos por ele. Para que o mecanismo Run2C funcione adequadamente, dos 32 bits deste campo, 20 bits, os 10 bits mais e os 10 bits menos significativos são responsáveis pela aleatoriedade do número de seqüência, gerando um total de 1 milhão de possíveis valores iniciais. Os 12 bits restantes devem ser iniciados com zero quando uma conexão TCP é estabelecida. Desta forma, se torna possível que o roteador diferencie fluxos curtos dos longos apenas aplicando se uma máscara nos 10 bits mais significativos e estabelecendo um limiar de bytes transferidos. Por esse motivo, limitou se o tamanho máximo dos arquivos em 2²² = 4MBytes nos experimentos do próximo capítulo. Para isto, alterou se as funções do kernel Linux responsável pela geração dos ISNs. O arquivo alterado foi o Random.c, localizado dentro do kernel em linux<versão>/drivers/char/, aplicando se uma máscara que zera os 12 bits centrais dos números de seqüências aleatórios gerados pelas funções do arquivo.

41 Conclusão Neste capítulo foi apresentado o ambiente de teste e as rotinas de coletas de estatísticas, comprovando a validade dos resultados obtidos por elas, quando se fez uma comparação com um elemento externo de medições, o Iperf. Criou se um ambiente de teste baseado em um servidor FTP, e um cliente que gera múltiplas conexões para transmissão de arquivos de diferentes tamanhos, a fim de que seja estabelecida concorrência entre conexões curtas e longas.

42 38 5 EXPERIMENTOS E RESULTADOS 5.1 Introdução Com a estrutura da rede de testes montada, roteador, servidor e cliente de para transferência de arquivos e rotinas de coletas de estatísticas, pode se seguir com os experimentos. Primeiramente foi construída uma base de arquivos amostrando se os arquivos do disco de um usuário doméstico de computador. Em seguida, realizou se medidas e comparação dos desempenhos dos roteadores com e sem política de priorização de tráfego. 5.2 Base de arquivos amostrada Visando a manutenção da proporção entre os arquivos da base a ser construída para testes e a distribuição dos arquivos no disco, mostrada na Figura 13, realizou se uma amostragem onde o menor número de arquivos numa faixa do histograma fosse 1 e que as demais faixas fossem incrementadas proporcionalmente a esta. Figura 15: Amostragem proporcional

43 39 Esta amostragem resultou no histograma da Figura 15 que totaliza numa base de 682 arquivos. Nos primeiros testes constatou se que esta base era muito grande para a transmissão simultânea por um único cliente. Assim, reduziu se a base para o número máximo de threads FTP simultâneas conseguido, resultando em uma nova base de 381 arquivos com a distribuição mostrada na Figura 16 abaixo. Figura 16: Histograma dos arquivos transmitidos via FTP Com a base de arquivos obtida pode se representar um backup. A título de experiência, comparou se a distribuição dos arquivos transmitidos com uma distribuição cauda pesada truncada em arquivos de 1 kbytes (t min ) até 4 Mbytes (t max ). Para isto, é necessário que se normalize o histograma da Figura 16 dividindo o valor de cada faixa pelo número total de arquivos, obtendo assim as probabilidades dos arquivos transmitidos estarem em cada faixa. Em seguida, é necessário que se calcule a partir da p.d.f. de Pareto, p T (t), mostrada na equação (1) da seção 3, a probabilidade dos arquivos se encontrar em cada faixa do histograma acima. Como p T (t) é contínua, para isto, integra se a função em cada faixa. A equação (5) mostra o cálculo da probabilidade da faixa i, P faixa (i). O

44 parâmetro da distribuição que mais se aproximou da base de arquivos utilizada foi α = i 1 P faixa i = p T t dt (5) i 40 Figura 17: Distribuições de probabilidades 5.3 Fluxos por tempo Os arquivos amostrados formam nossa base de teste e serão transmitidos por múltiplas conexões simultâneas ao servidor FTP. Nesta situação, todos os arquivos começam a ser transmitidos juntos e a comparação de como as políticas de diferenciação e escalonamento de tráfego utilizados com o roteador com uma única fila DropTail é mostrado na Figura 18. É de se esperar que os fluxos curtos acabem antes já que este tipo de fluxo tem prioridade, quando é implementado o mecanismo Run2C no roteador.

45 41 Figura 18: Comparação do término dos fluxos nos roteadores Figura 19: Detalhes da comparação do termino dos fluxos Nota se claramente o melhor desempenho do Run2C com o escalonamento RoundRobin. A diferença de término dos fluxos entre este e o mecanismo de escalonamento PrioSched, provavelmente se deve a característica do último

46 42 mecanismo de servir a fila dos fluxos curtos com extrema prioridade, fazendo com que os fluxos que ultrapassem do limiar estipulado tenham que esperar mais. Apesar dos fluxos se finalizarem primeiro no roteador com RoundRobin, temos que garantir que são os fluxos curtos os responsáveis por isto. Assim, é necessário o cálculo do tempo médio de termino destes fluxos para cada faixa do histograma mostrado na Figura Tempo médio e variância de termino dos fluxos Espera se que o tempo médio dos fluxos nos roteadores com mecanismo de diferenciação e priorização de fluxos curtos sejam menores que no roteador sem este mecanismo. Os tempos médios, xmed, foram calculados pela soma dos tempos de transmissão dos arquivos, x, desde o início da conexão com o servidor FTP, contando com a autenticação no mesmo, até o fim da transmissão dos mesmos, para cada faixa. Figura 20:Tempo médio de fim dos fluxos para política DropTail

47 43 Figura 21: Tempo médio de fim dos fluxos para política Run2C PrioSched Figura 22: Tempo médio de fim dos fluxos para política Run2C RoundRobin

48 44 A partir destes diagrama de barras percebe se a aleatoriedade dos tempos de finalização dos fluxos no roteador com fila única na Figura 20. Ao contrário disso as Figuras 21 e 22 mostram uma distribuição mais justa e equilibrada destes tempos, provavelmente devido à facilidade de troca das mensagens de controle do FTP. Quando os três diagramas são comparados nota se que a priorização dos fluxos curtos surte efeito na faixa de interesse, fluxos curtos, localizados na primeira faixas do gráficos comparativos. O tempo médio de transferência de arquivos pequenos para a política DropTail, Run2C PrioSched e Run2C RoundRobin são respectivamente , e segundos, o que totaliza um ganho 23.2% quando se utiliza o PrioSched e 34.2% quando o RoundRobin é utilizado. A comparação de todas as faixas é apresentada na Figura 23. Figura 23: Comparação dos tempos médios de transferência de arquivos A diminuição do tempo médio de finalização dos fluxos curtos mostra a eficácia do mecanismo Run2C no tratamento deste tipo de transferência de dados. Ainda, vale ressaltar a proporcionalidade dos tempos de transferências aos tamanhos dos fluxos

49 acima do limiar, quando utiliza se um mecanismo de priorização de fluxos curtos, caracterizando uma alocação mais justa dos recursos na rede. A variância dos fluxos curtos que foram de , 1579,6 e 1017,18 segundos ao quadrado, para as filas DropTail, Run2C com PrioSched e Run2C com RoundRobin, totalizando um desvio padrão de , e segundos respectivamente. Isto representa uma redução um redução de 84.7% entre os dois primeiros mecanismos e de 87.94% do primeiro para o terceiro. A equação utilizada para o cálculo da variância foi a equação (7), onde s² é a variância, n é o número total de arquivos de uma faixa do histograma, x i é valor do tempo de transferência do i ésimo arquivo desta faixa e x med é o tempo médio de transferência dos arquivos da mesma faixa. x med = 1 n n x i (6) i=1 n s 2 = 1 n 1 x i x med 2 (7) i =1 45 Figura 24: Variância dos tempos médios dos arquivos O desvio padrão é a raiz quadrada da variância, e está mostrado na Figura 25.

50 46 Figura 25: Comparação dos desvios padrão 5.5Experimentos sem limitação de banda Para garantir o não congestionamento no servidor FTP, evitando a influência disto nas medidas coletadas, limitou se a banda do roteador em 1 Mbps. Agora serão apresentadas as estatísticas das medidas retiradas sem o limitador de banda. Todas as máquinas utilizadas tem cartões de rede 10/100 Mbps. De acordo com os testes de vazão mostrados na seção 4.3.1, os roteadores CLICK utilizados teriam vazão de aproximadamente 70 Mbps. Utilizou se a mesma base de arquivos transmitida anteriormente. Com o aumento da banda é de se esperar que os fluxos durem menos tempo e que fluxos longos se finalizem mais rápido, já que a disponibilidade de recursos é maior. Assim, pode se não se perceber tão claramente a justiça na alocação de banda, porém um indicativo de melhora do sistema seria a diminuição dos tempos médios e variância destes fluxos ao se comparar a fila única com os mecanismos de diferenciação e priorização de tráfego implementados. Manteve se filas grandes o suficiente para evitar descarte de pacotes.

51 47 Figura 26: Finalização dos fluxos sem limitação de banda Figura 27: Detalhes das finalizações dos fluxos sem limitação de banda

52 48 Figura 28: Tempos médios de fim dos fluxos sem limitação de banda Figura 29: Variância dos tempos médios sem limitação de banda

53 49 Figura 30: Desvio padrão dos tempos médios sem limitação de banda Nos gráficos mostrados nas Figuras 28, 29 e 30, percebe se ganhos, no sentido de diminuição do tempo médio de transferência dos arquivos localizados na primeira faixa, fluxos curtos, além da redução do desvio padrão destes tempos utilizando as políticas de fila implementadas, utilizando o RuN2C comparado a utilização de uma fila única DropTail. Estes ganhos consistem na diminuição nos tempos médios de finalização em 2.27% e 4.73% para Run2C com PrioSched e RoundRobin respectivamente, diminuição da variância em 60.43% e 90.80% para os mesmos, e conseqüente diminuição do desvio padrão em 26.85% e 37.96%. 5.6 Conclusão Mostra se válida e eficaz a priorização de fluxos curtos pelo mecanismo Run2C com escalonamento PrioSched e RoundRobin quando comparadas com uma única fila DropTail. Utilizando o Run2C, independentemente do mecanismo escalonador de pacotes das filas obteve se uma distribuição mais justa da banda, onde o tempo médio de