[GTER] DiffServ em Linux

[Rafael Ganascim]

Uma tentativa para buscar a famosa strict priority, ou LLQ, ou qualquer nome
que queira dar para o tráfego EF (e afins) seria utilizar um esquema mais ou
menos assim:

Duas classes em PRIO:

- 1 de alta prioridade com:
-- TBF limitando a classe em X % da banda (ou [M|K]bps)
-- enfileiramento FIFO
-- igual à Cisco strict priority

- 1 de prioridade normal com HTB
-- daí os esquemas de distribuição, controle de congestionamento, etc
-- como seriam as demais 'class-based' dentro do Cisco


Em 26 de junho de 2011 19:59, Marlon Dutra <mfdutra at gmail.com> escreveu:

> Olá,
>
> Quem trabalha com roteadores Linux já deve ter percebido que fazer
> determinadas tarefas de QoS é ridiculamente difícil, muitas vezes não
> por falta de suporte do kernel, mas pela raríssima documentação
> existente. Quando se encontra alguma documentação, normalmente é
> extremamente técnica, mais voltada para os aspectos da implementação dos
> algoritmos no kernel, do que para o uso geral de administradores de
> rede em casos reais.
>
> Quem trabalha com outros roteadores se sente mais frustrado ainda, pois
> elaborar um bom esquema de QoS no Cisco, por exemplo, é bem fácil e a
> documentação é muito abundante, e bem voltada para casos reais.
>
> Nos últimos tempos tenho me dedicado a tentar construir um modelo
> DiffServ em Linux, implementando todas as classes. Consegui chegar num
> modelo que me pareceu interessante e bem parecido com o que eu consigo
> fazer em roteadores Cisco e Huawei, os quais tenho mais familiaridade.
>
> http://hackers.propus.com.br/~marlon/files/qos-maker.html
>
> Fiz o gerador de script QoS acima, onde se pode determinar as taxas de
> CIR e MIR desejadas para cada classe e um shell script de acordo é
> gerado. O script é HTML e java script puro e pode ser utilizado offline.
>
> A implementação de EF (expedited forwarding) não me parece exatamente o
> que é recomendado. No Cisco, eu faria usando LLQ (low latency queueing).
> No Huawei, existe um traffic behavior específico para EF, que deve ser
> muito similar ao LLQ. No Linux, coloquei o EF numa classe de tráfego HTB
> separada usando FIFO como mecanismo de fila. Todas as recomendações de
> EF que vi na Internet fazem isso. Embora funcione bem, não me parece que
> o kernel vai garantir a mínima latência possível nesses pacotes, como o
> LLQ faz.
>
> O AF (assured forwarding) foi implementado em 4 classes HTB (AF 1x 2x 3x
> 4x), cada classe usando GRED respeitando a probabilidade de descarte
> dentro das classes (1 2 3).
>
> O BE (best effort) foi implementando em outra classe HTB (classe padrão
> de tráfego), usando RED como mecanismo da fila. A Cisco recomenda usar
> WFQ (weighted fair queueing) (sfq no Linux) na classe BE, mas eu ainda
> acho RED mais prudente, para evitar o problema de sincronia do TCP. [1]
>
> Naturalmente, o script gerado é meio genérico e não vai atender 100% dos
> casos. Mas já é um bom ponto de partida para quem precisa de um modelo
> DiffServ.
>
> Não tive ainda a oportunidade de testar muito o resultado. Qualquer
> comentário, sugestão, patches, etc, são muito bem-vindos.
>
> Vou palestrar sobre QoS no FISL (Porto Alegre) na próxima quinta-feira
> às 16h. Se alguém estiver por lá e quiser depois bater um papo sobre
> isso, seria bacana. Não encontro muita gente disposta a embarcar nessa
> loucura que é QoS e Linux. :-)
>
> Saudações.
>
> [1] http://en.wikipedia.org/wiki/TCP_global_synchronization
>
> --
> MARLON DUTRA
> Propus
> GnuPG ID: 0x3E2060AC pgp.mit.edu
> http://www.propus.com.br/
> http://hackers.propus.com.br/~marlon/
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>