Usando htb para controle de tráfego por ip priorizando certos serviços

Sempre fui fiel usuário do htb-tools para controle de tráfego do meu roteador de internet na prefeitura de Terra de Areia. É claro que o uso do htb-tools dá-se principalmente pela minha completa falta de competência em saber lidar com o comando tc "na unha".
Minha estrutura é simples, por isto mantenho o squid nesta mesma máquina fazendo nat, o que sempre me trouxe o problema do controle preciso de upload, pois com nat e squid, definitivamente não dá pra fazer controle de upload da mesma forma "simples" que download.
Estes dias passei a estudar traffic control para linux e htb no intuito de preparar um novo roteador que me permitisse controle preciso de download e upload e para isto é lógico que precisava separar o nat e o squid para outra máquina a fim de manter de forma simples estes controles.
Até estava pensando em continuar usando htb-tools, afinal sempre fez muito bem seu trabalho, mas um htb generate eth0 (por exemplo) gerou uma infinidade de regras totalmente incompreensíveis para mim e decidi que queria saber como funcionam as suas entranhas.
A princípio sempre soube que o controle de tráfego é sempre feito no fluxo (interface) de saída e como faço controle de upload com htb-tools ele muda esta política e passa a controlar pelo fluxo de entrada (ingress, pelo menos eu acho).
Ainda estou totalmente cru com todos os conceitos envolvidos em controle de tráfego e com a forma de aplicá-los com o comando tc, por isto resolvi escrever minhas memórias como forma de documentação do meu aprendizado e para que as bondosas almas possam indicar-me minhas falhas.
Sem dúvida o fórum underlinux é minha principal fonte de aprendizado e busca por respostas, mas não posso deixar de citar o manual traduzido do htb e QosLinux.ppt.
Como resultado final deste trabalho pretendo desenvolver uma aplicação em ruby, java, php ou qualquer outra linguagem para que a partir de um arquivo com os ips e taxas de download e upload sejam geradas um conjunto de regras para estes controles.
Ainda não tenho a mínima idéia de como fazer, mas "em cima" do controle de tráfego de cada computador da rede quero fazer também priorização, ou seja, dar prioridade maior para pacotes de voip do que ftp, independente de quem está fazendo download, assim não precisaria prioriza individualmente.
Para começar quero registrar como faria para controlar o tráfego de dowload de um link de 512k entre 4 computadores. A interface da lan (ou saída do tráfego do roteador de internet para a lan) será a eth0, assim as regras para definir taxa garantida de 128k e limite de 512k ficariam assim:
tc qdisc add dev eth0 root handle 1:0 htb default 9
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 512kbit
tc class add dev eth0 parent 1:1 classid 1:9 htb rate 8k
tc class add dev eth0 parent 1:1 classid 1:101 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:102 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:103 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:104 htb rate 128k ceil 512k
tc qdisc add dev eth0 parent 1:9 handle 90: sfq perturb 10
tc qdisc add dev eth0 parent 1:101 handle 1010: sfq perturb 10
tc qdisc add dev eth0 parent 1:102 handle 1020: sfq perturb 10
tc qdisc add dev eth0 parent 1:103 handle 1030: sfq perturb 10
tc qdisc add dev eth0 parent 1:104 handle 1040: sfq perturb 10
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.101/32 flowid 1:101
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.102/32 flowid 1:102
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.103/32 flowid 1:103
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.104/32 flowid 1:104

Temos assim, a definição do htb como qdisc, a classe que estabelece a capacidade do link em 512k, as classes que definem as taxas para cada ip, as qdisc para cada uma destas classes e os filtros para direcionamento dos tráfegos de saída.
Acredito que seja simplesmente isto para fazer o controle básico de download embora ainda não tenha posto isto em prática. Num futuro gostaria de poder contar com as possíveis vantagens da utilização dos parâmetros quantum, burst e cburst (entre outros).
Por enquanto era isto, assim que conseguir testá-los vou usar basicamente estas mesmas regras com a interface de saída do roteador para o roteador de internet (eth1) para controle de upload, lembrando que não vou fazer nat e nem ter squid neste roteador.