Eu gostaria de adicionar algum tipo de gerenciamento de tráfego à nossa linha da Internet. Depois de ler muita documentação, acho que o HFSC é muito complicado para mim (não entendo todas as curvas, receio que nunca acerte), o CBQ não é recomendado e basicamente o HTB é o caminho para vá para a maioria das pessoas.
Nossa rede interna possui três "segmentos" e eu gostaria de compartilhar a largura de banda mais ou menos igualmente entre eles (pelo menos no começo). Além disso, devo priorizar o tráfego de acordo com pelo menos três tipos de tráfego (tráfego em tempo real, tráfego padrão e tráfego em massa). O compartilhamento de largura de banda não é tão importante quanto o fato de que o tráfego em tempo real sempre deve ser tratado como tráfego premium sempre que possível, mas é claro que nenhuma outra classe de tráfego também pode passar fome.
A questão é: o que faz mais sentido e também garante melhor rendimento em tempo real:
Criando uma classe por segmento, cada um com a mesma taxa (a prioridade não importa para as classes sem licença de acordo com o desenvolvedor HTB) e cada uma dessas classes possui três subclasses (folhas) para os três níveis de prioridade (com prioridades diferentes e taxas diferentes).
Ter uma classe por nível de prioridade no topo, cada uma com uma taxa diferente (novamente a prioridade não importa) e cada uma com três subclasses, uma por segmento, enquanto todas as três da classe em tempo real têm o maior e o menor em massa. classe e assim por diante.
Vou tentar deixar isso mais claro com a seguinte imagem artística ASCII:
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
Caso 1 Parece que a maioria das pessoas faria isso, mas, a menos que eu não leia os detalhes da implementação do HTB corretamente, o Caso 2 poderá oferecer uma melhor priorização.
O manual do HTB diz que, se uma classe atingiu sua taxa, ela pode pedir emprestado ao pai e, ao pedir, as classes com maior prioridade sempre recebem a largura de banda oferecida primeiro. No entanto, também diz que as classes com largura de banda disponível em um nível de árvore mais baixo são sempre preferidas àquelas em um nível de árvore mais alto, independentemente da prioridade .
Vamos assumir a seguinte situação: O segmento C não está enviando nenhum tráfego. O segmento A está apenas enviando tráfego em tempo real, o mais rápido possível (o suficiente para saturar o link sozinho) e o segmento B está enviando apenas tráfego em massa, o mais rápido possível (novamente, o suficiente para saturar o link completo sozinho). O que vai acontecer?
Caso 1:
O segmento A-> Alto Prio e o segmento B-> Baixo Prio têm pacotes para enviar, uma vez que A-> Alto Prio tem a maior prioridade, sempre será agendada primeiro, até atingir sua taxa. Agora, ele tenta emprestar do segmento A, mas como o segmento A está em um nível mais alto e o segmento B-> Prio baixo ainda não atingiu sua taxa, essa classe agora é atendida primeiro, até que ela também atinja a taxa e queira pedir emprestado de Segmento B. Uma vez que ambos atingiram suas taxas, ambos estão no mesmo nível novamente e agora o Segmento A-> Prio Alto ganhará novamente, até atingir a taxa do Segmento A. Agora, ele tenta emprestar da raiz (que tem bastante tráfego de sobra, pois o segmento C não usa nenhum de seu tráfego garantido), mas, novamente, ele precisa aguardar que o segmento B-> baixo preço também atinja o nível raiz. Quando isso acontece,
Caso 2:
Alto Prio-> Segmento A e Baixo Prio-> Segmento B ambos têm pacotes para enviar, novamente Alto Prio-> Segmento A ganhará, pois tem maior prioridade. Depois de atingir sua taxa, ele tenta emprestar ao High Prio, que tem largura de banda disponível, mas, em um nível mais alto, ele precisa aguardar Low Prio-> Segmento B novamente para também atingir sua taxa. Quando ambos atingem a taxa e tomam emprestado, High Prio-> Segmento A vencerá novamente até atingir a taxa da classe High Prio. Quando isso acontece, ele tenta emprestar da raiz, que tem novamente muita largura de banda restante (toda a largura de banda do Normal Prio não está sendo usada no momento), mas precisa esperar novamente até que Prio baixo-> o segmento B atinja o limite de taxa do Classe Prio baixa e também tenta emprestar da raiz. Finalmente, ambas as classes tentam tomar emprestado da raiz, a prioridade é levada em consideração e o High Prio->
Ambos os casos parecem sub-ideais, já que, de qualquer forma, o tráfego em tempo real às vezes precisa aguardar o tráfego em massa, apesar de haver muita largura de banda disponível. No entanto, no caso 2, parece que o tráfego em tempo real precisa esperar menos do que no caso 1, pois só precisa esperar até que a taxa de tráfego em massa seja atingida, o que provavelmente é menor que a taxa de um segmento inteiro (e, no caso 1 que é a taxa pela qual deve esperar). Ou estou totalmente errado aqui?
Pensei em configurações ainda mais simples, usando um qdisc prioritário. Mas as filas prioritárias têm o grande problema de causar inanição se não forem limitadas. A fome não é aceitável. Obviamente, é possível colocar um TBF (Token Bucket Filter) em cada classe de prioridade para limitar a taxa e, assim, evitar a fome, mas, ao fazer isso, uma única classe de prioridade não pode mais saturar o link por si só, mesmo que todas as outras classes de prioridade estiverem vazios, o TBF impedirá que isso aconteça. E isso também é subótimo, pois por que uma classe não obteria 100% da largura de banda da linha se nenhuma outra classe precisa disso no momento?
Quaisquer comentários ou idéias sobre esta configuração? Parece tão difícil fazer isso usando tc qdiscs padrão. Como programador, era uma tarefa tão fácil se eu pudesse escrever meu próprio agendador (o que não tenho permissão para fazer).