SlideShare uma empresa Scribd logo
1 de 43
MECANISMOS DE ESCALONAMENTO



                   Bernardo Pina

                    Filipe Cunha

                  Pedro Fernandes




    Departamento de Ciências de Computadores
Índice

INTRODUÇÃO................................................................................................................................. 3
MECANISMOS DE ESCALONAMENTO ............................................................................................. 5
INTRODUÇÃO AO LABORATÓRIO ................................................................................................. 18
       CONTROLO DE TRAFEGO EM LINUX ...................................................................................... 18

       MECANISMOS DE ESCALONAMENTO E LINUX....................................................................... 19

   SOFTWARE NECESSÁRIO .......................................................................................................... 20

       NETWORK TIME PROTOCOL (NTP) ........................................................................................ 20

       RUDE e CRUDE ..................................................................................................................... 20

       NETPERF e NETSERVER ......................................................................................................... 22

       TRAFFIC CONTROL NEXT GENERATION (TCNG) ..................................................................... 22

       TRAFFIC CONTROL (tc) .......................................................................................................... 24

LABORATÓRIO ............................................................................................................................. 25
   MECANISMOS CLASSLESS ......................................................................................................... 25

       FIFO ..................................................................................................................................... 25

       SFQ ...................................................................................................................................... 27

       RED ...................................................................................................................................... 29

       TBF ....................................................................................................................................... 30

   MECANISMOS CLASSFULLL ....................................................................................................... 31

       PRIO ..................................................................................................................................... 31

       HTB ...................................................................................................................................... 34

       Notas Finais.......................................................................................................................... 35

CONCLUSÃO ................................................................................................................................ 36
BIBLIOGRAFIA .............................................................................................................................. 37
ANEXOS ....................................................................................................................................... 38


                                                                                                                                                   2
INTRODUÇÃO

        Um “router” é um equipamento usado para fazer a comunicação entre diferentes redes de
computadores permitindo a comunicação entre computadores. Esses equipamentos contêm um
conjunto de sistemas e mecanismos de escalonamento através dos quais os pacotes são enviados
e recebidos, ao qual chamamos controlo de tráfego. Esse controlo 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 debito, na saída de uma interface.

        O controlo de tráfego fornece a possibilidade de tratar pacotes de forma diferente,
baseando-se nos atributos dos pacotes. As situações mais frequentes que requerem um controlo
de tráfego são as seguintes:

        Limitar a largura de banda total a uma determinada taxa ou a largura de banda que um
determinado utilizador, serviço ou aplicação cliente pode utilizar.
        Distribuir a largura de banda de forma equitativa por diferentes fluxos de tráfego.
Reservar largura de banda para uma determinada aplicação ou utilizador e dar prioridade a
tráfego sensível.
        Maximizar o throughtput, ou seja a quantidade de dados transferidos de um ponto para
outro durante um determinado período de tempo, do TCP de forma a dar prioridade à transmissão
de pacotes ACK.
        Assegurar que determinado tipo de tráfego não passa num router.

         A alguns anos atrás não havia uma preocupação excessiva de como os pacotes eram
transmitidos. Pouco importava se eles chegavam ao seu destino. Actualmente, com o surgimento
de aplicações como voz sobre IP e videoconferência, tais preocupações existem e são necessárias,
pois este tipo de aplicações necessitam de uma garantia de que os pacotes serão transferidos de
forma correcta aos seus destinatários.
         A Qualidade de Serviço, QoS, como já diz o nome, refere-se à garantia de um serviço de
qualidade. É um requisito das aplicações para as quais exige-se que determinados parâmetros
(atrasos, jitter, perdas, ...) estejam dentro de limites bem definidos (valor mínimo, valor máximo).
O termo é aplicado com frequência às aplicações de telecomunicações e redes de computadores,
recebendo uma definição específica para cada. Nas telecomunicações, Qualidade de Serviço
significa oferecer uma boa qualidade de voz, reduzir os ecos, etc. Nas aplicações de informática,
Qualidade de Serviço significa garantir uma transmissão eficiente de pacotes através da
implantação de sistemas de prioridade ou controle de banda.


        Alguns dos problemas que podem acontecer na transmissão de pacotes são:

        Atraso ou latência: É a medida do tempo decorrido entre o início de uma actividade e a
sua conclusão. Os atrasos podem acontecer quando pacotes tomam caminhos alternativos para
evitar congestionamentos ou quando enfrentam filas de espera.
        Jitter: É a variação na latência com que os pacotes atingem o seu destino final. A sua causa
é o processamento com tempo variável nos equipamentos de rede.
                                                                                                   3
Perda de pacotes: Pode acontecer quando pacotes são descartados quando há muito
congestionamento na rede. O uso de VoIP não é tolerante a perda de pacotes: perdas mínimas
como 1%, por exemplo, podem degradar uma chamada, provocando erros audíveis nesta.
        Entrega desordenada: Ocorre frequentemente a entrega de pacotes numa ordem
diferente da que foram enviados, uma vez que estes podem ser enviados por diferentes rotas, o
que provoca a exigência de protocolos especiais para que a informação possa ser reconstruída à
chegada.
        Erros: Também pode ocorrer que os pacotes sejam enviados para destinos errados, ou
misturados, ou mesmo serem corrompidos. O receptor terá então que detectá-lo e, tal como se o
pacote tivesse sido descartado, pedir a retransmissão.


        Existem, essencialmente, duas formas de oferecer garantias QoS. A primeira procura
oferecer bastantes recursos, suficientes para o pico esperado, com uma margem de segurança
substancial. É simples e eficaz, mas na prática é assumido como dispendioso, e tende a ser ineficaz
se o valor de pico aumentar além do previsto: reservar recursos gasta tempo.
        O segundo método é o de obrigar os utilizadores a reservar os recursos, e apenas aceitar
as reservas se os routers conseguirem servi-las com confiabilidade. Naturalmente, as reservas
podem ter um custo monetário associado! As duas variações mais conhecidas são o IntServ
(Integrated Services ou Serviços Integrados) e o DiffServ (Differentiated Services ou Serviços
Diferenciados).

        Do ponto de vista teórico serão apresentado diversos algoritmos de escalonamento
usados no controlo de tráfego bem como as suas principais características.Sob um ponto de vista
mais prático serão realizados um conjunto de testes de forma a tentar representar o maior
número possível de utilizações reais dos respectivos mecanismos de escalonamento e as suas
influências nas condições da rede.




                                                                                                  4
MECANISMOS DE ESCALONAMENTO

        Os mecanismos de escalonamento são algoritmos que geram 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).
Sem estes mecanismos, uma fila de espera não permite fazer qualquer tipo de controlo de tráfego.
Uma 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.
     Os mecanismos de classificação de pacotes marcam os pacotes de acordo com regras de
distinguir e isolar o tráfego em diferentes fluxos para os processar individualmente e garantir
assim um tratamento diferentes pa diferentes tipos de dados. Existem vários conjuntos de
mecanismos de classificação de pacotes, entre os quais:

    •   fw: Baseia a sua decisão na forma como a firewall marca os pacotes.
    •   u32: Baseia a sua decisão nos campos contidos nos pacotes.
    •   route: Baseia a decisão na rota que o pacote irá tomar.
    •   rsvp: Efectua a decisão baseada em rotas rsvp.

    Existem dois principais mecanismos, classless e classfulll.

    Os mecanismos classless são simples pois possuem apenas uma classe. Com isso, não há a
possibilidade de realizar a divisão de diferentes tráfegos. Podemos citar os seguintes mecanismos
classless:
    • FIFO (First In First Out)
    • PFIFO Fast (Packet First In First Out Fast - default no Kernel Linux)
    • SFQ (Stochastic Fair Queuing)
    • RED (Random Early Detection)
    • TBF (Token Bucket Filter)
    • WFQ (Weighted Fairness Queuing)

    Os mecanismos classfulll são mais eficientes e permitem a divisão do tráfego, priorizando cada
tipo de conexão de acordo com as configurações utilizadas pelo administrador da rede. Podemos
citar os seguintes mecanismos classfull:
    • CBQ (Class Based Queueing)
    • HTB (Hierarchy Token Bucket)
    • PRIO (Priority class)

   Atualmente, a melhor alternativa para o controle do tráfego é a associação do HTB com o
PRIO.


Classless (Sem classes):

                                                                                                    5
Estes mecanismos tratam o tráfego sem nenhuma diferenciação entre tipos de pacotes, ou
seja, todos os fluxos são processados de igual maneira.

FIFO – First In First Out

        É o mais simples mecanismo de escalonamento de pacotes onde estes são tratados de
igual maneira, sendo colocados numa fila única e servidos por ordem de chegada. Não permite
diferenciação por tipos de fluxos. À medida que os pacotes entram na fila da interface de entrada,
eles são colocados na fila da interface de saída na mesma ordem que foram recebidos. As figuras
abaixo ilustram duas representações do funcionamento de um mecanismo FIFO.




                                                                                                 6
As suas principais vantagens são:

         O seu comportamento é previsível, dado que os pacotes não são reordenados e o atraso
máximo é correspondente ao tamanho da fila de espera.
Em routers baseados em software este algoritmo não sobrecarrega as máquinas.
         Fornece um método de contenção simples para os recursos da rede enquanto o tamanho
da fila permanecer curto.

No entanto existem várias limitações:

        Uma única fila FIFO não permite a organização de pacotes em diferentes categorias.
        As aplicações que usam UDP são favorecidas relativamente às que usam TCP em períodos
de congestão de rede. O impacto do atraso influência de forma idêntica todos os fluxos.
        Um fluxo “mal comportado” pode consumir todo o espaço de memória de uma fila de
espera FIFO. A consequência destas limitações causam um aumento do atraso, do jitter(variação
do atraso sofrido por um pacote) e perdas para todos os outros fluxos UDP e TCP.
        Quando a rede IP opera sem sobrecarga, as filas são necessárias somente
para assegurar que os pacotes sejam descartados quando existe uma sucessão rápida, ininterrupta
e de curta duração de tráfego de dados. Nessa situação, este mecanismo é altamente eficiente, na
medida em que o tamanho da fila permanece pequeno. Entretanto, quando a carga da rede
aumenta, o tráfego rápido causa um atraso significativo de colocação na fila em relação ao atraso
da transmissão total e, quando a fila está totalmente cheia, todos os pacotes subsequentes são
descartados. Se a fila opera deste modo por longo período, a qualidade do serviço
inevitavelmente se degradará. Portanto, pode-se apontar como principal deficiência deste
algoritmo o facto deste usar a ordem de chegada dos pacotes para determinar a prioridade destes.
        Ainda assim, o FIFO é o mecanismo de escalonamento utilizado por defeito no Linux e na
maioria dos routers, devido à sua simplicidade e eficiência.




                                                                                                7
SFQ – Stochastic Fairness Queueing

        Este algoritmo foi desenhado para assegurar que cada fluxo tem um acesso “justo” aos
recursos da rede, evitando que um fluxo “mal-comportado” consuma mais do que a sua quota de
largura de banda.
        Os pacotes são classificados através de diferentes 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 de implementações mais sofisticadas o acrescento do tipo de protocolo ao
tuplo) 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.
        O SFQ utiliza uma função de hash para dividir os fluxos pois não é prático haver uma fila
para cada categoria de pacotes. Sendo assim, 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.
Para prevenir esta situação a função é trocada periodicamente, aumentando a “justiça” do
algoritmo.




        Este algoritmo tem como vantagem uma configuração extremamente intuitiva e simples.
Permite um acesso justo aos recursos da rede e apenas pode ser utilizado em situações que não
requeiram diferenciação, implementado quando se quer assegurar o mesmo acesso a vários
clientes.


                                                                                                 8
RED – Random Early Detection

          O mecanismo de escalonamento RED foi criado com o objectivo de prevenir o lock-out e
full-queues que são dois graves problemas que ocorrem na implementação de um mecanismo
FIFO.
          O lock-out acontece devido a efeitos de timing, o que resulta no facto de os pacotes de
alguns fluxos encontrarem a fila de espera cheia. Resumindo, os primeiros pacotes que chegam à
fila irão encontrar a fila ainda com capacidade de serviço, enquanto que os que chegarem a seguir
irão ser descartados.O full-queues são listas de espera que estão na grande maioria do tempo
ocupadas ao máximo.
          O RED fornece, o mais rapidamente possível, uma resposta a fluxos que implementem
congestão 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 pacotes descartados 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, comparando dois limiares (threshold), um mínimo e um máximo.




        Quando o tamanho médio da fila é inferior ao limiar mínimo, nenhum pacote é marcado.
Se o tamanho for superior ao limiar máximo, todos os pacotes que chegam são marcados.Entre
estes dois valores cada pacote é marcado com probabilidade pa.
        O RED tem 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; o 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.
        Existem três “modos” de descarte de pacotes:

   •   Sendo o tamanho médio da fila de espera inferior ao limiar mínimo, não existe congestão,
       logo nenhuma acção é tomada. A probabilidade de descarte de pacotes vai ser 0.

   •   Sendo 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 de rede – a grande maioria dos
       pacotes que chegam à fila vão ser descartados. A probabilidade de descarte será muito
       próxima de 1.

                                                                                                 9
•   Por último, 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.

         O cálculo do tamanho médio da fila de espera é determinado usando um filtro que não é
mais do que a função Exponential Weighted Moving Average (EWMA).
         No caso de marcação dos pacotes, a probabilidade de um pacote de uma determinada
ligação ser marcado é directamente proporcional à percentagem de largura de banda ocupada
pela ligação no router. E mais, assegura que o tamanho médio da fila de espera não excede
significativamente o limiar máximo definido.
Resumindo, a grande vantagem deste algoritmo é permitir um melhor serviço ao protocolo TCP e
de impedir a ocupação excessiva das filas por pequenos fluxos.


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 pois introduz um tópico importante, útil e
utilizado muito frequentemente com os mecanismos de escalonamento – traffic shaping.
         Para controlar a taxa de envio de pacotes uma opção de implementação é contar o
número de pacotes ou bytes que vão sendo enviados – 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.
         Explicando o algoritmo, é 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.
         Associando este algoritmo com os dois fluxos – token e dados, são estes os três possíveis
cenários:

    •   Os dados chegam à TBF a uma taxa que é igual à taxa de tokens que entram. Neste caso,
        cada pacote que entra possui um token correspondente e o mesmo é passado à fila sem
        qualquer atraso.
    •   Os dados chegam à TBF a uma taxa que é menor que a taxa de tokens. Somente uma parte
        dos tokens são removidos na saída de cada pacote de dados que é enviado à fila, assim as
        ficham vão-se acumulando, até ao tamanho do bucket. Os tokens não utilizados podem
        então ser usados para enviar os dados a uma velocidade que pode exceder à taxa do token
        padrão, nesse casso ocorrem “rajadas” curtas de dados.
    •   Os dados chegam à TBF a uma taxa maior que a taxa de tokens. Isso significa que o bucket
        ficará brevemente sem tokens, o que fará com que a TBF boqueie momentaneamente.
        Isso é normalmente designado por “overlimit situation”. Se os pacotes continuarem a
        entrar, então estes começam a ser descartados.



                                                                                                10
O último cenário é muito importante pois permite regular administrativamente a banda
disponível para os dados que estão a passar pelo filtro. A figura abaixo ilustra o funcionamento
deste tipo de mecanismo.




        Entre as principais vantagens deste algoritmo, conta-se o facto de ser simples e eficaz, sem
grandes requisitos em termos de complexidade computacional. É utilizado frequentemente para
controlar a taxa máxima dedicada a uma determinada ligação ou fluxo.

WFQ – Weighted Fairness Queueing

        Este algoritmo permite que cada fila do buffer tenha uma mesma quantidade de bytes
extraída e direccionada para a fila da interface de saída do dispositivo de rede. Isto torna mais
“justo” o escalonamento desses pacotes de dados e, consequentemente, uma igualdade no
fornecimento dos diferentes serviços. Assegura que cada fluxo tem um acesso justo aos recursos

                                                                                                   11
da rede, prevenindo que os fluxos mal comportados consumam mais do que a largura de banda
que lhes é atribuída.
           Para determinar a ordem de entrada na fila dos pacotes, este algoritmo utiliza pesos para
esse propósito e é necessário que cada pacote seja diferenciado quanto ao seu nível de prioridade.
Portanto, o WFQ analisa o campo Prioridade (Precedence) do cabeçalho do pacote de IP a fim de
atribuir um determinado peso a esse pacote. Esse campo contém uma prioridade que varia de 0
(normal) a 7 (pacote de controlo de rede). Quanto maior for o nível (valor) de prioridade menor é
o valor do peso atribuído a esse pacote. Assim, os pacotes com pesos baixos são escalonados
primeiro, ou seja, garantem ao fluxo desses pacotes um tempo de resposta mais imediato,
tornando este algoritmo mais adaptado às mudanças nas condições de tráfego da rede. Utiliza
uma função de hash juntamente com parâmetros de classificação para atribuir um pacote a uma
fila, tal como o SFQ.Assim, quanto maior for o número de filas, melhor é o funcionamento do
algoritmo.
           É um mecanismo eficiente pois pode-se utilizar toda a largura de banda disponível para
transmitir o tráfego de baixa prioridade se não existir tráfego de alta prioridade. A figura abaixo
ilustra o funcionamento do algoritmo WFQ.




        Como principais vantagens, o WFQ 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 tipo de pacotes.


Classfulll (Com classes):

         Os escalonadores Classfulll utilizam mecanismos de classificação de pacotes para dividir os
vários fluxos em classes, de forma a servir de forma diferente cada tipo de fluxo.


                                                                                                 12
CBQ – Class Based Queueing

        Este algoritmo foi projectado para permitir que várias aplicações, com especificações de
largura de banda mínima ou de exigências de atrasos, compartilhem a rede. É uma variação de
colocação em filas por prioridades, pois o buffer pode ser dividido em várias filas com diferentes
níveis de preferência (classes). Entretanto, este algoritmo permite definir a quantidade de bytes
de dados que deve ser retirada de cada fila do buffer para a fila da interface de saída do
dispositivo de rede.
        O CBQ é o mecanismo de escalonamento mais complexo existente actualmente. É
constituído por dois escalonadores: um genérico e um 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 de partilha de ligação 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. A figura abaixo ilustra o funcionamento deste algoritmo.




         Como vantagens tem 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, entre as quais: a necessidade de ser preciso saber a largura de banda do link, fica
“confuso” com tamanho 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.




                                                                                                 13
HTB – Hierarchy Token Bucket

        Hierarchic Token Buckets (HTB) é uma alternativa mais eficaz que o mecanismo CBQ.
Implementa um escalonador classfulll 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 “ceil”). 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.
        Como o próprio nome indica, o algoritmo faz uma partilha hierárquica de uma ligação e
como tal deve respeitar as seguintes regras:

Cada classe inferior 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 inferiores 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.

A figura abaixo ilustra a estrutura de classes do algoritmo HTB.




                                                                                                   14
Assim, o HTB assegura que a quantidade de serviço fornecida a cada classe e, no mínimo, a
quantidade que esta pede, e no máximo o tecto. Quando uma classe pede 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.
       Uma parte fundamental do escalonador HTB é o mecanismo de borrowing (empréstimo).
       Na tabela seguinte podemos observar o que acontece em cada caso, assim como as acções
tomadas.




                                                                                               15
Para evitar que haja empréstimo de largura de banda - o que pode ser necessário, 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 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
classfulll.

PRIO – Priority Class

        Este algoritmo foi projectado para dar uma maior prioridade ao tráfego de dados nas filas
de espera que exigem uma certa urgência de processamento. Este algoritmo é baseado no
conceito que certos tipos de tráfegos podem ser identificados e colocados à frente na fila de saída
e desta forma transmitidos primeiro que outros tráfegos.
        A forma como o tráfego de dados pode ser classificado na interface de rede de um
dispositivo de rede é bastante flexível. Esta classificação pode ser feita de acordo com o protocolo
de rede (Internet Protocol, Internetwork Packet Exchange, Apple Talk) que está a ser utilizado no
pacote de dados, no tamanho destes pacotes (quantidades de bytes), no endereço IP de origem e
de destino. Cada pacote pode ser classificado em quatros níveis de prioridades: alto, médio,
normal e baixo.
        A figura abaixo mostra os pacotes de dados a seres colocados nas respectivas filas de
acordo com a classificação dada a cada pacote na interface de entrada de um dispositivo de rede.
Em seguida esses pacotes são colocados na fila de saída de acordo com os seus níveis de
prioridades.




        O PRIO tem a vantagem de ser a forma mais simples de implementar a diferenciação de
tipo de pacotes. Por outro lado, tem a desvantagem: no caso de não existir nenhum mecanismo de
                                                                                                  16
controlo 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 menos 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.

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:

    •   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-fillho, 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 ligacão com largura de banda váriavel 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 traffic-shaping. 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,emule entre outros. 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 Classfulll com TBF (Token Bucket Filter) para fazer traffic-
shapping.

    •    Partilhar ou 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
Classfulll com N classes - uma para cada IP.




                                                                                                     17
INTRODUÇÃO AO LABORATÓRIO

        Neste trabalho foram utilizados três computadores, todos eles com sistema operativo
Linux: um a servir de router, um como gerador de fluxo e outro como receptor do mesmo.
        No router utilizaram-se duas placas de rede:

       Placa Ethernet de 10Mbps à entrada
       Placa Ethernet de 10Mbps à saída

       O router possuía o sistema operativo Linux Mandriva 2009.0 (Free) com Kernel 2.6.27.14.
       Tanto no gerador como no receptor de fluxos, utilizamos placas Ethernet de 10 Mbps.

        Todos os interfaces de rede estavam configurados com mecanismo de escalonamento
FIFO (pfifo_fast) com excepção da porta de saída do router, que foi alvo das configurações
pretendidas para efeito de teste.




Figura 1: Esquema da rede montada


       CONTROLO DE TRAFEGO EM LINUX

         Cada interface de rede em Linux é controlada por um driver que controla o hardware. Esse
driver funciona como um mecanismo de troca de pacotes entre a camada de rede e a rede física.
         Quando um pacote chega a uma máquina Linux é passado pelo interface de rede ao
desmultiplexador que o examina e determina se é destinado a máquina local. Se for o caso, o
pacote é enviado para as camadas acima. Caso contrário, é analisada a tabela de 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.




                                                                                              18
Esse controlo de tráfego pode ser realizado em duas fases:

       no policiamento a entrada (ingress policing)
       nas filas de espera a saída (output queueing)

       No funcionamento de um router normal, os pacotes raramente passam acima da camada
de rede, pelo que nenhum pacote é gerado ou consumido pela máquina. Todos os pacotes que
passam pelo router ora são encaminhados ou descartados.


       MECANISMOS DE ESCALONAMENTO E LINUX

       Para que uma máquina Linux funcione como escalonador necessita de ter os respectivos
módulos compilados directamente no kernel ou então carregados depois de o kernel estar
compilado.
       Os módulos do Linux relativos aos mecanismos de escalonamento estão em

       /lib/modules/<versão kernel>/kernel/net/sched/

       E possuem nomes com prefixo sch_.

       Os mecanismos disponíveis no router (PC) usado são:
   •   First In First Out (FIFO)
   •   Priority FIFO Fast (PFIFO-FAST)
   •   Stochastic Fair Queuing (SFQ)
   •   Random Early Detection (RED)
   •   Generalized RED (GRED)
   •   Token Bucket Filter (TBF)
   •   Prioridade Estrita (PRIO)
   •   Class Based Queueing (CBQ)
   •   Hierarchical Token Bucket (HTB)
   •   Clark-Shenker-Zhang (CSZ)
   •   Diff-Serv Marker (DS MARK)
   •   Traffic Equalizer (TEQL)

       Como optamos por carregar os módulos manualmente para a memória do kernel, tivemos
que realizar o seguinte comando:

       bash# modprobe <nome dos mecanismos de escalonamento>

       Para se verificar se o módulo foi carregado com sucesso, basta ver se o mesmo se
encontra listado no output do comando

       bash# lsmod



                                                                                              19
SOFTWARE NECESSÁRIO


        NETWORK TIME PROTOCOL (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 tempo que
existir entre as máquinas.
         Para o efeito, decidimos utilizar o NTP.

        A configuração do NTP e extremamente simples e directa. Tanto nos servidores como nos
clientes, o ficheiro de configuração a utilizar é o

        /etc/ntp.conf

       O nosso router, como servidor NTP das restantes máquinas, teve de ser configurado
colocando a seguinte linha no ficheiro supracitado:

        bash# server <IP interface Ethernet>

nos clientes basta configurar adicionando a seguinte linha:

        bash# server <IP do servidor>

        As restantes opções de configuração dos ficheiros foram todas mantidas.

       Antes de executar o daemon do NTP é necessário efectuar duas sincronizações (pelo
menos), recorrendo-se ao ntpdate da seguinte forma:

        bash# ntpdate <IP do servidor >

para inicializar o NTP deve-se correr o daemon respectivo com o seguinte comando:

        bash# service ntpd start


        RUDE e CRUDE

         O rude (gerador de tráfego UDP) e o crude (receptor do tráfego UDP e gerador de
estatísticas), no seu conjunto, formam uma aplicação interessante para avaliar os efeitos dos
mecanismos do escalonamento nos fluxos de dados de uma rede. A escolha desta aplicação
deveu-se a sua configuração ser simples e ao facto de fornecer dados significativos relativos aos
fluxos no colector, tais como:



                                                                                                    20
•   Débito
    •   Número de pacotes recebidos e perdidos
    •   Atraso médio dos pacotes
    •   Jitter médio
    •   Jitter máximo


       Para instalar o rude sem problemas, bastou seguir os ficheiros de ajuda disponibilizados
com a aplicação.
       Para gerarmos os fluxos pretendidos, é necessário elaborar um ficheiro de configuração
com a seguinte estrutura:

        START NOW
        1000 10 ON 3001 192.168.2.2:10001 CONSTANT 150 1000
        TOS 10 0x10
        61000 10 OFF

         De seguida faz-se a descrição de cada um dos parâmetros:
    • Linha 1: marca o inicio da configuração para um fluxo de dados
    • Linha 2:
         - 1000 - milissegundos aos quais o fluxo começa a ser transmitido
         - 10 - identificador do fluxo gerado
         - ON - indica o inicio do fluxo
         - 3001 - porta utilizada na máquina de origem
         - 192.168.2.2:1001 - ip e porta da máquina de destino
         - CONSTANT - tipo do fluxo gerado, no caso Constant Bit Rate
         - 150 - número de pacotes gerado por segundo
         - 1000 - 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 esta normalmente associado a tráfego interactivo.
    • Linha 4: indica que o fluxo deixa de ser transmitido aos 61000 milissegundos

       No que diz respeito à utilização, começamos por correr o receptor dos fluxos, para não se
perderem pacotes enviados pelo emissor, o comando a utilizar foi:
       bash# crude -s <id do fluxo gerado pelo servidor>

         Por sua vez, após criado o ficheiro de configuração pretendido para o emissor, o comando
a utilizar é:

        bash# rude -s <caminho para o ficheiro de configuração>

        Quando o emissor terminar o envio de pacotes, basta efectuar “control+c” no receptor
para os resultados serem mostrados.
        O facto de nem o cliente nem o servidor gerarem output durante o decorrer dos testes
e 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.

                                                                                                  21
NETPERF e NETSERVER

        Uma vez que o Rude não gera tráfego TCP, a aplicação que decidimos utilizar para o efeito
foi o netperf. Esta aplicação baseia-se em dois executáveis : netperf e netserver.
        Quando executado o netperf (no emissor), é 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 (no receptor).
        Após o estabelecimento da ligação de controlo, uma ligação nova é estabelecida para a
medição da performance . De seguida o teste é efectuado e os resultados são gerados.
        O netperf não gera nenhum tráfego para a ligação de controlo enquanto os testes
estão a decorrer.
        Para este trabalho o netperf foi utilizado apenas para o seu teste por defeito: 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 receptor, bastou executar a aplicação netserver que fica a correr
como daemon.
      Por sua vez, no emissor, basta utilizar o netperf da seguinte forma:

        bash# netperf -H <ip do receptor> -l <duração do teste>

       Com esta configuração simples, é efectuado um teste de l segundos entre o emissor e o
receptor, da qual são geradas estatísticas, neste caso ,no emissor de tráfego.
       A estatística gerada contem, entre outros, os seguintes dados: taxa de transmissão
conseguida e tempo decorrido.


        TRAFFIC CONTROL NEXT GENERATION (TCNG)

        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 no tc ( traffic control).


Configuração e utilização


        O TCNG utiliza uma linguagem de configuração semelhante às linguagens orientadas
a objectos, compacta e simples.
        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.

                                                                                                  22
• Exemplo 1:
   dev eth0 {
      egress {
               fifo (limit 100p );
      }
   }

       De seguida, é feita a explicação das configurações apresentadas acima:

       Com este exemplo, associa-se os mecanismos de escalonamento FIFO com fila de espera
de cem pacotes à interface de rede eth0.

       A palavra egress é um sinónimo para dsmark.

   • Exemplo 2:
   #include "fields.tc"
   #include "ports.tc"
   dev eth0 {
          egress {
                    // classificacao
                    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.
       Esta configuração baseia-se em duas partes:

   1. 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
                                                                                              23
todos os pacotes que sobram.
    2. 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.

       Depois da escrita dos ficheiros de configuração, o tcng (traffic control new generation)
recebe
como argumento esses ficheiros e gera scripts para configurar os mecanismos de escalonamento
como pretendido.


        TRAFFIC CONTROL (tc)

        Sempre que nos foi possível, utilizamos TCNG para configurar os mecanismos de
escalonamento. No entanto, esporadicamente utilizamos o TC ( apesar deste
possuir uma sintaxe mais complexa e menos intuitiva) ,apenas por o TCNG não apresentar suporte
para alguns mecanismos de escalonamento .

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âmetros>

       Uma outra utilidade do TC que utilizamos regularmente foi:

       bash# tc qdisc show

        Que serve para visualizar as varias interfaces, os mecanismos e parâmetros a elas
associados.



                                                                                              24
LABORATÓRIO

      Neste capítulo vamos apresentar os resultados obtidos no trabalho laboratorial efectuado.
      As configurações dos mecanismos de escalonamento (feitas no router) são apresentadas
em anexo, assim como as configurações do rude e netperf para geração dos fluxos UDP e TCP.
      Todos fluxos UDP (bem como os TCP) usados têm a exacta duração de 60 segundos.



       MECANISMOS CLASSLESS
       Estes mecanismos tratam o tráfego sem nenhuma diferenciação entre tipos de pacotes, ou
seja, todos os fluxos são processados de igual maneira.


         FIFO

        O FIFO é o mecanismo de escalonamento mais simples e consiste apenas numa fila de
espera. Essa fila de espera pode ser quantificada por número de pacotes ou bytes.

Caso 1

Objectivo

       Verificar como uma FIFO se comporta com dois fluxos UDP iguais.

Método

       Dois fluxos UDP CBR iguais e sem ToS

   •   Um fluxo 10 com 6Mbps
   •   Um fluxo 20 com 6Mbps

       Configuramos no router uma FIFO com tamanho de 100 pacotes, para efeito de testes.

       Os resultados foram medidos no crude do receptor.




                                                                                            25
Resultado

Fluxos           Throughput     Jitter (s)         Pacotes          Pacotes      Pacotes fora
                 médio                             Recebidos        perdidos     de sequência
                 (Mbps)
10               5.93297        0.011364           356076           123924       0
20               5.35858        0.011397           339894           124106       0
Tabela 1: Resultados UDP do Caso 1, FIFO

       Após vários testes chegamos a conclusão que o fluxo que entra primeiro na fila FIFO ganha
sempre um valor de throughput médio ligeiramente superior e jitter inferior. Isto deve-se ao facto
do primeiro fluxo ocupar primeiro a fila.

Caso 2

Objectivo

         Este teste pretende verificar se o FIFO distingue fluxos pelo seu ToS

Método

         Dois fluxos UDP CBR iguais e com ToS diferentes
    •    Um fluxo 10 com ToS 0x0 e taxa de 750Kbps
    •    Um fluxo 20 com ToS 0x10 e taxa de 750Kbps

         Os resultados foram medidos no crude do receptor.

Resultado

Fluxos           Throughput     Jitter (s)         Pacotes          Pacotes      Pacotes fora
                 médio (bps)                       Recebidos        perdidos     de sequência
10               750183         0.007914           45012            0            0
20               750183         0.007845           45012            0            0
Tabela 2: Resultados UDP do Caso 2, FIFO

        Através dos resultados obtidos podemos concluir que o FIFO não faz qualquer distinção
entre fluxos com ToS diferentes.

Caso 3

Objectivo
        Verificar, à semelhança do Caso 1, como se comporta o FIFO na presença de 2 fluxos TCP
iguais.




                                                                                                26
Método
      Dois fluxos TCP STREAM iguais e com a mesma duração.

         Os resultados foram medidos no netperf do emissor.

Resultado

Fluxo                           Throughput médio (Mbps)        Elapsed time (s)
Gerador TCP 1                   4.543                          60.16
Gerador TCP 2                   4.883                          60.42
Tabela 3: Resultados TCP do Caso 3, FIFO

        Conclui-se portanto que o comportamento é semelhante ao verificado no Caso 1, sendo
que neste caso o throughput médio é um pouco mais semelhante entre os dois fluxos e no total
mais equilibrada, tendo em conta o limite máximo da largura de banda (10Mbps).
        Isto prova que, mesmo num ambiente sem mecanismos de escalonamento ajustados para
o acesso justo dos fluxos, os mecanismos próprios de controlo de congestão do TCP, acabam por
funcionar perfeitamente.


         SFQ

       O SFQ tem como objectivo garantir o acesso “justo” de todos os fluxos. Os casos
estudados foram idealizados tendo em vista demonstrar essa característica. Para analisarmos o
SFQ configuramos o tc do router com SFQ e uma perturbação de hash a ser substituída de 5 em 5
segundos.

Caso 1

Objectivo

         Com este caso pretende-se demonstrar o acesso “justo” que o SFQ preconiza.

Método

         Dois fluxos UDP CBR iguais e sem ToS

   •     Um fluxo 10 UDP com 10Mbps
   •     Um fluxo 20 UDP com 20Mbps

         Os resultados foram medidos no crude do receptor.




                                                                                            27
Resultado


Fluxos           Throughput      Jitter (s)      Pacotes        Pacotes            Pacotes fora
                 médio                           recebidos      perdidos           de sequência
                 (Mbps)
10               5.57085         0.068004        334273         265589             0
20               5.78023         0.023918        346836         852886             0
Tabela 4: Resultados do Caso 1, SFQ

        Analisando os resultados, chegamos a conclusão que o SFQ garante o acesso justo de
fluxos, mesmo que os throughputs enviados inicialmente pelo gerador sejam muitos desiguais.
        Em situações normais o SFQ pode originar pacotes fora de sequência (é de resto o
mecanismo que mais verifica esse fenómeno) no entanto isso acabou por não se verificar.

Caso 2

Objectivo

       Este caso foi pensado com o objectivo de verificar como o TCP se comporta em conjunto
com o UDP neste género de escalonamento.

Método

         Um fluxo UDP CBR e um fluxo de TCP:

    •    Um fluxo 10 UDP com 10Mbps
    •    Um fluxo TCP STREAM de 60 segundos

         Os resultados foram medidos no crude do receptor e no netperf do emissor.

Resultados


Fluxos           Throughput     Jitter (s)       Pacotes        Pacotes            Pacotes fora
                 médio                           Recebidos      perdidos           de sequência
                 (Mbps)
10               6.977          0.021110         418617         181384             52
Tabela 5: Resultados do UDP, Caso 2 SFQ

Fluxo                            Throughput médio (Mbps)        Elapsed time (s)
TCP STREAM                       4.612                          60.15
Tabela 6: Resultados do TCP, Caso 2 SFQ

        Mais uma vez se verifica, que apesar de estarmos na presença de dois fluxos de géneros
diferentes, o acesso é “justamente” garantido. Não havendo um que canibalize o outro.

                                                                                                  28
Neste caso 2, conseguimos verificar pacotes fora de sequência. Isto pode acontecer devido ao
facto da função de hash usada para dividir os fluxos entre as diferentes filas, colocar pacotes
pertencentes ao mesmo fluxo, em filas diferentes, logo servindo-os com ordem trocada.


         RED

Caso 1

        O RED tem como função evitar a sincronização global e executar congestion avoidance em
ligações TCP.

Objectivo

         Testarmos as propriedades deste mecanismo de escalonamento, sobre diversas fontes
TCP.

Método

         10 fluxos de TCP STREAM com duração de um segundo cada.

         Decidimos configurar o router da seguinte forma:

    •    Bandwith - 10000Kbps (largura de banda da ligação)
    •    Probability - 0.02 (probabilidade do pacote ser marcado)
    •    Burst - 666 (este parâmetro define quão rápido o tamanho médio da fila é influenciado
         pelo tamanho real da fila, deve calcular-se da seguinte forma:(min*2+max)/(3*avptk))
    •    Avpkt - 1000
    •    Max - 1000000 bytes (tamanho máximo da fila)
    •    Min - 500000 bytes (tamanho médio da fila)
    •    Limit - 8000000bytes (limite de dados na fila, a partir da qual são descartados)

Resultados

Número do fluxo                  Throughput médio (Mbps)          Elapsed time
1                                7.533                            1.29
2                                1.745                            1.35
3                                0.125                            1.17
4                                0.139                            1.16
5                                0.248                            1.27
6                                0.332                            1.32
7                                0.094                            1.06
8                                0.340                            1.05
9                                0.546                            1.05
10                               0.659                            1.07
Tabela 7 : Resultados usando FIFO.
                                                                                                  29
Número do fluxo                 Throughput médio (Mbps)            Elapsed time
1                               8.528                              1.31
2                               0.224                              1.23
3                               0.720                              1.35
4                               0.162                              1.18
5                               0.247                              1.25
6                               0.137                              1.10
7                               0.230                              1.06
8                               0.268                              1.04
9                               1.278                              1.17
10                              1.658                              1.12
Tabela 8 : Resultados usando RED.

         Estes resultados não foram os ideais para retirar conclusões. No entanto, podemos
verificar algumas melhorias a nível de throughput médio, para as diferentes ligações, quando se
utiliza o RED, o que prova, de alguma forma, que os efeitos de lock-out (quando um recurso é
consumido excessivamente por um pequeno numero de fluxos) são minimizados.


         TBF

       O TBF é um “traffic-shapper” que é bastante interessante de analisar. O traffic-shapping é
uma técnica bastante usada pelos operadores de forma a controlar a largura de banda das suas
redes.

Caso 1

Objectivo

         Analisar a influência do traffic shapping num fluxo normal.

Método

         Um fluxo UDP CBR

    • fluxo 10 com 12MBps

         Configuramos o router com TBF da seguinte forma:

   •     rate – 512kbps (débito pretendido para o fluxo)
   •     burst – 40kB (tamanho do bucket)
   •     limit – 40kB (numero de bytes que podem estar em fila de espera)
   •     mtu – 1514B

         Os resultados foram medidos no crude do receptor.
                                                                                                  30
Resultado


Fluxos            Throughput    Jitter (s)         Pacotes        Pacotes          Pacotes fora
                  médio (bps)                      Recebidos      perdidos         de sequência
10                489403        0.013736           29407          693466           0
Tabela 9 : Resultado do UDP, Caso 1 TBF

         Verificamos que o throughput médio foi muito aproximado ao configurado no TBF.
Portanto, bastante longe do throughput esperado inicialmente.
Fica assim provado que o TBF consegue de facto limitar o débito de um canal eficazmente.




         MECANISMOS CLASSFULLL

        Nos mecanismos classfulll de escalonamento, faz-se uso das chamadas classes, como já foi
explicado anteriormente.
        Assim, nesta secção, utilizamos o mecanismo de classificação de pacotes Dsmark, com as
classes seguintes:


    o    Classe 1 – pacotes IP com ToS 0x10
    o    Classe 2 – pacotes IP com ToS 0x04
    o    Classe 3 – pacotes IP sem ToS definido
    o    Classe TCP – pacotes IP com ToS 0x06


         PRIO

         O PRIO é o mecanismo de escalonamento mais simples que faz uso de classes.

Caso 1

Objectivo

         Observar que cada fluxo recebe o serviço configurado para a sua classe.

Método

         Três fluxos UDP CBR com ToS diferentes:

    •    fluxo 10 classe 1 de 150Kbps
    •    fluxo 20 classe 2 de 75Kbps
    •    fluxo 30 classe 3 de 1Mbps

                                                                                                  31
Configuramos o router com PRIO e em cada classe colocamos um TBF a fazer traffic-
shapping da seguinte forma:

    •    classe 1 com rate 128Kbps
    •    classe 2 com rate 64Kbps
    •    classe 3 com rate 32Kbps

         Os resultados foram medidos no crude do receptor.

Resultados


Fluxos            Throughput    Jitter (s)         Pacotes        Pacotes         Pacotes fora
                  médio (bps)                      Recebidos      perdidos        de sequência
10                122468        0.008114           7367           82720           0
20                61391.4       0.015070           3703           41307           0
30                30854.6       0.032758           1870           569310          0
Tabela 10 : Resultados do UDP, Caso 1 PRIO

         Observou-se então o previsto. Cada classe teve o seu fluxo limitado ao rate imposto pelo
TBF. O PRIO permite-nos então ter várias classes com diferentes prioridades e ao mesmo tempo
limitar o thoughput dessas classes.


Caso 2

Objectivo

        Colocar FIFO em cada classe do PRIO, de forma a provar que o fluxo com classe 3 só ocupa
a largura de banda deixada pelos fluxos de maior prioridade.

Método

         Três fluxos UDP CBR com ToS diferentes:

    •    fluxo 10 classe 1 de 3.75Mbps
    •    fluxo 20 classe 2 de 2.5Mbps
    •    fluxo 30 classe 3 de 10Mbps

         No router, cada classe do PRIO possuía FIFO com filas de 100 pacotes.

         Os resultados foram medidos no crude do receptor.




                                                                                                 32
Resultado

Fluxos            Throughput    Jitter (s)       Pacotes          Pacotes         Pacotes fora
                  médio                          Recebidos        perdidos        de sequência
                  (Mbps)
10                3.75877       0.010148         225534           30              0
20                2.49914       0.009939         149980           21              0
30                5.46285       0.010244         327847           243580          0
Tabela 11 : Resultados do UDP, Caso 2 PRIO

        Constatamos então que, sem o TBF a fazer shapping dos fluxos, as classes com maior
prioridade foram servidas em primeiro lugar. Assim sendo o fluxo 10 (classe 1) ficou com o
throughput esperado, assim como o fluxo 20 (classe 2). O fluxo 30 (classe 3) ficou com a largura de
banda restante, pelo que apenas conseguiu metade do throughput pretendido.


Caso 3

Objectivo

         Originar fenómeno de starvation nos fluxos de menor prioridade.


Método
      Três fluxos UDP CBR com ToS diferentes:

    •    fluxo 10 classe 1 de 12Mbps
    •    fluxo 20 classe 2 de 3Mbps
    •    fluxo 30 classe 3 de 8Mbps

         Cada classe do PRIO possuía, mais uma vez, FIFO com filas de 100 pacotes.

         Os resultados foram medidos no crude do receptor.

Resultados


Fluxos            Throughput    Jitter (s)       Pacotes          Pacotes         Pacotes fora
                  médio                          Recebidos        perdidos        de sequência
                  (Mbps)
10                10.4752       0.034637         688624           220467          0
20                0.0931295     21.972095        5590             214255          0
30                0.0103741     21.990317        6227             578559          0
Tabela 12 : Resultados do UDP, Caso 3 PRIO



                                                                                                 33
Verifica-se assim que quando mal configurado, mesmo um mecanismo de escalonamento
com classes e prioridades, pode originar problemas.
        Neste caso o fenómeno de starvation é bem evidente. Como o fluxo 10 tem prioridade
sobre os restantes, é o primeiro a ser processado. No entanto, como não existe mecanismo de
controlo do rate máximo, este fluxo apodera-se de toda a largura de banda disponível, não dando
margem de manobra aos restantes fluxos. Mesmo os que possuem algum grau de prioridade.



         HTB

Caso 1

Objectivo

        Com este caso de estudo, pretendemos verificar a eficiência do Hierarchical Token Bucket
na resolução das seguintes questões:

   •     Certificar que o problema de starvation observado no PRIO já não se verifica
   •     Garantir que há bom serviço para os fluxos com requisitos de real time, mas certificando
         que não monopolizam a largura de banda
   •     Com vários fluxos diferentes, verificar se cada um é servido pela sua classe




Método
      Quatro fluxos UDP CBR com ToS diferentes:

   •     fluxo 10 classe 1 de 1.6Mbps
   •     fluxo 20 classe 1 de 1.6Mbps
   •     fluxo 30 classe 2 de 18Mbps
   •     fluxo 40 classe 3 de 32Mbps

         Um fluxo TCP:
   •     um fluxo TCP STREAM de 60 segundos

         No router temos a seguinte configuração:

   •     classe 1 – tem associado um SFQ, com taxa garantida de 128Kbps e tecto de 256Kbps
   •     classe 2 – tem associado um SFQ, com taxa garantida de 256Kbps e tecto de 512Kbps
   •     classe 3 – tem associado um SFQ, taxa garantida de 64Kbps e tecto de 128Kbps
   •     classe TCP – tem associado um RED, com taxa garantida de 2Mbps e tecto de 4Mbps

         Os resultados foram medidos no crude do receptor e no netperf do gerador.

                                                                                                34
Resultados


Fluxos            Throughput    Jitter (s)      Pacotes         Pacotes            Pacotes fora
                  médio (bps)                   Recebidos       perdidos           de sequência
10                122232        0.106865        3726            56268              0
20                122200        0.101608        3724            56253              0
30                346064        0.115324        10504           176953             0
40                122221        0.109549        3791            450655             0
Tabela 13 : Resultados UDP, Caso 1 HTB

Fluxo                            Throughput médio (Mbps)        Elapsed time (s)
Gerador TCP                      3.86                           60.85
Tabela 14 : Resultados TCP, Caso 1 HTB

        Através da análise dos resultados obtidos chegamos a algumas conclusões interessantes.
        O fluxo 10 e 20 tem o mesmo ToS (0x10) e o mesmo débito inicial (2MBps), no entanto,
como a sua classe é gerenciada por SFQ, verificamos que não se canibalizam uma a outra, como
aconteceria em FIFO. Pelo contrário, ambas acedem equitativamente aos recursos da sua classe,
dividindo a largura de banda disponível.
        O fluxo 30 tem por sua vez ToS 0x04, pelo que ocupou parte significativa da largura de
banda disponibilizada para a sua classe. Um valor entre a taxa garantida e o tecto disponível.
        O fluxo 40, uma fonte potencial de starvation (como verificamos no Caso 3 do PRIO) por
sua vez, acede apenas aos recursos disponibilizados pela sua classe. Neste caso o throughput
médio é aquele que a sua classe permite, encontrando-se por isso longe dos 32MBps (!) esperados
(☺).
        Também o fluxo TCP ocupa quase a totalidade da largura de banda disponibilizada para a
sua classe, sem no entanto causar starvation nas restantes ligações, fruto naturalmente das
limitações impostas pelo HTB.



         Notas Finais


        Dadas as limitações técnicas conhecidas, não conseguimos fazer uma rede com mais do
que um router Linux físico, pelo que os resultados obtidos poderiam ser mais óbvios e
contundentes se, em alguns mecanismos de escalonamento, utilizássemos redes de maior
dimensão. Exemplo disso, parece-nos ser o caso do SFQ, no qual não conseguimos verificar a
ocorrência de pacotes fora de sequência, no caso 1. Numa situação real, onde os pacotes tivessem
de realizar um número maior de hops, esse fenómeno seria facilmente observado.




                                                                                                  35
CONCLUSÃO

       Após o estudo e realização de diversas experiências laboratoriais, podemos finalmente
chegar a algumas conclusões relativamente aos mecanismos de escalonamento.

        Quando bem utilizados, os mecanismos de escalonamento possibilitam uma série de
formas de controlo de tráfego que permitem gerenciar uma rede, de reduzida ou elevada
dimensão.
        Nos diversos testes realizados podemos comprovar isso mesmo: desde limitar o débito de
um determinado tipo de serviço até, precisamente o oposto, garantir o débito de um tipo de
serviço específico, no meio de outros tantos que cruzam a rede.
        Tanto os mecanismos de escalonamento classfulll como os classless são importantes para
garantir qualidade de serviço numa rede. É a sua conjugação de esforços que nos permitem ter um
maior leque de opções, para resolver problemas reais de forma eficaz. É em grande medida devido
aos mecanismos de escalonamento que, protocolos como o RTP, conseguem singrar na internet,
por exemplo.

      No entanto, nem tudo são vantagens e o elevado poder adaptativo destes mecanismos
têm um preço.

        Alguns do algoritmos são relativamente pesados para as máquinas convencionais que
utilizamos. Por esse mesmo facto, existe hardware especificamente desenhado para suportar este
género de serviço, em situações extremas de fluxos muito mais exigentes do que aqueles que
foram testados por nós. Outra desvantagem, é também o facto de a configuração de alguns
mecanismos poder ser extremamente complexa. Nomeadamente, se estivermos a falar de
configurações para resolução de problemas que tendem a ter um elevado grau de
imprevisibilidade.
        Exemplo disso mesmo é a dificuldade em implementar modelos IntServ em grande escala,
por forma a garantir qualidade de serviço.

        O grande inimigo que se apresenta, ainda e sempre, aos mecanismos de escalonamento é,
curiosamente, o aumento sucessivo da capacidade/largura de banda das redes.
        O preço de custo de implementação de um sistema de controlo de tráfego eficiente a nível
global é maior, do que o necessário para aumentar a largura de banda disponível em alguns troços
da rede e assim “solucionar” os problemas. Parece-nos uma falsa solução. Teríamos tudo a ganhar
se estes mecanismos de escalonamento fossem adoptados em conjunto com todas as outras
evoluções naturais das redes de internet. Parece-nos pois que, com o advento das comunicações
em VoIP, os fornecedores de serviços de internet têm todo o interesse em que assim seja.

        Em suma, os mecanismos de escalonamento fornecem um “estado” a um protocolo que
não o implementa de origem – o protocolo IP.




                                                                                               36
BIBLIOGRAFIA

•   PUB – Rio – Certificação digital Nº0310457/CA
•   http://www.eriberto.pro.br/wiki/index.php?title=Controle_de_tr%C3%A1fego_com_TC%2
    C_HTB_e_Iptables
•   http://www.howtoforge.com/voip_qos_traffic_shaping_iproute2_asterisk
•   http://www.pop-pr.rnp.br/tiki-index1b91.html?page=Roteadores+Controle+de+Trafego
•   http://linux-ip.net/articles/Traffic-Control-HOWTO/
•   http://www.opalsoft.net/qos/DS-21.htm
•   http://en.wikipedia.org/wiki/Quality_of_service
•   http://vonage.nmhoy.net/qos.html
•   http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS.html
•   http://en.wikipedia.org/wiki/Traffic_shaping
•   http://vonage.nmhoy.net/qos.html
•   http://tcng.sourceforge.net/
•   http://www.netperf.org/netperf/
•   http://rude.sourceforge.net/
•   http://www.ntp.org/




                                                                                  37
ANEXOS

Ficheiros de configuração do router:


FIFO

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 pfifo limit 100


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 5

RED

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 red limit 8000000 min 500000
max 1000000 avpkt 1000 burst 666 probability 0.02 bandwidth 10000


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 40960 limit 40960
mtu 1514 rate 512kbps


PRIO

caso 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 20480 limit 20480
mtu 1514 rate 128000bps
tc qdisc add dev eth2 handle 4:0 parent 2:2 tbf burst 20480 limit 20480
mtu 1514 rate 64000bps
tc qdisc add dev eth2 handle 5:0 parent 2:3 tbf burst 20480 limit 20480
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

                                                                          38
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

caso 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
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


caso 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 10000
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



                                                                          39
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 1250000bps ceil
1250000bps
tc class add dev eth2 parent 2:1 classid 2:2 htb rate 128000bps ceil
256000bps
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
512000bps
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 256000bps ceil
512000bps
tc qdisc add dev eth2 handle 5:0 parent 2:4 red limit 8000000 min 500000
max 1000000 avpkt 1000 burst 666 probability 0.02 bandwidth 10000000
tc class add dev eth2 parent 2:1 classid 2:5 htb rate 64000bps ceil
128000bps
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
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


Ficheiros de configuração dos fluxos no emissor:

FIFO

Caso 1

START NOW
1000 10 ON 30001 1.1.2.100:10001 CONSTANT 750 1000
30000 20 ON 30002 1.1.2.100:10001 CONSTANT 750 1000
61000 10 OFF
61000 20 OFF




                                                                       40
Caso 2

START NOW
1000 10 ON 3001 1.1.1.100:10001 CONSTANT 95 1000
1000 20 ON 3002 1.1.1.100:10002 CONSTANT 95 1000
TOS 10 0x0
TOS 20 0x10
61000 10 OFF
61000 20 OFF

Caso 3


netperf -H 1.1.2.100 -l 60

e

netperf -H 1.1.2.100 -l 60



SFQ

Caso 1

START NOW
1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1250 1000
1000 20 ON 3002 1.1.2.100:10001 CONSTANT 2500 1000
61000 10 OFF
61000 20 OFF


Caso 2

START NOW
1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1250 1000
61000 10 OFF

e

netperf -H 1.1.2.100 -l 60

RED

#!/bin/sh
for ((i=0; i<10; i++))
do
      netperf -H 1.1.2.100 -l 1 &
done




                                                     41
TBF

START NOW
1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1500 1000
61000 10 OFF


PRIO

Caso 1

START NOW
1000 10 ON 3001 1.1.2.100:10001 CONSTANT 18 1000
1000 20 ON 3002 1.1.2.100:10001 CONSTANT 10 1000
1000 30 ON 3003 1.1.2.100:10001 CONSTANT 125 1000
TOS 10 0x10
TOS 20 0x04
TOS 30 0x0
61000 10 OFF
61000 20 OFF
61000 30 OFF

Caso 2

START NOW
1000 10 ON 3001 1.1.2.100:10001 CONSTANT 470 1000
1000 20 ON 3002 1.1.2.100:10001 CONSTANT 310 1000
1000 30 ON 3003 1.1.2.100:10001 CONSTANT 1250 1000
TOS 10 0x10
TOS 20 0x04
TOS 30 0x0
61000 10 OFF
61000 20 OFF
61000 30 OFF

Caso 3

START NOW
1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1500 1000
1000 20 ON 3002 1.1.2.100:10001 CONSTANT 375 1000
1000 30 ON 3003 1.1.2.100:10001 CONSTANT 1000 1000
TOS 10 0x10
TOS 20 0x04
TOS 30 0x0
61000 10 OFF
61000 20 OFF
61000 30 OFF




                                                     42
HTB

START NOW
1000 10 ON 30001   1.1.2.100:10001   CONSTANT   200 1000
1000 20 ON 30002   1.1.2.100:10001   CONSTANT   200 1000
1000 30 ON 30003   1.1.2.100:10001   CONSTANT   2000 1000
1000 40 ON 30004   1.1.2.100:10001   CONSTANT   4000 1000
TOS 10 0x10
TOS 20 0x10
TOS 30 0x04
31000 10 OFF
31000 20 OFF
31000 30 OFF
31000 40 OFF


e

netperf -H 1.1.2.100 -l 60




                                                            43

Mais conteúdo relacionado

Mais procurados (8)

Comunicação de Dados Sem Fio Utilizando Técnica de Espalhamento de Espectro p...
Comunicação de Dados Sem Fio Utilizando Técnica de Espalhamento de Espectro p...Comunicação de Dados Sem Fio Utilizando Técnica de Espalhamento de Espectro p...
Comunicação de Dados Sem Fio Utilizando Técnica de Espalhamento de Espectro p...
 
HornetQ - 11.Mensagens Expiradas
HornetQ - 11.Mensagens ExpiradasHornetQ - 11.Mensagens Expiradas
HornetQ - 11.Mensagens Expiradas
 
R&C 0301 07 1
R&C 0301 07 1R&C 0301 07 1
R&C 0301 07 1
 
Redes Industriais 30h
Redes Industriais 30hRedes Industriais 30h
Redes Industriais 30h
 
Aula 1
Aula 1Aula 1
Aula 1
 
O sistema mais eficiente e confiável para integrar o alto tráfego da comunica...
O sistema mais eficiente e confiável para integrar o alto tráfego da comunica...O sistema mais eficiente e confiável para integrar o alto tráfego da comunica...
O sistema mais eficiente e confiável para integrar o alto tráfego da comunica...
 
Protocolos
ProtocolosProtocolos
Protocolos
 
Evolução protocolo rdt
Evolução protocolo rdtEvolução protocolo rdt
Evolução protocolo rdt
 

Destaque (6)

Ryan Bierl Mae377 Project02
Ryan Bierl Mae377 Project02Ryan Bierl Mae377 Project02
Ryan Bierl Mae377 Project02
 
Контур-Отчет ПФ
Контур-Отчет ПФКонтур-Отчет ПФ
Контур-Отчет ПФ
 
CIV
CIVCIV
CIV
 
Multicast on Cisco Network
Multicast on Cisco NetworkMulticast on Cisco Network
Multicast on Cisco Network
 
Body Area Networks
Body Area NetworksBody Area Networks
Body Area Networks
 
Ambient Talk
Ambient TalkAmbient Talk
Ambient Talk
 

Semelhante a Quality of Service and Linux

Analisadores de protocolo: comparação e uso
Analisadores de protocolo: comparação e usoAnalisadores de protocolo: comparação e uso
Analisadores de protocolo: comparação e uso
Jerônimo Medina Madruga
 
Mecanismos de segurança linux
Mecanismos de segurança linuxMecanismos de segurança linux
Mecanismos de segurança linux
Allan Reis
 
Firewall baseado em pacotes
Firewall baseado em pacotesFirewall baseado em pacotes
Firewall baseado em pacotes
eusouloko
 
Firewall baseado em_pacotes
Firewall baseado em_pacotesFirewall baseado em_pacotes
Firewall baseado em_pacotes
eusouloko
 
Aula 03 - Analisando objetivos técnicos - Projeto de Redes de Computadores
Aula 03 - Analisando objetivos técnicos - Projeto de Redes de ComputadoresAula 03 - Analisando objetivos técnicos - Projeto de Redes de Computadores
Aula 03 - Analisando objetivos técnicos - Projeto de Redes de Computadores
Dalton Martins
 
Segurança na Interoperabilidade de Redes TCP IP
Segurança na  Interoperabilidade de Redes TCP IPSegurança na  Interoperabilidade de Redes TCP IP
Segurança na Interoperabilidade de Redes TCP IP
Bruno Milani
 
Metodos de transmissao_contencao
Metodos de transmissao_contencaoMetodos de transmissao_contencao
Metodos de transmissao_contencao
Andressa Silveira
 

Semelhante a Quality of Service and Linux (20)

Congestionamento
CongestionamentoCongestionamento
Congestionamento
 
Analisadores de protocolo: comparação e uso
Analisadores de protocolo: comparação e usoAnalisadores de protocolo: comparação e uso
Analisadores de protocolo: comparação e uso
 
Redes4
Redes4Redes4
Redes4
 
Mecanismos de segurança linux
Mecanismos de segurança linuxMecanismos de segurança linux
Mecanismos de segurança linux
 
Frame Relay
Frame RelayFrame Relay
Frame Relay
 
TradeTech Brazil 2011 - O Desafio Da Latencia
TradeTech Brazil 2011 - O Desafio Da LatenciaTradeTech Brazil 2011 - O Desafio Da Latencia
TradeTech Brazil 2011 - O Desafio Da Latencia
 
Firewall baseado em pacotes
Firewall baseado em pacotesFirewall baseado em pacotes
Firewall baseado em pacotes
 
Firewall baseado em_pacotes
Firewall baseado em_pacotesFirewall baseado em_pacotes
Firewall baseado em_pacotes
 
Aula 03 - Analisando objetivos técnicos - Projeto de Redes de Computadores
Aula 03 - Analisando objetivos técnicos - Projeto de Redes de ComputadoresAula 03 - Analisando objetivos técnicos - Projeto de Redes de Computadores
Aula 03 - Analisando objetivos técnicos - Projeto de Redes de Computadores
 
Rui simao
Rui simaoRui simao
Rui simao
 
Segurança na Interoperabilidade de Redes TCP IP
Segurança na  Interoperabilidade de Redes TCP IPSegurança na  Interoperabilidade de Redes TCP IP
Segurança na Interoperabilidade de Redes TCP IP
 
Intro redes
Intro redesIntro redes
Intro redes
 
Metodos de transmissao_contencao
Metodos de transmissao_contencaoMetodos de transmissao_contencao
Metodos de transmissao_contencao
 
Noções de informática GranCursos.pdf
Noções de informática GranCursos.pdfNoções de informática GranCursos.pdf
Noções de informática GranCursos.pdf
 
Analysis of the GNS3 as a teaching tool by simulated networks
Analysis of the GNS3 as a teaching tool by simulated networksAnalysis of the GNS3 as a teaching tool by simulated networks
Analysis of the GNS3 as a teaching tool by simulated networks
 
02 - Aplicação-Transporte.pdf
02 - Aplicação-Transporte.pdf02 - Aplicação-Transporte.pdf
02 - Aplicação-Transporte.pdf
 
Artigo Atividade 1 Gredes
Artigo Atividade 1 GredesArtigo Atividade 1 Gredes
Artigo Atividade 1 Gredes
 
Open vpn
Open vpnOpen vpn
Open vpn
 
Planejamento rede
Planejamento rede Planejamento rede
Planejamento rede
 
Redes de Computadores Capítulo 6 - Camada de Transporte
Redes de Computadores Capítulo 6 - Camada de TransporteRedes de Computadores Capítulo 6 - Camada de Transporte
Redes de Computadores Capítulo 6 - Camada de Transporte
 

Último

ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024
ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024
ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024
azulassessoria9
 
1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf
1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf
1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf
aulasgege
 

Último (20)

Quando a escola é de vidro, de Ruth Rocha
Quando a escola é de vidro, de Ruth RochaQuando a escola é de vidro, de Ruth Rocha
Quando a escola é de vidro, de Ruth Rocha
 
Prova nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptx
Prova nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptxProva nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptx
Prova nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptx
 
MESTRES DA CULTURA DE ASSARÉ Prof. Francisco Leite.pdf
MESTRES DA CULTURA DE ASSARÉ Prof. Francisco Leite.pdfMESTRES DA CULTURA DE ASSARÉ Prof. Francisco Leite.pdf
MESTRES DA CULTURA DE ASSARÉ Prof. Francisco Leite.pdf
 
QUESTÃO 4 Os estudos das competências pessoais é de extrema importância, pr...
QUESTÃO 4   Os estudos das competências pessoais é de extrema importância, pr...QUESTÃO 4   Os estudos das competências pessoais é de extrema importância, pr...
QUESTÃO 4 Os estudos das competências pessoais é de extrema importância, pr...
 
Periodo da escravidAo O Brasil tem seu corpo na América e sua alma na África
Periodo da escravidAo O Brasil tem seu corpo na América e sua alma na ÁfricaPeriodo da escravidAo O Brasil tem seu corpo na América e sua alma na África
Periodo da escravidAo O Brasil tem seu corpo na América e sua alma na África
 
13_mch9_hormonal.pptx............................
13_mch9_hormonal.pptx............................13_mch9_hormonal.pptx............................
13_mch9_hormonal.pptx............................
 
CATEQUESE primeiro ano . CATEQUESE 1ºano
CATEQUESE primeiro ano . CATEQUESE 1ºanoCATEQUESE primeiro ano . CATEQUESE 1ºano
CATEQUESE primeiro ano . CATEQUESE 1ºano
 
Química-ensino médio ESTEQUIOMETRIA.pptx
Química-ensino médio ESTEQUIOMETRIA.pptxQuímica-ensino médio ESTEQUIOMETRIA.pptx
Química-ensino médio ESTEQUIOMETRIA.pptx
 
ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024
ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024
ATIVIDADE 3 - DESENVOLVIMENTO E APRENDIZAGEM MOTORA - 52_2024
 
Acróstico - Maio Laranja
Acróstico  - Maio Laranja Acróstico  - Maio Laranja
Acróstico - Maio Laranja
 
Tema de redação - A prática do catfish e seus perigos.pdf
Tema de redação - A prática do catfish e seus perigos.pdfTema de redação - A prática do catfish e seus perigos.pdf
Tema de redação - A prática do catfish e seus perigos.pdf
 
1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf
1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf
1. Aula de sociologia - 1º Ano - Émile Durkheim.pdf
 
Histogramas.pptx...............................
Histogramas.pptx...............................Histogramas.pptx...............................
Histogramas.pptx...............................
 
Religiosidade de Assaré - Prof. Francisco Leite
Religiosidade de Assaré - Prof. Francisco LeiteReligiosidade de Assaré - Prof. Francisco Leite
Religiosidade de Assaré - Prof. Francisco Leite
 
ESPANHOL PARA O ENEM (2).pdf questões da prova
ESPANHOL PARA O ENEM (2).pdf questões da provaESPANHOL PARA O ENEM (2).pdf questões da prova
ESPANHOL PARA O ENEM (2).pdf questões da prova
 
Edital do processo seletivo para contratação de agentes de saúde em Floresta, PE
Edital do processo seletivo para contratação de agentes de saúde em Floresta, PEEdital do processo seletivo para contratação de agentes de saúde em Floresta, PE
Edital do processo seletivo para contratação de agentes de saúde em Floresta, PE
 
Currículo Professor Pablo Ortellado - Universidade de São Paulo
Currículo Professor Pablo Ortellado - Universidade de São PauloCurrículo Professor Pablo Ortellado - Universidade de São Paulo
Currículo Professor Pablo Ortellado - Universidade de São Paulo
 
Maio Laranja - Combate à violência sexual contra crianças e adolescentes
Maio Laranja - Combate à violência sexual contra crianças e adolescentesMaio Laranja - Combate à violência sexual contra crianças e adolescentes
Maio Laranja - Combate à violência sexual contra crianças e adolescentes
 
425416820-Testes-7º-Ano-Leandro-Rei-Da-Heliria-Com-Solucoes.pdf
425416820-Testes-7º-Ano-Leandro-Rei-Da-Heliria-Com-Solucoes.pdf425416820-Testes-7º-Ano-Leandro-Rei-Da-Heliria-Com-Solucoes.pdf
425416820-Testes-7º-Ano-Leandro-Rei-Da-Heliria-Com-Solucoes.pdf
 
Apresentação | Símbolos e Valores da União Europeia
Apresentação | Símbolos e Valores da União EuropeiaApresentação | Símbolos e Valores da União Europeia
Apresentação | Símbolos e Valores da União Europeia
 

Quality of Service and Linux

  • 1. MECANISMOS DE ESCALONAMENTO Bernardo Pina Filipe Cunha Pedro Fernandes Departamento de Ciências de Computadores
  • 2. Índice INTRODUÇÃO................................................................................................................................. 3 MECANISMOS DE ESCALONAMENTO ............................................................................................. 5 INTRODUÇÃO AO LABORATÓRIO ................................................................................................. 18 CONTROLO DE TRAFEGO EM LINUX ...................................................................................... 18 MECANISMOS DE ESCALONAMENTO E LINUX....................................................................... 19 SOFTWARE NECESSÁRIO .......................................................................................................... 20 NETWORK TIME PROTOCOL (NTP) ........................................................................................ 20 RUDE e CRUDE ..................................................................................................................... 20 NETPERF e NETSERVER ......................................................................................................... 22 TRAFFIC CONTROL NEXT GENERATION (TCNG) ..................................................................... 22 TRAFFIC CONTROL (tc) .......................................................................................................... 24 LABORATÓRIO ............................................................................................................................. 25 MECANISMOS CLASSLESS ......................................................................................................... 25 FIFO ..................................................................................................................................... 25 SFQ ...................................................................................................................................... 27 RED ...................................................................................................................................... 29 TBF ....................................................................................................................................... 30 MECANISMOS CLASSFULLL ....................................................................................................... 31 PRIO ..................................................................................................................................... 31 HTB ...................................................................................................................................... 34 Notas Finais.......................................................................................................................... 35 CONCLUSÃO ................................................................................................................................ 36 BIBLIOGRAFIA .............................................................................................................................. 37 ANEXOS ....................................................................................................................................... 38 2
  • 3. INTRODUÇÃO Um “router” é um equipamento usado para fazer a comunicação entre diferentes redes de computadores permitindo a comunicação entre computadores. Esses equipamentos contêm um conjunto de sistemas e mecanismos de escalonamento através dos quais os pacotes são enviados e recebidos, ao qual chamamos controlo de tráfego. Esse controlo 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 debito, na saída de uma interface. O controlo de tráfego fornece a possibilidade de tratar pacotes de forma diferente, baseando-se nos atributos dos pacotes. As situações mais frequentes que requerem um controlo de tráfego são as seguintes: Limitar a largura de banda total a uma determinada taxa ou a largura de banda que um determinado utilizador, serviço ou aplicação cliente pode utilizar. Distribuir a largura de banda de forma equitativa por diferentes fluxos de tráfego. Reservar largura de banda para uma determinada aplicação ou utilizador e dar prioridade a tráfego sensível. Maximizar o throughtput, ou seja a quantidade de dados transferidos de um ponto para outro durante um determinado período de tempo, do TCP de forma a dar prioridade à transmissão de pacotes ACK. Assegurar que determinado tipo de tráfego não passa num router. A alguns anos atrás não havia uma preocupação excessiva de como os pacotes eram transmitidos. Pouco importava se eles chegavam ao seu destino. Actualmente, com o surgimento de aplicações como voz sobre IP e videoconferência, tais preocupações existem e são necessárias, pois este tipo de aplicações necessitam de uma garantia de que os pacotes serão transferidos de forma correcta aos seus destinatários. A Qualidade de Serviço, QoS, como já diz o nome, refere-se à garantia de um serviço de qualidade. É um requisito das aplicações para as quais exige-se que determinados parâmetros (atrasos, jitter, perdas, ...) estejam dentro de limites bem definidos (valor mínimo, valor máximo). O termo é aplicado com frequência às aplicações de telecomunicações e redes de computadores, recebendo uma definição específica para cada. Nas telecomunicações, Qualidade de Serviço significa oferecer uma boa qualidade de voz, reduzir os ecos, etc. Nas aplicações de informática, Qualidade de Serviço significa garantir uma transmissão eficiente de pacotes através da implantação de sistemas de prioridade ou controle de banda. Alguns dos problemas que podem acontecer na transmissão de pacotes são: Atraso ou latência: É a medida do tempo decorrido entre o início de uma actividade e a sua conclusão. Os atrasos podem acontecer quando pacotes tomam caminhos alternativos para evitar congestionamentos ou quando enfrentam filas de espera. Jitter: É a variação na latência com que os pacotes atingem o seu destino final. A sua causa é o processamento com tempo variável nos equipamentos de rede. 3
  • 4. Perda de pacotes: Pode acontecer quando pacotes são descartados quando há muito congestionamento na rede. O uso de VoIP não é tolerante a perda de pacotes: perdas mínimas como 1%, por exemplo, podem degradar uma chamada, provocando erros audíveis nesta. Entrega desordenada: Ocorre frequentemente a entrega de pacotes numa ordem diferente da que foram enviados, uma vez que estes podem ser enviados por diferentes rotas, o que provoca a exigência de protocolos especiais para que a informação possa ser reconstruída à chegada. Erros: Também pode ocorrer que os pacotes sejam enviados para destinos errados, ou misturados, ou mesmo serem corrompidos. O receptor terá então que detectá-lo e, tal como se o pacote tivesse sido descartado, pedir a retransmissão. Existem, essencialmente, duas formas de oferecer garantias QoS. A primeira procura oferecer bastantes recursos, suficientes para o pico esperado, com uma margem de segurança substancial. É simples e eficaz, mas na prática é assumido como dispendioso, e tende a ser ineficaz se o valor de pico aumentar além do previsto: reservar recursos gasta tempo. O segundo método é o de obrigar os utilizadores a reservar os recursos, e apenas aceitar as reservas se os routers conseguirem servi-las com confiabilidade. Naturalmente, as reservas podem ter um custo monetário associado! As duas variações mais conhecidas são o IntServ (Integrated Services ou Serviços Integrados) e o DiffServ (Differentiated Services ou Serviços Diferenciados). Do ponto de vista teórico serão apresentado diversos algoritmos de escalonamento usados no controlo de tráfego bem como as suas principais características.Sob um ponto de vista mais prático serão realizados um conjunto de testes de forma a tentar representar o maior número possível de utilizações reais dos respectivos mecanismos de escalonamento e as suas influências nas condições da rede. 4
  • 5. MECANISMOS DE ESCALONAMENTO Os mecanismos de escalonamento são algoritmos que geram 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). Sem estes mecanismos, uma fila de espera não permite fazer qualquer tipo de controlo de tráfego. Uma 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. Os mecanismos de classificação de pacotes marcam os pacotes de acordo com regras de distinguir e isolar o tráfego em diferentes fluxos para os processar individualmente e garantir assim um tratamento diferentes pa diferentes tipos de dados. Existem vários conjuntos de mecanismos de classificação de pacotes, entre os quais: • fw: Baseia a sua decisão na forma como a firewall marca os pacotes. • u32: Baseia a sua decisão nos campos contidos nos pacotes. • route: Baseia a decisão na rota que o pacote irá tomar. • rsvp: Efectua a decisão baseada em rotas rsvp. Existem dois principais mecanismos, classless e classfulll. Os mecanismos classless são simples pois possuem apenas uma classe. Com isso, não há a possibilidade de realizar a divisão de diferentes tráfegos. Podemos citar os seguintes mecanismos classless: • FIFO (First In First Out) • PFIFO Fast (Packet First In First Out Fast - default no Kernel Linux) • SFQ (Stochastic Fair Queuing) • RED (Random Early Detection) • TBF (Token Bucket Filter) • WFQ (Weighted Fairness Queuing) Os mecanismos classfulll são mais eficientes e permitem a divisão do tráfego, priorizando cada tipo de conexão de acordo com as configurações utilizadas pelo administrador da rede. Podemos citar os seguintes mecanismos classfull: • CBQ (Class Based Queueing) • HTB (Hierarchy Token Bucket) • PRIO (Priority class) Atualmente, a melhor alternativa para o controle do tráfego é a associação do HTB com o PRIO. Classless (Sem classes): 5
  • 6. Estes mecanismos tratam o tráfego sem nenhuma diferenciação entre tipos de pacotes, ou seja, todos os fluxos são processados de igual maneira. FIFO – First In First Out É o mais simples mecanismo de escalonamento de pacotes onde estes são tratados de igual maneira, sendo colocados numa fila única e servidos por ordem de chegada. Não permite diferenciação por tipos de fluxos. À medida que os pacotes entram na fila da interface de entrada, eles são colocados na fila da interface de saída na mesma ordem que foram recebidos. As figuras abaixo ilustram duas representações do funcionamento de um mecanismo FIFO. 6
  • 7. As suas principais vantagens são: O seu comportamento é previsível, dado que os pacotes não são reordenados e o atraso máximo é correspondente ao tamanho da fila de espera. Em routers baseados em software este algoritmo não sobrecarrega as máquinas. Fornece um método de contenção simples para os recursos da rede enquanto o tamanho da fila permanecer curto. No entanto existem várias limitações: Uma única fila FIFO não permite a organização de pacotes em diferentes categorias. As aplicações que usam UDP são favorecidas relativamente às que usam TCP em períodos de congestão de rede. O impacto do atraso influência de forma idêntica todos os fluxos. Um fluxo “mal comportado” pode consumir todo o espaço de memória de uma fila de espera FIFO. A consequência destas limitações causam um aumento do atraso, do jitter(variação do atraso sofrido por um pacote) e perdas para todos os outros fluxos UDP e TCP. Quando a rede IP opera sem sobrecarga, as filas são necessárias somente para assegurar que os pacotes sejam descartados quando existe uma sucessão rápida, ininterrupta e de curta duração de tráfego de dados. Nessa situação, este mecanismo é altamente eficiente, na medida em que o tamanho da fila permanece pequeno. Entretanto, quando a carga da rede aumenta, o tráfego rápido causa um atraso significativo de colocação na fila em relação ao atraso da transmissão total e, quando a fila está totalmente cheia, todos os pacotes subsequentes são descartados. Se a fila opera deste modo por longo período, a qualidade do serviço inevitavelmente se degradará. Portanto, pode-se apontar como principal deficiência deste algoritmo o facto deste usar a ordem de chegada dos pacotes para determinar a prioridade destes. Ainda assim, o FIFO é o mecanismo de escalonamento utilizado por defeito no Linux e na maioria dos routers, devido à sua simplicidade e eficiência. 7
  • 8. SFQ – Stochastic Fairness Queueing Este algoritmo foi desenhado para assegurar que cada fluxo tem um acesso “justo” aos recursos da rede, evitando que um fluxo “mal-comportado” consuma mais do que a sua quota de largura de banda. Os pacotes são classificados através de diferentes 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 de implementações mais sofisticadas o acrescento do tipo de protocolo ao tuplo) 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. O SFQ utiliza uma função de hash para dividir os fluxos pois não é prático haver uma fila para cada categoria de pacotes. Sendo assim, 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. Para prevenir esta situação a função é trocada periodicamente, aumentando a “justiça” do algoritmo. Este algoritmo tem como vantagem uma configuração extremamente intuitiva e simples. Permite um acesso justo aos recursos da rede e apenas pode ser utilizado em situações que não requeiram diferenciação, implementado quando se quer assegurar o mesmo acesso a vários clientes. 8
  • 9. RED – Random Early Detection O mecanismo de escalonamento RED foi criado com o objectivo de prevenir o lock-out e full-queues que são dois graves problemas que ocorrem na implementação de um mecanismo FIFO. O lock-out acontece devido a efeitos de timing, o que resulta no facto de os pacotes de alguns fluxos encontrarem a fila de espera cheia. Resumindo, os primeiros pacotes que chegam à fila irão encontrar a fila ainda com capacidade de serviço, enquanto que os que chegarem a seguir irão ser descartados.O full-queues são listas de espera que estão na grande maioria do tempo ocupadas ao máximo. O RED fornece, o mais rapidamente possível, uma resposta a fluxos que implementem congestão 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 pacotes descartados 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, comparando dois limiares (threshold), um mínimo e um máximo. Quando o tamanho médio da fila é inferior ao limiar mínimo, nenhum pacote é marcado. Se o tamanho for superior ao limiar máximo, todos os pacotes que chegam são marcados.Entre estes dois valores cada pacote é marcado com probabilidade pa. O RED tem 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; o 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. Existem três “modos” de descarte de pacotes: • Sendo o tamanho médio da fila de espera inferior ao limiar mínimo, não existe congestão, logo nenhuma acção é tomada. A probabilidade de descarte de pacotes vai ser 0. • Sendo 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 de rede – a grande maioria dos pacotes que chegam à fila vão ser descartados. A probabilidade de descarte será muito próxima de 1. 9
  • 10. Por último, 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. O cálculo do tamanho médio da fila de espera é determinado usando um filtro que não é mais do que a função Exponential Weighted Moving Average (EWMA). No caso de marcação dos pacotes, a probabilidade de um pacote de uma determinada ligação ser marcado é directamente proporcional à percentagem de largura de banda ocupada pela ligação no router. E mais, assegura que o tamanho médio da fila de espera não excede significativamente o limiar máximo definido. Resumindo, a grande vantagem deste algoritmo é permitir um melhor serviço ao protocolo TCP e de impedir a ocupação excessiva das filas por pequenos fluxos. 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 pois introduz um tópico importante, útil e utilizado muito frequentemente com os mecanismos de escalonamento – traffic shaping. Para controlar a taxa de envio de pacotes uma opção de implementação é contar o número de pacotes ou bytes que vão sendo enviados – 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. Explicando o algoritmo, é 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. Associando este algoritmo com os dois fluxos – token e dados, são estes os três possíveis cenários: • Os dados chegam à TBF a uma taxa que é igual à taxa de tokens que entram. Neste caso, cada pacote que entra possui um token correspondente e o mesmo é passado à fila sem qualquer atraso. • Os dados chegam à TBF a uma taxa que é menor que a taxa de tokens. Somente uma parte dos tokens são removidos na saída de cada pacote de dados que é enviado à fila, assim as ficham vão-se acumulando, até ao tamanho do bucket. Os tokens não utilizados podem então ser usados para enviar os dados a uma velocidade que pode exceder à taxa do token padrão, nesse casso ocorrem “rajadas” curtas de dados. • Os dados chegam à TBF a uma taxa maior que a taxa de tokens. Isso significa que o bucket ficará brevemente sem tokens, o que fará com que a TBF boqueie momentaneamente. Isso é normalmente designado por “overlimit situation”. Se os pacotes continuarem a entrar, então estes começam a ser descartados. 10
  • 11. O último cenário é muito importante pois permite regular administrativamente a banda disponível para os dados que estão a passar pelo filtro. A figura abaixo ilustra o funcionamento deste tipo de mecanismo. Entre as principais vantagens deste algoritmo, conta-se o facto de ser simples e eficaz, sem grandes requisitos em termos de complexidade computacional. É utilizado frequentemente para controlar a taxa máxima dedicada a uma determinada ligação ou fluxo. WFQ – Weighted Fairness Queueing Este algoritmo permite que cada fila do buffer tenha uma mesma quantidade de bytes extraída e direccionada para a fila da interface de saída do dispositivo de rede. Isto torna mais “justo” o escalonamento desses pacotes de dados e, consequentemente, uma igualdade no fornecimento dos diferentes serviços. Assegura que cada fluxo tem um acesso justo aos recursos 11
  • 12. da rede, prevenindo que os fluxos mal comportados consumam mais do que a largura de banda que lhes é atribuída. Para determinar a ordem de entrada na fila dos pacotes, este algoritmo utiliza pesos para esse propósito e é necessário que cada pacote seja diferenciado quanto ao seu nível de prioridade. Portanto, o WFQ analisa o campo Prioridade (Precedence) do cabeçalho do pacote de IP a fim de atribuir um determinado peso a esse pacote. Esse campo contém uma prioridade que varia de 0 (normal) a 7 (pacote de controlo de rede). Quanto maior for o nível (valor) de prioridade menor é o valor do peso atribuído a esse pacote. Assim, os pacotes com pesos baixos são escalonados primeiro, ou seja, garantem ao fluxo desses pacotes um tempo de resposta mais imediato, tornando este algoritmo mais adaptado às mudanças nas condições de tráfego da rede. Utiliza uma função de hash juntamente com parâmetros de classificação para atribuir um pacote a uma fila, tal como o SFQ.Assim, quanto maior for o número de filas, melhor é o funcionamento do algoritmo. É um mecanismo eficiente pois pode-se utilizar toda a largura de banda disponível para transmitir o tráfego de baixa prioridade se não existir tráfego de alta prioridade. A figura abaixo ilustra o funcionamento do algoritmo WFQ. Como principais vantagens, o WFQ 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 tipo de pacotes. Classfulll (Com classes): Os escalonadores Classfulll utilizam mecanismos de classificação de pacotes para dividir os vários fluxos em classes, de forma a servir de forma diferente cada tipo de fluxo. 12
  • 13. CBQ – Class Based Queueing Este algoritmo foi projectado para permitir que várias aplicações, com especificações de largura de banda mínima ou de exigências de atrasos, compartilhem a rede. É uma variação de colocação em filas por prioridades, pois o buffer pode ser dividido em várias filas com diferentes níveis de preferência (classes). Entretanto, este algoritmo permite definir a quantidade de bytes de dados que deve ser retirada de cada fila do buffer para a fila da interface de saída do dispositivo de rede. O CBQ é o mecanismo de escalonamento mais complexo existente actualmente. É constituído por dois escalonadores: um genérico e um 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 de partilha de ligação 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. A figura abaixo ilustra o funcionamento deste algoritmo. Como vantagens tem 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, entre as quais: a necessidade de ser preciso saber a largura de banda do link, fica “confuso” com tamanho 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. 13
  • 14. HTB – Hierarchy Token Bucket Hierarchic Token Buckets (HTB) é uma alternativa mais eficaz que o mecanismo CBQ. Implementa um escalonador classfulll 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 “ceil”). 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. Como o próprio nome indica, o algoritmo faz uma partilha hierárquica de uma ligação e como tal deve respeitar as seguintes regras: Cada classe inferior 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 inferiores 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. A figura abaixo ilustra a estrutura de classes do algoritmo HTB. 14
  • 15. Assim, o HTB assegura que a quantidade de serviço fornecida a cada classe e, no mínimo, a quantidade que esta pede, e no máximo o tecto. Quando uma classe pede 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. Uma parte fundamental do escalonador HTB é o mecanismo de borrowing (empréstimo). Na tabela seguinte podemos observar o que acontece em cada caso, assim como as acções tomadas. 15
  • 16. Para evitar que haja empréstimo de largura de banda - o que pode ser necessário, 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 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 classfulll. PRIO – Priority Class Este algoritmo foi projectado para dar uma maior prioridade ao tráfego de dados nas filas de espera que exigem uma certa urgência de processamento. Este algoritmo é baseado no conceito que certos tipos de tráfegos podem ser identificados e colocados à frente na fila de saída e desta forma transmitidos primeiro que outros tráfegos. A forma como o tráfego de dados pode ser classificado na interface de rede de um dispositivo de rede é bastante flexível. Esta classificação pode ser feita de acordo com o protocolo de rede (Internet Protocol, Internetwork Packet Exchange, Apple Talk) que está a ser utilizado no pacote de dados, no tamanho destes pacotes (quantidades de bytes), no endereço IP de origem e de destino. Cada pacote pode ser classificado em quatros níveis de prioridades: alto, médio, normal e baixo. A figura abaixo mostra os pacotes de dados a seres colocados nas respectivas filas de acordo com a classificação dada a cada pacote na interface de entrada de um dispositivo de rede. Em seguida esses pacotes são colocados na fila de saída de acordo com os seus níveis de prioridades. O PRIO tem a vantagem de ser a forma mais simples de implementar a diferenciação de tipo de pacotes. Por outro lado, tem a desvantagem: no caso de não existir nenhum mecanismo de 16
  • 17. controlo 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 menos 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. 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: • 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-fillho, 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 ligacão com largura de banda váriavel 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 traffic-shaping. 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,emule entre outros. 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 Classfulll com TBF (Token Bucket Filter) para fazer traffic- shapping. • Partilhar ou 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 Classfulll com N classes - uma para cada IP. 17
  • 18. INTRODUÇÃO AO LABORATÓRIO Neste trabalho foram utilizados três computadores, todos eles com sistema operativo Linux: um a servir de router, um como gerador de fluxo e outro como receptor do mesmo. No router utilizaram-se duas placas de rede: Placa Ethernet de 10Mbps à entrada Placa Ethernet de 10Mbps à saída O router possuía o sistema operativo Linux Mandriva 2009.0 (Free) com Kernel 2.6.27.14. Tanto no gerador como no receptor de fluxos, utilizamos placas Ethernet de 10 Mbps. Todos os interfaces de rede estavam configurados com mecanismo de escalonamento FIFO (pfifo_fast) com excepção da porta de saída do router, que foi alvo das configurações pretendidas para efeito de teste. Figura 1: Esquema da rede montada CONTROLO DE TRAFEGO EM LINUX Cada interface de rede em Linux é controlada por um driver que controla o hardware. Esse driver funciona como um mecanismo de troca de pacotes entre a camada de rede e a rede física. Quando um pacote chega a uma máquina Linux é passado pelo interface de rede ao desmultiplexador que o examina e determina se é destinado a máquina local. Se for o caso, o pacote é enviado para as camadas acima. Caso contrário, é analisada a tabela de 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. 18
  • 19. Esse controlo de tráfego pode ser realizado em duas fases: no policiamento a entrada (ingress policing) nas filas de espera a saída (output queueing) No funcionamento de um router normal, os pacotes raramente passam acima da camada de rede, pelo que nenhum pacote é gerado ou consumido pela máquina. Todos os pacotes que passam pelo router ora são encaminhados ou descartados. MECANISMOS DE ESCALONAMENTO E LINUX Para que uma máquina Linux funcione como escalonador necessita de ter os respectivos módulos compilados directamente no kernel ou então carregados depois de o kernel estar compilado. Os módulos do Linux relativos aos mecanismos de escalonamento estão em /lib/modules/<versão kernel>/kernel/net/sched/ E possuem nomes com prefixo sch_. Os mecanismos disponíveis no router (PC) usado são: • First In First Out (FIFO) • Priority FIFO Fast (PFIFO-FAST) • Stochastic Fair Queuing (SFQ) • Random Early Detection (RED) • Generalized RED (GRED) • Token Bucket Filter (TBF) • Prioridade Estrita (PRIO) • Class Based Queueing (CBQ) • Hierarchical Token Bucket (HTB) • Clark-Shenker-Zhang (CSZ) • Diff-Serv Marker (DS MARK) • Traffic Equalizer (TEQL) Como optamos por carregar os módulos manualmente para a memória do kernel, tivemos que realizar o seguinte comando: bash# modprobe <nome dos mecanismos de escalonamento> Para se verificar se o módulo foi carregado com sucesso, basta ver se o mesmo se encontra listado no output do comando bash# lsmod 19
  • 20. SOFTWARE NECESSÁRIO NETWORK TIME PROTOCOL (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 tempo que existir entre as máquinas. Para o efeito, decidimos utilizar o NTP. A configuração do NTP e extremamente simples e directa. Tanto nos servidores como nos clientes, o ficheiro de configuração a utilizar é o /etc/ntp.conf O nosso router, como servidor NTP das restantes máquinas, teve de ser configurado colocando a seguinte linha no ficheiro supracitado: bash# server <IP interface Ethernet> nos clientes basta configurar adicionando a seguinte linha: bash# server <IP do servidor> As restantes opções de configuração dos ficheiros foram todas mantidas. Antes de executar o daemon do NTP é necessário efectuar duas sincronizações (pelo menos), recorrendo-se ao ntpdate da seguinte forma: bash# ntpdate <IP do servidor > para inicializar o NTP deve-se correr o daemon respectivo com o seguinte comando: bash# service ntpd start RUDE e CRUDE O rude (gerador de tráfego UDP) e o crude (receptor do tráfego UDP e gerador de estatísticas), no seu conjunto, formam uma aplicação interessante para avaliar os efeitos dos mecanismos do escalonamento nos fluxos de dados de uma rede. A escolha desta aplicação deveu-se a sua configuração ser simples e ao facto de fornecer dados significativos relativos aos fluxos no colector, tais como: 20
  • 21. Débito • Número de pacotes recebidos e perdidos • Atraso médio dos pacotes • Jitter médio • Jitter máximo Para instalar o rude sem problemas, bastou seguir os ficheiros de ajuda disponibilizados com a aplicação. Para gerarmos os fluxos pretendidos, é necessário elaborar um ficheiro de configuração com a seguinte estrutura: START NOW 1000 10 ON 3001 192.168.2.2:10001 CONSTANT 150 1000 TOS 10 0x10 61000 10 OFF De seguida faz-se a descrição de cada um dos parâmetros: • Linha 1: marca o inicio da configuração para um fluxo de dados • Linha 2: - 1000 - milissegundos aos quais o fluxo começa a ser transmitido - 10 - identificador do fluxo gerado - ON - indica o inicio do fluxo - 3001 - porta utilizada na máquina de origem - 192.168.2.2:1001 - ip e porta da máquina de destino - CONSTANT - tipo do fluxo gerado, no caso Constant Bit Rate - 150 - número de pacotes gerado por segundo - 1000 - 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 esta normalmente associado a tráfego interactivo. • Linha 4: indica que o fluxo deixa de ser transmitido aos 61000 milissegundos No que diz respeito à utilização, começamos por correr o receptor dos fluxos, para não se perderem pacotes enviados pelo emissor, o comando a utilizar foi: bash# crude -s <id do fluxo gerado pelo servidor> Por sua vez, após criado o ficheiro de configuração pretendido para o emissor, o comando a utilizar é: bash# rude -s <caminho para o ficheiro de configuração> Quando o emissor terminar o envio de pacotes, basta efectuar “control+c” no receptor para os resultados serem mostrados. O facto de nem o cliente nem o servidor gerarem output durante o decorrer dos testes e 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. 21
  • 22. NETPERF e NETSERVER Uma vez que o Rude não gera tráfego TCP, a aplicação que decidimos utilizar para o efeito foi o netperf. Esta aplicação baseia-se em dois executáveis : netperf e netserver. Quando executado o netperf (no emissor), é 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 (no receptor). Após o estabelecimento da ligação de controlo, uma ligação nova é estabelecida para a medição da performance . De seguida o teste é efectuado e os resultados são gerados. O netperf não gera nenhum tráfego para a ligação de controlo enquanto os testes estão a decorrer. Para este trabalho o netperf foi utilizado apenas para o seu teste por defeito: 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 receptor, bastou executar a aplicação netserver que fica a correr como daemon. Por sua vez, no emissor, basta utilizar o netperf da seguinte forma: bash# netperf -H <ip do receptor> -l <duração do teste> Com esta configuração simples, é efectuado um teste de l segundos entre o emissor e o receptor, da qual são geradas estatísticas, neste caso ,no emissor de tráfego. A estatística gerada contem, entre outros, os seguintes dados: taxa de transmissão conseguida e tempo decorrido. TRAFFIC CONTROL NEXT GENERATION (TCNG) 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 no tc ( traffic control). Configuração e utilização O TCNG utiliza uma linguagem de configuração semelhante às linguagens orientadas a objectos, compacta e simples. 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. 22
  • 23. • Exemplo 1: dev eth0 { egress { fifo (limit 100p ); } } De seguida, é feita a explicação das configurações apresentadas acima: Com este exemplo, associa-se os mecanismos de escalonamento FIFO com fila de espera de cem pacotes à interface de rede eth0. A palavra egress é um sinónimo para dsmark. • Exemplo 2: #include "fields.tc" #include "ports.tc" dev eth0 { egress { // classificacao 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. Esta configuração baseia-se em duas partes: 1. 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 23
  • 24. todos os pacotes que sobram. 2. 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. Depois da escrita dos ficheiros de configuração, o tcng (traffic control new generation) recebe como argumento esses ficheiros e gera scripts para configurar os mecanismos de escalonamento como pretendido. TRAFFIC CONTROL (tc) Sempre que nos foi possível, utilizamos TCNG para configurar os mecanismos de escalonamento. No entanto, esporadicamente utilizamos o TC ( apesar deste possuir uma sintaxe mais complexa e menos intuitiva) ,apenas por o TCNG não apresentar suporte para alguns mecanismos de escalonamento . 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âmetros> Uma outra utilidade do TC que utilizamos regularmente foi: bash# tc qdisc show Que serve para visualizar as varias interfaces, os mecanismos e parâmetros a elas associados. 24
  • 25. LABORATÓRIO Neste capítulo vamos apresentar os resultados obtidos no trabalho laboratorial efectuado. As configurações dos mecanismos de escalonamento (feitas no router) são apresentadas em anexo, assim como as configurações do rude e netperf para geração dos fluxos UDP e TCP. Todos fluxos UDP (bem como os TCP) usados têm a exacta duração de 60 segundos. MECANISMOS CLASSLESS Estes mecanismos tratam o tráfego sem nenhuma diferenciação entre tipos de pacotes, ou seja, todos os fluxos são processados de igual maneira. FIFO O FIFO é o mecanismo de escalonamento mais simples e consiste apenas numa fila de espera. Essa fila de espera pode ser quantificada por número de pacotes ou bytes. Caso 1 Objectivo Verificar como uma FIFO se comporta com dois fluxos UDP iguais. Método Dois fluxos UDP CBR iguais e sem ToS • Um fluxo 10 com 6Mbps • Um fluxo 20 com 6Mbps Configuramos no router uma FIFO com tamanho de 100 pacotes, para efeito de testes. Os resultados foram medidos no crude do receptor. 25
  • 26. Resultado Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio Recebidos perdidos de sequência (Mbps) 10 5.93297 0.011364 356076 123924 0 20 5.35858 0.011397 339894 124106 0 Tabela 1: Resultados UDP do Caso 1, FIFO Após vários testes chegamos a conclusão que o fluxo que entra primeiro na fila FIFO ganha sempre um valor de throughput médio ligeiramente superior e jitter inferior. Isto deve-se ao facto do primeiro fluxo ocupar primeiro a fila. Caso 2 Objectivo Este teste pretende verificar se o FIFO distingue fluxos pelo seu ToS Método Dois fluxos UDP CBR iguais e com ToS diferentes • Um fluxo 10 com ToS 0x0 e taxa de 750Kbps • Um fluxo 20 com ToS 0x10 e taxa de 750Kbps Os resultados foram medidos no crude do receptor. Resultado Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio (bps) Recebidos perdidos de sequência 10 750183 0.007914 45012 0 0 20 750183 0.007845 45012 0 0 Tabela 2: Resultados UDP do Caso 2, FIFO Através dos resultados obtidos podemos concluir que o FIFO não faz qualquer distinção entre fluxos com ToS diferentes. Caso 3 Objectivo Verificar, à semelhança do Caso 1, como se comporta o FIFO na presença de 2 fluxos TCP iguais. 26
  • 27. Método Dois fluxos TCP STREAM iguais e com a mesma duração. Os resultados foram medidos no netperf do emissor. Resultado Fluxo Throughput médio (Mbps) Elapsed time (s) Gerador TCP 1 4.543 60.16 Gerador TCP 2 4.883 60.42 Tabela 3: Resultados TCP do Caso 3, FIFO Conclui-se portanto que o comportamento é semelhante ao verificado no Caso 1, sendo que neste caso o throughput médio é um pouco mais semelhante entre os dois fluxos e no total mais equilibrada, tendo em conta o limite máximo da largura de banda (10Mbps). Isto prova que, mesmo num ambiente sem mecanismos de escalonamento ajustados para o acesso justo dos fluxos, os mecanismos próprios de controlo de congestão do TCP, acabam por funcionar perfeitamente. SFQ O SFQ tem como objectivo garantir o acesso “justo” de todos os fluxos. Os casos estudados foram idealizados tendo em vista demonstrar essa característica. Para analisarmos o SFQ configuramos o tc do router com SFQ e uma perturbação de hash a ser substituída de 5 em 5 segundos. Caso 1 Objectivo Com este caso pretende-se demonstrar o acesso “justo” que o SFQ preconiza. Método Dois fluxos UDP CBR iguais e sem ToS • Um fluxo 10 UDP com 10Mbps • Um fluxo 20 UDP com 20Mbps Os resultados foram medidos no crude do receptor. 27
  • 28. Resultado Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio recebidos perdidos de sequência (Mbps) 10 5.57085 0.068004 334273 265589 0 20 5.78023 0.023918 346836 852886 0 Tabela 4: Resultados do Caso 1, SFQ Analisando os resultados, chegamos a conclusão que o SFQ garante o acesso justo de fluxos, mesmo que os throughputs enviados inicialmente pelo gerador sejam muitos desiguais. Em situações normais o SFQ pode originar pacotes fora de sequência (é de resto o mecanismo que mais verifica esse fenómeno) no entanto isso acabou por não se verificar. Caso 2 Objectivo Este caso foi pensado com o objectivo de verificar como o TCP se comporta em conjunto com o UDP neste género de escalonamento. Método Um fluxo UDP CBR e um fluxo de TCP: • Um fluxo 10 UDP com 10Mbps • Um fluxo TCP STREAM de 60 segundos Os resultados foram medidos no crude do receptor e no netperf do emissor. Resultados Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio Recebidos perdidos de sequência (Mbps) 10 6.977 0.021110 418617 181384 52 Tabela 5: Resultados do UDP, Caso 2 SFQ Fluxo Throughput médio (Mbps) Elapsed time (s) TCP STREAM 4.612 60.15 Tabela 6: Resultados do TCP, Caso 2 SFQ Mais uma vez se verifica, que apesar de estarmos na presença de dois fluxos de géneros diferentes, o acesso é “justamente” garantido. Não havendo um que canibalize o outro. 28
  • 29. Neste caso 2, conseguimos verificar pacotes fora de sequência. Isto pode acontecer devido ao facto da função de hash usada para dividir os fluxos entre as diferentes filas, colocar pacotes pertencentes ao mesmo fluxo, em filas diferentes, logo servindo-os com ordem trocada. RED Caso 1 O RED tem como função evitar a sincronização global e executar congestion avoidance em ligações TCP. Objectivo Testarmos as propriedades deste mecanismo de escalonamento, sobre diversas fontes TCP. Método 10 fluxos de TCP STREAM com duração de um segundo cada. Decidimos configurar o router da seguinte forma: • Bandwith - 10000Kbps (largura de banda da ligação) • Probability - 0.02 (probabilidade do pacote ser marcado) • Burst - 666 (este parâmetro define quão rápido o tamanho médio da fila é influenciado pelo tamanho real da fila, deve calcular-se da seguinte forma:(min*2+max)/(3*avptk)) • Avpkt - 1000 • Max - 1000000 bytes (tamanho máximo da fila) • Min - 500000 bytes (tamanho médio da fila) • Limit - 8000000bytes (limite de dados na fila, a partir da qual são descartados) Resultados Número do fluxo Throughput médio (Mbps) Elapsed time 1 7.533 1.29 2 1.745 1.35 3 0.125 1.17 4 0.139 1.16 5 0.248 1.27 6 0.332 1.32 7 0.094 1.06 8 0.340 1.05 9 0.546 1.05 10 0.659 1.07 Tabela 7 : Resultados usando FIFO. 29
  • 30. Número do fluxo Throughput médio (Mbps) Elapsed time 1 8.528 1.31 2 0.224 1.23 3 0.720 1.35 4 0.162 1.18 5 0.247 1.25 6 0.137 1.10 7 0.230 1.06 8 0.268 1.04 9 1.278 1.17 10 1.658 1.12 Tabela 8 : Resultados usando RED. Estes resultados não foram os ideais para retirar conclusões. No entanto, podemos verificar algumas melhorias a nível de throughput médio, para as diferentes ligações, quando se utiliza o RED, o que prova, de alguma forma, que os efeitos de lock-out (quando um recurso é consumido excessivamente por um pequeno numero de fluxos) são minimizados. TBF O TBF é um “traffic-shapper” que é bastante interessante de analisar. O traffic-shapping é uma técnica bastante usada pelos operadores de forma a controlar a largura de banda das suas redes. Caso 1 Objectivo Analisar a influência do traffic shapping num fluxo normal. Método Um fluxo UDP CBR • fluxo 10 com 12MBps Configuramos o router com TBF da seguinte forma: • rate – 512kbps (débito pretendido para o fluxo) • burst – 40kB (tamanho do bucket) • limit – 40kB (numero de bytes que podem estar em fila de espera) • mtu – 1514B Os resultados foram medidos no crude do receptor. 30
  • 31. Resultado Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio (bps) Recebidos perdidos de sequência 10 489403 0.013736 29407 693466 0 Tabela 9 : Resultado do UDP, Caso 1 TBF Verificamos que o throughput médio foi muito aproximado ao configurado no TBF. Portanto, bastante longe do throughput esperado inicialmente. Fica assim provado que o TBF consegue de facto limitar o débito de um canal eficazmente. MECANISMOS CLASSFULLL Nos mecanismos classfulll de escalonamento, faz-se uso das chamadas classes, como já foi explicado anteriormente. Assim, nesta secção, utilizamos o mecanismo de classificação de pacotes Dsmark, com as classes seguintes: o Classe 1 – pacotes IP com ToS 0x10 o Classe 2 – pacotes IP com ToS 0x04 o Classe 3 – pacotes IP sem ToS definido o Classe TCP – pacotes IP com ToS 0x06 PRIO O PRIO é o mecanismo de escalonamento mais simples que faz uso de classes. Caso 1 Objectivo Observar que cada fluxo recebe o serviço configurado para a sua classe. Método Três fluxos UDP CBR com ToS diferentes: • fluxo 10 classe 1 de 150Kbps • fluxo 20 classe 2 de 75Kbps • fluxo 30 classe 3 de 1Mbps 31
  • 32. Configuramos o router com PRIO e em cada classe colocamos um TBF a fazer traffic- shapping da seguinte forma: • classe 1 com rate 128Kbps • classe 2 com rate 64Kbps • classe 3 com rate 32Kbps Os resultados foram medidos no crude do receptor. Resultados Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio (bps) Recebidos perdidos de sequência 10 122468 0.008114 7367 82720 0 20 61391.4 0.015070 3703 41307 0 30 30854.6 0.032758 1870 569310 0 Tabela 10 : Resultados do UDP, Caso 1 PRIO Observou-se então o previsto. Cada classe teve o seu fluxo limitado ao rate imposto pelo TBF. O PRIO permite-nos então ter várias classes com diferentes prioridades e ao mesmo tempo limitar o thoughput dessas classes. Caso 2 Objectivo Colocar FIFO em cada classe do PRIO, de forma a provar que o fluxo com classe 3 só ocupa a largura de banda deixada pelos fluxos de maior prioridade. Método Três fluxos UDP CBR com ToS diferentes: • fluxo 10 classe 1 de 3.75Mbps • fluxo 20 classe 2 de 2.5Mbps • fluxo 30 classe 3 de 10Mbps No router, cada classe do PRIO possuía FIFO com filas de 100 pacotes. Os resultados foram medidos no crude do receptor. 32
  • 33. Resultado Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio Recebidos perdidos de sequência (Mbps) 10 3.75877 0.010148 225534 30 0 20 2.49914 0.009939 149980 21 0 30 5.46285 0.010244 327847 243580 0 Tabela 11 : Resultados do UDP, Caso 2 PRIO Constatamos então que, sem o TBF a fazer shapping dos fluxos, as classes com maior prioridade foram servidas em primeiro lugar. Assim sendo o fluxo 10 (classe 1) ficou com o throughput esperado, assim como o fluxo 20 (classe 2). O fluxo 30 (classe 3) ficou com a largura de banda restante, pelo que apenas conseguiu metade do throughput pretendido. Caso 3 Objectivo Originar fenómeno de starvation nos fluxos de menor prioridade. Método Três fluxos UDP CBR com ToS diferentes: • fluxo 10 classe 1 de 12Mbps • fluxo 20 classe 2 de 3Mbps • fluxo 30 classe 3 de 8Mbps Cada classe do PRIO possuía, mais uma vez, FIFO com filas de 100 pacotes. Os resultados foram medidos no crude do receptor. Resultados Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio Recebidos perdidos de sequência (Mbps) 10 10.4752 0.034637 688624 220467 0 20 0.0931295 21.972095 5590 214255 0 30 0.0103741 21.990317 6227 578559 0 Tabela 12 : Resultados do UDP, Caso 3 PRIO 33
  • 34. Verifica-se assim que quando mal configurado, mesmo um mecanismo de escalonamento com classes e prioridades, pode originar problemas. Neste caso o fenómeno de starvation é bem evidente. Como o fluxo 10 tem prioridade sobre os restantes, é o primeiro a ser processado. No entanto, como não existe mecanismo de controlo do rate máximo, este fluxo apodera-se de toda a largura de banda disponível, não dando margem de manobra aos restantes fluxos. Mesmo os que possuem algum grau de prioridade. HTB Caso 1 Objectivo Com este caso de estudo, pretendemos verificar a eficiência do Hierarchical Token Bucket na resolução das seguintes questões: • Certificar que o problema de starvation observado no PRIO já não se verifica • Garantir que há bom serviço para os fluxos com requisitos de real time, mas certificando que não monopolizam a largura de banda • Com vários fluxos diferentes, verificar se cada um é servido pela sua classe Método Quatro fluxos UDP CBR com ToS diferentes: • fluxo 10 classe 1 de 1.6Mbps • fluxo 20 classe 1 de 1.6Mbps • fluxo 30 classe 2 de 18Mbps • fluxo 40 classe 3 de 32Mbps Um fluxo TCP: • um fluxo TCP STREAM de 60 segundos No router temos a seguinte configuração: • classe 1 – tem associado um SFQ, com taxa garantida de 128Kbps e tecto de 256Kbps • classe 2 – tem associado um SFQ, com taxa garantida de 256Kbps e tecto de 512Kbps • classe 3 – tem associado um SFQ, taxa garantida de 64Kbps e tecto de 128Kbps • classe TCP – tem associado um RED, com taxa garantida de 2Mbps e tecto de 4Mbps Os resultados foram medidos no crude do receptor e no netperf do gerador. 34
  • 35. Resultados Fluxos Throughput Jitter (s) Pacotes Pacotes Pacotes fora médio (bps) Recebidos perdidos de sequência 10 122232 0.106865 3726 56268 0 20 122200 0.101608 3724 56253 0 30 346064 0.115324 10504 176953 0 40 122221 0.109549 3791 450655 0 Tabela 13 : Resultados UDP, Caso 1 HTB Fluxo Throughput médio (Mbps) Elapsed time (s) Gerador TCP 3.86 60.85 Tabela 14 : Resultados TCP, Caso 1 HTB Através da análise dos resultados obtidos chegamos a algumas conclusões interessantes. O fluxo 10 e 20 tem o mesmo ToS (0x10) e o mesmo débito inicial (2MBps), no entanto, como a sua classe é gerenciada por SFQ, verificamos que não se canibalizam uma a outra, como aconteceria em FIFO. Pelo contrário, ambas acedem equitativamente aos recursos da sua classe, dividindo a largura de banda disponível. O fluxo 30 tem por sua vez ToS 0x04, pelo que ocupou parte significativa da largura de banda disponibilizada para a sua classe. Um valor entre a taxa garantida e o tecto disponível. O fluxo 40, uma fonte potencial de starvation (como verificamos no Caso 3 do PRIO) por sua vez, acede apenas aos recursos disponibilizados pela sua classe. Neste caso o throughput médio é aquele que a sua classe permite, encontrando-se por isso longe dos 32MBps (!) esperados (☺). Também o fluxo TCP ocupa quase a totalidade da largura de banda disponibilizada para a sua classe, sem no entanto causar starvation nas restantes ligações, fruto naturalmente das limitações impostas pelo HTB. Notas Finais Dadas as limitações técnicas conhecidas, não conseguimos fazer uma rede com mais do que um router Linux físico, pelo que os resultados obtidos poderiam ser mais óbvios e contundentes se, em alguns mecanismos de escalonamento, utilizássemos redes de maior dimensão. Exemplo disso, parece-nos ser o caso do SFQ, no qual não conseguimos verificar a ocorrência de pacotes fora de sequência, no caso 1. Numa situação real, onde os pacotes tivessem de realizar um número maior de hops, esse fenómeno seria facilmente observado. 35
  • 36. CONCLUSÃO Após o estudo e realização de diversas experiências laboratoriais, podemos finalmente chegar a algumas conclusões relativamente aos mecanismos de escalonamento. Quando bem utilizados, os mecanismos de escalonamento possibilitam uma série de formas de controlo de tráfego que permitem gerenciar uma rede, de reduzida ou elevada dimensão. Nos diversos testes realizados podemos comprovar isso mesmo: desde limitar o débito de um determinado tipo de serviço até, precisamente o oposto, garantir o débito de um tipo de serviço específico, no meio de outros tantos que cruzam a rede. Tanto os mecanismos de escalonamento classfulll como os classless são importantes para garantir qualidade de serviço numa rede. É a sua conjugação de esforços que nos permitem ter um maior leque de opções, para resolver problemas reais de forma eficaz. É em grande medida devido aos mecanismos de escalonamento que, protocolos como o RTP, conseguem singrar na internet, por exemplo. No entanto, nem tudo são vantagens e o elevado poder adaptativo destes mecanismos têm um preço. Alguns do algoritmos são relativamente pesados para as máquinas convencionais que utilizamos. Por esse mesmo facto, existe hardware especificamente desenhado para suportar este género de serviço, em situações extremas de fluxos muito mais exigentes do que aqueles que foram testados por nós. Outra desvantagem, é também o facto de a configuração de alguns mecanismos poder ser extremamente complexa. Nomeadamente, se estivermos a falar de configurações para resolução de problemas que tendem a ter um elevado grau de imprevisibilidade. Exemplo disso mesmo é a dificuldade em implementar modelos IntServ em grande escala, por forma a garantir qualidade de serviço. O grande inimigo que se apresenta, ainda e sempre, aos mecanismos de escalonamento é, curiosamente, o aumento sucessivo da capacidade/largura de banda das redes. O preço de custo de implementação de um sistema de controlo de tráfego eficiente a nível global é maior, do que o necessário para aumentar a largura de banda disponível em alguns troços da rede e assim “solucionar” os problemas. Parece-nos uma falsa solução. Teríamos tudo a ganhar se estes mecanismos de escalonamento fossem adoptados em conjunto com todas as outras evoluções naturais das redes de internet. Parece-nos pois que, com o advento das comunicações em VoIP, os fornecedores de serviços de internet têm todo o interesse em que assim seja. Em suma, os mecanismos de escalonamento fornecem um “estado” a um protocolo que não o implementa de origem – o protocolo IP. 36
  • 37. BIBLIOGRAFIA • PUB – Rio – Certificação digital Nº0310457/CA • http://www.eriberto.pro.br/wiki/index.php?title=Controle_de_tr%C3%A1fego_com_TC%2 C_HTB_e_Iptables • http://www.howtoforge.com/voip_qos_traffic_shaping_iproute2_asterisk • http://www.pop-pr.rnp.br/tiki-index1b91.html?page=Roteadores+Controle+de+Trafego • http://linux-ip.net/articles/Traffic-Control-HOWTO/ • http://www.opalsoft.net/qos/DS-21.htm • http://en.wikipedia.org/wiki/Quality_of_service • http://vonage.nmhoy.net/qos.html • http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS.html • http://en.wikipedia.org/wiki/Traffic_shaping • http://vonage.nmhoy.net/qos.html • http://tcng.sourceforge.net/ • http://www.netperf.org/netperf/ • http://rude.sourceforge.net/ • http://www.ntp.org/ 37
  • 38. ANEXOS Ficheiros de configuração do router: FIFO 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 pfifo limit 100 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 5 RED 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 red limit 8000000 min 500000 max 1000000 avpkt 1000 burst 666 probability 0.02 bandwidth 10000 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 40960 limit 40960 mtu 1514 rate 512kbps PRIO caso 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 20480 limit 20480 mtu 1514 rate 128000bps tc qdisc add dev eth2 handle 4:0 parent 2:2 tbf burst 20480 limit 20480 mtu 1514 rate 64000bps tc qdisc add dev eth2 handle 5:0 parent 2:3 tbf burst 20480 limit 20480 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 38
  • 39. 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 caso 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 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 caso 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 10000 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 39
  • 40. 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 1250000bps ceil 1250000bps tc class add dev eth2 parent 2:1 classid 2:2 htb rate 128000bps ceil 256000bps 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 512000bps 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 256000bps ceil 512000bps tc qdisc add dev eth2 handle 5:0 parent 2:4 red limit 8000000 min 500000 max 1000000 avpkt 1000 burst 666 probability 0.02 bandwidth 10000000 tc class add dev eth2 parent 2:1 classid 2:5 htb rate 64000bps ceil 128000bps 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 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 Ficheiros de configuração dos fluxos no emissor: FIFO Caso 1 START NOW 1000 10 ON 30001 1.1.2.100:10001 CONSTANT 750 1000 30000 20 ON 30002 1.1.2.100:10001 CONSTANT 750 1000 61000 10 OFF 61000 20 OFF 40
  • 41. Caso 2 START NOW 1000 10 ON 3001 1.1.1.100:10001 CONSTANT 95 1000 1000 20 ON 3002 1.1.1.100:10002 CONSTANT 95 1000 TOS 10 0x0 TOS 20 0x10 61000 10 OFF 61000 20 OFF Caso 3 netperf -H 1.1.2.100 -l 60 e netperf -H 1.1.2.100 -l 60 SFQ Caso 1 START NOW 1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1250 1000 1000 20 ON 3002 1.1.2.100:10001 CONSTANT 2500 1000 61000 10 OFF 61000 20 OFF Caso 2 START NOW 1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1250 1000 61000 10 OFF e netperf -H 1.1.2.100 -l 60 RED #!/bin/sh for ((i=0; i<10; i++)) do netperf -H 1.1.2.100 -l 1 & done 41
  • 42. TBF START NOW 1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1500 1000 61000 10 OFF PRIO Caso 1 START NOW 1000 10 ON 3001 1.1.2.100:10001 CONSTANT 18 1000 1000 20 ON 3002 1.1.2.100:10001 CONSTANT 10 1000 1000 30 ON 3003 1.1.2.100:10001 CONSTANT 125 1000 TOS 10 0x10 TOS 20 0x04 TOS 30 0x0 61000 10 OFF 61000 20 OFF 61000 30 OFF Caso 2 START NOW 1000 10 ON 3001 1.1.2.100:10001 CONSTANT 470 1000 1000 20 ON 3002 1.1.2.100:10001 CONSTANT 310 1000 1000 30 ON 3003 1.1.2.100:10001 CONSTANT 1250 1000 TOS 10 0x10 TOS 20 0x04 TOS 30 0x0 61000 10 OFF 61000 20 OFF 61000 30 OFF Caso 3 START NOW 1000 10 ON 3001 1.1.2.100:10001 CONSTANT 1500 1000 1000 20 ON 3002 1.1.2.100:10001 CONSTANT 375 1000 1000 30 ON 3003 1.1.2.100:10001 CONSTANT 1000 1000 TOS 10 0x10 TOS 20 0x04 TOS 30 0x0 61000 10 OFF 61000 20 OFF 61000 30 OFF 42
  • 43. HTB START NOW 1000 10 ON 30001 1.1.2.100:10001 CONSTANT 200 1000 1000 20 ON 30002 1.1.2.100:10001 CONSTANT 200 1000 1000 30 ON 30003 1.1.2.100:10001 CONSTANT 2000 1000 1000 40 ON 30004 1.1.2.100:10001 CONSTANT 4000 1000 TOS 10 0x10 TOS 20 0x10 TOS 30 0x04 31000 10 OFF 31000 20 OFF 31000 30 OFF 31000 40 OFF e netperf -H 1.1.2.100 -l 60 43