Quality of Service and Linux

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


Resultado

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


27

Resultado

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 TCP STREAM de 60 segundos

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

Resultados

(Mbps)
10 6.977 0.021110 418617 181384 52
Tabela 5: Resultados do UDP, Caso 2 SFQ

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

30

Resultado

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


Resultados

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


• fluxo 10 classe 1 de 3.75Mbps

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


32

Resultado

(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

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


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


Resultados

(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

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:


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

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

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 2:0 parent 1:0 sfq perturb 5

RED

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 2:0 parent 1:0 tbf burst 40960 limit 40960
mtu 1514 rate 512kbps

PRIO

caso 1

tc qdisc add dev eth2 handle 2:0 parent 1:0 prio
mtu 1514 rate 128000bps
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
classid 2:2
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
0x0 at 0 classid 1:3

caso 2

shift 0
classid 2:3
classid 2:2
classid 2:1

caso 3

shift 0
classid 2:3
classid 2:2
classid 2:1

39

HTB

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
256000bps
tc qdisc add dev eth2 handle 3:0 parent 2:2 sfq
512000bps
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
128000bps
shift 0
classid 2:5
classid 2:4
classid 2:3
classid 2:2

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

Quality of Service and Linux

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (8)

Destaque

Destaque (6)

Semelhante a Quality of Service and Linux

Semelhante a Quality of Service and Linux (20)

Último

Último (20)

Quality of Service and Linux