O objetivo deste artigo é introduzir o tema "qualidade de serviço" (QoS) na Internet. Ele não será um "livro de receitas" para QoS no Linux, pois já existem documentos mais apropriados para esse fim.
"A maneira de meu pai resolver as coisas se acabou. Ele mesmo sabe disso." -- Michael Corleone
Nos anos 90, oferecer acesso à Web aos usuários, ou oferecer Webmail para "road warriors" era uma grata surpresa, um privilégio; não importava muito se funcionasse precariamente. Hoje em dia, tais serviços são praticamente essenciais. Os usuários esperam que funcione o tempo todo, e que funcione bem.
A Internet está tornando-se uma ferramenta crítica à missão de toda empresa, e quase todo mundo ignora, ou finge ignorar, que a Internet não foi projetada com tamanhas exigências em mente. A Internet pode, como um todo, sobreviver a um ataque nuclear massivo, mas certamente não garante que este ou aquele usuário terá acesso rápido ao seu Webmail quando isso acontecer.
E, nós, os administradores de rede, estamos tendo dificuldades em entregar uma boa qualidade de acesso à Internet aos usuários. A demanda por banda é cada vez maior, com páginas Web cheias de imagens, programas estilo Kazaa, voz sobre IP etc.
O primeiro impulso é aumentar a velocidade do link à Internet. Resolve por uns tempos, mas breve os usuários tratam de consumir toda a banda e recomeçam a reclamar. Mesmo decuplicando a velocidade, ainda assim há dificuldade em fazer o VoIP funcionar; os amantes de música, estimulados pelo link mais veloz, dão um jeito de contornar o firewall e baixar ainda mais MP3 (e também filmes); os usuários externos continuam tendo grandes dificuldades em acessar serviços da Intranet; etc. etc.
Esta é a situação de grande parte das redes corporativas hoje. Muitas vezes, a velocidade do link original realmente era insuficiente (ainda há quem use 64kbps, ou mesmo linha discada). Mas de um certo ponto em diante, é preciso trabalhar a qualidade de serviço de forma mais elaborada.
O método mais simples e bruto é usar mais de um link à Internet, destinando cada classe de tráfego para um link diferente. Por exemplo, se desejo implantar VoIP entre matriz e filial, providencio em cada ponta um link exclusivo para esse fim.
Usar dois ou mais links funciona muito bem, mas não é financeiramente viável ter um link para cada serviço: VoIP, acesso Web, Webmail, e-mail, FTP, banco de dados... Também significará em geral um enorme desperdício de banda, pois a maioria dos links ficará ociosa a maior parte do tempo, sem poder emprestar banda para outro link que talvez esteja sobrecarregado.
Então, é necessário implementar políticas de qualidade de serviço (Quality of Service - QoS) dentro do contexto de cada link, ou do único link existente como é o caso mais comum.
"Eu tentei evitar isso, mas não foi possível. Não neste... mundo" -- Michael Corleone
A Internet e o protocolo TCP/IP não foram projetados com qualidade de serviço em mente.
As primeiras redes com garantias de QoS foram as de comutação de circuitos. Exemplos: telefone, satélite e televisão. Cada fluxo de dados tem um circuito reservado entre transmissor e receptor durante todo o tempo da conexão. Funciona maravilhosamente, mas é caro.
Em redes de comutação de pacotes, temos as arquiteturas FDDI e ATM que possuem previsão de QoS. Com o advento dos switches Ethernet, esta última também pode contar com QoS, que é implementado nos switches mais caros.
Note que em todas essas arquiteturas, o QoS é implementado de todo ou em parte nos equipamentos ativos da rede; não depende da vontade dos terminais.
Mas a Internet não é uma única rede ATM ou FDDI; é uma coleção gigantesca e anárquica de inúmeras tecnologias de rede. O QoS de cada arquitetura em particular só atua nos limites de uma rede. Implementar QoS na camada de enlace não é uma opção viável para a Internet. Resta tentar fazer isso na camada de rede.
Mas um aspecto "sagrado" da Internet é a concentração de toda a inteligência nos terminais. A rede, na pessoa dos roteadores intermediários, é "burra" e só sabe repassar pacotes. Toda e qualquer garantia, desde retransmissão de erros até (eventualmente) qualidade de serviço, tem de ser implementada nos terminais.
Roteadores "burros" não têm como implementar QoS. Mas eles poderiam receber um upgrade para isso, tornando a rede como um todo mais inteligente, a ponto de suportar QoS. Os protocolos para isso já existem; o principal deles denomina-se RSVP (Resource reSerVation Protocol). Há roteadores à venda que suportam RSVP. Sim, QoS em TCP/IP é possível.
Essa implementação do RSVP na Internet (ainda) não foi feita, basicamente porque ninguém se habilita a pagar a conta. Reserva de QoS custa substituição de equipamentos por outros mais caros; custa processamento e banda; como identificar e tarifar o usuário final ? Um RSVP totalmente gratuito está fora de questão - todos os usuários abusariam do serviço, solicitando QoS para qualquer bobagem.
De qualquer forma, o RSVP é uma solução válida numa rede TCP/IP fechada. Você pode comprar roteadores que implementem RSVP para sua empresa e usar aplicações que façam uso de RSVP, e então terá uma rede inteligente com QoS perfeito. Quem sabe no futuro, provedores Internet façam o mesmo em suas redes, e vendam esse serviço para clientes de uma região etc.
Restam dois problemas: as aplicações que não sabem usar RSVP (que infelizmente são a suprema maioria), e a comunicação com o resto da Internet onde RSVP não é implementado. Na verdade o problema original continua exatamente do mesmo tamanho :)
Outras técnicas, mais indiretas, complexas e talvez difíceis de entender, são necessárias para implementação do QoS na Internet.
"E, por favor não perca o controle, como de costume" -- Virgil Solozzo
A verdade básica é que podemos controlar apenas os pacotes que transmitimos. Não podemos controlar o que recebemos (i.e. o que transmitem para nós).
Naturalmente, podemos usar regras de firewall para ignorar determinado tipo de tráfego; mas aquele tráfego continuará ocupando banda do nosso link. Só nos resta esperar que o transmissor desista :)
Repetindo, só temos 2 ferramentas para implementar QoS em TCP/IP sem RSVP:
No Linux padrão, só é possível ignorar (descartar) pacotes que entram pela interface de rede; não há como atrasar a entrega de um pacote da rede para a aplicação. É uma limitação importante.
Numa rede corporativa pequena típica, ligada à Internet por um roteador e um link, o QoS será implementado apenas no roteador, considerando que os usuários em geral não colaboram voluntariamente.
Como o roteador vai ter no mínimo 2 interfaces de rede, é possível controlar a transmissão tanto para a Internet como para a rede interna, bem como descartar pacotes vindos tanto da Internet como da rede interna.
Portanto, temos não 2 mas 4 ferramentas, rudimentares é bem verdade, para implementar QoS:
Lembrar que, no Linux padrão, as ferramentas 3 e 4 restringem-se a descartar pacotes.
Quando o "roteador" é na verdade um pobre computador Linux que também implementa proxy, Webmail, antispam e outros serviços, a capacidade de QoS fica prejudicada:
Para implementar QoS de forma eficaz, precisamos de um roteador "puro", ou seja, que não roda nenhum serviço utilizado freqüentemente. Isso ficará mais claro ao longo dos próximos tópicos.
"Eu fiz o que pude, Kay, para protegê-la dos horrores deste mundo" -- Michael Corleone
Quando temos um link privado, onde controlamos os roteadores das 2 pontas, podemos implementar QoS praticamente perfeito, pois controlamos ambos os sentidos de transmissão, e portanto ambos os sentidos de recepção. (Uma coisa óbvia, mas de obviedade em obviedade reunimos elementos para construir QoS em TCP/IP.)
O mesmo se aplica quando dois ou mais sítios estão ligados à Internet, e todo o tráfego é estritamente entre os sítios. Se controlamos todos os sítios, é possível implementar um bom QoS.
Uma outra situação freqüente é dois (ou mais) sítios ligados à Internet, todos pelo mesmo provedor. Se a distância geográfica não for muito grande, pode ser que todos os sítios estejam numa mesma rede ATM ou Frame Relay, e isso nos dá a opção de solicitar QoS ao provedor, ao menos no tráfego intra-sítios.
Isso não nos livra de implementar QoS também em nossos roteadores, mas pelo menos assegura que teremos um caminho com comportamento conhecido e estável.
"Afinal, vou precisar de uma carta de apresentação para entrar na fila ?" -- Frank Pentangeli
Além das ferramentas supracitadas, temos um outro fator indireto que permite a implementação de QoS. É o controle de congestionamento do protocolo TCP, que é imitado por todos os protocolos não-TCP decentes.
Esse controle, presente em qualquer pilha TCP/IP moderna, faz o TCP diminuir o ritmo de transmissão na ocorrência de perda de pacotes. O propósito original é evitar entupir a fila de transmissão dos roteadores com pacotes duplicados. O controle de congestionamento também adequa o ritmo de transmissão à latência do caminho.
Interessante notar que esse controle foi adicionado ao TCP muitos anos depois da criação da pilha TCP/IP. Ele não exige nenhuma alteração nos protocolos em si, apenas nas implementações dos terminais.
Assim, temos um meio indireto de controlar o tráfego donwstream: se começarmos a descartar pacotes, as pilhas TCP/IP dos terminais detectarão isso e procurarão reduzir a velocidade, até não haver mais perdas.
Isso não funciona para protocolos de transporte sem esse controle. Exemplo: se alguém resolver bombardear outrem com pacotes ICMP, não adianta ignorar o tráfego. O jeito é chamar a polícia para rastrear a origem.
No tráfego upstream, também poderíamos descartar pacotes para controlar tráfego, mas isso é um pouco estúpido, pois estamos jogando nosso próprio trabalho fora.
Para upstream, a estratégia ideal é "segurar" os pacotes no roteador, aumentando artificialmente a latência do caminho, o que também fará a conexão TCP diminuir sua velocidade.
"Eu peço desculpas pelo meu filho. Os jovens falam, quando deveriam ouvir" -- Vito Corleone
Quando se fala em QoS, a primeira coisa que vem à mente é o controle de banda.
As formas de controlar banda são basicamente as sugeridas no tópico anterior. Descartamos ou "atrasamos" pacotes para sugerir às conexões que reduzam a velocidade.
Supondo o seguinte caso: limitar download para o usuário X, pois ele está puxando músicas.
Vamos implementar o QoS no roteador intermediário. Temos duas opções: descartar pacotes no downstream, ou "atrasar" pacotes na retransmissão para a rede local. Qual das opções é melhor, já que ambas funcionarão?
Sem dúvida, atrasar os pacotes é melhor que descartar, pois evita retransmissões desnecessárias que consomem banda. Também é mais fácil implementar controles de banda diferentes para cada usuário.
Agora outro caso: link de 256kpbs, limitar download Web para acomodar um telefone VoIP (64kbps).
Isso é mais difícil de resolver, pois não podemos controlar diretamente o download, ou seja, o que mandam para nós. O jeito é reservar 64kbps para VoIP, deixar 192kbps para Web, e descartar/atrasar tudo que ultrapasse 192kpbs, e rezar para que o controle de congestionamento funcione.
Haverá o inconveniente de, mesmo que o VoIP não seja usado, a banda reservada não poderá ser emprestada para outros tráfegos.
Se o tráfego web usa um proxy que roda no próprio roteador, é ainda mais difícil, pois, no Linux, a única coisa que podemos fazer com pacotes entrantes é descartar seletivamente.
Descartar pacotes implica em desperdício de trabalho e retransmissões; é ainda outro preço do QoS.
Em qualquer dos dois casos acima, possivelmente o tráfego Web terá picos downstream maiores que 192kbps antes que o controle de congestionamento atue. Como os picos quebram o VoIP, na prática teríamos de reservar mais banda para VoIP, o que desperdiça mais banda VoIP ociosa e prejudica o acesso à Web.
Tais inconvenientes são o preço de implementar QoS num sistema que não foi projetado para isso. Ainda assim, o VoIP será muito mais barato que o circuito telefônico correspondente...
"Em cinco anos a família Corleone estará completamente legalizada" -- Michael Corleone
Embora largamente ignorada e negligenciada, é a latência a grande vilã da qualidade de serviço. Uma latência grande é mais incômoda ao usuário que uma baixa vazão. O usuário quer ver a barrinha andando, não importa que muito devagar ;)
Latência é o tempo que algo (e.g. um pacote) leva para ir da origem ao destino. Alguns chamam latência de "atraso", o que considero errado, pois atraso é algo evitável. A latência tem um patamar mínimo inevitável, pois a velocidade da luz é limitada e os roteadores intermediários têm de processar os pacotes.
O componente variável, evitável, da latência, é o enfileiramento nos roteadores intermediários.
A fila do roteador é algo útil e necessário. Imagine o roteador que liga sua rede local, de 100Mbps, à Internet, através de um link de 64kbps. Sem uma boa fila de transmissão, haveria grande perda de pacotes no sentido rede -> Internet.
Mas a fila introduz latência. Imagine uma fila de 50KBytes, um link de 400kbps, e uma latência-base de 50ms com fila vazia. a latência pura para 50+1000=1050ms. Fica 21 vezes pior. Tais mudanças bruscas de latência fazem o controle de congestionamento do TCP retransmitir pacotes, fazem aplicações multimídia (e.g. VoIP) degradarem a qualidade etc. etc.
Não podemos simplesmente eliminar a fila para melhorar a latência, pois isso teria um custo enorme de perda de pacotes, e consequentemente uma queda na vazão. De maneira geral, vazão e latência são mutuamente prejudiciais: providências que melhorem um fator, pioram o outro. A fila do roteador é um caso bem típico.
Em particular em links ADSL, a fila do roteador é bastante grande, para privilegiar a vazão, em detrimento da latência. Para evitar latência, basta que nosso roteador Linux limite a transmissão de pacotes à banda que realmente temos, devidamente descontada dos "overheads". Isso evita enfileiramento no roteador ADSL.
Assim, com um controle de banda, estamos na verdade resolvendo um problema de latência.
Para evitar enfileiramento no roteador ADSL da empresa telecom, e portanto evitar latência no downstream, temos de fazer algo feio: descartar ou atrasar pacotes entrantes (no Linux só é possivel descartar), pra que os fluxos se adaptem e evitem mandar dados em excesso. Também é um tipo de controle de banda.
Em ambos os casos, para uma banda hipotética de 100kbps líquida, teremos de controlar a banda para uns 90kbps nos dois sentidos, para evitar enfileiramento. Isso porque as velocidades oscilam um pouco, e precisamos deixar uma margem de segurançca para oscilações positivas.
Controlar a banda em 100kbps seria absolutamente inútil, pois o link não entrega mais que isso mesmo que haja pacotes enfileirados do outro lado. É ainda mais um preço do QoS: estamos na verdade reservando um pouquinho da banda para detectar congestionamentos.
Ao evitarmos enfileiramento nos roteadores ADSL de ambas as pontas, o problema não desapareceu; ele simplesmente pulou para o nosso roteador Linux ;) Teremos de lidar com ele de alguma forma mais inteligente, privilegiando algum tipo de tráfego em detrimento dos demais. Essa discussão será objeto de tópicos futuros.
Usar um link não-ADSL também pode ajudar na latência, pois os roteadores de borda (os da telecom, não o nosso) não costumam usar filas tão grandes, o que colabora para diminuir a latência.
"Você me disse 'em cinco anos a família Corleone estaria completamente legalizada'. Bem, já fazem sete anos" -- Kay Adams
Jitter é a oscilação da latência. Se os pacotes chegam sempre com a mesma latência, o jitter é zero.
O jitter nunca é bom. No caso do tráfego de dados, o controle de congestionamento é prejudicado pelo jitter, mas bem ou mal os dados acabam sendo transmitidos e tudo acaba bem. O jitter realmente incomoda em sistemas de multimídia em tempo real, como VoIP e rádio via Internet.
O jitter é impossível de eliminar completamente do TCP/IP. Todo software multimídia para TCP/IP tem algum buffer para compensar o jitter até certo ponto. O problema é que esse buffer aumenta a latência para o usuário final.
Exemplo: se um software VoIP possui um buffer de 500ms, ele suportará jitters na rede de até 250ms positivos ou negativos. Mas a voz de um interlocutor vai demorar 500ms + latência da rede para sair no outro lado, e isso é *extremamente* desagradável em telefonia. (Não seria problema numa rádio via Internet, todavia.)
Bons softwares são capazes de adaptar-se ao jitter da rede, mas o processo de adaptação causa perda de qualidade, e um jitter muito grande continua sendo ruim para VoIP.
O que podemos fazer, assumindo que nossa banda é suficiente e os softwares VoIP são bem-comportados, é colocar os pacotes VoIP em prioridade máxima, transmitindo-os ou repassando-os tão logo são recebidos, evitando qualquer enfileiramento, descarte ou competição com outros serviços.
Isso não resolve o jitter eventualmente introduzido pela Internet mas assegura que nosso roteador não está piorando as coisas. Em último caso, teremos de alugar um link melhor (e.g. migrar de ADSL para Frame Relay).
"Se o seu patrão pensa em tentar alguma coisa, saiba que não sou nenhum empresário barato" -- Woltz
Existem alguns nomes e algoritmos para controle de banda em uma rede de comutação de pacotes.
Balde furado: tipo de fila representada alegoricamente por um balde com um furo no fundo. A fila em si é o volume do balde. Independente de como cheguem dados na fila, a saída é sempre uniforme em vazão e latência, com jitter zero.
Se os pacotes enfileirados ultrapassam a capacidade da fila, eles são jogados fora ("vazam fora").
Sim, eu sei que a vazão de um balde furado real varia conforme a quantidade de água no balde, devido à pressão hidrostática. Mas no balde furado virtual, essa vazão é fixa.
Token bucket (recipiente de fichas): Uma "máquina" gera fichas num intervalo fixo. As fichas caem num recipiente. Os pacotes vão pegando fichas (proporcionalmente ao seu tamanho e.g. se a ficha vale 100 bytes, um pacote de 1500 bytes precisa de 10 fichas) para serem transmitidos.
Se não há fichas suficientes, o pacote aguarda até a máquina produzir as fichas que faltam. Este é o controle básico de banda.
Se não há pacotes na fila, a coisa fica mais interessante. As fichas poderiam acumular em grande monta, possibilitando uma longa rajada acima da banda quando mais pacotes chegassem. Para evitar isso, o recipiente de fichas tem amanho limitado, e esse tamanho corresponde à rajada aceitável.
Note que o balde furado é um caso-limite do token bucket; basta reduzir a capacidade do recipiente de fichas a zero.
CBQ: O controle de banda é baseado no tempo ocioso da fila, ou do link. Se a capacidade total é 100Mbps, e a banda deve ser de 10Mbps, o link deve permanecer ocioso 90% do tempo.
A ociosidade é criada através do atraso na liberação de pacotes. Para a ociosidade desejada, é calculado o tempo ideal entre duas liberações. No nosso exemplo acima, se o pacote médio tem 1000 bytes, os pacotes devem ser liberados em média a cada 0.8ms.
Note que o CBQ não conta bytes, e sim pacotes, e por isso a informação do tamanho médio de pacote deve ser de boa qualidade.
O tempo médio de liberação é mantido através de uma média móvel exponencial (EWMA). Se a média está acima do ideal (0.8ms no nosso exemplo), os pacotes são mais atrasados. Se está abaixo, os pacotes são entregues adiantados.
Se não houver pacotes para entregar, a média móvel pode aumentar muito, possibilitando longas rajadas quando houver enfim dados. Da mesma forma, se a média cair muito, vai segurar pacotes por tempo excessivo.
Para evitar essas anomalias, a média móvel possui limitadores que evitam valores muito altos ou muito baixos.
Se houver um pacote na fila, e a linha estiver livre, mas transmitir o pacote significaria passar do limite de banda controlado, o comportamento de uma fila pode estar em dois tipos básicos:
Conservador de trabalho: transmite o pacote. Traz um melhor aproveitamento do link (que geralmente tem custo fixo), mas pode causar rajadas, e oscilações bruscas na latência (que aumentam o jitter).
Não conservador de trabalho: não transmite o pacote. Causa ociosidade no link, mas evita oscilações na latência (o que diminui o jitter).
Uma analogia para fixar o conceito de conservação de trabalho é o famoso "caixa exclusivo para gestantes, idosos e crianças de colo". Em alguns estabelecimentos, o caixa atende pessoas "normais" quando não há gestantes; este conserva o trabalho, pois o caixa pode ser utilizado o tempo todo. Mas se a gestante aparecer enquanto houver alguém sendo atendido, terá de esperar ao menos este atendimento finalizar.
Já outros lugares fazem reserva rígida do caixa de gestantes; se não há gestante, o caixa fica ocioso. Este não conserva o trabalho, e teoricamente joga dinheiro fora, mas garante que a gestante será imediatamente atendida quando aparecer.
"O poder desgasta àqueles que não o tem" -- Calo
É difícil, e talvez inútil, controlar QoS dentro de um canal VPN.
As estratégias de QoS para TCP/IP têm poucas ferramentas com que trabalhar, pois quase nada é garantido pelo protocolo de rede. Mas existe uma garantia "dura", que é a vazão do link. É talvez o único parâmetro estável na comunicação TCP/IP.
Um canal VPN não possui essa garantia, pois depende da velocidade de uma conexão subjacente. Isso quebra algoritmos como o token bucket. Como a interface de rede virtual criada pelo túnel VPN é processada por software, isso quebra o CBQ que é baseado em tempo ocioso da interface de rede.
Naturalmente é possível, e recomendável, aplicar QoS à conexão que serve de transporte ao VPN. Se há tráfegos com necessidades diferentes de QoS, pode-se criar vários túneis VPN, cada um com um QoS diferente.
Também é possível e recomendável atribuir uma disciplina de tráfego (de prioridade ou de justiça) à interface de rede virtual VPN. As disciplinas serão objeto dos tópicos a seguir.
"Ele (Don Corleone) nunca pede um segundo favor quando o primeiro é recusado." -- Tom Hagen
Basicamente, o que vimos até agora foram formas de controlar a banda em uma fila de um dispositivo de rede, ou de sub-filas que alimentam a fila principal. Mas, o que fazer quando a fila está cheia de pacotes?
A disciplina de tráfego define como os pacotes da fila serão priorizados. Dentro da banda limitada que definimos, alguns pacotes serão privilegiados, em detrimento do resto.
Reiterando, a disciplina só atua quando há fila de pacotes, e a banda está sendo totalmente ocupada. Se não há fila, todo pacote é transmitido assim que entra na fila.
"Primeiro vá ver seus filhos. Depois entre na fila [para falar com Michael], como todo mundo." -- Carmella Corleone
Esta é a disciplina que qualquer roteador sem QoS implementa: o primeiro pacote da fila é o primeiro a ser transmitido.
No caso específico do Linux, a disciplina padrão pfifo_fast permte que pacotes marcados como "tráfego interativo" furem a fila. Portanto, tem um certo controle de prioridade embutido (abordaremos controle de prioridade no tópico a seguir). Portanto, o Linux faz algum QoS por padrão, sem qualquer configuração explícita.
Não fosse por isso, administrar servidores remotamente, em redes sem QoS, seria não apenas desagradável, mas praticamente impossível.
"Foi ele quem entregou papai. Não quero vê-lo mais. Que seja prioridade em sua lista" -- Santino Corleone
Nesta disciplina, alguns usuários ou serviços terão prioridade sobre outros, e "furam a fila". Entre usuários e serviços com a mesma prioridade, vale a ordem na fila.
Os usuários ou serviços com maior prioridade terão a latência e o jitter diminuídos. Os serviços e usuários preteridos terão, por outro lado, uma piora nesses parâmetros. É preciso tomar muito cuidado com a priorização. Se um serviço de alta prioridade gerar pacotes demais, as prioridades mais baixas morrem de fome.
Para evitar isso, pode-se associar um controle de banda separado para cada fila de prioridade, para que sobre alguma banda às prioridades mais baixas mesmo em caso de saturação da alta prioridade.
Também é comum o "empréstimo" de banda entre diversas prioridades, de modo que a ausência de tráfego de alta prioridade não gere ociosidade no link.
No Linux padrão, controles com esse nível de refinamento não estão disponíveis para downstream. E de qualquer forma não podemos controlar o que nos é mandado; apenas descartar eventuais excessos. Lembrar sempre que, se o Linux é um roteador puro, temos a chance de controlar o tráfego no upstream para a rede local. Só estamos "encrencados" se nosso roteador é também cliente ou servidor final de algum serviço.
"Você vem em minha casa me pedir para matar por dinheiro... Mas isso não é justiça. Sua filha ainda está viva." -- Vito Corleone
O controle de justiça usa técnicas estatísticas para garantir que cada conexão tenha direito a uma fatia justa da banda total. Isso evita que uma conexão rápida inunde a fila de transmissão e mate de fome as outras conexões, como infelizmente é comum em TCP/IP.
O funcionamento deste controle é um tanto curioso. Basicamente, as conexões são classificadas por um "hash" (código de resumo) em algumas sub-filas.
Em cada rodada do SFQ, cada sub-fila recebe a chance de transmitir um pacote, assim como jogadores num jogo de cartas. A sub-fila vazia passa a chance adiante e não acumula créditos por isso.
O controle implementado desta forma evita que se tenha de controlar a banda individual de cada conexão (podem haver centenas de milhares delas), e ainda assim ser quase perfeitamente justo.
Vamos supor que nosso SFQ tenha apenas 4 sub-filas. (Um SFQ real tem algo como 1024 sub-filas.) Como a distribução das conexões é essencialmente aleatória, algumas situações azaradas podem sim ocorrer, como estas:
a) um cliente abre várias conexões rápidas, e cada uma se apossa de uma sub-fila, matando outras conexões de fome;
b) grande número de conexões cai, por azar, em uma única sub-fila, privilegiando as poucas conexões que ficaram de fora.
Para evitar que tais situações cheguem a prejudicar os usuários, o "hash" é mudado e as conexões redistribuídas a cada poucos segundos. Se ocorrer uma má distribuição, não importa, pois ela será desfeita em muito breve.
Esse controle dilui a latência entre as diversas conexões. Como existe enfileiramento no roteador, a latência geral sobe, mas ao menos o dano é distribuído entre todos os usuários. O jitter, que será provavelmente alto também, não parece ser consideravelmente melhorado ou piorado por este controle.
Todo roteador que não implementasse qualquer política de QoS deveria ao menos implementar essa justiça entre conexões.
Tal controle vale apenas para o upstream, portanto pode não surtir o efeito esperado numa rede típica onde o tráfego downstream é o mais importante.
"Não se pode ser justo com animais" -- Frank Pentangeli
O controle de justiça é daninho para tráfego de multimídia em tempo real, pois coloca-o em pé de igualdade com outros tráfegos menos exigentes.
O controle de prioridade é potencialmente perigoso se o tráfego de alta prioridade tiver volume inesperadamente alto. Notamos que os dois tipos de controle têm defeitos "opostos".
"Sempre gostei de pensar a família Corleone como o Império Romano, com capos, caporegimes..." -- Frank Pentangeli
Pelo conflito acima, e vários outros que já citamos, vemos que uma única política ou disciplina para todo o tráfego não será suficiente. Será necessário estruturar o tráfego em "sub-filas" ou algo semelhante.
No Linux, e possivelmente em outros sistemas operacionais, o controle de tráfego é estruturado da seguinte maneira:
- o tráfego é dividido por classes. Cada classe funciona como uma sub-fila de transmissão;
- pode haver classes dentro de outras classes;
- cada classe possui um controle de banda, podendo haver ou não empréstimo de banda ociosa a outras classes-irmãs; (o controle de banda está associado ao conceito de classe)
- a fila principal do roteador retira pacotes primeiro da classe de maior prioridade; quando esta estiver esgotada ou com a banda estourada, vai à 2a prioridade e assim por diante; (portanto, implementar prioridade e controlar latência implica em usar classes)
- a classe-pai, quando solicitada pela fila principal, retira pacotes das classes-filhas, também de acordo com a prioridade e a banda de cada uma;
- a banda total da classe-pai limita o total de pacotes retirados das classes-filhas;
- A classe que não tem classes-filhas deve ter então uma disciplina de tráfego, que será prioridade por TOS (pfifo_fast, que é default) ou controle de justiça (sfq, recomendada para tráfego de dados geral). (aqui pode-se então implementar justiça)
- O pacote que entra na fila de transmissão é direcionado a uma das classes existentes através de filtros. Os filtros podem basear-se em características do pacote IP (endereço, porta etc.) ou em marcações feitas pelo iptables.
- Na fila de recepção de pacotes, só é possível anexar filtros, não classes nem disciplinas;
- Pode haver filtros cuja função é unicamente descartar pacotes com determinadas características e/ou que ultrapassem determinada banda;
- Deduz-se então que a única possibilidade de controlar tráfego de entrada é usando filtros de descarte de pacotes.