ALGORITMO HIERARCHICAL TOKEN BUCKET, HTB

O HTB é um mecanismo de escalonamento que foi criado por Martin Devera nos finais de 2001, sendo actualmente o sucessor do Class Based Queueing (CBQ). HTB tem algumas vantagens relativamente a outras técnicas de QoS e especialmente quando comparado com CBQ: é mais simples e mais intuitivo, é mais preciso na implementação da partilha de tráfego e permite técnicas de empréstimo. Assegura que pelo menos uma quantidade mínima de tráfego para uma classe é fornecida; quando essa mesma classe não usa os recursos atribuídos, a largura de banda que não está a ser usada é temporariamente distribuída pelas outras classes.

No intuito de implementar um mecanismo que permitisse especificar regras que optimizem a utilização de um link, a estrutura de partilha de recursos especifica uma divisão da largura de banda para um link em particular de uma forma estática ou dinâmica. Cada classe deverá receber a sua largura de banda atribuída [Floyd]. Uma partilha de link hierárquica pode contemplar múltiplos links tal como indica a Figura 2.12. Um link pode ser partilhado por 3 organizações (Org A, B, C), o tráfego de todas as organizações é escalonado segundo os protocolos (P1, P2, P3) e a hierarquia pode descer ainda para links individuais (L1, L2) com classes de serviço.

Figura 2.12: Partilha hierárquica de recursos

Como se pode ver a Org B recebe uma percentagem de largura de banda total do link para os protocolos P1 e P2; se P1 não tiver dados para transmitir a largura de banda não utilizada pode ser utilizada pela subclasse P2 da mesma organização.

HTB assume que a árvore está completa e o tráfego é dividido em fluxos. O algoritmo usado para escalonar pacotes é o seguinte: primeiro, escolhe todos as “folhas” da árvore cuja taxa máxima ainda não foi atingida e envia os pacotes dessas “folhas” começando pelos pacotes de mais alta prioridade e continuando com as “folhas” de menor prioridade. Para “folhas” com a mesma prioridade usa-se DRR. Quando as taxas para todas as “folhas” são excedidas, todo o ciclo é repetido mas para cada “folha” é realizado um teste para verificar se é possível obter empréstimo dos seus pais sem utilizar o seu próprio débito; quando não faltar mais nenhuma classe, o ciclo é repetido começando pelos primeiros nós da árvore.

Ainda relativamente à Figura 2.12, quando a classe Org A tem maior prioridade que a Org B e ambas vão receber largura de banda emprestada pela Org C, então Org A serve-se o máximo que pode e o restante é dado a Org B; se Org B tem a mesma prioridade que Org A então o empréstimo de largura de banda por parte de Org C deve ser divido entre as outras duas organizações na mesma proporção que as suas próprias taxas iniciais. Link Org X Org B P1 P2 P1 P2 Org C P3 P1 P2 L1 L2

O HTB é mais lento mas mais preciso que CBQ. O CBQ mantém uma variável e um ciclo de alto nível somente sobre as folhas e em cada “folha” tenta emprestar para os seus antecessores até ao nível superior. A taxa é medida pelo intervalo de tempo entre ocorrência de pacotes. Os ciclos do HTB sobre as folhas ocorrem mais vezes tornando o processo mais lento mas mais preciso.

São usados os seguintes termos:

• Ceil – a largura de banda máxima que uma classe pode usar

• Burst – a quantidade de dados que pode ser enviada com a máxima velocidade para uma classe sem servir outra classe. O valor para este parâmetro nunca deve ser maior para a classe filha do que para os seus pais.

Um exemplo pode ser visto na figura seguinte:

Figura 2.13: Exemplo prático de uma árvore HTB

Por exemplo, num ISP, em que cada utilizador paga pela sua ligação, basta colocar a taxa com o mesmo valor que o ceil na configuração do HTB.

Entre as inúmeras vantagens que advêm do uso do HTB, destaca-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 divisão de um link entre fluxos heterogéneos. No entanto a implementação é bastante complexa.

10 Mbps 2 Mbps 5 Mbps 1 Mbps 0.7 Mbps 3 Mbps 2 Mbps 3 Mbps 0.3 Mbps 2 Mbps 1 Mbps 2 Mbps 1 Mbps

2.6.

DESCARTE

As técnicas de descarte definem quais os pacotes, numa fila de espera de um router, que devem ser descartados em determinado instante. Esse descarte pode ser efectuado numa situação de congestionamento ou com o objectivo de evitar essa situação [Keshav]. No entanto, no caso mais simples, os pacotes podem ser descartados mesmo antes de serem colocados na fila de espera do router (tail drop).

As técnicas de descarte distinguem-se pela posição na fila de espera do pacote a descartar e pela condição que define o descarte dos pacotes. A situação mais comum e mais simples de implementar é o descarte do último pacote recebido. Neste caso, quando um pacote chega ao sistema, é verificado se:

• a fila de espera tem espaço disponível para receber o mesmo,

• ou, mesmo que a fila não esteja cheia, se pode ser aceite de acordo com a estratégia adoptada (e.g., Random Early Detection - RED),

se estes dois pontos não se verificarem o pacote é descartado.

O descarte do primeiro pacote da fila é mais complexo porque implica alterar o ponteiro que indica qual o próximo pacote a ser transmitido. Para além disso, no caso dos recursos da fila de espera serem geridos em bytes, é necessário verificar se o tamanho do pacote a descartar é igual ou superior ao tamanho do pacote que acabou de chegar; caso isto não se verifique, é necessário descartar um número n de pacotes para que a fila tenha espaço para receber o pacote que acaba de chegar. Escolher um pacote aleatório para descarte ainda é mais complexo, pois requer a existência de um ponteiro para cada pacote, o que torna mais complexa a gestão da fila de espera. Na prática, devido à sua complexidade, esta técnica não é muito utilizada.

As técnicas de descarte analisadas neste capítulo serão a DropTail e a Random Early Detection, RED. A primeira descarta pacotes da sua fila de espera sempre que não tem espaço disponível para receber o pacote que acaba de chegar. No caso da técnica de descarte RED, os pacotes são descartados aleatoriamente, com uma determinada probabilidade dependendo do tamanho da fila de espera e do número de pacotes que

chegam, com o objectivo de manter o tamanho médio da fila de espera entre os valores configurados.

Várias variantes do RED foram já propostas e adoptadas pela comunidade IP. Um estudo comparativo sobre algumas variantes do RED, incluindo WRED, GRED, RIO- C e RIO-DC, é apresentado em [Makkar].