Disciplinas de Enfileiramento Avançadas & Menos Comum

Capítulo 14 – Disciplinas de Enfileiramento Avançadas & Menos Comum

Se você descobrir que você tem necessidades não abarcadas pelas filas mencionadas anteriormente, o kernel possui algumas outras filas mais especializadas que serão mencionadas aqui.

14.1. bfifo/pfifo

Essas filas classless são de fato mais simples do que pfifo_fast em que elas carecem das bandas internas – todo tráfego é realmente igual. Elas têm algum beneficio importante embora, elas possuam algumas estatísticas. Assim mesmo que você não precise shappar ou priorizar, você pode usar essa qdisc para determinar o backlog em sua interface.

O pfifo possui um comprimento medido em pacotes, bfifo em bytes.

14.1.1. Parâmetros & Uso

limit

Especifica o comprimento da fila. Medido em bytes para bfifo, em pacotes para pfifo. É padronizado o txqueuelen da interface (veja o capítulo pfifo_fast) com pacotes longos ou txqueuelen * mtu bytes para bfifo.

14.2. Algoritmo Clark-Shenker-Zhang (CSZ)

Esse é tão teórico que nem mesmo o Alexey (o autor principal do CBQ) se queixou para compreendê-lo. De sua fonte:

David D. Clark, Scott Shenker and Lixia Zhang Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism.

Como eu o entendi, a idéia principal é criar fluxos WFQ para cada serviço garantido e alocar o resto da largura de banda para abstrair o flow-0. O flow-0 engloba os serviços preditivos e o tráfego de melhor esforço; ele é manipulado por um escalonador de prioridade com a banda de prioridade mais alta para serviços preditivos, e o resto – para os pacotes de melhor esforço.

Observe que nos fluxos CSZ NÃO são limitados a sua largura de banda. É suposto que o fluxo passou por controle de admissão na borda da rede com QoS e ele não precisa mais ser shape-adado. Qualquer tentativa para melhorar o fluxo ou para shapê-lo em um balde de fichas em saltos intermediários introduzirá atrasos indesejados e aumentará o jitter.

No momento o CSZ é o único escalonador que fornece serviço garantido verdadeiramente. Nenhum outro esquema (incluindo o CBQ) não fornece nenhuma garantia contra atraso e jitter randômico.

Atualmente não aparece como um bom candidato a usar, a não ser que você tenha lido e entendido o artigo mencionado.

14.3. DSMARK

Esteve Camps
marvin@grn.es

Esse texto é um extrato da minha tese sobre QoS Support in Linux, Setembro de 2000.

Fontes dos documentos:


   •  Draft-almesberger-wajhak-diffserv-linux-01.txt.
   •  Examples in iproute2 distribution.
   •  White Paper-QoS protocols e architectures and IP QoS Frequently Asked 
Questions ambos pelo Quality of Service Forum.

Esse capítulo foi escrito por Esteve Camps esteve@hades.udg.es.

14.3.1. Introdução

Antes de tudo, é uma grande idéia você ler as RFC´s escritas sobre esse assunto (RFC2474, RFC2475, RFC2597 e RFC2598) no site web IETF DiffServ working Group e no site web do Werner Almesberger (esse escreveu o código para suportar Serviços Diferenciados no Linux).

14.3.2. Com que Dsmark está relacionado?

O dsmark é uma disciplina de enfileiramento que oferece as capacidades necessárias em Serviços Diferenciados (também chamado DiffServ ou, simplesmente, DS). O DiffServ é um dos duas arquiteturas de QoS atuais (a outra é chamada Serviços Integrados) que é baseada em um valor transportado pelos pacotes no campo DS do cabeçalho IP.

Uma das primeiras soluções em IP projetava oferecer algum nível de QoS era o campo Type of Service (byte TOS) no cabeçalho IP. Alterando esse valor, nós poderíamos escolher um nível alto/baixo de transferência, atraso ou confiabilidade. Mas isso não fornecia flexibilidade suficiente para as necessidades dos novos serviços (como aplicações de tempo real, aplicações interativas, entre outras). Depois disso, novas arquiteturas apareceram. Uma dessas foi o DiffServ que manteve os bits TOS e que renomeou o campo DS.

14.3.3. Orientações para Serviços Diferenciados

Os Serviços Diferenciados é orientado a grupo. Eu quis dizer que não sabemos nada a respeito de fluxos (isso seria a finalidade dos Serviços Integrados); nós sabemos sobre as agregações de fluxo e nós aplicaremos diferentes comportamentos dependendo de qual agregação um pacote pertence.

Quando um pacote chega a um nó de borda (nó de entrada a um domínio DiffServ) entra em um Domínio DiffServ que nós precisaremos policiar, shape-ar e/ou marcar esses pacotes (marcação se refere a atribuir um valor ao campo DS. É justamente igual a ferrar gado ). Essa será a marca/valor que os nó´s internos/núcleo no nosso Domínio DiffServ examinará para determinar qual comportamento ou nível de QoS aplicar.

Como você pode deduzir, os Serviços Diferenciados envolvem um domínio em que todas as regras DS precisarão ser aplicadas. De fato você pode pensar que classificarei todos os pacotes que entram no meu domínio. Uma vez que eles tenham entrado em meu domínio eles ficarão sujeitos as regras que minha classificação ditar e todo nó atravessado aplicará aquele nível de QoS.

De fato, você pode aplicar suas próprias políticas nos seus domínios locais, mas alguns Acordos de Níveis de Serviços (Service Level Agreements) devem ser considerados quando se conectando a outros domínios DS.

Nesse ponto, você talvez tenha um monte de questões. O DiffServ é mais do que eu tenho explicado. De fato, você pode compreender que eu não posso resumir mais do que 3 RFC´s em apenas 50 linhas .

14.3.4. Trabalhando com Dsmark

Como a bibliografia DiffServ especifica, nós diferenciamos nó´s fronteira e nó´s interior. Existem dois pontos importantes no caminho do tráfego. Ambos os tipos executam uma classificação quando os pacotes chegam. Seu resultado pode ser usado em diferentes lugares junto com o processo DS antes que o pacote seja liberado na rede. É justamente por causa disso que o código diffserv fornece uma estrutura chamada sk_buff, que inclui um novo campo chamado skb->tc_index onde armazenaremos o resultado da classificação inicial que pode ser usado em vários pontos no tratamento DS.

O valor do campo skb->tc_index será inicialmente definido pela qdisc DSMARK, que o recupera do campo DS no cabeçalho IP de cada pacote recebido. Além do mais, o classificador cls_tcindex lerá todo ou parte do valor do campo skb->tcindex e usa-o para selecionar classes.

Mas, antes de tudo, examine o comando qdisc DSMARK e seus parâmetros:


... dsmark indices INDICES [ default_index DEFAULT_INDEX ] [ set_tc_index ]

O que significa esses parâmetros?


  •  indices: tamanho da tabela de pares (mask,value). Valor máximo é 2ˆn, onde n>=0.
  •  default_index: o índice de entrada da tabela padrão se o classificador não encontrou nenhum match.
  •  set_tc_index: instrui a disciplina dsmark para recuperar o valor do campo DS e armazená-lo em skb->tc_index.

Vejamos o processo DSMARK.

14.3.5. Como funciona SCH_DSMARK...

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