Relatório - Mecanismos de escalonamento de pacotes

Transcrição

1 Relatório - Mecanismos de escalonamento de pacotes Luísa Lima e João Vilela Departamento de Ciência de Computadores, FCUP c @alunos.dcc.fc.up.pt, c @alunos.dcc.fc.up.pt 13 de Junho de 2004

2 Conteúdo 1 Introdução 9 2 Mecanismos de Escalonamento Filas de espera Mecanismos de escalonamento - O que são? Mecanismos de Classificação de Pacotes Classless - Sem classes FIFO - First In First Out SFQ - Stochastic Fairness Queueing RED - Random Early Detection TBF - Token Bucket Filter Aproximação ao sistema de fluidos WFQ - Weighted Fairness Queueing Classfull - Com classes PRIO - Prioridade Estrita CBQ - Class-Based Queueing HTB - Hierarchical Token Bucket Que mecanismo de escalonamento usar? Ambiente de desenvolvimento Mecanismos de escalonamento e controlo de tráfego em Linux Interacção com o kernel do sistema operativo

3 CONTEÚDO Software utilizado NTP iproute rude e crude netperf TCNG - Traffic Control Next Generation TC tcpdump tcptrace tethereal Outro Trabalho desenvolvido FIFO Cenário Cenário Cenário Cenário SFQ Cenário Cenário RED Cenário TBF Cenário PRIO Cenário Cenário Cenário

4 CONTEÚDO HTB Cenário Ourmix Conclusão 66 A Gráficos 71 A.1 FIFO A.2 SFQ A.3 TBF A.4 PRIO A.5 HTB B Scripts desenvolvidos 95 B.1 Inicialização e configuração das máquinas B.2 Criação dos ficheiros de configuração para gerar tráfego B.3 Configuração dos mecanismos de escalonamento no router B.4 Análise de capturas e geração de gráficos C Configurações 117 C.1 Mecanismos de escalonamento C.1.1 Configurações TC C.1.2 Configurações TCNG C.2 Geração de tráfego C.2.1 Gerador C FIFO C SFQ C RED C TBF C PRIO

5 CONTEÚDO 4 C HTB C.2.2 Gerador 2 (enchimento) C FIFO C SFQ C RED C PRIO C HTB D Glossário 136 Referências 137

6 Lista de Figuras 2.1 Uma fila FIFO A estrutura do Stochastic Fairness Queueing A fila do Random Early Detection, com os limites mínimo e máximo Gráfico de descarte de pacotes do Random Early Detection Token Bucket Filter O funcionamento do Weighted Fairness Queueing O funcionamento do PRIO Class-Based Queueing Hierarchical Token Bucket - Uma estrutura de partilha hierárquica de uma ligação Hierarchical Token Bucket - um esquema possível Hierarchical Token Bucket - estrutura de classes e empréstimo Esquema do cenário utilizado Processamento de dados de rede em Linux A.1 Cenário 1 - Gerador 1 - entrada do router (vermelho) e saída do router (verde) A.2 Cenário 1 - Gerador 2 - entrada do router (vermelho) e saída do router (verde) A.3 Cenário 1 - Saída do router - G1 (Vermelho), G2 (Verde) A.4 Cenário 3 - Gerador 1 - entrada do router A.5 Cenário 3 - Gerador 1 - saída do router

7 LISTA DE FIGURAS 6 A.6 Cenário 4 - Gerador 1 - entrada do router (tcp) A.7 Cenário 4 - Gerador 1 - saída do router (tcp) A.8 Cenário 4 - Gerador 2 - entrada do router (udp) A.9 Cenário 1 - Geradores 1 (vermelho) e 2 (verde) - entrada do router A.10 Cenário 1 - Geradores 1 (vermelho) e 2 (verde) - saída do router A.11 Cenário 2 - Gerador 1 - saída do router (tcp) A.12 Cenário 2 - Gerador 2 - saída do router (udp) A.13 Cenário 1 - Gerador 1 - entrada do router (vermelho) e saída do router (verde) A.14 Cenário 1 - Gerador 1 - saída do router - tos 0x04 (vermelho), tos 0x10 (verde) e sem tos (azul) A.15 Cenário 2 - Gerador 1 - saída do router - tos 0x04 (vermelho), tos 0x10 (verde) e sem tos (azul) A.16 Cenário 3 - Gerador 1 - saída do router - tos 0x04 (vermelho), tos 0x10 (verde) e sem tos (azul) A.17 Cenário 1 - Gerador 1 - entrada no router (udp) A.18 Cenário 1 - Gerador 1 - saída do router (udp) A.19 Cenário 1 - Geradores 1 e 2 - saída do router - tos 0x04(vermelho), tos 0x10(verde), tos 0x10(azul), sem tos(amarelo)

8 Lista de Tabelas 2.1 HTB Mecanismos de escalonamento e parâmetros associados do TCNG ( - parâmetros obrigatórios, o - parâmetros facultativos) Parâmetros mais importantes dos mecanismos de escalonamento e unidades associadas Mecanismos de escalonamento classfull e parâmetros associados do TCNG ( - parâmetros obrigatórios, o - parâmetros facultativos) Parâmetros mais importantes dos mecanismos de escalonamento e unidades associadas Cenário 1 - FIFO (Resultados Crude) Cenário 3 - FIFO, TCP (Resultados Netperf) Cenário 3 - FIFO (Resultados Crude) Cenário 3 - FIFO, TCP sem enchimento UDP (Resultados Netperf) Cenário 4 - FIFO, TCP (Resultados Netperf) Cenário 4 - FIFO (Resultados Crude) Cenário 1 - SFQ (Resultados Crude) Cenário 2 - SFQ, TCP (Resultados Netperf) Cenário 1 - RED, TCP (Resultados Netperf) - FIFO no router Cenário 1 - RED, TCP (Resultados Netperf) - RED no router Cenário 1 - TBF (Resultados Crude) Cenário 1 - PRIO (Resultados Crude)

9 LISTA DE TABELAS Cenário 2 - PRIO (Resultados Crude) Cenário 3 - PRIO (Resultados Crude) Cenário 1 - HTB (Resultados Crude) Cenário 1 - HTB, TCP (Resultados Netperf)

10 Capítulo 1 Introdução O controlo de tráfego é o nome dado ao conjunto de sistemas e mecanismos de escalonamento através dos quais os pacotes são recebidos ou transmitidos num router. Isto inclui tanto as decisões sobre quais os pacotes a aceitar e a que taxa, na entrada de uma interface, como a determinação de quais os pacotes a transmitir e com que débito, na saída de uma interface. Na situação mais simples, o controlo de tráfego reduz-se a uma única fila de espera que recebe os pacotes e os liberta o mais rapidamente possível - este tipo de filas de espera designa-se por FIFO 1. As filas de esperas são locais onde os pacotes de uma rede esperam para ser processados, ou seja, são uma forma de organização de dados pendentes com a qual se pretende gerir os fluxos de dados que circulam numa rede, recorrendo-se para isso aos algoritmos de escalonamento. Os algoritmos de escalonamento decidem qual o próximo pacote que será servido na fila de espera, sendo, assim, um dos mecanismos responsáveis por distribuir a largura de banda da ligação pelos diferentes fluxos. Estes algoritmos podem ser do tipo work-conserving ou non-work-conserving. No primeiro caso, o servidor trabalha sempre, enquanto que no segundo caso, um nó pode transmitir um pacote apenas quando este se torna elegível 2. Se no nó apenas se encontrarem pacotes não elegíveis em espera, então o servidor manter-se-á inactivo. Este tipo de servidores é projectado para aplicações que não toleram variações no atraso de transmissão. 1 Sigla para First In - First Out. 2 Um pacote elegível é um pacote cujo tempo necessário para se manter em espera terminou. 9

11 CAPÍTULO 1. INTRODUÇÃO 10 A necessidade para este tipo de soluções prende-se com o facto de as redes baseadas em comutação de pacotes não terem estado, ao contrário das redes baseadas em comutação de circuitos (tais como as redes telefónicas), que têm de manter um estado dentro da própria rede. Apesar de esta falta de estado ser uma das vantagens principais do protolo IP 3, o ponto fraco desta implementação é a falta de diferenciação entre tipos de fluxos de pacotes. A maneira de introduzir o estado na rede é então precisamente o controlo de tráfego, que fornece a possibilidade de tratar os pacotes de forma diferente, baseando-se nos atributos do pacote. As situações mais frequentes que requerem controlo de tráfego são as seguintes: Limitar a largura de banda total a uma determinada taxa; Limitar a largura de banda que um determinado utilizador, serviço ou aplicação cliente pode utilizar; Maximizar o throughtput 4 do TCP, dando prioridade à transmissão dos pacotes ACK 5 ; Reservar largura de banda para uma determinada aplicação ou utilizador; Dar prioridade a tráfego sensível a variações de atraso; Distribuir a largura de banda de forma equitativa por diversos fluxos de tráfego; Assegurar que determinado tipo de tráfego não passa num router. Com este trabalho, pretende-se estudar os diferentes mecanismos de classificação e escalonamento de pacotes e a sua influência nos diferentes fluxos de dados. Para tal, sob o ponto de vista teórico, são apresentados vários algoritmos de escalonamento usados no controlo do tráfego, e as suas características associadas. Sob um ponto de vista mais prático, é realizado um conjunto de testes o mais abrangente possível, de forma a que sejam representativos do maior número de possíveis utilizações reais condições da rede. dos respectivos mecanismos de escalonamento e da sua influência nas 3 IP - Abreviatura de Internet Protocol. 4 Ver glossário. 5 Pacotes Acknowledgement do TCP

12 CAPÍTULO 1. INTRODUÇÃO 11 Neste relatório pretende-se assim apresentar o trabalho desenvolvido para o objectivo atrás explicado. Começa-se assim por, no segundo capítulo, explicar o que são e para que servem os mecanismos de escalonamento, seguindo-se uma descrição de cada mecanismo de escalonamento analisado ao longo deste trabalho. No terceiro capítulo, será apresentado o ambiente no qual foram desenvolvidos os cenários de teste. Será também feita uma análise de diversos programas utilizados, assim como da estrutura de apoio aos mecanismos do sistema operativo utilizado - o Linux. De seguida, no quarto capítulo, são mostrados os cenários de teste e será feita uma análise dos resultados obtidos. Começa-se, assim, por analisar os mecanismos de escalonamento Classless - ou seja, mecanismos de escalonamento que tratam indiferenciadamente todos os pacotes recebidos, sem os dividir em classes. De seguida continua-se a análise com os mecanismos Classfull, que têm a vantagem de implementar a diferenciação de pacotes já referida. O quinto e último capítulo é a conclusão e análise crítica do trabalho desenvolvido, sendo aqui também apresentadas as principais dificuldades surgidas ao longo deste.

13 Capítulo 2 Mecanismos de Escalonamento As redes de comunicação são atravessadas por pacotes que entram por um determinado nó e saem por outro. Durante esses percursos, esses mesmos pacotes são controlados por diversos mecanismos de controlo de tráfego. Controlo de tráfego é o nome dado ao conjunto dos sistemas de filas de espera e mecanismos associados pelos quais os pacotes são recebidos e transmitidos num router. Isto inclui decisões tais como quantos (e quais) os pacotes a aceitar e a que taxa de transmissão na entrada de uma interface, e quais os pacotes a transmitir e em que ordem na saída. 2.1 Filas de espera As filas de espera são o conceito fundamental por trás dos mecanismos de escalonamento. No contexto das redes, uma fila é um local que contém um conjunto finito de pacotes à espera de serem processados. 2.2 Mecanismos de escalonamento - O que são? Os mecanismos de escalonamento são algoritmos que gerem a forma como os pacotes são processados dentro das filas de espera. No modelo mais simples, os pacotes são servidos pela mesma ordem que são recebidos numa interface. Este modelo é designado por FIFO (First In First Out) (ver secção 2.4.1). 12

14 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 13 Sem mecanismos, uma fila de espera não permite fazer qualquer tipo de controlo de tráfego. Um fila torna-se muito mais útil quando associada a outros mecanismos que permitam atrasar pacotes, reordená-los, descartá-los e separar os pacotes por diversas classes consoante a sua prioridade. Estes mecanismos irão ser analisados ao longo deste capítulo. 2.3 Mecanismos de Classificação de Pacotes Os mecanismos de classificação de pacotes marcam os pacotes de acordo com regras predefinidas. Todos os pacotes pertencentes a um determinado fluxo cumprem essas regras e são processados de maneira semelhante. Determinados tipos de mecanismos de escalonamento necessitam de ter a capacidade de distinguir e isolar o tráfego em diferentes fluxos para os processar individualmente e garantir assim um tratamento diferente para diferentes tipos de dados. Assim sendo, existe um conjunto de mecanismos de classificação de pacotes que, utilizando diferentes regras, servem para classificar os pacotes de diferentes formas: fw Baseia a sua decisão na forma como a firewall marca os pacotes. u32 Baseia a decisão nos campos contidos nos pacotes (i.e. endereço de origem, etc). route Baseia a decisão na rota que o pacote irá tomar. rsvp Efectua a decisão baseada em rotas rsvp 1 tcindex Foi especialmente desenhado para a implementação de serviços diferenciados e é utilizado na disciplina de escalonamento Dsmark, estando fora do âmbito deste trabalho a sua explicação. 1 Resource Reservation Setup Protocol - usando rsvp, uma aplicação poderá reservar recursos numa rota desde a origem até ao destino.

15 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO Classless - Sem classes Os mecanismos Classless tratam o tráfego sem nenhuma diferenciação entre tipos de pacotes. Todos os fluxos são, assim, processados de igual maneira FIFO - First In First Out É o mecanismo de escalonamento de pacotes mais simples: todos os pacotes são tratados de igual maneira, sendo colocados numa fila única e servidos por ordem de chegada. Figura 2.1: Uma fila FIFO Apesar de ser simples, não permite diferenciação por tipos de fluxos, assim como dos limites máximos nos atrasos. Sendo assim, os fluxos de tráfego que recebem um serviço melhor são os que geram mais tráfego. As suas principais vantagens são: Para routers baseados em software, este algoritmo não sobrecarrega as máquinas, comparativamente com outros algoritmos de escalonamento de pacotes mais sofisticados. O comportamento do algoritmo é previsível, dado que os pacotes não são reordenados e o atraso máximo é correspondente ao tamanho da fila de espera.

16 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 15 Enquanto o tamanho da fila permanecer curto, o FIFO fornece um método de contenção simples para os recursos da rede, sem acrescentar uma diferença significativa ao atraso da fila em cada nó da rede. Tem, no entanto, bastantes limitações: Uma fila FIFO única não permite a organização dos pacotes em diferentes categorias, de forma a que os routers possam servir uma classe de tráfego de forma independente das outras classes. Como é uma fila única, o impacto do atraso influencia de forma idêntica todos os fluxos. É possível, assim, aumentar o atraso, o jitter e as perdas nas aplicações de tempo-real. Em períodos de congestão de rede, as aplicações que usam UDP são favorecidas relativamente às que usam TCP: quando existe perda de pacotes nesta situação, as aplicações baseadas em TCP reduzem a sua taxa de transmissão, adaptando-se às condições da rede actuais, enquanto que as baseadas em UDP continuam a transmitir pacotes à mesma taxa, dado que não estão informadas sobre as perdas de pacotes. Assim, a largura de banda ocupada pelo TCP é reduzida, aumentando o atraso 2 e o jitter 3. Um fluxo mal comportado pode consumir todo o espaço de memória de uma fila de espera FIFO, o que provoca a negação do serviço a todos os outros fluxos até que este acabe. Mais uma vez, a consequência é o aumento do atraso, jitter, e perdas para todos os outros fluxos UDP e TCP que passem por esta fila. Ainda assim, o FIFO é o mecanismo de escalonamento utilizado por defeito no Linux (apesar de ser uma versão optimizada deste algoritmo - o pfifo-fast) e na maioria dos routers, devido à sua simplicidade e eficiência SFQ - Stochastic Fairness Queueing O algoritmo de escalonamento Stochastic Fairness Queueing pertence à família de algoritmos baseado no algoritmo Fair Queueing, proposto por John Nagle em 1987: estes foram desenhados para assegurar que cada fluxo tem um acesso justo aos recursos da 3 Atraso - tempo que decorre desde que um pacote sai do emissor até chegar ao receptor, numa rede. 3 Jitter - é a variação do atraso sofrido por um pacote na rede.

17 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 16 rede, evitando que um fluxo largura de banda. mal-comportado consuma mais do que a sua quota de Os pacotes são classificados através de diversas características (normalmente, através de um valor numérico gerado a partir do tuplo [endereço de origem, porta de origem, endereço de destino], ou, no caso das implementações mais sofisticadas, [endereço de origem, porta de origem, endereço de destino, protocolo]) em filas de fluxos, e colocados numa fila (FIFO) dedicada a esse fluxo. As filas são então servidas, um pacote de cada vez, por um algoritmo round-robin; filas vazias não são consideradas. Sendo assim, quanto maior for o número de filas maior será a justiça do algoritmo; no entanto, como não é prático haver uma fila para cada categoria de pacotes, o SFQ utiliza uma função de hash para dividir os fluxos. Precisamente devido ao facto de se utilizar uma função de hash, vários fluxos podem ser classificados na mesma fila, o que iria diminuir a oportunidade de cada fluxo mandar pacotes, diminuindo a largura de banda efectiva. Para prevenir esta situação, aumentando a justiça do algoritmo, a função é trocada periodicamente. Figura 2.2: A estrutura do Stochastic Fairness Queueing Como vantagens de utilização, o Stochastic Fairness Queueing tem a vantagem de

18 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 17 ter uma configuração extremamente fácil e intuitiva, com parâmetros simples. Permite também um acesso justo aos recursos da rede, apesar de não permitir diferenciação de pacotes (o objectivo do algoritmo é, na realidade, precisamente o oposto!). A sua principal vantagem relativamente aos outros algoritmos da família Fair Queueing é a de a sua complexidade computacional ser inferior, apesar de ser menos preciso. Este algoritmo de escalonamento apenas pode ser utilizado em situações que não requeiram diferenciação (excepto quando utilizado em conjunção com mecanismos classfull (ver secção 2.5). É, assim, implementado quando se quer assegurar o mesmo acesso a vários clientes. Deixa-se como nota o facto de este algoritmo só actuar no caso de a interface de saída estar realmente cheia, dado que é necessário haver filas nesta interface RED - Random Early Detection O mecanismo de escalonamento de pacotes implementado nos routers da Internet originalmente foi o First-In, First-Out DropTail. Como já visto anteriormente, com este mecanismo os pacotes são servidos por ordem de chegada, sendo colocados no fim da fila quando chegam e retirados da cabeça da fila quando há capacidade disponível na ligação. O DropTail é um mecanismo que consiste em descartar os pacotes que chegam quando a fila está cheia (ou, em algumas implementações, descartar o pacote que está no início da fila). Esta maneira, apesar de ser de simples utilização e implementação, originam dois problemas graves: lock-out - É o fenómeno que acontece quando um recurso (neste caso a largura de banda da ligação) é consumida excessivamente por um pequeno número de fluxos. Os restantes fluxos são locked-out (isto é, não conseguem aceder à fila) e, consequentemente, é-lhes negado o acesso à ligação. Neste caso, a fila é ocupada apenas pelos pacotes de um pequeno número de fluxos, enquanto que os pacotes associados à maioria dos fluxos são constantemente descartados (fenómeno designado por starvation). Este fenómeno acontece devido a efeitos de timing, o que resulta no facto de os pacotes de alguns fluxos encontrarem sempre a fila de espera cheia: considerando uma situação na qual muitas fontes mandam bursts de pacotes periodicamente que no conjunto excedem a capacidade da fila, se estas fontes estiverem sincronizadas (mandando os pacotes quase em simultâneo), os primeiros pacotes que chegam à fila

19 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 18 (normalmente, os da fonte mais próxima do bottleneck da ligação) irão encontrar a fila ainda com capacidade de serviço, enquanto que os que chegarem a seguir irão ser descartados. Se esta sincronização se mantiver entre as fontes, as fontes que mandam os pacotes primeiro irão fazer progressos, enquanto que todas as outras irão ver os seus pacotes sistematicamente descartados. full-queues - As full-queues são filas de espera que estão na grande maioria do tempo ocupadas ao máximo. Se bursts de pacotes chegarem a uma fila de espera cheia, muitos pacotes são descartados simultaneamente, o que pode levar a grandes oscilações na utilização da rede. Se os pacotes descartados forem de fluxos diferentes, pode haver respostas (back-off) sincronizadas entre vários fluxos. O back-off sincronizado é um fenómeno no qual muitas fontes recebem simultaneamente notificações de congestão, reduzindo consequentemente a quantidade de informação enviada. Como resultado, a taxa de ocupação da rede pode descer abaixo da capacidade da ligação, subindo novamente mais tarde para vir a exceder a mesma - levando mais uma vez a descartes simultâneos devido ao excesso de pacotes nas filas. Este fenómeno acontece, por exemplo, com o protocolo TCP, dado que este tem mecanismos de congestão tais como o Slow-Start; neste caso tem o nome de Sincronização Global. O mecanismo de escalonamento RED foi criado com o objectivo de prevenir estes fenómenos, fornecendo o mais rapidamente possível uma resposta a fluxos que implementem controle de congestão (tais como o TCP) antes que a fila encha, indicando assim que a congestão da rede está eminente, em vez de esperar que esta se torne excessiva. Os descartes de pacotes são também distribuídos de forma mais equilibrada entre todos os fluxos. Este efeito é obtido controlando o tamanho médio da fila de espera no router: este é comparado a dois limiares (threshold), um mínimo e um máximo. Figura 2.3: A fila do Random Early Detection, com os limites mínimo e máximo. Quando o tamanho médio da fila é inferior ao limiar mínimo, nenhum pacote é marcado. Já se este tamanho for superior ao limiar máximo, todos os pacotes que chegam

20 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 19 são marcados; entre estes dois valores cada pacote é marcado com probabilidade p a (valor calculado com em função do tamanho médio da fila). O RED tem, assim, dois algoritmos distintos: um para calcular o tamanho médio da fila, que vai determinar a quantidade de pacotes que vão ser descartados na fila de espera; e outro para calcular a probabilidade de marcação de pacotes, que determina quão frequentemente o router marca os pacotes, de acordo com o nível actual de congestão. O objectivo é não só marcar pacotes em intervalos periódicos, de forma a evitar a sincronização global, mas marcá-los também com a frequência suficiente para controlar o tamanho médio da fila. Figura 2.4: Gráfico de descarte de pacotes do Random Early Detection Existem três modos de descarte de pacotes: Quando o tamanho médio da fila de espera é inferior ao limiar mínimo, não existe congestão, portanto nenhuma acção é tomada - a probabilidade de descarte de pacotes vai ser zero. No outro extremo, quando o tamanho médio da fila de espera é superior ao limiar máximo, ou se a fila está cheia, o algoritmo assume que existe uma grave congestão da rede - a grande maioria dos pacotes que chegam à fila de espera vão então ser descartados. A probabilidade de descarte é, assim, muito próxima de 1. Finalmente, quando o tamanho médio da fila de espera está entre os dois limiares, o algoritmo opera num modo probabilístico de descarte de pacotes. Assim, os pacotes vão ser descartados aleatoriamente, sendo que a probabilidade de um determinado pacote ser descartasdo oscila entre zero e um em função de três parâmetros: maxp - que determina a probabilidade máxima de dois pacotes consecutivos serem descartados quando se está neste modo (de descarte probabilístico), o tamanho médio da

21 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 20 fila de espera, e o parâmetro count - que indica quantos pacotes foram servidos desde que o último pacote foi descartado. Se os pacotes marcados forem efectivamente descartados, isto assegura que o tamanho médio da fila de espera não excede significativamente o limiar máximo definido; por outro lado, a probabilidade de um pacote de uma determinada ligação ser marcado é directamente proporcional à percentagem de largura de banda ocupada por essa ligação no router. Estes dois factos asseguram que o RED previne a congestão na rede. O RED é, assim, um algoritmo de escalonamento bastante engenhoso, com a grande vantagem de assegurar um melhor serviço ao protocolo TCP e de impedir a ocupação excessiva das filas por pequenos fluxos. Para suportar a diferenciação de serviços, deve-se utilizar o GRED - Generalized RED TBF - Token Bucket Filter O Token Bucket Filter não é um mecanismo de escalonamento, mas sim um traffic shaper - controla, assim, a taxa máxima à qual os pacotes são processados de uma fila. Sendo assim, decidimos analisá-lo neste trabalho por introduzir um tópico importante, útil e utilizado muito frequentemente com os mecanismos de escalonamento - traffic shaping. Os tokens e os buckets são os conceitos-chave no algoritmo do Token Bucket Filter. Para controlar a taxa de envio, ou de serviço de pacotes, uma opção de implementação é contar o número de pacotes ou bytes que vão sendo servidos - no entanto, isto requer um uso complexo de timers e medições para funcionar de forma correcta. Uma alternativa é gerar tokens a uma determinada taxa, e enviar os pacotes ou bytes apenas se um token estiver disponível. O TBF tem, assim, um funcionamento bastante simples: é criado um buffer - neste caso apelidado de bucket -, que se vai enchendo com tokens, a uma determinada taxa. Assim que houver tokens no bucket e pacotes na fila escolhe-se um token e manda-se os pacotes. O bucket vai-se enchendo com tokens de acordo com uma determinada taxa; se os tokens não forem utilizados, o bucket pode encher completamente, sendo os tokens guardados até serem utilizados. Senão, o bucket nunca poderá encher. Frequentemente usa-se a relação token-pacote de um token para um byte (leaky bucket), dado que a relação token-pacote não pode ser de um para um, pois os pacotes são na grande maioria das vezes de tamanhos diferentes...

22 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 21 Figura 2.5: Token Bucket Filter Existe também possibilidade de mandar bursts de tamanho preciso (do tamanho do bucket), em excesso da taxa definida. Entre as principais vantagens do TBF, conta-se o facto de ser simples e eficaz, sem grandes requisitos em termos de complexidade computacional. É utilizado, assim, frequentemente, para controlar a taxa máxima dedicada a uma determinada ligação ou fluxo Aproximação ao sistema de fluidos WFQ - Weighted Fairness Queueing Tal como o SFQ (Stochastic Fairness Queueing - ver secção 2.4.2) e todos os algoritmos da família FQ, o Weighted Fairness Queueing foi desenvolvido para assegurar que cada fluxo tem um acesso justo aos recursos de rede, prevenindo que os fluxos mal comportados consumam mais do que a largura de banda que lhes é atribuída.

23 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 22 Apesar de não ser um algoritmo de escalonamento Classfull (isto é, com classes) e de ser orientado para garantir a justiça na partilha de recursos entre fluxos, o SFQ permite fazer uma certa diferenciação entre tipos de pacotes. Figura 2.6: O funcionamento do Weighted Fairness Queueing Quando um pacote chega, é avaliado pelo mecanismo de classificação e atribuído a uma fila. A ordem do serviço é weighted round-robin 4, ou seja, round-robin com pesos, determinados por vários parâmetros: normalmente, uma representação numérica baseada em informação retirada do header do pacote (endereço e porta de origem, endereço de destino, protocolo, etc...). Mais uma vez, tal como o SFQ, o WFQ utiliza uma hash, juntamente com os parâmetros de classificação, para atribuir um pacote a uma fila. Assim, quanto maior for o número de filas, melhor é o funcionamento do algoritmo. Nos routers da Cisco esta implementação é mais sofisticada; este é o escalonador utilizado por defeito nas interfaces de série destes routers, se forem configuradas para serem utilizadas a velocidades menores ou iguais às E1 (2.048 Mbps). Para além de fazerem precedências por IP, o WFQ classifica o tráfego em diferentes fluxos, baseando-se na rede de origem e de destino ou nos endereços MAC, no protocolo, no número de socket da sessão, no valor DLCI - Frame Relay data-link connection identifier - e no valor do TOS (Type Of Service 5 ), para além de outras vantagens. 4 Ver glossário. 5 Ver glossário.

24 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 23 Como vantagens principais, o SFQ tem a facilidade de configuração e a de assegurar um acesso justo na partilha de recursos entre fluxos, apesar de fornecer maneira de fazer uma certa diferenciação entre tipos de pacotes. 2.5 Classfull - Com classes Os escalonadores Classfull utilizam os mecanismos de classificação de pacotes para o dividir os vários fluxos em classes, de forma a servir de forma diferente cada tipo de fluxo PRIO - Prioridade Estrita Neste caso, o escalonador é constituído por diversas filas de espera, cada uma com uma prioridade diferente, sendo o tráfego servido por ordem de prioridade. É a forma mais simples de permitir diferenciação de tipos de fluxos. No PRIO, os pacotes são classificados pelo sistema, sendo de seguida colocados em filas (FIFO) com diferentes prioridades; os pacotes das filas das filas de prioridade seguinte são servidos apenas se todas as filas de prioridade superior estiverem vazias. Figura 2.7: O funcionamento do PRIO O PRIO tem a vantagem de ser a forma mais simples de implementar a diferenciação de tipos de pacotes. Por outro lado, tem uma desvantagem: no caso de não existir

25 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 24 nenhum mecanismo de controle de admissão dos fluxos com maior prioridade, uma grande quantidade de pacotes de elevada prioridade pode impedir completamente o serviço de pacotes com menor prioridade - fenómeno designado por starvation. No entanto, isto pode ser prevenido se se utilizar, por exemplo, o TBF (Token Bucket Filter, descrito acima) para garantir que os fluxos de maior prioridade impeçam os seguintes de serem servidos CBQ - Class-Based Queueing Figura 2.8: Class-Based Queueing O CBQ não vai ser analisado em profundidade nesta secção, dado que a nossa escolha para análise recaiu sobre o HTB (Hierarchical Token Bucket - ver a próxima secção). O CBQ é, provavelmente, o mecanismo de escalonamento mais complexo existente actualmente. É constituído por dois escalonadores: um escalonador genérico e um escalonador de partilha de ligação. O escalonador genérico tenta garantir aos fluxos com requisitos de tempo real baixos atrasos na fila de espera, enquanto que o escalonador de partilha impede que as classes de tráfego de tempo real monopolizem a utilização da ligação, e faz também a distribuição do débito excedente. Baseia-se numa estrutura hierárquica em árvore de classes de tráfego, sendo cada pacote classificado à entrada dos nós. Entre as suas principais vantagens, contam-se o facto de ser um método de diferenciação de pacotes em classes, e de não ser muito complexo computacionalmente. No entanto, as desvantagens são actualmente inúmeras: precisa de saber a largura

26 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 25 de banda do link, fica confuso com tamanhos de pacotes demasiado dispersos e tem de fazer uma aproximação do idle time, dado que não há maneira de o medir em Linux. Os principais usos são os serviços diferenciados e redes complexas, com requisitos específicos para vários fluxos heterogéneos, e/ou requisitos de tempo real HTB - Hierarchical Token Bucket O Hierarchical Token Bucket é um mecanismo de escalonamento surgido recentemente. Foi criado por Martin Devera, sendo actualmente considerado o sucessor do Class-Based Queueing. O HTB implementa um escalonador classfull para o controlo de tráfego, fornecendo métodos para controlar a largura de banda que cada classe de tráfego pode utilizar, assim como de indicar a razão de distribuição de largura de banda quando existe largura de banda extra disponível (sendo que a máxima que uma classe pode utilizar é sempre o tecto). O Hierarchical Token Bucket faz, então, a partilha hierárquica de uma ligação. Esta deve obedecer a duas regras: Cada classe interior ou classe folha deve receber aproximadamente a sua largura de banda alocada durante os intervalos de tempo apropriados, se houver pedidos para essa classe. Se todas as classes folha e classes interiores com pedidos suficientes tiverem recebido pelo menos a sua largura de banda alocada, a distribuição de largura de banda que sobra não deve ser arbitrária, mas sim seguir um conjunto de regras. Conceptualmente, o HTB é constituído por um número arbitrário de token buckets organizados numa hierarquia. Cada classe HTB tem dois parâmetros principais - rate (taxa) e ceil (tecto). A largura de banda usada entre a taxa e o tecto é emprestada do pai da classe. A taxa é, assim, a largura de banda garantida disponível para uma dada classe, enquanto que o tecto é a largura de banda máxima que uma classe pode consumir. Uma parte fundamental do escalonador HTB é o mecanismo de borrowing (empréstimo). Na tabela 2.1 podemos observar o que acontece em cada caso, assim como as acções tomadas. Assim, o HTB assegura que a quantidade de serviço fornecida a cada classe é, no mínimo, a quantidade que esta pede, e no máximo o tecto. Quando uma classe pede

27 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 26 Tipo de Estado da Classe Estado interno do HTB Acção tomada Classe folha < taxa HTB CAN SEND A classe folha vai servir os bytes na fila até esgotar os tokens disponíveis (sem ultrapassar o valor do burst) folha > taxa, < tecto HTB MAY BORROW A classe folha vai tentar pedir tokens emprestados da classe pai. Se os tokens estiverem disponíveis, eles irão ser emprestados incrementalmente em quantums e a classe folha vai servir até burst bytes. folha > tecto HTB CANT SEND Nenhuns pacotes irão ser servidos, o que irá aumentar o atraso dos pacotes de forma a ajustar-se à taxa desejada. classe interior ou raiz < taxa HTB CAN SEND A classe interior irá emprestar os tokens aos seus filhos. classe interior ou raiz > taxa, < tecto HTB MAY BORROW A classe interior irá tentar pedir tokens emprestados à clase pai, emprestando-os de seguida aos filhos, em quantums incrementáveis por pedido. classe interior ou raiz > tecto HTB CANT SEND A classe interior não irá tentar pedir tokens ao seu pai e não irá emprestar tokens às classes-filho. Tabela 2.1: HTB

28 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 27 Figura 2.9: Hierarchical Token Bucket - Uma estrutura de partilha hierárquica de uma ligação Figura 2.10: Hierarchical Token Bucket - um esquema possível menos do que a quantidade a que tem direito, a largura de banda em excesso é distribuída pelas outras classes que façam pedidos de largura de banda. Para evitar que haja empréstimo de largura de banda - o que pode ser necessário,

29 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 28 Figura 2.11: Hierarchical Token Bucket - estrutura de classes e empréstimo por exemplo, num ISP, em que cada utilizador paga pela sua ligação - basta colocar a taxa com o mesmo valor que o tecto na configuração do HTB. Entre as inúmeras vantagens que advém do uso do HTB, destacam-se o facto de ter a mesma capacidade de traffic shaper que o Token Bucket Filter (TBF). A configuração e o uso de classes hierárquicas são fáceis, permitindo assim a partilha de uma ligação entre fluxos heterogéneos. Infelizmente, por ser bastante recente e ainda pouco divulgado, é pouco utilizado actualmente, sendo o CBQ a escolha generalizada no que toca aos mecanismos de escalonamento classfull. 2.6 Que mecanismo de escalonamento usar? O mecanismo de escalonamento a utilizar numa rede depende apenas dos requisitos que se tem para a utilização da rede. Sendo assim, vamos analisar de seguida algumas situações típicas em que seria útil utilizar mecanismos de escalonamento, e qual deverá ser utilizado:

30 CAPÍTULO 2. MECANISMOS DE ESCALONAMENTO 29 Controlar uma ligação com largura de banda conhecida O HTB - Hierarchical Token Bucket é o mecanismo de escalonamento ideal para se utilizar numa ligação com largura de banda conhecida, dado que a classe-pai pode ser configurada com a largura de banda máxima disponível numa determinada ligação. Os fluxos podem ser de seguida repartidos por classes-filho, de forma a garantir uma determinada largura de banda a uma classe de tráfego ou dar uma prioridade superior a determinados tipos de tráfego. Controlar uma ligação com largura de banda variável (ou desconhecida) Em teoria, o mecanismo de escalonamento PRIO é o ideal para ligações com largura de banda variável, dado que é um escalonador work-conserving, que não faz trafficshaping. Então, no caso de uma ligação com uma largura de banda desconhecida ou variável, a única coisa que o escalonador PRIO faz é dar prioridade de serviço a qualquer pacote que esteja na fila de prioridade máxima, seguindo-se as filas de prioridade inferior. Partilhar ou dividir a largura de banda baseada em fluxos Utilizando o mecanismo de escalonamento SFQ (Stochastic Fairness Queueing), o tráfego vai ser separado em fluxos, cada um dos quais vai ser servido de forma justa. O calcanhar de Aquiles de todos os algoritmos da família Fair Queueing são as aplicações ou utilizadores que abram muitas ligações simultaneamente - tais como o kazaa. Através da criação de um grande número de fluxos individuais, a aplicação pode dominar os lugares nas filas do escalonador: o algoritmo não sabe que é uma única aplicação a gerar a maioria dos fluxos, não penalizando o utilizador ou aplicação. Neste caso é necessário utilizar outros métodos (tais como mecanismos de escalonamento Classfull com TBF (Token Bucket Filter) para fazer traffic-shapping). Partilhar o dividir a largura de banda baseado no endereço IP Esta é, para muitos administradores, a forma ideal de dividir a largura de banda entre os seus clientes. No entanto, não há uma solução fácil: para dividir a largura de banda de forma equitativa entre N endereços IP, a única opção é mesmo ter um algoritmo de escalonamento Classfull com N classes - uma para cada IP.

31 Capítulo 3 Ambiente de desenvolvimento Para a realização deste trabalho foram utilizados cinco computadores pessoais, todos com o sistema operativo Linux: um a servir de router, dois geradores e dois receptores de tráfego. No router utilizaram-se três placas de rede: uma de 100Mbps (à entrada) e uma de 10Mbps (à saída), considerando-se o tráfego no sentido geradores de tráfego -> receptores de tráfego. Utilizou-se ainda uma placa de 100Mbps para ligar a máquina ao mundo exterior. O router possuía o sistema operativo Linux Mandrake 9.2 com o kernel mdk. Em todos os restantes PCs utilizámos placas de rede de 100Mbps. Para ligar os dois geradores e os dois receptores ao router utilizámos, respectivamente, um Switch e um Hub, de 10/100Mbps ambos. Colocando placas com maior capacidade em todos os pontos menos na saída do router, pretende-se que a influência das restantes placas nesta seja a menor possível, para podermos então alterar os seus mecanismos de controlo de tráfego e verificar os efeitos por eles induzidos. Colocámos também em todas as restantes placas o mecanismo de escalonamento FIFO explicado no capítulo anterior, com uma fila de espera de 100 pacotes - o suficiente para não serem descartados pacotes nessas interfaces que funcionam então como simples encaminhadores de pacotes. Todos os testes foram realizados em modo de texto e com o menor número de programas desnecessários a correr na máquina para tentar evitar influências externas nos resultados obtidos. 30

32 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 31 Figura 3.1: Esquema do cenário utilizado 3.1 Mecanismos de escalonamento e controlo de tráfego em Linux Cada interface de rede em Linux é controlada por um driver que controla o hardware. Este driver funciona como um mecanismo de troca de pacotes entre a camada de rede do Linux e a rede física. Quando um pacote chega a uma máquina Linux é passado por uma interface de rede ao desmultiplexador que o examina e determina se é destinado à máquina local. Se for o caso, o pacote é enviado para as camadas acima. Caso contrário, é analisada a tabela de

33 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 32 encaminhamento e determinado o próximo nó no percurso do pacote, que é colocado na fila de espera da interface de saída para ser transmitido. É neste altura que o controlo de tráfego do Linux entra em jogo, através de um conjunto de disciplinas de escalonamento, classes e filtros que controlam os pacotes que são enviados para a interface de saída. Figura 3.2: Processamento de dados de rede em Linux O controlo de tráfego pode ser realizado em duas fases: no policiamento à entrada (ingress policing) onde os pacotes indesejados são descartados para limitar a taxa de entrada de pacotes; nas filas de espera à saída (output queueing) onde se pode descartar, atrasar ou dar prioridade aos pacotes de acordo com a política desejada. Como se pretende que uma das máquinas funcione como um router puro, nenhum pacote vai ser gerado ou consumido por essa máquina, ou seja, nenhum pacote vai ser trocado com as camadas acima - os pacotes ou são encaminhados ou descartados. Neste caso, o percurso dos pacotes será o seguinte: interface de entrada (input interfaces) -> policiamento à entrada (ingress policing) -> desmultiplexador (input demultiplexer) -> forwarding 1 -> fila de espera à saída (output queueing) -> interface de saída (output interface) Interacção com o kernel do sistema operativo operativo Os mecanismos de escalonamento em Linux podem fazer parte do kernel 2 do sistema em si, ou ser utilizados como módulos 3. A primeira opção é desaconselhada 1 Apenas para passar os pacotes à interface de saída 2 É o elemento fundamental do sistema operativo, responsável pela gestão da memória e dos processos de uma máquina.

34 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 33 pois conduz a um aumento do tamanho do kernel e a ser necessário recompilar e reiniciar o mesmo de cada vez que se pretende utilizar uma nova funcionalidade. Por sua vez, a segunda opção permite extender a funcionalidade do kernel sem sequer ser necessário reiniciar o sistema operativo. Os módulos do Linux relativos aos mecanismos de escalonamento são os ficheiros iniciados por sch em /lib/modules/<versao kernel>/kernel/net/sched/. O parâmetro versao kernel pode ser obtido através do comando uname -r. Os mecanismos disponíveis nas máquinas que utilizámos são: First In First Out (FIFO) Priority Fifo Fast (PFIFO-FAST) 4 Stochastic Fair Queuing (SFQ) Random Early Detection (RED) Generalized RED (GRED) Token Bucket Filter (TBF) Prioridade Estrita (PRIO) Class Based Queueing (CBQ) Hierarchical Tocken Bucket (HTB) Clark-Shenker-Zhang (CSZ) Diff-Serv Marker (DS MARK) Traffic Equalizer (TEQL) Para utilizar um dos mecanismos de escalonamento é necessário previamente carregálo para a memória do kernel. Isto pode ser feito através do seguinte comando: modprobe <nome_do_mec_esc> 3 Pedaços de código que podem ser carregados para o kernel extendendo a sua funcionalidade. 4 Disciplina de escalonamento utilizada pelo Linux por defeito - é uma variação do FIFO

35 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 34 Parâmetro cbq fifo htb prio red sfq tbf avptk bands o bandwidth burst ecn o - - ewma o limit - o max min mtu peakrate o perturb o - priomap o - - o probability o - - quantum o - r2q - - o rate Tabela 3.1: Mecanismos de escalonamento e parâmetros associados do TCNG ( - parâmetros obrigatórios, o - parâmetros facultativos) Onde nome do mes esc é normalmente da forma sch <sigla do mecanismo de escalonamento>, tal como se vê nos módulos que se encontram no directório acima referido. Para se verificar se o módulo foi carregado com sucesso, basta ver se o mesmo se encontra listado no output do comando lsmod 3.2 Software utilizado NTP No sentido de compararmos os vários mecanismos de escalonamento, vamos ter em conta dados (como por exemplo, o atraso dos pacotes) que dependem da sincronização de

36 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 35 Parâmetro Unidade Descrição avptk Bytes tamanho médio dos pacotes bands inteiro número de classes bandwidth bps capacidade da interface burst Bytes burst a permitido indices inteiro índices usados para modificar o campo DS b limit Bytes tamanho máximo da fila em Bytes limit pacotes tamanho máximo da fila em pacotes max Bytes threshold c máximo min Bytes threshold d mínimo mtu Bytes maximum transmission unit e peakrate bps burst máximo permitido perturb segundos intervalo de perturbação priomap lista de classes mapa de classes probability número racional probabilidade máxima de descarte quantum Bytes burst máximo quando escalonado quantum segundos duração do burst quando escalonado rate bps capacidade máxima de ligação atribuída set tc index flag indica que deve copiar o campo DS para o tc index Tabela 3.2: unidades associadas Parâmetros mais importantes dos mecanismos de escalonamento e a normalmente >= MTU (Maximum Transfer Unit) b normalmente >= MTU (Maximum Transfer Unit) c campo de DiffServ, especialmente utilizado quando se pretendem serviços diferenciados d limiar máximo para um pacote ser descartado e limiar mínimo para um pacote ser descartado f tamanho máximo da unidade de transmissão

37 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 36 Parâmetro cbq gred hbf allot - - avpkt o - bandwidth - - bounded o - - burst o o cburst - - o ceil - - o default - o o isolated o - - ewma o - - limit o - max o - maxburst o - - min o - minburst o - - mpu o - - prio o o o probability - o - rate - weigth o - - Tabela 3.3: Mecanismos de escalonamento classfull e parâmetros associados do TCNG ( - parâmetros obrigatórios, o - parâmetros facultativos) Parâmetro Unidade Descrição allot Bytes tamanho médio dos pacotes bounde flag indica que a classe não pode usar larg. de banda de outras classes cburst Bytes tecto para o burst ceil bps largura de banda máxima que a classe pode usar isolated flag não pode emprestar nem usar larg. de banda de outras classes maxburst pacotes burst máximo quando limitada (ceil) minburst pacotes burst mínimo quando sujeito a escalonamento prio inteiro prioridade associada Tabela 3.4: Parâmetros mais importantes dos mecanismos de escalonamento e unidades associadas

38 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 37 tempo que existir entre as máquinas. Para o efeito, decidimos utilizar o NTP por ser um protocolo simples, com pouco overhead tanto para a rede, como para a própria máquina - tanto em termos de memória como em termos de processador. No entanto, apesar de ser a melhor opção que temos, para testes relacionados com performance em rede, este protocolo não apresenta precisão suficiente, daí que em alguns casos tenhamos mesmo chegado a obter resultados negativos para o atraso dos pacotes. Existem outras alternativas a este protocolo, no entanto, devido ao equipamento associado ser normalmente caro, essas opções nem se colocaram. Configuração e utilização A configuração do NTP é extremamente simples e directa. Tanto nos servidores como nos clientes, o ficheiro de configuração a utilizar é o /etc/ntp.conf. O nosso router, além de funcionar como servidor de NTP, era também um cliente de um servidor externo. Como tal, foi necessário especificar isso no ficheiro de configuração através das seguintes linhas: server server <ip do servidor a que nos vamos ligar> <ip do próprio router> Nos clientes, basta configurar uma daquelas linhas, da seguinte forma: server <ip do servidor> As restantes opções de configuração do ficheiro foram todas mantidas. É aconselhável antes de se começar a correr o daemon do NTP efectuar (pelo menos) duas sincronizações manuais, recorrendo-se ao ntpdate da seguinte forma: bash# ntpdate <ip do servidor> Esta sincronização é importante pois quando a diferença entre o tempo da máquina e o tempo do servidor for significativa, o NTP não funciona. Para finalizar o processo, coloca-se o daemon do NTP a correr com o seguinte comando: d Global Positioning System

39 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 38 bash# service ntpd start É possível observar a sincronização da máquina através do comando: bash# ntpq -p iproute2 O iproute2 é um conjunto de aplicações que configuram as estruturas do kernel relacionadas com as redes IP. O tc, uma das aplicações deste pacote, é a única utilizada para controlo de tráfego. Como tal, é aquela sobre a qual vamos incidir mais deste conjunto. Uma outra aplicação deste pacote que é útil é o ip. Esta aplicação foi utilizada para visualizar os atributos das interfaces de rede, nomeadamente os mecanismos de escalonamento e parâmetros associados. Para obter esses dados, a sintaxe do comando utilizada foi: bash# ip link sh rude e crude O rude (gerador de tráfego) e o crude (receptor do tráfego e gerador de estatísticas), no seu conjunto, formam uma aplicação interessante para avaliar os efeitos dos mecanismos de escalonamento nos fluxos de dados de uma rede. Apesar de não gerar tráfego TCP, a escolha desta aplicação deveu-se à sua configuração simples e ao facto de fornecer dados significativos relativos aos fluxos no colector, tais como: débito número de pacotes recebidos e perdidos atraso médio dos pacotes jitter médio jitter máximo

40 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 39 Instalação, configuração e utilização A instalação do rude decorreu sem problemas. Para tal bastou seguir os ficheiros de ajuda disponibilizados com a aplicação. Em termos de configuração, é necessário elaborar um ficheiro de configuração com a seguinte estrutura: START NOW ON :10001 CONSTANT TOS 10 0x OFF De seguida faz-se a descrição de cada um dos parâmetros: Linha 1: marca o início da configuração para um fluxo de dados Linha 2: milisegundos aos quais o fluxo começa a ser transmitido 10 - identificador do fluxo gerado ON - indica o início do fluxo porta utilizada na máquina de origem : ip e porta da máquina de destino CONSTANT - tipo do fluxo gerado, no caso Constant Bit Rate número de pacotes gerado por segundo tamanho em bytes dos pacotes gerados Linha 3: indica o tipo de serviço que é definido no cabeçalho IP dos pacotes. Este significa minimize delay e está normalmente associado a tráfego interactivo. Linha 4: indica que o fluxo deixa de ser transmitido aos milisegundos Para facilitar e uniformizar a tarefa de geração de gráficos, implementámos um script em Perl que gera estes ficheiros automaticamente (ver anexos: gera trafego.pl). O script permite escolher o início e o fim dos testes, o TOS e, o número de pacotes por segundo e o tamanho em bytes de cada pacote.

41 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 40 Os IPs de origem e destino e os IDs dos fluxos variam consoante o gerador que está a correr o script. Já no que diz respeito à utilização, começando por correr o cliente, para não se perderem pacotes enviados pelo servidor, o comando a utilizar é: crude -s <id do fluxo gerado pelo servidor> Por sua vez, após criado o ficheiro de configuração pretendido para o servidor, o comando a utilizar é: rude -s <caminho para o ficheiro de configuraç~ao> Quando o servidor terminar o envio de pacotes, basta efectuar um control+c no cliente para os resultados serem mostrados. O facto de nem o cliente nem o servidor gerarem output durante o decorrer dos testes é relevante, pois as operações de impressão de dados para o ecrã são gastadoras em termos de processador, o que poderia influenciar os resultados. Tanto no gerador como no receptor, optámos também por utilizar o parâmetro -P <prioridade> que dava prioridade aos processos originados por esta aplicação relativamente aos restantes, o que deverá induzir um menor erro nos resultados obtidos netperf Uma vez que o Rude não gera tráfego TCP, a aplicação que decidimos utilizar para o efeito é o netperf. Esta aplicação baseia-se em dois executáveis - netperf e netserver. Quando se executa o netperf, é estabelecida uma ligação de controlo com o sistema remoto (onde se colocou o netserver a correr). Esta ligação é utilizada para trocar configurações e resultados com o servidor. Após o estabelecimento da ligação de controlo, uma ligação nova é estabelecida para a medição da performance em si. De seguida o teste é efectuado e os resultados gerados. O netperf não gera nenhum tráfego para a ligação de controlo enquanto os testes estão a decorrer. e Type Of Service (tipo de serviço) - é um campo do cabeçalho IP dos pacotes que indica qual o tipo de serviço associado a um pacote e que pode influenciar a maneira como este é tratado.

42 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 41 Apesar de o netperf ter muitas outras funcionalidades, no âmbito deste trabalho ele vai ser utilizado apenas para o seu teste por omissão: verificar com que taxa de transmissão o gerador consegue transmitir dados num fluxo unidireccional tcp no sentido do receptor. Utilização Para correr netperf no servidor, basta executar a aplicação netserver que fica a correr como daemon. Por sua vez, no cliente, basta utilizar o netperf da seguinte forma: netperf -H <ip do receptor> Com esta configuração simples, é efectuado um teste de dez segundos (por vezes maior quando é gerado tráfego de enchimento) entre o gerador e o receptor, findo o qual são geradas estatísticas, neste caso e ao contrário do rude, no gerador de tráfego. A estatística gerada contém, entre outras, as seguintes medições: taxa de transmissão conseguida e tempo decorrido TCNG - Traffic Control Next Generation O TCNG é um projecto iniciado por Werner Almesberger com o intuito de providenciar uma linguagem poderosa e abstracta na qual se podem especificar estruturas de controle de tráfego em Linux. Este projecto surgiu com o objectivo de tornar a configuração do controlo de tráfego em Linux mais simples do que na aplicação mais utilizada para o efeito actualmente - o tc. são: É constituído por várias aplicações, das quais as mais relevantes para este trabalho TCC O tcc é um parser que transforma a linguagem tcng em vários formatos possíveis. Por defeito, o tcc lê um ficheiro e retorna uma série de comandos tc utilizados para criar a estrutura de controle de tráfego desejada no kernel. Neste trabalho, apenas usamos o output por defeito ( tc ). tcsim

43 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 42 O tcsim é um simulador de controle de tráfego que aceita os ficheiros de configuração do tcng, em conjunto com uma linguagem de controle, para simular o comportamento de um kernel que envia e recebe pacotes de acordo com as especificações fornecidas. Instalação Durante a instalação do TCNG ocorreram alguns problemas, que foram resolvidos através das seguintes modificações: Instalação do sed v3.02, pois a versão instalada (4.0.7) era incompatível com o tcng (ver No ficheiro tcsim/trace.c, foi necessário comentar as seguintes linhas: if KFULLVERSIONNUM >= 0x20416 else define SCH_DROP_UNSIGNED endif E deixar apenas a seguinte linha descomentada: define SCH_DROP_UNSIGNED unsigned Isto foi feito para resolver a seguinte mensagem de erro, obtida ao compilar o programa: invalid suffix mdkcustom on integer constant tcsim/modules/sch discard.c. Configuração e utilização O TCNG utiliza uma linguagem de configuração semelhante às linguagens orientadas a objectos, compacta e simples e que permite fazer muita coisa com muito pouco. Nesta secção vão ser apresentados dois exemplos (um simples e um mais complexo) de ficheiros utilizados para configurar os mecanismos de escalonamento em Linux. Exemplo 1: dev eth0 { egress {

44 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 43 fifo (limit 100p ); De seguida, é feita a explicação das configurações apresentadas acima: Com este exemplo, associa-se o mecanismos de escalonamento FIFO com fila de espera de cem pacotes à interface de rede eth0. A palavra egress é um sinónimo para dsmark f. Exemplo 2: #include "fields.tc" #include "ports.tc" dev eth0 { egress { // classificaç~ao class (<$high>) if tcp_dport == PORT_HTTP; class (<$low>) if 1; // filas de espera prio { $high = class (1) { fifo (limit 20kB); $low = class (2) { fifo (limit 100kB); De seguida, é feita a explicação das configurações apresentadas acima: As primeiras duas linhas incluem ficheiros com definições que permitem obter dados dos cabeçalhos dos pacotes e números de portas.

45 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO 44 Esta configuração baseia-se em duas partes: Classificação dos pacotes Os pacotes com destino à porta http (parâmetro tcp dport), são enviados para a classe de prioridade alta ($high); Todos os restantes pacotes são enviados para uma classe de prioridade baixa ($low). É sempre uma boa ideia terminar a classificação com uma regra onde encaixam todos os pacotes que sobram. Configuração do sistema de filas de esperas Na parte de configuração das filas de espera, define-se que tanto os pacotes com prioridade alta como com prioridade baixa são controlados pelo mecanismo de escalonamento FIFO. No entanto, com este esquema, garante-se uma largura de banda de 20kB para o tráfego http, e 100kB para o restante tráfego. Naturalmente é possível utilizar qualquer outro mecanismo de escalonamento para gerir os pacotes internamente em cada classe. Esta é uma configuração pouco complexa, no entanto, com pouco mais do que isto vai ser possível configurar todos os casos de teste realizados neste trabalho (os ficheiros de configuração podem ser vistos em anexo). Depois da escrita dos ficheiros de configuração, o tcc (trafic control compiler) recebe como argumento esses ficheiros e gera scripts de bash para configurar os mecanismos de escalonamento como pretendido. Por omissão, estes scripts são um conjunto de comandos de TC (ver abaixo) que configuram os mecanismos, no entanto, é possível originar ficheiros em C++ ou até módulos para o kernel. A sintaxe utilizada para gerar a generalidade dos ficheiros de configuração foi: bash# tcc ficheiro de configuracao tcng > ficheiro de configuracao gerado f É uma disciplina de escalonamento que não ajusta, controla ou policia o tráfego. Não dá prioridade não atrasa, não reordena nem descarta pacotes. Apenas marca os pacotes utilizando o campo DS (diff serv). Esta classe é especialmente importante no âmbito dos serviços diferenciados, no entanto, também vai ser utilizada ao longo deste trabalho para permitir definir classes identificadoras dos fluxos.

46 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO TC Sempre que nos foi possível, utilizámos TCNG para configurar os mecanismos de escalonamento. No entanto, esporadicamente utilizámos o TC (traffic control) apesar deste possuir uma sintaxe mais complexa e menos intuitiva. Umas vezes utilizámo-lo por o TCNG não apresentar suporte para alguns mecanismos de escalonamento, outras vezes devido à documentação encontrada estar mais explícita num caso do que noutro. Configuração e utilização Antes da adição de um novo mecanismo de escalonamento a controlar uma interface de rede, remove-se o anterior através da seguinte sintaxe: bash# tc qdisc del dev <interface a modificar> root Remove o mecanismo de escalonamento associado a uma interface de rede, colocando aquele que é configurado por omissão no Linux quando nenhum outro é definido (pfifo fast). A sintaxe genérica de utilização deste utilitário para modificar o mecanismo de escalonamento associado a uma interface de rede, é a seguinte: bash# tc qdisc add dev <interface a modificar> root \ > <mecanismo de escalonamento> <conjunto de par^ametros> No fundo, todos os scripts que utilizámos para configurar as interfaces de rede utilizam o TC; no entanto, como a maior parte deles foram gerados através do TCNG que tem uma linguagem de alto nível mais intuitiva, não foi necessário ir muito mais além do que este comando, na complexidade do TC. Uma outra utilidade do TC que utilizámos regularmente foi: bash# tc qdisc sh Que serve para visualizar as várias interfaces e os mecanismos e parâmetros a elas associados. Todos os scripts, quer os criados manualmente, quer aqueles que foram gerados com o TCNG estão disponíveis no Apêndice.

47 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO tcpdump O tcpdump é uma ferramenta que permite fazer sniffing numa interface de rede e, consequentemente, análise estatística através das suas capturas. No nosso caso, o tcpdump foi essencialmente utilizado para gerar ficheiros com capturas dos pacotes que passam no router, para serem feitas estatísticas relativamente ao throughput médio e instantâneo e gráficos com essas estatísticas. Para fazer as respectivas estatísticas e gerar os gráficos, implementámos um conjunto de scripts em Perl (ver Geração de gráficos no Apêndice B) que, analisando as capturas do tcpdump, permitem obter o throughput instantâneo e médio dos fluxos gerados. Para o cálculo do throughput médio, é acumulado o tamanho dos pacotes de cem em cem pacotes (configurável) e quando chegamos ao centésimo, dividimos esse valor pela diferença entre o tempo inicial e o tempo final. Utilização O tcpdump permite utilizar filtros para limitar os pacotes que são apanhados, de acordo com um critério definido. Neste trabalho, para evitar a interferência de outros fluxos utilizou-se um filtro que permite limitar os pacotes apanhados de acordo com os IPs de origem e destino dos pacotes, com a seguinte sintaxe: bash# tcpdump src host <ip do gerador 1> or src host <ip do gerador 2> and \ > dst host <ip do receptor 1> or dst host <ip do receptor 2> A utilização do tcpdump variou consoante os fluxos gerados fossem tcp ou udp: Fluxos udp Para gerar os gráficos dos fluxos udp, utilizámos as capturas do tcpdump obtidas através do redireccionamento para um ficheiro de dados: bash# tcpdump > <ficheiro_dados> Fluxos tcp Por sua vez, como para gerar os gráficos dos fluxos tcp utilizámos a aplicação tcptrace (a ver de seguida), que recebe como dados ficheiros binários gerados com a opção -w do tcpdump. A sintaxe utilizada, sem incluir os filtros já referidos, é a seguinte: bash# tcpdump -w <ficheiro de saída>

48 CAPÍTULO 3. AMBIENTE DE DESENVOLVIMENTO tcptrace O tcptrace é uma aplicação que utiliza as capturas do tcpdump para gerar estatísticas relativas aos fluxos tcp encontrados. Em relação aos fluxos udp apresenta poucos dados relativamente ao que pretendemos. Apesar de ter um grande conjunto de opções, foi utilizado essencialmente para gerar gráficos de throughput. A sintaxe utilizada para o efeito foi: bash# tcptrace -T <captura do tcpdump> Os gráficos gerados com esta opção correspondem ao throughput médio dos últimos dez segmentos e podem ser visualizados através do Xplot tethereal O tethereal é uma aplicação semelhante ao tcpdump, no entanto, foi utilizada apenas para transformar os ficheiros binários obtidos do tcpdump em ficheiros de texto para podermos obter estatísticas baseadas neles. A sintaxe utilizada para isso é: bash# tethereal -r <captura do tcpdump> Quando estamos a analisar a interacção entre fluxos tcp e udp, o tcptrace utiliza os ficheiros binários do tcpdump para gerar os gráficos, no entanto, as estatísticas udp são obtidas através de ficheiros em texto. Esta aplicação faz a conversão do primeiro para o segundo formato Outro Além dos geradores e receptores de tráfego, foram utilizadas as aplicações reais interactivas, para testar os efeitos dos diferentes mecanismos de escalonamento no tráfego originado: SSH Quake3

49 Capítulo 4 Trabalho desenvolvido Neste capítulo iremos apresentar os resultados obtidos nos cenários experimentados durante o desenvolvimento do trabalho, assim como uma breve interpretação dos mesmos. As configurações dos mecanismos de escalonamento (feitas no router) são apresentadas em anexo, no Apêndice C, assim como as configurações do rude e netperf para geração de tráfego UDP e TCP. 4.1 FIFO Como já foi apresentado acima, o FIFO é o mecanismo de escalonamento mais simples, consistindo numa única fila de espera. Sendo assim, os seguintes cenários foram pensados principalmente como termo de comparação com os mecanismos de escalonamento mais complexos. Para analisarmos o FIFO, configurámos uma fila FIFO com 100 pacotes no router Cenário 1 Objectivo Este cenário foi pensado como um primeiro cenário de teste, para analisarmos como é que o mecanismo de escalomento FIFO se comporta com dois fluxos iguais. 48

50 CAPÍTULO 4. TRABALHO DESENVOLVIDO 49 Gerador Throughput médio (Mbps) Jitter (s) Pacotes recebidos Pacotes perdidos Gerador Gerador Tabela 4.1: Cenário 1 - FIFO (Resultados Crude) Metodologia Este cenário consiste na geração de dois fluxos UDP CBR iguais: O gerador 1 gera 6Mbps. O gerador 2 gera 6Mbps. Os resultados foram medidos no crude em cada um dos receptores, assim como no tcpdump no router. Resultado obtido Os resultados medidos no crude são os apresentados na tabela 4.1. Este cenário foi repetido algumas vezes; chegámos à constatação de que, apesar de os resultados serem semelhantes para cada cenário, estes dependiam da ordem pela qual as fontes UDP eram activadas. Isto acontece pois o primeiro fluxo irá ocupar a fila primeiro, sendo que o segundo fluxo fica com o que sobra Cenário 2 Objectivo Este cenário foi pensado para se verificar se o FIFO diferencia os fluxos por tipo de serviço ou não. Metodologia Este cenário consiste na geração de dois fluxos UDP CBR com throughputs iguais, mas TOS diferentes: O gerador 1 gera 6Mbps.

51 CAPÍTULO 4. TRABALHO DESENVOLVIDO 50 Gerador Throughput médio (Mbps) Elapsed time Gerador Tabela 4.2: Cenário 3 - FIFO, TCP (Resultados Netperf) O gerador 2 gera 6Mbps. Resultado obtido Os resultados obtidos foram em tudo semelhantes aos resultados obtidos na experiência anterior, tendo-se assim chegado à conclusão de que o mecanismo de escalonamento FIFO não faz diferenciação por tipo de serviço Cenário 3 Objectivo Este cenário foi pensado para se analisar o comportamento do TCP face ao enchimento UDP com um mecanismo de escalonamento FIFO. Metodologia TCP: Este cenário consiste na geração de um fluxo UDP de enchimento e um fluxo O gerador 1 gera um fluxo TCP. O gerador 2 gera um fluxo UDP com 10Mbps. Os resultados foram medidos no netperf do gerador 1 e no crude do receptor 2, assim como no tcpdump no router. Resultado obtido Os resultados medidos no netperf são os apresentados na tabela 4.2. Os resultados medidos no crude são os apresentados na tabela 4.3.

52 CAPÍTULO 4. TRABALHO DESENVOLVIDO 51 Gerador Throughput médio (Mbps) Jitter (s) Pacotes recebidos Pacotes perdidos Gerador Tabela 4.3: Cenário 3 - FIFO (Resultados Crude) Gerador Throughput médio (Mbps) Elapsed time Gerador Tabela 4.4: Cenário 3 - FIFO, TCP sem enchimento UDP (Resultados Netperf) Adicionalmente fizemos um teste de geração de um fluxo TCP apenas (sem qualquer espécie de tráfego UDP), tendo sido os resultados os apresentados na tabela 4.4. Verifica-se, assim, uma grande discrepância entre os resultados obtidos no teste apenas com o fluxo TCP e no teste com o fluxo TCP e o fluxo UDP de enchimento. Isto acontece pois o TCP, sendo um protocolo fiável, tem mecanismos de congestão de forma a não haver perda de pacotes; já o UDP manda o CBR 10Mbps pois, não tendo esses mecanismos, não detecta perdas de pacotes. Sendo assim, podemos concluir que o TCP apenas ocupa a largura de banda deixada livre pelo UDP - o FIFO não é, assim, uma boa alternativa no caso de uma rede com vários fluxos UDP e TCP, pois estes serão sempre prejudicados relativamente aos fluxos UDP Cenário 4 Objectivo Este cenário foi pensado para se confirmar os resultados do cenário anterior, analisando o comportamento do TCP face a um fluxo UDP que não encha a ligação. Metodologia Este cenário consiste na geração de um fluxo UDP com débito abaixo da capacidade máxima da ligação e um fluxo TCP: O gerador 1 gera um fluxo TCP. O gerador 2 gera um fluxo UDP com 8Mbps.

53 CAPÍTULO 4. TRABALHO DESENVOLVIDO 52 Gerador Throughput médio (Mbps) Elapsed time Gerador Tabela 4.5: Cenário 4 - FIFO, TCP (Resultados Netperf) Gerador Throughput médio (Mbps) Jitter (s) Pacotes recebidos Pacotes perdidos Gerador Tabela 4.6: Cenário 4 - FIFO (Resultados Crude) Os resultados foram medidos no netperf do gerador 1 e no crude do receptor 2, assim como no tcpdump no router. Resultado obtido Os resultados medidos no netperf são os apresentados na tabela 4.5. Os resultados medidos no crude são os apresentados na tabela 4.6. Confirmaram-se, assim, as conclusões tiradas do cenário anterior. 4.2 SFQ Sendo (como já referido no Capítulo 2) o SFQ um mecanismo de escalonamento que tem o objectivo de assegurar um acesso justo a todos os fluxos, os cenários que se seguem foram pensados com o objectivo de ilustrar esta característica. Para analisarmos o SFQ, configurámos o SFQ no router, com uma perturbação de 10 segundos, ou seja, com função de hash a ser rodada de 10 em 10 segundos Cenário 1 Objectivo Este cenário foi pensado com o objectivo de ilustrar o acesso justo dos diferentes fluxos aos serviços.

54 CAPÍTULO 4. TRABALHO DESENVOLVIDO 53 Gerador Throughput Pac. perdidos Pac. fora da Jitter (s) Pac. recebi- médio (Mbps) dos sequência Gerador Gerador Tabela 4.7: Cenário 1 - SFQ (Resultados Crude) Metodologia Este cenário consiste na geração de dois fluxos UDP CBR diferentes: O gerador 1 gera 12Mbps. O gerador 2 gera 16Mbps. Os resultados foram medidos no crude em cada um dos receptores, assim como no tcpdump no router. Resultado obtido Os resultados medidos no crude são os apresentados na tabela 4.7. Analisando os resultados obtidos, podemos desde já constatar que foi o primeiro (e único) cenário em que obtivemos pacotes fora de sequência. Isto pode, com efeito, acontecer no SFQ, dado que, devido à função de hash utilizada para dividir os fluxos entre as diferentes filas, pode acontecer que os pacotes de um mesmo fluxo sejam recebidos em filas diferentes e, portanto, servidos com os tempos trocados. Podemos também constatar que tanto os throughputs médios como o jitter são bastante aproximados, tal como seria de esperar. Analisando os gráficos dos throughputs médios, tanto à entrada como à saída do router (ver Apêndice A) podemos ter uma visualização dos resultados resumidos na tabela 4.7: com efeito, à entrada do router, ambos os fluxos têm os throughputs CBR enviados, sendo que à saída, com a excepção de uma ligeira perturbação inicial, os dois fluxos têm um throughput médio bastante aproximado ao longo dos sessenta segundos que demora a simulação.

55 CAPÍTULO 4. TRABALHO DESENVOLVIDO 54 Gerador Throughput médio (Mbps) Elapsed time Gerador Tabela 4.8: Cenário 2 - SFQ, TCP (Resultados Netperf) Cenário 2 Objectivo Este cenário foi pensado com o objectivo de observar como é que o TCP se comporta em conjunto com o UDP com o mecanismo de escalonamento de pacotes SFQ. Metodologia TCP: Este cenário consiste na geração de um fluxo UDP de enchimento e um fluxo O gerador 1 gera um fluxo TCP. O gerador 2 gera um fluxo UDP com 10Mbps. Os resultados foram medidos no netperf do gerador 1 e no crude do receptor 2, assim como no tcpdump no router. Resultado obtido Os resultados medidos no netperf são os apresentados na tabela 4.2. Os resultados medidos no crude não são significativos pois o teste TCP dura apenas 10 segundos. Para visualizar a progressão do throughput do fluxo UDP ao longo do tempo, gerámos o gráfico apresentado em anexo (Anexo A). Os resultados do teste de geração de um fluxo TCP apenas (sem qualquer espécie de tráfego UDP) são apresentados na tabela 4.4, já referida anteriormente. Podemos assim observar que efectivamente o SFQ fornece um acesso justo a todos os fluxos (tanto TCP como UDP): com efeito, nos dez segundos que dura a geração de tráfego TCP, pode-se observar que o throughput médio é aproximadamente o mesmo. É de notar também a grande discrepância entre os resultados obtidos com o SFQ e os resultados obtidos com o FIFO (cenário 3): o TCP aqui tem direito a uma percentagem da ligação

56 CAPÍTULO 4. TRABALHO DESENVOLVIDO 55 equivalente à do UDP, ao contrário do que acontecia com o mecanismo de escalonamento FIFO. 4.3 RED Como já foi visto anteriormente, o RED é um mecanismo de escalonamento que surgiu principalmente com o intuito de evitar a sincronização global. Para testarmos o RED, configurámos este mecanismo de escalonamento no router com os seguintes parâmetros: limit bytes; é o limite de dados na fila, a partir do qual os pacotes são descartados. min bytes; é o tamanho médio da fila. max bytes; avpkt ; burst - 666; este valor é utilizado para determinar quão rápido o tamanho médio da fila é influenciado pelo tamanho real da fila, e é aconselhado que seja igual a (min*2+max)/(3*avptk) probability ; probabilidade de marcar pacotes; 0.01 ou 0.02 são os valores aconselhados. bandwidth Kbps; é a largura de banda da ligação Cenário 1 Objectivo O objectivo deste cenário é analisar o impacto do mecanismo de escalonamento RED ao correr várias fontes TCP em simultâneo. Metodologia Este cenário consiste na geração de 20 fluxos TCP, na medida do possível em simultâneo:

57 CAPÍTULO 4. TRABALHO DESENVOLVIDO 56 Número do fluxo Throughput médio (Mbps) Elapsed time Tabela 4.9: Cenário 1 - RED, TCP (Resultados Netperf) - FIFO no router O gerador 1 gera 20 fluxos TCP. Foram realizados dois testes: um implementando o mecanismo de escalonamento FIFO no router e outro implementando o mecanismo de escalonamento RED no router, com as configurações indicadas em anexo. Os resultados foram medidos no netperf do gerador 1. Resultado obtido Os resultados medidos no netperf, implementando FIFO no router, são os apresentados na tabela 4.9; já os resultados medidos no netperf, implementando RED no router, são os apresentados na tabela Este cenário foi o mais difícil de implementar, dado que gerar 20 fluxos ao mesmo tempo num só computador é impossível... Sendo assim, os resultados obtidos acima são aproximados. Mesmo assim, podemos observar que os resultados de throughput médio do TCP quando o algoritmo de escalonamento implementado no router é o RED têm

58 CAPÍTULO 4. TRABALHO DESENVOLVIDO 57 Número do fluxo Throughput médio (Mbps) Elapsed time Tabela 4.10: Cenário 1 - RED, TCP (Resultados Netperf) - RED no router

59 CAPÍTULO 4. TRABALHO DESENVOLVIDO 58 valores bastante mais próximos entre eles do que os obtidos implementando o FIFO no router; sendo assim, o RED evita efectivamente o efeito de sincronização, melhorando a estabilidade dos fluxos TCP na rede. 4.4 TBF Apesar de o TBF ser um traffic-shapper, por ser tão utilizado hoje em dia, achámos que seria interessante fazer um cenário com TBF. Configurámos, assim, o TBF no router, com os seguintes parâmetros: rate (taxa) kbps; é a taxa pretendida para o fluxo. burst - 20 kb; é o tamanho do bucket. limit - 20 kb; é o número de bytes que podem estar em fila de espera, enquanto os tokens não estão disponíveis. mtu B Cenário 1 Objectivo O objectivo deste cenário é fazer traffic shapping com o TBF. Metodologia Este cenário consiste na geração de um fluxo UDP CBR: O gerador 1 gera 4Mbps. Os resultados foram medidos no crude no receptor 1, assim como no tcpdump no router. Resultado obtido Os resultados medidos no crude são os apresentados na tabela Observámos que efectivamente o tráfego resultante tinha o throughput esperado.

60 CAPÍTULO 4. TRABALHO DESENVOLVIDO 59 Throughput médio (Kbps) Jitter (s) Pacotes recebidos Pacotes perdidos Tabela 4.11: Cenário 1 - TBF (Resultados Crude) 4.5 PRIO O PRIO é o mecanismo de escalonamento classfull mais simples. Este foi o único algoritmo de escalonamento para o qual variámos as configurações no router, conforme o cenário; estas alterações irão ser referidas em cada secção. O mecanismo de classificação de pacotes usado foi o Dsmark, sendo as classes as seguintes: Classe 1 - Minimize delay, para tráfego interactivo: pacotes IP com TOS 0x10. Classe 2 - Maximize reliability, para tráfego do tipo do ssh: pacotes IP com TOS 0x04. Classe 3 - Para qualquer outro tipo de tráfego Cenário 1 Objectivo O objectivo deste cenário é apenas verificar que cada fluxo recebe o serviço configurado em cada classe. Metodologia Este cenário consiste na geração de três fluxos UDP CBR com TOS diferentes: O gerador 1 gera um fluxo com TOS 0x04 (Maximize Reliability) de 600Kbps e um fluxo com TOS 0x10 (Minimize Delay) de 1200Kbps O gerador 2 gera um fluxo sem TOS de 8Mbps Configurámos o PRIO no router, utilizando um shapper TBF associado a cada classe: Classe 1 - taxa associada: 1024 kbps

61 CAPÍTULO 4. TRABALHO DESENVOLVIDO 60 TOS Throughput médio (Mbps) Jitter (s) Pacotes recebidos Pacotes perdidos 0x x Sem TOS Tabela 4.12: Cenário 1 - PRIO (Resultados Crude) Classe 2 - taxa associada: 512 kbps Classe 3 - taxa associada: 256 kbps Os fluxos são, assim, distinguidos através do seu TOS. Os resultados foram medidos no crude em cada um dos receptores, assim como no tcpdump no router. Resultado obtido Os resultados medidos no crude são os apresentados na tabela Observou-se assim o que seria esperado: o fluxo da classe 1 (TOS 0x10) teve um throughput médio de 490Kbps, enquanto que o fluxo da classe 2 (TOS 0x04), enquanto que o fluxo sem TOS teve um throughput médio de 250Kbps, o que demonstra que cada fluxo foi servido na classe correcta Cenário 2 Objectivo Colocar FIFO s dentro de cada classe PRIO, de forma a verificar que os dois fluxos restantes só ocupam a largura de banda que é deixada pelo fluxo de maior prioridade. Metodologia Este cenário consiste na geração de três fluxos UDP CBR com TOS diferentes: O gerador 1 gera um fluxo com TOS 0x04 (Maximize Reliability) de 2Mbps e um fluxo com TOS 0x10 (Minimize Delay) de 3Mbps O gerador 2 gera um fluxo sem TOS de 8Mbps

62 CAPÍTULO 4. TRABALHO DESENVOLVIDO 61 TOS Throughput médio (Mbps) Jitter (s) Pacotes recebidos Pacotes perdidos 0x x Sem TOS Tabela 4.13: Cenário 2 - PRIO (Resultados Crude) Configurámos o PRIO no router, tendo cada classe uma fila FIFO com um limite de 100 pacotes associada. Os resultados foram medidos no crude em cada um dos receptores, assim como no tcpdump no router. Resultado obtido Os resultados medidos no crude são os apresentados na tabela Podemos, assim, observar pelos resultados obtidos, que o fluxo de maior prioridade (TOS 0x10) ocupa a largura de banda requisitada (2.9Mbps); de seguida encontra-se o fluxo com a prioridade seguinte, com 2.0Mbps de throughput médio. Em último lugar, e ocupando apenas a largura de banda deixada livre pelos dois fluxos de maior prioridade, encontra-se o fluxo sem TOS, ocupando 4.2 Mbps. Podemos também constatar que efectivamente o fluxo de maior prioridade é servido primeiro, seguido pelo fluxo de prioridade média e prioridade mínima, pois os jitters associados aos fluxos são tanto maiores quanto menor for a sua prioridade Cenário 3 Objectivo Fazer starvation nos fluxos de menor prioridade. Metodologia Este cenário consiste na geração de três fluxos UDP CBR com TOS diferentes: O gerador 1 gera um fluxo com TOS 0x04 (Maximize Reliability) de 3Mbps e um fluxo com TOS 0x10 (Minimize Delay) de 12Mbps

63 CAPÍTULO 4. TRABALHO DESENVOLVIDO 62 TOS Throughput médio (Mbps) Jitter (s) Pacotes recebidos Pacotes perdidos 0x x Sem TOS Tabela 4.14: Cenário 3 - PRIO (Resultados Crude) O gerador 2 gera um fluxo sem TOS de 8Mbps Configurámos o PRIO no router, tendo cada classe uma fila FIFO com um limite de 100 pacotes associada. Os resultados foram medidos no crude em cada um dos receptores, assim como no tcpdump no router. Resultado obtido Os resultados medidos no crude são os apresentados na tabela Podemos, assim, observar que efectivamente, se o fluxo de maior prioridade ocupar a largura de banda toda, os outros fluxos não são praticamente servidos: esta é uma das falhas principais do PRIO, sendo normalmente utilizado um TBF (Token Bucket Filter) nos fluxos de maior prioridade, de forma a que os fluxos seguintes possam ser servidos mesmo que o fluxo de maior prioridade seja um fluxo mal comportado. Para além do throughput médio baixíssimo associado aos fluxos de prioridades menores, é de notar também que o jitter associado é muito elevado, demonstrando mais uma vez que estes são servidos apenas depois de todos os pacotes do fluxo de maior prioridade serem servidos. 4.6 HTB Cenário 1 Objectivo Este cenário, tendo sido o único cenário de Hierarchical Token Bucket realizado, visa demonstrar três aspectos: Testando com vários fluxos de tipos diferentes, verificar que cada um é servido pela

64 CAPÍTULO 4. TRABALHO DESENVOLVIDO 63 sua classe; Verificar que há bom serviço para todos os fluxos com requisitos de tempo real, mas que mesmo assim estes não monopolizam a utilização da ligação; Verificar que a starvation observada no PRIO já não se verifica com fluxos malcomportados. Metodologia Este cenário consiste na geração de três fluxos UDP CBR com TOS diferentes, e um fluxo TCP: O gerador 1 gera: 1 fluxo com TOS 0x04 (Maximize Reliability), 5Mbps 2 fluxos com TOS 0x10 (Minimize Delay), os dois com 1.6Mbps 1 fluxo TCP O gerador 2 gera um fluxo sem TOS de 16Mbps (fluxo mal comportado) Foi configurado, no router, um escalonador HTB com a seguinte configuração: Classe tráfego interactivo (TOS minimize delay: 0x10) - foi-lhe associado um SFQ, com taxa garantida de 1024kbps, e tecto 2048kbps. Classe maximize reliability (TOS 0x04) - foi-lhe associada um SFQ, com taxa garantida de 128kbps, e tecto 4096kbps. Classe TCP (se o tráfego for TCP) - foi-lhe associado um RED, com taxa garantida de 2048kbps, e tecto 4096kbps. Classe outro tráfego - foi-lhe associado um SFQ, com taxa garantida de 512kbps, e tecto 1024kbps. Os resultados foram medidos no crude em cada um dos receptores, e no netperf no gerador, assim como no tcpdump no router.

65 CAPÍTULO 4. TRABALHO DESENVOLVIDO 64 TOS Throughput médio (Mbps) Jitter (s) Pacotes recebidos Pacotes perdidos 0x o 0x o 0x Sem TOS Tabela 4.15: Cenário 1 - HTB (Resultados Crude) Gerador Throughput médio (Mbps) Elapsed time Gerador Tabela 4.16: Cenário 1 - HTB, TCP (Resultados Netperf) Resultado obtido Os resultados medidos no crude são os apresentados na tabela Os resultados medidos no netperf são os apresentados na tabela Numa primeira observação dos resultados obtidos, podemos constatar que cada fluxo foi, efectivamente, servido pela classe correspondente, como se pode observar pelos throughputs médios obtidos. Observamos também que, tendo o TCP uma classe dedicada, não entra em starvation como acontecia, por exemplo, com o mecanismo de escalonamento FIFO, ocupando, assim, quase o limiar máximo que poderia ocupar com esta configuração - ou seja, 3.92Mbps. Continuando a análise, podemos verificar que o fluxo mal comportado apenas ocupou a largura de banda esperada (ou seja, 750kbps - o intermédio entre a taxa garantida e o tecto). O facto de este fluxo não ter ocupado toda a largura de banda que poderia ocupar kbps indica que a sua classe pai (no caso, a classe raiz do HTB) não tinha mais largura de banda disponível para lhe dar, estando esta a ser ocupada com as outras classes. Verifica-se assim que não acontece a starvation observada com o mecanismo de escalonamento PRIO. Observamos também que, com uma configuração apropriada, os fluxos com requisitos de tempo real obtiveram um bom serviço, sem monopolizar a utilização da ligação tal como acontecia com o PRIO - como se pode constatar para os resultados obtidos para os fluxos com TOS 0x10 e 0x04. Em conclusão, o HTB é uma boa opção para conjugação de diferentes tipos de serviços.

66 CAPÍTULO 4. TRABALHO DESENVOLVIDO Ourmix Esta foi uma conjugação de vários mecanismos de escalonamento, pensada para a apresentação, como tal só vai ser aqui brevemente referida. O objectivo foi demonstrar o comportamento de duas aplicações com requisitos de serviço em tempo real (o ssh e o jogo Quake 3 em rede), em duas situações de configuração de mecanismos de escalonamento do router por onde o tráfego por elas gerado passava. Sendo assim, a primeira demonstração foi a utilização tanto do ssh como do Quake, com tráfego de enchimento UDP a ser gerado no gerador 1; constatou-se que, como o ssh utiliza TCP, era quase impossível a sua utilização - nas poucas vezes em que se conseguia fazer um simples login, quase não se conseguia trabalhar. Quanto ao Quake, cujos pacotes são UDP, as perdas no cliente do jogo eram muitas, ficando o jogo bastante mais lento. Aplicando a conjugação de mecanismos de escalonamento por nós pensada (Hierarchical Token Bucket, sendo as classes SSH, kazaa, quake e outros tipos de tráfego, com SFQ associado a todas estas menos ao quake - ao qual foi associada uma fila FIFO de 100 pacotes), observou-se que, mesmo correndo o ssh e o quake em simultâneo com a geração de tráfego de enchimento, todas as aplicações se comportavam bastante melhor do que com o FIFO, o que seria o comportamento esperado, como se pôde ler pela demonstração atrás explicada.

67 Capítulo 5 Conclusão Quando utilizado de forma apropriada, o controle de tráfego leva a uma utilização mais controlada dos recursos de rede, assim como uma menor contenção de certos serviços (como, por exemplo, as aplicações TCP no caso de se usar o RED). Podemos, por exemplo, atribuir uma largura de banda controlada aos downloads numa rede, enquanto que o tráfego interactivo é servido de forma contínua. Podemos até alocar uma largura de banda inferior para transferências de dados de prioridade inferior, tais como o , de forma a que estas não afectem os outros tipos de tráfego. O facto de o comportamento da rede ser mais previsível torna torna também mais fácil a escolha e programação das aplicações que utilizam recursos de rede: partindo para um nível mais geral, da internet no geral, se os routers nos diversos nós implementarem mecanismos de escalonamento de forma controlada e apropriada, as aplicações de rede terão um melhor serviço. Entrando já no campo dos mecanismos de classificação e policiamento de pacotes, pode-se até controlar que tipo de conteúdos circulam numa rede; isto poderá ser útil, por exemplo, numa empresa ou numa universidade. Por outro lado, a complexidade é uma das desvantagens mais significativas da utilização do controlo de tráfego. Apesar de toda a informação disponível, fazer a análise da utilização e recursos de rede é uma tarefa morosa, assim como a escolha do(s) próprio(s) mecanismo de escalonamento. É fácil, portanto, utilizar os mecanismos de escalonamento de uma forma menos apropriada, podendo o impacto no tráfego das redes até ser negativo. Outra desvantagem é a de determinados mecanismos necessitarem de um elevado poder computacional caso sejam utilizados em redes com muito tráfego. Adicionalmente, hoje em dia as empresas preferem comprar mais largura de banda do que providenciar formação 66

68 CAPÍTULO 5. CONCLUSÃO 67 aos técnicos para implementarem o controlo de tráfego na rede, dado que a primeira opção tem custos mais reduzidos. Para testarmos a potencialidade dos mecanismos de escalonamento analisados ao longo deste trabalho, configurámos um cenário extra, no qual as condições de rede seriam mais próximas do que acontece nas redes normais: o que observámos foi que é possível, com algum cuidado e planeamento, adaptar a realidade da rede de forma a que os clientes e aplicações tenham um melhor serviço. É especialmente interessante utilizar os mecanismos de escalonamento Classfull, em conjugação com os mecanismos de classificação de pacotes, de forma a cobrir necessidades específicas de certos fluxos. Em conclusão, achámos que a realização deste trabalho foi positiva, dado que cumprimos o nosso objectivo utilizando diversos mecanismos de escalonamento em sofware opensource gratuito e equipamento computacional de nível normal. Os mecanismos de escalonamento fornecem, assim, um estado a um protocolo que não o implementa - o protocolo IP.

69 Bibliografia Mecanismos de Escalonamento e QoS [1] - QoS support in Linux [2] html - Queues and Queueing Disciplines explained [3] - Linux Advanced Routing and Traffic Control HOWTO [4] - Advanced and less common queueing disciplines [5] - Traffic Shaping [6] - Traffic Control HOWTO [7] - Differentiated Service on Linux HOWTO [8] Rui Pedro de Magalhães Claro Prior, Qualidade de Serviço em Redes de Comutação de Pacotes [9] - FAQ [10] - CBQ and HTB presentation [11] manipulation.html - TOS Bit Manipulation [12] - Routage avancé et contrôle de trafic sous Linux 68

70 BIBLIOGRAFIA 69 Conceitos de Redes em Linux [13] - Rusty s Remarkably Unreliable Guides [14] - Linux Networking HOWTO [15] - Guide to IP Layer Network Administration with Linux TCNG e TC [16] - Traffic Control Next Generation [17] -Installing and Using tcng under Debian GNU/Linux [18] - iproute2+tc notes Geradores de tráfego [19] - Rude and Crude [20] - Netperf Gráficos e analisadores de logs [21] - Tcptrace [22] - Xgraph [23] - Xplot Programas vários [24] - Setting up NTP in Linux [25] - NTP HOWTO

71 BIBLIOGRAFIA 70 [26] - NTP Support [27] - Linguagem de programação Perl Motores de busca [28] - Google

72 Apêndice A Gráficos A.1 FIFO 71

73 APÊNDICE A. GRÁFICOS 72 Figura A.1: Cenário 1 - Gerador 1 - entrada do router (vermelho) e saída do router (verde)

74 APÊNDICE A. GRÁFICOS 73 Figura A.2: Cenário 1 - Gerador 2 - entrada do router (vermelho) e saída do router (verde)

75 APÊNDICE A. GRÁFICOS 74 Figura A.3: Cenário 1 - Saída do router - G1 (Vermelho), G2 (Verde)

76 APÊNDICE A. GRÁFICOS 75 Figura A.4: Cenário 3 - Gerador 1 - entrada do router

77 APÊNDICE A. GRÁFICOS 76 Figura A.5: Cenário 3 - Gerador 1 - saída do router

78 APÊNDICE A. GRÁFICOS 77 Figura A.6: Cenário 4 - Gerador 1 - entrada do router (tcp)

79 APÊNDICE A. GRÁFICOS 78 Figura A.7: Cenário 4 - Gerador 1 - saída do router (tcp)

80 APÊNDICE A. GRÁFICOS 79 Figura A.8: Cenário 4 - Gerador 2 - entrada do router (udp)

81 APÊNDICE A. GRÁFICOS 80 A.2 SFQ

82 APÊNDICE A. GRÁFICOS 81 Figura A.9: Cenário 1 - Geradores 1 (vermelho) e 2 (verde) - entrada do router

83 APÊNDICE A. GRÁFICOS 82 Figura A.10: Cenário 1 - Geradores 1 (vermelho) e 2 (verde) - saída do router

84 APÊNDICE A. GRÁFICOS 83 Figura A.11: Cenário 2 - Gerador 1 - saída do router (tcp)

85 APÊNDICE A. GRÁFICOS 84 Figura A.12: Cenário 2 - Gerador 2 - saída do router (udp)

86 APÊNDICE A. GRÁFICOS 85 A.3 TBF

87 APÊNDICE A. GRÁFICOS 86 Figura A.13: Cenário 1 - Gerador 1 - entrada do router (vermelho) e saída do router (verde)

88 APÊNDICE A. GRÁFICOS 87 A.4 PRIO

89 APÊNDICE A. GRÁFICOS 88 Figura A.14: Cenário 1 - Gerador 1 - saída do router - tos 0x04 (vermelho), tos 0x10 (verde) e sem tos (azul)

90 APÊNDICE A. GRÁFICOS 89 Figura A.15: Cenário 2 - Gerador 1 - saída do router - tos 0x04 (vermelho), tos 0x10 (verde) e sem tos (azul)

91 APÊNDICE A. GRÁFICOS 90 Figura A.16: Cenário 3 - Gerador 1 - saída do router - tos 0x04 (vermelho), tos 0x10 (verde) e sem tos (azul)

92 APÊNDICE A. GRÁFICOS 91 A.5 HTB

93 APÊNDICE A. GRÁFICOS 92 Figura A.17: Cenário 1 - Gerador 1 - entrada no router (udp)

94 APÊNDICE A. GRÁFICOS 93 Figura A.18: Cenário 1 - Gerador 1 - saída do router (udp)

95 APÊNDICE A. GRÁFICOS 94 Figura A.19: Cenário 1 - Geradores 1 e 2 - saída do router - tos 0x04(vermelho), tos 0x10(verde), tos 0x10(azul), sem tos(amarelo)

96 Apêndice B Scripts desenvolvidos Neste anexo apresentam-se os scripts desenvolvidos para a configuração dos geradores, router e receptores, o script criado para automatizar a criação dos ficheiros de configuração para gerar tráfego, assim como os scripts utilizados para fazer a análise do output do tcpcump e tethereal e consequente geração de gráficos. B.1 Inicialização e configuração das máquinas O seguinte script configura ambos os geradores para ficarem prontos a ser utilizados para os cenários efectuados: #!/usr/bin/perl #### configuracao generica - geradores ###### # argumentos my $gerador = int(shift) or die "Usage:./script_gerador <nr_gerador>"; print "A inicializar gerador...\n"; # variaveis "globais" my $router = " "; my $receptor = " "; my $our_ip = " ".$gerador; 95

97 APÊNDICE B. SCRIPTS DESENVOLVIDOS 96 my $hostname = "gerador".$gerador; # funcoes sub set_cmd { my $cmd = shift; print "\t\t",$cmd, "\n"; print $cmd ; # configuraç~oes set_cmd "ifconfig eth0 $our_ip"; set_cmd "route add default gw $router"; set_cmd "service ntpd stop"; set_cmd "ntpdate $router"; set_cmd "ntpdate $router"; set_cmd "ntpdate $router"; set_cmd "service ntpd start"; De forma análoga ao caso dos geradores, foram implementados scripts de inicialização semelhantes para os receptores. No caso do router, o ficheiro de inicialização é semelhante aos restantes, com a ressalva que se configuram duas interfaces de rede (uma para a rede dos geradores de tráfego e outra para os receptores) e se activa a opção de ip forward, para permitir à máquina funcionar como encaminhador de pacotes. #!/usr/bin/perl -w ##### configuracao generica - router ####### print "A fazer configuracao de inicializaç~ao do router...\n"; # variaveis "globais" my $ip_interface_1 = " "; my $ip_interface_2 = " ";

98 APÊNDICE B. SCRIPTS DESENVOLVIDOS 97 my $dir_modules = "/lib/modules/ mdk/kernel/net/sched/"; # funcoes sub set_cmd { my $cmd = shift; print $cmd, "\n"; print $cmd ; # configuraç~oes # ntp set_cmd "killall -9 ntpd"; set_cmd "killall -9 ifplugd"; set_cmd "killall -9 dhclient"; # hostname, ip set_cmd "hostname router"; # placa do meio set_cmd "ifconfig eth2 $ip_interface_2"; # placa de cima - ligaç~ao ao exterior set_cmd "ifup eth1"; # placa de baixo set_cmd "ifconfig eth0 $ip_interface_1"; # ip forward... para ele reenviar pacotes funcionando como router set_cmd "echo \"1\" > /proc/sys/net/ipv4/ip_forward"; # fazer 2 sincronizacoes antes set_cmd "ntpdate "; set_cmd "ntpdate "; set_cmd "service ntpd start";

99 APÊNDICE B. SCRIPTS DESENVOLVIDOS 98 B.2 Criação dos ficheiros de configuração para gerar tráfego Para uniformizar a criação dos ficheiros de configuração para os geradores de tráfego, foi implementado o seguinte script que permite, consoante o cenário que se pretende testar e o gerador onde é executado, criar os ficheiros de configuração automaticamente. #!/usr/bin/perl # argumentos # numero do gerador my $gerador = int(shift) die "Usage:./gera_trafego.pl [nr_gerador]\ [alg_escalonamento] [nr_cenario]\n"; # sacar tipo de escalonamento my $alg_escalonamento = shift die "Usage:./gera_trafego.pl [nr_gerador]\ [alg_escalonamento] [nr_cenario]\n"; # sacar cenario my $cenario = int(shift) die "Usage:./gera_trafego.pl [nr_gerador]\ [alg_escalonamento] [nr_cenario]\n"; print "\t *Cenario: $alg_escalonamento, $cenario *\n"; # funcoes sub set_cmd { my $cmd = shift; print "\t\t",$cmd, "\n"; print $cmd ; # gera ficheiros simples para o rude sub gera_script_rude { my $filename = shift; my $id_fluxo = shift; my $start_time = shift; my $end_time = shift; my $ip_destino = shift;

100 APÊNDICE B. SCRIPTS DESENVOLVIDOS 99 my $tos = shift; my $packets_per_second = shift; my $bytes_per_packet = shift; print "Id do fluxo: $id_fluxo\n"; print "Start time: $start_time\n"; print "End time: $end_time\n"; print "Ip de de destino: $ip_destino\n"; print "TOS: $tos\n"; print "Pacotes por segundo: $packets_per_second\n"; print "Bytes por pacote: $bytes_per_packet\n"; open(file, "> $filename"); print FILE "START NOW\n"; print FILE "$start_time $id_fluxo ON 3001 $ip_destino:10001 \ CONSTANT $packets_per_second $bytes_per_packet\n"; if($tos ne "") { print FILE "TOS $id_fluxo $tos\n"; print FILE "$end_time $id_fluxo OFF\n"; close FILE; # variaveis print "Gerador... [$gerador]\n"; my $ip_destino; if($gerador == 1) { $ip_destino = " "; else { $ip_destino = " "; my $id_fluxo="3$gerador"; my $dir_cfgs_rude = "./rude_cfgs_g$gerador";

101 APÊNDICE B. SCRIPTS DESENVOLVIDOS 100 my $filename = "$dir_cfgs_rude/$alg_escalonamento.$cenario.cfg"; # ======= classless =========== # # pfifo bfifo pfifo_fast # if($alg_escalonamento eq "fifo") { # C1 - dois fluxos UDP iguais, com largura # de banda total = 12Mb/seg if($cenario == 1) { my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 750; my $bytes_per_packet = 1000; if($gerador == 1 $gerador == 2) { gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # C2 - encher o link com tráfego UDP (enchimento) e UDP com # outro TOS ao mesmo tempo, com valores =s aos anteriores elsif($cenario == 2) { if($gerador == 1) { # gerador 1 my $start_time = 1000; my $end_time = 61000; my $tos = "0x0"; # normal service my $packets_per_second = 750; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); else { # gerador 2 my $start_time = 1000;

102 APÊNDICE B. SCRIPTS DESENVOLVIDOS 101 my $end_time = 61000; my $tos = "0x10"; # minimize delay my $packets_per_second = 750; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # C3 - encher o link com tráfego UDP (enchimento) e TCP ao mesmo # tempo (gerador1) primeiro ainda fizemos um teste sem UDP, para # avaliar quanto é que o TCP dava sozinho (fifo.3.teste_sem_udp.netperf) elsif($cenario == 3) { if($gerador == 1) { # gerador 1 print "netperf -H $ip_destino"; else { # gerador 2 my $start_time = 1000; my $end_time = 90000; # normal service my $tos = ""; # para estourar mesmo com a ligacao (10Mb/seg)...\ my $packets_per_second = 1250; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # C4 - (para comparacao com o C3) - trafego UDP sem # quebrar a ligacao e TCP ao mesmo tempo elsif($cenario == 4) { if($gerador == 1) { # gerador 1 print "netperf -H $ip_destino"; else { # gerador 2

103 APÊNDICE B. SCRIPTS DESENVOLVIDOS 102 my $start_time = 1000; my $end_time = 61000; my $tos = "0x0"; # normal service my $packets_per_second = 1000; # 8Mb/seg my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # C5 - varios fluxos UDP com diferentes debitos elsif($cenario == 5) { if($gerador == 1) { # gerador 1 (6Mb/seg) my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 750; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); else { # gerador 2 (1Mb/seg) my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 250; my $bytes_per_packet = 500; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # sfq # elsif ($alg_escalonamento eq "sfq") {

104 APÊNDICE B. SCRIPTS DESENVOLVIDOS 103 # C1 - testar com vários fluxos com diferentes debitos e # verificar se existe uma distribuicao equitativa do debito # disponivel pelos fluxos que partilham a ligacao if($cenario == 1) { if($gerador == 1) { # gerador 1 (12Mb/seg) my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 1000; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); elsif($gerador == 2) { # gerador 2 (16Mb/seg) my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 2000; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # C2 - UDP a estourar com a ligaç~ao e TCP ao mesmo tempo elsif($cenario == 2) { if($gerador == 1) { # gerador 1 print "FAZER: netperf -H $ip_destino\n\n"; else { # gerador 2 my $start_time = 1000; my $end_time = 61000; # normal service my $tos = ""; # para estourar mesmo com a ligacao (10Mb/seg)... my $packets_per_second = 1250;

105 APÊNDICE B. SCRIPTS DESENVOLVIDOS 104 my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # tbf # elsif ($alg_escalonamento eq "tbf") { # C1 - testar com varios fluxos udp e verificar se a soma das # larguras de banda passa a ser a escolhida if($cenario == 1) { if($gerador == 1) { # gerador 1 print "rude -s rude_cfgs_g1/tbf.1.cfg\n"; else { # gerador 2 print "No need for YOU in this experiment...\n"; # ====== classfull ======= # # prio # elsif ($alg_escalonamento eq "prio") { # C1 - gerar fluxos com diferentes TOS / prioridades, para # verificar shaping atraves de tbf em cada fluxo if($cenario == 1) { # gerador 1, gera varios fluxos com os TOS especificados no router if($gerador == 1) { print "rude -s rude_cfgs_g1/prio.1.tos10.cfg\n";

106 APÊNDICE B. SCRIPTS DESENVOLVIDOS 105 print "rude -s rude_cfgs_g1/prio.1.tos04.cfg\n"; # gerador 2, gera fluxo sem TOS --> 8Mbit/s else { my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 1000; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # C2 - verificar q os 2 fluxos restantes so ocupam a largura de banda # q é deixada pelo fluxo com a maior prioridade elsif ($cenario == 2) { # gerador 1, gera varios fluxos com os TOS especificados no router if($gerador == 1) { print "rude -s rude_cfgs_g1/prio.2.tos10.cfg\n"; print "rude -s rude_cfgs_g1/prio.2.tos04.cfg\n"; # gerador 2, gera fluxo sem TOS --> 8Mbit/s else { my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 1000; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # C3 - fazer starvation elsif ($cenario == 3) {

107 APÊNDICE B. SCRIPTS DESENVOLVIDOS 106 # gerador 1, gera o primeiro fluxo a ocupar tudo de forma a q # os outros entrem em starvation... if($gerador == 1) { print "rude -s rude_cfgs_g1/prio.3.tos10.cfg\n"; print "rude -s rude_cfgs_g1/prio.3.tos04.cfg\n"; # gerador 2, gera fluxo sem TOS --> 8Mbit/s else { my $start_time = 1000; my $end_time = 61000; my $tos = ""; my $packets_per_second = 1000; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # cbq # elsif ($alg_escalonamento eq "cbq") { # C1 - testar com varios fluxos, verificar cada um a "cair" # na sua classe # C2 - testar com fluxos com requisitos de tempo real # (verificar se há bom serviço para todas e se estas # n~ao monopolizam a utilizaç~ao da ligaç~ao) # C3 - testar com fluxos "mal-comportados" if($cenario == 1) { if($gerador == 1) { # TOS 10 print "rude -s rude_cfgs_g1/cbq.1.tos10_1.cfg\n"; # TOS 10 print "rude -s rude_cfgs_g1/cbq.1.tos10_2.cfg\n"; # TOS 04 print "rude -s rude_cfgs_g1/cbq.1.tos04.cfg\n";

108 APÊNDICE B. SCRIPTS DESENVOLVIDOS 107 # TCP print "netperf -H \n"; else { my $start_time = 1000; my $end_time = 81000; my $tos = ""; my $packets_per_second = 2000; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); # htb # elsif ($alg_escalonamento eq "htb") { # C1 - testar com varios fluxos, verificar cada um a "cair" # na sua classe # C2 - verificar que ha bom serviço para todos os fluxos com # requisitos de tempo real e que estes nao monopolizam # a utilizacao da ligacao # C3 - verificar que a "starvation" observada no PRIO ja nao # se verifica com fluxos mal-comportados if($cenario == 1) { if($gerador == 1) { # TOS 10 print "rude -s rude_cfgs_g1/htb.1.tos10_1.cfg\n"; # TOS 10 print "rude -s rude_cfgs_g1/htb.1.tos10_2.cfg\n"; # TOS 04 print "rude -s rude_cfgs_g1/htb.1.tos04.cfg\n"; # TCP print "netperf -H \n"; else {

109 APÊNDICE B. SCRIPTS DESENVOLVIDOS 108 my $start_time = 1000; my $end_time = 81000; my $tos = ""; my $packets_per_second = 2000; my $bytes_per_packet = 1000; gera_script_rude($filename,$id_fluxo,$start_time,$end_time,\ $ip_destino,$tos,$packets_per_second,$bytes_per_packet); B.3 Configuração dos mecanismos de escalonamento no router No que diz respeito à configuração dos mecanismos de escalonamento no router, foi implementado um script que utilizando os ficheiros de configuração de TC e TCNG do Apêndice C, configura o mecanismo de escalonamento pretendido na interface de rede. #!/usr/bin/perl # argumentos do script --- # my $alg_escalonamento = shift "pfifo"; print "\t *** A fazer configuracao para [$alg_escalonamento] ***\n"; my $dir_tcng_cfgs = "./tcng_cfgs"; my $dir_tc_cfgs = "./tc_cfgs"; # funcoes # sub set_cmd { my $cmd = shift; my $tmp = $cmd; print $tmp, "\n"; print $tmp ;

110 APÊNDICE B. SCRIPTS DESENVOLVIDOS 109 # aplicar as configuracoes do tc sub corre_configuracoes_tc { my $alg_escalonamento = shift; set_cmd "sh $dir_tc_cfgs/$alg_escalonamento.sh"; # gerar script a partir da configuracao tcng para o tc sub gera_tc_sh { my $alg_escalonamento = shift; set_cmd "tcc < $dir_tcng_cfgs/$alg_escalonamento.cfg > \ $dir_tc_cfgs/$alg_escalonamento.sh"; corre_configuracoes_tc $alg_escalonamento; # # # por a placa anterior a reenviar para a outra set_cmd "tc qdisc add dev eth0 root pfifo limit 100"; # apagar todas as configuracoes que tivessem sido feitas anteriormente set_cmd "tc qdisc del dev eth2 root"; # =================== classless ======================= # # pfifo (bfifo, tb) # tc & tcng *** if($alg_escalonamento eq "fifo") { my $tamanho_fila = shift "100"; set_cmd "tc qdisc add dev eth2 root pfifo limit $tamanho_fila"; # pfifo_fast # nao precisa de nada *** elsif ($alg_escalonamento eq "pfifo_fast") { set_cmd "tc qdisc add dev eth2 root pfifo_fast"; # sfq # tcng ***

111 APÊNDICE B. SCRIPTS DESENVOLVIDOS 110 elsif ($alg_escalonamento eq "sfq") { set_cmd "modprobe sch_sfq"; gera_tc_sh($alg_escalonamento); # red # tc elsif ($alg_escalonamento eq "red") { corre_configuracoes_tc($alg_escalonamento); # tbf # tcng *** elsif ($alg_escalonamento eq "tbf") { gera_tc_sh($alg_escalonamento); # wfq elsif ($alg_escalonamento eq "wfq") { print "This is not a CISCO router :P\n"; # ================ classfull ======================== # # tbf # tcng *** elsif ($alg_escalonamento eq "htb") { set_cmd "modprobe sch_htb"; gera_tc_sh($alg_escalonamento); # prio # tcng *** elsif ($alg_escalonamento eq "prio") { my $cenario = shift die "O prio precisa de ter \ dos cenarios...\n"; set_cmd "modprobe sch_prio"; gera_tc_sh($alg_escalonamento.$cenario);

112 APÊNDICE B. SCRIPTS DESENVOLVIDOS 111 # cbq # so tc * elsif ($alg_escalonamento eq "cbq") { set_cmd "modprobe sch_cbq"; corre_configuracoes_tc(); # ourmix elsif ($alg_escalonamento eq "ourmix") { set_cmd "modprobe sch_red"; set_cmd "modprobe sch_sfq"; gera_tc_sh($alg_escalonamento.$cenario); set_cmd "tc qdisc sh dev eth2"; B.4 Análise de capturas e geração de gráficos Para visualizarmos melhor os resultados do tcpdump, desenvolvemos um script em Perl para gerar throughputs instantâneos, médios acumulados e médios com base nos N valores anteriores. Estes valores eram colocados num ficheiro de texto, num formato interpretável pelo programa xgraph. No script abaixo, utiliza-se uma captura do tcpdump para gerar os gráficos correspondentes a um fluxo proveniente de um IP passado como argumento. gera grafico 1 fluxo tcpdump.pl #!/usr/bin/perl -w my $file = shift die "Usage:./gera_grafico_1fluxo_tcpdump.pl \ <tcpdump_file> <ip_origem_fluxo>"; my $ip_origem = shift die "Usage:./gera_grafico_1fluxo_tcpdump.pl \ <tcpdump_file> <ip_origem_fluxo>";

113 APÊNDICE B. SCRIPTS DESENVOLVIDOS 112 print "Fich: $file\n"; print "IP: $ip_origem\n"; print "Fich: $file\n"; print "IP: $ip_origem\n"; open FILE, $file; open FILE4, "> grafico_thru_last_$ip_origem.tr"; open FILE3, "> grafico_thru_medio_$ip_origem.tr"; open FILE2, "> grafico_fluxo_$ip_origem.tr"; my $total_bytes_received = 0; my $nr_throughput_avg = 100; my $count = $nr_throughput_avg; my $bytes_acum = 0; my ($tempo_inicio, $tempo_fim); my $aux = <FILE>; $aux =~ /\d*:(\d*):(\d*.\d*)/; my $base = $1; my $old_time = -1; while(<file>) { # so aceita as linhas que tiverem aquele ip como origem # no entanto, o tcpdump deve ser corrido com a opcao: # src host <ip> dst host <ip> if($_ =~ /$ip_origem\.\d*\s*>/) { # vai buscar o tempo $_ =~ /\d*:(\d*):(\d*.\d*)/; my $time = ($1 - $base)*60 + $2; # vai buscar o tamanho dos pacotes $_ =~ /udp\s*(\d*)/; my $size = $1; $bytes_acum += $size; # calcula a media dos ultimos throughputs if($count == 0) {

114 APÊNDICE B. SCRIPTS DESENVOLVIDOS 113 $tempo_fim = $time; $media = ($bytes_acum * 8) / ($tempo_fim - $tempo_inicio); $tempo_inicio = $tempo_fim; $count = $nr_throughput_avg; $bytes_acum = 0; print FILE4 $time." ".$media."\n"; $count--; if($old_time!= -1) { # calcula o throughput instantaneo my $dif = $time - $old_time; my $throughput = $size/$dif * 8; print FILE2 $time." ".$throughput."\n"; # calcula o throughput medio, durante a ligacao toda $total_bytes_received += $size; my $dif_so_far = $time - $first_time; my $avg_throughput = $total_bytes_received / $dif_so_far * 8; print FILE3 $time." ".$avg_throughput."\n"; else { $first_time = $time; $tempo_inicio = $first_time; $old_time = $time; close FILE; close FILE2; close FILE3; close FILE4; De forma análoga ao de cima, o script a seguir apresentado é utilizado quando se pretende gerar gráficos de dois fluxos em vez de apenas um, através de uma captura com o tcpdump.

115 APÊNDICE B. SCRIPTS DESENVOLVIDOS 114 gera graficos 2fluxos tcpdump.pl #!/usr/bin/perl -w my $file = shift die "Usage:./gera_graf_2fluxos_tcpdump.pl \ <tcpdump_infile> <ip_origem_fluxo1> <ip_origem_fluxo2>"; my $ip_origem1 = shift die "Usage:./gera_graf_2fluxos_tcpdump.pl \ <tcpdump_infile> <ip_origem_fluxo1> <ip_origem_fluxo2>"; my $ip_origem2 = shift die "Usage:./gera_graf_2fluxos_tcpdump.pl \ <tcpdump_infile> <ip_origem_fluxo1> <ip_origem_fluxo2>"; if(-e "grafico_fluxo_$ip_origem1.tr") { print "O ficheiro do grafico a gerar (grafico_fluxo_$ip_origem1) ja existe. "; print "Move-o para outro e volta a correr o programa.\n"; exit; if(-e "grafico_fluxo_$ip_origem2.tr") { print "O ficheiro do grafico a gerar (grafico_fluxo_$ip_origem2) ja existe. "; print "Move-o para outro e volta a correr o programa.\n"; exit; # separa os fluxos no ficheiro do tcpdump em dois ficheiros diferentes # para calcular o throughput para cada um deles individualmente open FLUXO_1, "> fluxo_$ip_origem1"; open FLUXO_2, "> fluxo_$ip_origem2"; open FILE, "< $file"; while(<file>) { if($_ =~ /$ip_origem1\.\d*\s*>/) { print FLUXO_1 $_; elsif($_ =~ /$ip_origem2\.\d*\s*>/) { print FLUXO_2 $_;

116 APÊNDICE B. SCRIPTS DESENVOLVIDOS 115 close FILE; close FLUXO_1; close FLUXO_2; print "IP1: $ip_origem1\n"; print "IP2: $ip_origem2\n"; # utiliza o programa anterior para gerar os graficos de 1 fluxo individuais system "/gera_grafico_1fluxo_tcpdump.pl fluxo_$ip_origem1 $ip_origem1"; system "/gera_grafico_1fluxo_tcpdump.pl fluxo_$ip_origem2 $ip_origem2"; # mostra os resultados xgraph grafico_fluxo_$ip_origem1.tr grafico_fluxo_$ip_origem2.tr & ; xgraph grafico_thru_last_$ip_origem1.tr grafico_thru_last_$ip_origem2.tr & ; xgraph grafico_thru_medio_$ip_origem1.tr grafico_thru_medio_$ip_origem2.tr & ; Como o output do tethereal é ligeiramente diferente do obtido com o tcpdump, foram feitas modificações a ambos os scripts acima para funcionarem com o output desta aplicação. Como as modificações são mínimas, esses scripts não são aqui incluídos. O script abaixo foi utilizado como suporte aos scripts que geram gráficos através do output do tcpdump ou do tethereal quando há dois ou mais fluxos de tráfego envolvidos. O que faz é separar, baseado no IP e na porta de origem, os diferentes fluxos encontrados numa captura, gerando um ficheiro para cada fluxo encontrado, com os pacotes correspondentes, para serem posteriormente analisados individualmente. separa fluxos com portas.pl #!/usr/bin/perl -w use strict;

117 APÊNDICE B. SCRIPTS DESENVOLVIDOS 116 my $file = shift die "Usage:./separa_fluxos_por_portas.pl <fich> <ip_origem>"; my $ip_origem = shift die "Usage:./separa_fluxos_por_portas.pl <fich> <ip_origem>"; open FILE, "< $file"; while(<file>) { if($_ =~ /$ip_origem\.(\d+)\s*>/) { open NEW_FILE, ">> fluxo_$ip_origem:$1"; print NEW_FILE $_; close NEW_FILE; close FILE;

118 Apêndice C Configurações Nesta secção, apresentam-se as configurações para o rude para geração de tráfego e as configurações TC e TCNG utilizadas no router. Os receptores não estão aqui incluídos pois apenas foram utilizados para correr o colector do rude e o servidor do netperf, que não utilizam ficheiros de configuração. Para cada um dos cenários vai ser apresentado o ficheiro de configuração para o gerador de tráfego utilizado. C.1 Mecanismos de escalonamento C.1.1 Configurações TC SFQ tc qdisc add dev eth2 handle 1:0 root dsmark indices 1 default_index 0 tc qdisc add dev eth2 handle 2:0 parent 1:0 sfq perturb 10 RED tc qdisc del dev eth2 root tc qdisc add dev eth2 root red limit min max \ avpkt 1000 burst 666 probability 0.02 bandwidth

119 APÊNDICE C. CONFIGURAÇÕES 118 TBF tc qdisc add dev eth2 handle 1:0 root dsmark indices 1 default_index 0 tc qdisc add dev eth2 handle 2:0 parent 1:0 tbf burst limit \ mtu 1514 rate 32000bps Prio - cenário 1 tc qdisc add dev eth2 handle 1:0 root dsmark indices 4 default_index 0 tc qdisc add dev eth2 handle 2:0 parent 1:0 prio tc qdisc add dev eth2 handle 3:0 parent 2:1 tbf burst limit \ mtu 1514 rate bps tc qdisc add dev eth2 handle 4:0 parent 2:2 tbf burst limit \ mtu 1514 rate 64000bps tc qdisc add dev eth2 handle 5:0 parent 2:3 tbf burst limit \ mtu 1514 rate 32000bps tc filter add dev eth2 parent 2:0 protocol all prio 1 tcindex mask 0x3 \ shift 0 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 3 tcindex \ classid 2:3 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 2 tcindex \ classid 2:2 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 1 tcindex \ classid 2:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x10 0xff at 1 classid 1:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x4 0xff at 1 classid 1:2 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u32 0x0 0x0 at 0 classid 1:3 Prio - cenário 2 tc qdisc add dev eth2 handle 1:0 root dsmark indices 4 default_index 0 tc qdisc add dev eth2 handle 2:0 parent 1:0 prio tc qdisc add dev eth2 handle 3:0 parent 2:1 pfifo limit 100

120 APÊNDICE C. CONFIGURAÇÕES 119 tc qdisc add dev eth2 handle 4:0 parent 2:2 pfifo limit 100 tc qdisc add dev eth2 handle 5:0 parent 2:3 pfifo limit 100 tc filter add dev eth2 parent 2:0 protocol all prio 1 tcindex mask 0x3 shift 0 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 3 \ tcindex classid 2:3 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 2 \ tcindex classid 2:2 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 1 \ tcindex classid 2:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x10 0xff at 1 classid 1:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x4 0xff at 1 classid 1:2 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u32 0x0 0x0 at 0 classid 1:3 Prio - cenário 3 tc qdisc add dev eth2 handle 1:0 root dsmark indices 4 default_index 0 tc qdisc add dev eth2 handle 2:0 parent 1:0 prio tc qdisc add dev eth2 handle 3:0 parent 2:1 pfifo limit tc qdisc add dev eth2 handle 4:0 parent 2:2 pfifo limit 100 tc qdisc add dev eth2 handle 5:0 parent 2:3 pfifo limit 100 tc filter add dev eth2 parent 2:0 protocol all prio 1 \ tcindex mask 0x3 shift 0 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 3 \ tcindex classid 2:3 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 2 \ tcindex classid 2:2 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 1 \ tcindex classid 2:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x10 0xff at 1 classid 1:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x4 0xff at 1 classid 1:2 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \

121 APÊNDICE C. CONFIGURAÇÕES 120 u32 0x0 0x0 at 0 classid 1:3 HTB tc qdisc add dev eth2 handle 1:0 root dsmark indices 8 default_index 0 tc qdisc add dev eth2 handle 2:0 parent 1:0 htb tc class add dev eth2 parent 2:0 classid 2:1 htb rate bps \ ceil bps tc class add dev eth2 parent 2:1 classid 2:2 htb rate bps \ ceil bps tc qdisc add dev eth2 handle 3:0 parent 2:2 sfq tc class add dev eth2 parent 2:1 classid 2:3 htb rate 16000bps \ ceil bps tc qdisc add dev eth2 handle 4:0 parent 2:3 sfq tc class add dev eth2 parent 2:1 classid 2:4 htb rate bps \ ceil bps tc qdisc add dev eth2 handle 5:0 parent 2:4 red limit \ min max burst 0 avpkt 1000 bandwidth bps \ probability tc class add dev eth2 parent 2:1 classid 2:5 htb rate 64000bps \ ceil bps tc qdisc add dev eth2 handle 6:0 parent 2:5 sfq tc filter add dev eth2 parent 2:0 protocol all prio 1 \ tcindex mask 0x7 shift 0 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 4 \ tcindex classid 2:5 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 3 \ tcindex classid 2:4 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 2 \ tcindex classid 2:3 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 1 \ tcindex classid 2:2 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 \ match u8 0x10 0xff at 1 classid 1:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 \ match u8 0x4 0xff at 1 classid 1:2

122 APÊNDICE C. CONFIGURAÇÕES 121 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 \ match u8 0x6 0xff at 9 classid 1:3 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 \ match u32 0x0 0x0 at 0 classid 1:4 Ourmix Esta é uma configuração de mecanismos de escalonamento que foi utilizada no exemplo final da apresentação deste trabalho. tc qdisc add dev eth2 handle 1:0 root dsmark indices 8 default_index 0 tc qdisc add dev eth2 handle 2:0 parent 1:0 htb tc class add dev eth2 parent 2:0 classid 2:1 htb rate bps \ ceil bps tc class add dev eth2 parent 2:1 classid 2:2 htb rate bps \ ceil bps tc qdisc add dev eth2 handle 3:0 parent 2:2 sfq tc class add dev eth2 parent 2:1 classid 2:3 htb rate bps \ ceil bps tc qdisc add dev eth2 handle 4:0 parent 2:3 sfq tc class add dev eth2 parent 2:1 classid 2:4 htb rate bps \ ceil bps tc qdisc add dev eth2 handle 5:0 parent 2:4 pfifo tc class add dev eth2 parent 2:1 classid 2:5 htb rate bps \ ceil bps tc qdisc add dev eth2 handle 6:0 parent 2:5 sfq tc filter add dev eth2 parent 2:0 protocol all prio 1 tcindex \ mask 0x7 shift 0 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 4 \ tcindex classid 2:5 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 3 \ tcindex classid 2:4 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 2 \ tcindex classid 2:3 tc filter add dev eth2 parent 2:0 protocol all prio 1 handle 1 \ tcindex classid 2:2

123 APÊNDICE C. CONFIGURAÇÕES 122 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 1:0:0 \ u32 divisor 1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 1:0:0 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 1:0:1 \ u32 ht 1:0:0 match u16 0x16 0xffff at 0 classid 1:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 2:0:0 \ u32 divisor 1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 2:0:0 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 2:0:1 \ u32 ht 2:0:0 match u16 0x16 0xffff at 2 classid 1:1 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 3:0:0 \ u32 divisor 1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 3:0:0 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 3:0:1 \ u32 ht 3:0:0 match u16 0x4be 0xffff at 2 classid 1:2 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 4:0:0 \ u32 divisor 1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 4:0:0 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 4:0:1 \ u32 ht 4:0:0 match u16 0x4be 0xffff at 0 classid 1:2 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 5:0:0 \ u32 divisor 1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 5:0:0 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 5:0:1 \ u32 ht 5:0:0 match u16 0x6d38 0xffff at 2 classid 1:3 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 6:0:0 \ u32 divisor 1 tc filter add dev eth2 parent 1:0 protocol all prio 1 u32 match \ u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 6:0:0 tc filter add dev eth2 parent 1:0 protocol all prio 1 handle 6:0:1 \ u32 ht 6:0:0 match u16 0x6d38 0xffff at 0 classid 1:3

124 APÊNDICE C. CONFIGURAÇÕES 123 tc filter add dev eth2 parent 1:0 protocol all prio 1 \ u32 match u32 0x0 0x0 at 0 classid 1:4 C.1.2 Configurações TCNG FIFO /* * make a FIFO on eth2 with 100 packet queue size */ dev eth2 { egress { fifo (limit 100p ); SFQ /* * fazer um SFQ no eth2 com funç~ao de hash * a ser rodada de 10 em 10 segundos */ dev eth2 { egress { sfq( perturb 10s ); TBF /* * make a 256kbit/s TBF on eth2 */

125 APÊNDICE C. CONFIGURAÇÕES 124 dev eth2 { egress { tbf( rate 256 kbps, burst 20 kb, limit 20 kb, mtu 1514 B ); PRIO - cenário 1 /* * prio */ dev "eth2" { egress { /* ****** definir classes baseadas no TOS ******* */ /* classe 1: minimize delay - interactive */ class(<$min_delay>) if ip_tos == 0x10; /* classe 2: maximize reliability - tipo ssh */ class(<$reliable>) if ip_tos == 0x4; /* classe 3 - qualquer outra */ class(<$other>) if 1; /* Configure our classful qdisc */ prio { $min_delay = class { tbf( rate 1024 kbps, burst 20 kb, limit 20 kb, mtu 1514 B ); //fifo( limit 100pcks); $reliable = class { tbf( rate 512 kbps, burst 20 kb, limit 20 kb, mtu 1514 B );

126 APÊNDICE C. CONFIGURAÇÕES 125 //fifo( limit 20kB ); $other = class { tbf( rate 256 kbps, burst 20 kb, limit 20 kb, mtu 1514 B ); PRIO - cenário 2 #include <ports.tc> #include <fields.tc> /* * prio */ dev "eth2" { egress { /* ****** definir classes baseadas no TOS ******* */ /* classe 1: minimize delay - interactive */ class(<$min_delay>) if ip_tos == 0x10; /* classe 2: maximize reliability - tipo ssh */ class(<$reliable>) if ip_tos == 0x4; /* classe 3 - qualquer outra */ class(<$other>) if 1; /* Configure our classful qdisc */ prio { $min_delay = class {

127 APÊNDICE C. CONFIGURAÇÕES 126 fifo( limit 100pcks); $reliable = class { fifo( limit 100pcks); $other = class { fifo( limit 100pcks); PRIO - cenário 3 #include <ports.tc> #include <fields.tc> /* * prio */ dev "eth2" { egress { /* ****** definir classes baseadas no TOS ******* */ /* classe 1: minimize delay - interactive */ class(<$min_delay>) if ip_tos == 0x10; /* classe 2: maximize reliability - tipo ssh */ class(<$reliable>) if ip_tos == 0x4; /* classe 3 - qualquer outra */ class(<$other>) if 1;

128 APÊNDICE C. CONFIGURAÇÕES 127 /* Configure our classful qdisc */ prio { $min_delay = class { fifo( limit 10000pcks); $reliable = class { fifo( limit 100pcks); $other = class { fifo( limit 100pcks); HTB #include "fields.tc" #include "ports.tc" #define INTERFACE eth2 dev INTERFACE { egress { /* ****** definir classes baseadas no TOS - dsmark ******* */ /* classe 1: minimize delay - interactive */ class(<$min_delay>) if ip_tos == 0x10; /* classe 2: maximize reliability - tipo ssh */ class(<$reliable>) if ip_tos == 0x4; /* classe 3 - tcp */

129 APÊNDICE C. CONFIGURAÇÕES 128 class(<$tcp>) if ip_proto == IPPROTO_TCP; /* classe 4 - qualquer outra */ class(<$other>) if 1; /* configurar o escalonador */ htb () { // rate e ceil devem ser iguais para o top level, // e representam a largura de banda maxima disponivel no link class ( rate 10000kbps, ceil 10000kbps ) { // rate: $min_delay = class ( rate 1024kbps, ceil 2048kbps ) \ { sfq; ; $reliable = class ( rate 128kbps, ceil 4096kbps ) \ { sfq; ; $tcp = class ( rate 2048kbps, ceil 4096kbps ) \ { red(limit B, min B, max B, \ avpkt 1000B, burst 666B, probability 0.02, \ bandwidth 10000kBps); ; $other = class ( rate 512kbps, ceil 1024kbps ) { sfq; ; OurMix Esta é uma configuração de mecanismos de escalonamento que foi feita para a apresentação deste trabalho. /* * our own mix */ #include "fields.tc"

130 APÊNDICE C. CONFIGURAÇÕES 129 #include "ports.tc" #define INTERFACE eth2 dev INTERFACE { egress { /* ****** definir classes baseadas no TOS ******* */ // ssh class(<$ssh>) if tcp_sport == PORT_SSH tcp_dport == PORT_SSH; // kazaa class(<$kazaa>) if tcp_dport == PORT_KAZAA tcp_sport == PORT_KAZAA; // quake class(<$quake>) if tcp_dport == tcp_sport == 27960; // todos os outros class(<$other>) if 1; htb () { // rate e ceil devem ser iguais para o top level, // e representam a largura de banda maxima disponivel no link class ( rate 10000kbps, ceil 10000kbps ) { $ssh = class (rate 2048kbps, ceil 4096kbps) { sfq; ; $kazaa = class (rate 4096kbps, ceil 8192kbps) { sfq; ; $quake = class (rate 2048kbps, ceil 4096kbps) { fifo; ; $other = class (rate 2048kbps, ceil 4024kbps) { sfq; ;

131 APÊNDICE C. CONFIGURAÇÕES 130 C.2 Geração de tráfego C.2.1 Gerador 1 C FIFO Cenário 1 START NOW ON :10001 CONSTANT OFF Cenário 2 START NOW ON :10001 CONSTANT TOS 31 0x OFF Cenário 3 Neste caso, foi gerado tráfego tcp através do comando: bash# netperf -H Cenário 4 Neste caso, foi gerado tráfego tcp através do comando: bash# netperf -H C SFQ Cenário 1 START NOW ON :10001 CONSTANT OFF

132 APÊNDICE C. CONFIGURAÇÕES 131 Cenário 2 Neste caso, foi gerado tráfego tcp através do comando: bash# netperf -H C RED Cenário 1 Foram gerados 20 fluxos tcp através do script de bash: #!/bin/sh for ((i=0; i<20; i++)) do./netperf -H & done C TBF START NOW ON :10001 CONSTANT # 400Kbps MODIFY CONSTANT OFF C PRIO Cenário 1 START NOW # 600Kbps ON :10002 CONSTANT TOS 04 0x OFF e...

133 APÊNDICE C. CONFIGURAÇÕES 132 START NOW #1200Kbps ON :10001 CONSTANT TOS 10 0x OFF Cenário 2 START NOW # 2Mbps ON :10002 CONSTANT TOS 04 0x OFF e... START NOW #3Mbps ON :10001 CONSTANT TOS 10 0x OFF Cenário 3 START NOW #3Mbps ON :10002 CONSTANT TOS 04 0x OFF e... START NOW #12Mbps ON :10001 CONSTANT TOS 10 0x OFF

134 APÊNDICE C. CONFIGURAÇÕES 133 C HTB START NOW # 1.6Mbps ON :10001 CONSTANT TOS x OFF e... START NOW # 1.6Mbps ON :10002 CONSTANT TOS x10 e... START NOW # 5Mbps ON :10003 CONSTANT TOS x OFF C.2.2 C Gerador 2 (enchimento) FIFO Cenário 1 START NOW ON :10001 CONSTANT OFF Cenário 2 START NOW ON :10001 CONSTANT

135 APÊNDICE C. CONFIGURAÇÕES 134 TOS 32 0x OFF Cenário 3 START NOW ON :10001 CONSTANT OFF Cenário 4 START NOW ON :10001 CONSTANT TOS 32 0x OFF C SFQ Cenário 1 START NOW ON :10001 CONSTANT OFF Cenário 2 START NOW ON :10001 CONSTANT OFF C RED Cenário 1 Foram gerados 20 fluxos tcp através do script de bash: #!/bin/sh

136 APÊNDICE C. CONFIGURAÇÕES 135 for ((i=0; i<20; i++)) do./netperf -H & done C PRIO Cenário 1 START NOW ON :10001 CONSTANT OFF Cenário 2 START NOW ON :10001 CONSTANT OFF Cenário 3 START NOW ON :10001 CONSTANT OFF C HTB START NOW ON :10001 CONSTANT OFF

137 Apêndice D Glossário Ātraso Intervalo de tempo decorrido desde que o pacote deixa o emissor receptor. até chegar ao Este atraso global é, assim, composto pela acumulação de diversos atrasos: o atraso de transmissão, atraso de propagação, atraso de processamento e atraso em filas de espera. J itter É a variação do atraso sofrido por um pacote na rede. Classe É o constituinte básico dos mecanismos de escalonamento classfull e têm como principal função permitir especificar dentro de cada uma delas um novo mecanismo de escalonamento independente do que implementa as classes. Throughput É a quantidade de dados transferida de um ponto para outro durante um determinado período de tempo. Round-Robin É uma técnica que visa o balanço, através de um sistema rotativo, neste contexto, entre as várias classes de um mecanismo de escalonamento. TOS - Type of Service 136

138 APÊNDICE D. GLOSSÁRIO 137 É um campo do cabeçalho IP dos pacotes que indica qual o tipo de serviço associado a um pacote e que pode influenciar a maneira como este é tratado.