Disciplinas de Enfileiramento Classless Simples

9.2. Disciplinas de Enfileiramento Classless Simples

Como dito, por disciplinas de enfileiramento, nós alteramos a forma como os dados são enviados. Disciplinas de enfileiramento Classless (implementadas sem o conceito de classe) são aquelas que, geralmente aceitam dados e que somente os re-escalonam, os atrasam ou os descartam.

Essas classes podem ser usadas para tratar o tráfego para uma interface inteira, sem nenhuma subdivisão. É vital que você entenda essa parte de enfileiramento antes que sigamos na qdisc classful que contém as qdiscs!

De longe a disciplina usada mais amplamente é a qdisc pfifo_fast – ela é a padrão. Isso também explica o porquê dessas funcionalidades avançadas serem tão robustas. Elas são nada mais do que ‘uma outra fila precisamente’.

Cada uma dessas filas possui pontos fortes e fracos específicos. Nem todas elas podem ser também testadas.

9.2.1. pfifo_fast

Essa fila é, como o próprio nome diz, Primeiro a Entrar, Primeiro a Sair, o que significa que nenhum pacote recebe tratamento especial. Pelo menos, não completamente. Essa fila possui 3 ‘bandas’, assim chamada. Dentro de cada banda, regras FIFO são aplicadas. Contudo, desde que existam pacotes aguardando na banda 0, a banda 1 não será processada. O mesmo acontece em relação à banda 1 e a banda 2.
O kernel respeita o flag Tipo de Serviço, assim chamado, dos pacotes, e toma cuidado de inserir pacotes 'minimum delay' na banda 0.

Não confunda essa qdisc classless simples com a qdisc PRIO classful. Embora elas se comportem de forma similar, pfifo_fast é classless e você não pode adicionar outras qdiscs a ela com o comando tc.

9.2.1.1. Parâmetros & Uso

Você não pode configurar a 'qdisc pfifo_fast' porque ela é o padrão que está associado com o hardware. Assim é como ela é configurada por padrão:

priomap

Determina como as prioridades de pacotes, conforme atribuído pelo kernel, são mapeadas por banda. O mapeamento ocorre baseado no octeto TOS do pacote, que se parece com quadro abaixo:


   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |                       |     |
|   PRECEDENCE    |          TOS          | MBZ |
|                 |                       |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

Os quatro bits TOS (o 'campo TOS') são definidos como:


Binary Decimal  Meaning
-----------------------------------------
1000   8        Minimize delay (md)
0100   4        Maximize throughput (mt)
0010   2        Maximize reliability (mr)
0001   1        Minimize monetary cost (mmc)
0000   0        Normal Service

Como existe 1 bit a direita desses quatro bits, o valor real do campo TOS é o dobro do valor dos bits TOS. O programa tcpdump -v -v mostra-lhe o valor do campo TOS inteiro, e não somente os quatro bits. É o valor que você verá na primeira coluna dessa tabela:


TOS     Bits  Means                    Linux Priority    Band
------------------------------------------------------------
0x0     0     Normal Service           0 Best Effort     1
0x2     1     Minimize Monetary Cost   1 Filler          2
0x4     2     Maximize Reliability     0 Best Effort     1
0x6     3     mmc+mr                   0 Best Effort     1
0x8     4     Maximize Throughput      2 Bulk            2
0xa     5     mmc+mt                   2 Bulk            2
0xc     6     mr+mt                    2 Bulk            2
0xe     7     mmc+mr+mt                2 Bulk            2
0x10    8     Minimize Delay           6 Interactive     0
0x12    9     mmc+md                   6 Interactive     0
0x14    10    mr+md                    6 Interactive     0
0x16    11    mmc+mr+md                6 Interactive     0
0x18    12    mt+md                    4 Int. Bulk       1
0x1a    13    mmc+mt+md                4 Int. Bulk       1
0x1c    14    mr+mt+md                 4 Int. Bulk       1
0x1e    15    mmc+mr+mt+md             4 Int. Bulk       1

São muitos números. A segunda coluna contém o valor dos quatro bits TOS relevantes, seguidos por seus significados correspondentes. Por exemplo, o valor 15 significa que um pacote exige Custo Monetário Mínimo, Confiabilidade Máxima, Máxima Velocidade E Atraso Mínimo. Eu o chamaria de um ‘Pacote Holandês’.

A quarta coluna lista a forma como o Kernel Linux interpreta os bits TOS, que mostra para qual Prioridade eles são mapeados.

A última coluna mostra o resultado do priomap padrão. Na linha de comando, o priomap padrão se parece com:

1, 2, 2, 2, 1, 2, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1

Isso significa que a prioridade 4, por exemplo, é mapeada para a banda número 1. O parâmetro priomap também permite você listar prioridades mais altas (> 7) que não faz correspondência ao mapeamento TOS, mas que são definidos para outras finalidades.

Essa tabela da RFC 1349 (leia-a para mais detalhes) lhe diz como as aplicações podem muito bem definir seus bits TOS:


TELNET                1000           (minimize delay)
FTP
Control               1000           (minimize delay)
Data                  0100           (maximize throughput)

TFTP                  1000           (minimize delay)

SMTP 
 Command phase        1000           (minimize delay)
 DATA phase           0100           (maximize throughput)

Domain Name Service
 UDP Query            1000           (minimize delay)
 TCP Query            0000
 Zone Transfer        0100           (maximize throughput)

NNTP                  0001           (minimize monetary cost)

ICMP
 Errors               0000
 Requests             0000           (mostly)
 Responses      <same as request>    (mostly)

txqueuelen

O comprimento dessa fila é colhido a partir da configuração da interface, o que você pode ver e definir com os comandos ifconfig e ip. Para definir o comprimento da fila igual a 10, execute o comando: ifconfig eth0 txqueuelen 10.

Você não consegue definir esse parâmetro com o comando tc!

9.2.2. Filtro Token Bucket...

Autores Originais dos textos:

Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl

Thomas Graf (Autor de Seção)
tgraf@suug.ch

Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx

Remco van Mook (Autor de Seção)
remco@virtu.nl

Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com

Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com

Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl

Pedro Larroy (Autor de Seção)
piotr@member.fsf.org