Adocao de Quality of Service em Ambientes de Operadores de Redes

Introdução

Este artigo discute os conceitos e a correta implementação de diversos dos mecanismos de Qualidade de Serviço (Quality of Service) ou QoS para infraestruturas de redes baseadas na tecnologia de enlace Ethernet e em combinação com redes IP e MPLS. Recomendo a completa e minuciosa leitura de todo o documento por parte dos profissionais engajados nos projetos de infraestrutura de redes, sejam projetos de ISPs ou projetos de ambientes corporativos.

Por que o QoS é necessário?

Não atreva-se a configurar um mix complexo de tecnologias, só porque você acha que precisa, sem ao menos compreender com clareza para que serve o QoS e quais problemas são resolvidos com estas estratégias.

É fato que as infraestruturas de redes estão cada vez mais convergentes, no sentido de que estas redes atualmente transportam uma magnitude de aplicações e serviços orientados a aplicações de Dados, Voz e Vídeo, sendo que estas aplicações operam e são transportadas sobre uma mesma infraestrutura em comum e baseada no protocolo IP. Este cenário de convergência (Dados, Voz, e Vídeo, todos sobre o protocolo IP) diminui custos muito significativamente, simplifica as infraestruturas e a complexidade dos ambientes dissimilares, além de reduzir o esforço operacional e quantidades de equipes, viabilizando, portanto, novas aplicações e facilidades.

No entanto, cada tipo de tráfego - Vídeo (VoD, IPTV, vídeo-conferência...), Voz (VoIP, Telefonia IP, Colaboração...), Dados (Internet recreativa, aplicações corporativas diversas, aplicações de missão crítica, network control, etc.) - possui requerimentos distintos em termos de transporte e sensibilidades particulares. Sem contar também com adventos tais como o Fibre Channel over Ethernet (FCoE), cujos pacotes exigem um fabric completamente capaz de assegurar zero descartes de pacotes - no caso do FCoE, resolvemos isto com tecnologias Ethernet mais avançadas, tais como Data Center Bridging (DCBX, PFC, ETC, VoQ, etc., ou tecnologias similares.).

Para exemplificar as exigências em termos de transporte para cada uma das aplicações, posso citar:

Tipos de Aplicações em uma Rede e Respectivas Características e Requerimentos de Transporte

Tipo de Tráfego	Características
Voz	Uma chamada telefônica por VoIP consome pouca banda, e esta banda é fixa, ou seja, definida pelo codec (codificador/decodificador) empregado. O overhead (a razão cabeçalho/payload) é tida como alta, pois boa parte do payload total corresponde aos cabeçalhos necessários para viabilizar o transporte. Além disto, voz sobre IP é um tipo de tráfego que exige transmissão absolutamente em tempo real, e, portanto requer prioridades que assegurem baixa latência (pouquíssimo tempo de espera nas filas), baixo jitter (a variação de atraso entre os pacotes tem que ser bem baixa) e quase zero índice de perda de pacotes (não há retransmissão de pacotes VoIP/IPT perdidos, pois é transportado por RTP/UDP).
Vídeo	Dependendo da plataforma, uma chamada de videoconferência pode consumir banda bastante razoável, comportando-se neste sentido e aparentando ser uma transmissão de dados, mas com as mesmas exigências de transporte de uma chamada de VoIP, ou seja, baixa latência, baixo jitter, mínimo índice de perda de pacotes, e baixa proporção de pacotes fora de ordem/reordering, etc.
Dados	Uma transmissão de dados pode ser considerada como “normal”, “razoável”, ou “greedy” (egoísta, e que consume muita banda e esgota as filas). No entanto, a referida transmissão não é muito sensível à latência (o janelamento do protocolo TCP se encarrega dos efeitos adversos), tampouco a jitter, e descartes são resolvidos automaticamente pelo próprio protocolo TCP (por meios de retransmissões dos segmentos eventualmente perdidos durante os congestionamentos).
Dados de Aplicações de Missão Crítica	Há aqui o conceito de dados “críticos”, que são aquelas aplicações críticas para o negócio da empresa e que precisam da devida prioridade e garantias de recursos de rede tais como a banda. Por exemplo, CRM, ERP e similares. Mesmo que haja outras transmissões não importantes e/ou recreativas (Internet “convencional”, por exemplo), é necessário para que haja também esta distinção entre estes casos.
Dados de Controle	Figura nesta categoria o tráfego produzido por protocolos de roteamento, que normalmente consome pouca banda, especialmente quando utilizamos protocolos mais inteligentes e através de um projeto técnico bem equilibrado (ajustes nos temporizadores, refinamento do throtlling, sumarização de prefixos, etc.). Todavia, os pacotes gerados pelos protocolos de roteamento em operação nos equipamentos da rede precisam ser processados pontualmente para garantir a estabilidade da infraestrutura e possibilitar a correta convergência desta em casos de falhas de equipamentos e/ou enlaces físicos.

O QoS é necessário porque as tecnologias de camada de enlace (L2) e de camada de rede (L3) adotadas nos operadores de redes e ambientes corporativos atualmente – a saber, primariamente Ethernet e IP, respectivamente – possuem transmissão de natureza estatística e, por conta disto, a possibilidade de ocorrerem descarte devido à insuficiência de recursos em alguns momentos é elevada e até mesmo tida como normal, desde que em níveis sustentáveis. Em adição, num ambiente de transmissão estatística - sem o emprego das ferramentas corretas - não há realmente como priorizar as aplicações mais sensíveis ao jitter, latência e descarte de pacotes. E este artigo buscará promover este entendimento.

Quais problemas são resolvidos com o QoS?

Antecipando aqui: QoS não é "um" recurso ou um procedimento apenas, mas sim uma coletânea de procedimentos e ferramentas. Isto será discutido posteriormente. As tecnologias que fomentam o QoS existem para resolver os seguintes problemas existentes em ambientes de redes de transmissão estatística. E não somente as ferramentas relacionadas ao QoS em si, mas a própria abordagem de projeto de infraestrutura ajudará muito no fornecimento da qualidade requerida pelas aplicações e serviços na rede..

Redução dos impactos da contenção e insuficiência de recursos de banda

Isto é notório em cenários onde há um excesso de banda ("oversubscription”) que precisa ser transportada através de uma ou mais partes da rede. Para exemplificar isto melhor, existe um conceito chamado “Fan-In Fan-Out”, onde o tráfego entrante registrado na interface LAN, por exemplo, é bem maior do que a capacidade nominal de saída da interface WAN (ex: 1 Gbps na LAN e 50 Mbps na WAN), como ocorre com o roteador CPE de clientes em muitos casos. Outro exemplo aqui seria dentro da própria LAN de clientes corporativos e isto é bastante comum: imagine cinco (05) switches de Acesso com 48 portas 1 Gbps usando dois (02) uplinks de 10 Gbps, sendo que o protocolo Spanning-Tree normalmente bloqueará uma destas portas uplinks para uma ou todas as VLANs do switch, dependendo do projeto, enfim... seriam 240 Gbps entrando na Distribuição e apenas 10 Gbps possíveis na saída para o Core, considerando que há dois (02) uplinks 10 Gbps mas que apenas um deles pode ser usado efetivamente. No entanto, geralmente nas LANs isto não é problema, pois na maior parte do tempo as estações/computadores não estão transmitindo, então este oversubscription dificilmente ofereceria problemas com relação à banda numa LAN. Em certos tipos de mercado (imagens, editoração eletrônica pesada, etc.), o oversubscription pode ser problema.

E, no que diz respeito à WAN, isto é frequentemente um problema, dependendo do dimensionamento do link de WAN ou do link de Internet, pois o volume de tráfego saindo da LAN através da WAN tende a apresentar picos que em alguns momentos do dia acarretam em insuficiência de recursos de transmissão (banda) pela interface WAN do roteador CPE. E isto leva frequentemente a congestionamentos e demais efeitos adversos associados tais como o global synchronization do protocolo TCP, decorrente de entupimento de filas e vários descartes, lentidões, etc.

Toda a vez que a banda real/efetiva de entrada for (bem) maior que a banda de saída, serão percebidos muitos problemas de contenção. Por estes motivos as capacidades dos enlaces e dos próprios equipamentos precisam ser bem dimensionadas para que evitemos estes gargalos e congestionamento. Porém, o aumento da capacidade dos circuitos não elimina a necessidade de implementação de QoS, até mesmo porque muitas vezes os custos são proibitivos e estes tipos de upgrades não são viáveis em curto ou médio prazo.

A ilustração a seguir mostra um cenário de "oversubscription" deste "Fan-In Fan-Out", exemplificando como isto seria em um switch na sua rede.

Oversubscription natural de um switch em uma rede LAN

Como você pode notar, a prática do dimensionamento do oversubscription é comum e perfeitamente natural em projetos de infraestrutura, pois sabemos que na maior parte do tempo integral e absoluto as estações de trabalho não estarão transmitindo, o que permite o dimensionamento estratégico dos uplinks para acomodar a vazão do tráfego "real" em horários ou situações de pico. Considerando a ilustração acima, você colocaria um uplink de 100 Gbps num switch de Acesso em uma rede corporativa? Claro que não, que loucura! Se você monitorasse essas portas de acesso (que conectam para os usuários) você descobriria que eles estão longe, muito longe mesmo, de consumir aquela banda de 1 Gbps cada uma. Mas, talvez, ou fatalmente em alguns casos, um uplink de 1 Gbps não fosse dar conta de transportar o tráfego real/efetivo de todas as estações em determinados horários do dia. Compreende?

Agora consideremos outra topologia aqui, a de uma rede corporativa como um todo. Como deveríamos dimensionar os enlaces antes de experimentarmos problemas de congestionamentos e ainda sem considerar aqui o emprego de quaisquer ferramentas específicas para Quality of Service (QoS):

Oversubscription e planejamento de capacidades para transmissão estatística com foco no problema de congestionamentos

Conforme citado anteriormente, numa LAN problemas de congestionamentos são relativamente raros, especialmente em segmentos tradicionais. Talvez em ambientes onde há o processamento de imagens de altíssima resolução ou fábricas de software e ambientes de pesquisas com alta demanda de canal de rede e processamento.

Isto significa, considerando a ilustração acima, que a rede LAN do ambiente demonstrado fluiria excepcionalmente bem na questão de disponibilidade e suficiência de banda para os usuários. Mas nem tudo é perfeito, e isto foi destacado propositalmente nesta topologia.

Com o advento da centralização de recursos computacionais em um data center, e os serviços nas nuvens privadas, públicas ou híbridas, há uma demanda natural por escoamento do tráfego originado no Acesso até o local onde encontram-se estes recursos, ou seja, a "nuvem", o "data center" e a "Internet". Isto promove um fluxo de tráfego bastante "Norte-Sul" nestes tipos de ambientes, e as camadas da rede - em especial a Distribuição/Agregação e Core" normalmente são dimensionadas para acomodar a agregação estatística deste tráfego. No ambiente LAN exemplificado pela topologia acima, vemos que quase tudo está OK neste sentido, exceto pelos links de Internet e de um dos links que transporta os usuários até o data center, os quais podem estar subdimensionados.

O problema da contenção é ainda mais notório em três situações discutidas a seguir:

• Capacidade do link de Internet em uma empresa do segmento corporativo: o circuito contratado é insuficiente para acomodar a carga de tráfego e demanda de usuários, quantidade de acessos simultâneos, etc.
• Capacidade do link de WAN que conecta matriz, filiais, etc.: a capacidade dos circuitos de uma ou mais localidades está aquém da demanda real dos usuários, especialmente porque os recursos corporativos gerais estão centralizados na matriz ou em um data center.
• Capacidade nominal das interfaces uplinks de switches e roteadores dos provedores de acesso de Internet (ISP): a previsibilidade e dimensionamento da razão estatística das transmissões é muito mais complicada em ambientes de operadores de redes ou ISPs. A rede vai coletando e transportando os pacotes dos assinantes até os pontos de interesse da infraestrutura do provedor, tais como CDNs, peering e trânsito, e planejar a capacidade de uma rede metropolitana é algo sempre mais complexo.

São três das situações que mais se qualificam a problemas envolvendo a contenção e insuficiência de recursos de banda.

OBS: eu poderia ter ido diretamente ao ponto e informado estes três "bullets" acima, certo? Mas preferi fazer isto de forma mais ampla e didática, pois nem todos os usuários/visitantes da Wiki do BPF são profissionais experientes.

Redução da latência fim-a-fim

Há diversos tipos de atrasos nas transmissões que fatoram para a latência fim a fim presente na comunicação entre dois dispositivos que desejam se comunicar (um cliente e um servidor na Internet, por exemplo). Entendamos estes tipos de atrasos.

• Atraso de Processamento: um índice de atraso ou delay variável que é alimentado pelas tecnologias de processamento de pacotes dos equipamentos presentes na rede. Há diferenças nem significativas entre arquiteturas de comutação baseadas em software (softrouters) e arquiteturas baseadas em silício especializado, seja de mercado ("merchant") ou customizado ("custom"). É um atraso variável porque tudo dependerá da demanda por processamento de tráfego naquele equipamento (sessões, acessos, taxa efetiva de pacotes por segundo, etc). E, como a rede opera por modelo de transmissão estatística, isto significa que, dependendo da arquitetura do equipamento, maior demanda por tráfego e sessões acarretará em aumento de processamento e, consequentemente, o aumento deste tipo de atraso sobre as transmissões.
• Atraso de Enfileiramento: um tipo de atraso de natureza também variável. Quando pacotes precisam ser transmitidos através de uma interface do equipamento, uma verificação é feita acerca da disponibilidade de recursos para a sua transmissão. Caso não haja recursos suficientes, o pacote é posicionado em uma fila aguardando a sua vez para ser transmitido. Como o controle de filas é igualmente estatístico, isto é, em dadas ocasiões poderá haver cinco pacotes numa fila e, em outros, 30 pacotes na fila, haverá esta flutuação que provocará diferenças neste atraso. Para constar, um único pacote numa fila já significa que o meio físico correspondente encontra-se congestionado!
• Atraso de Serialização: um atraso de natureza fixa, medido em microsegundos, relacionado à codificação dos dados em bits para transmissão no meio físico associado à interface de saída para aquele pacote.
• Atraso de Propagação: um delay fixo, mas que varia de meio físico para meio físico. Por exemplo, 2 Mbps por transmissão sem fio propaga mais rápido do que os mesmos 2 Mbps sobre uma fibra óptica. Uma fibra óptica possui características de propagação melhores que um cabo elétrico, etc. Outro exemplo tem relação com a distância: um enlace 1 Gbps propaga mais rapidamente numa fibra ótica a 10 km de distância do que sobre uma fibra a 70 km de distância, isto é, considerando as mesmas condições de qualidade. Acho que não preciso aqui exemplificar o caso de uma comunicação satelital...

Atenuação do jitter

Como os atrasos (delays) incluem o fixo (serialização e propagação) e o variável (processamento e enfileiramento), e são computados a cada salto, ou seja, a soma de todos os atrasos ao longo do caminho entre "A" e "B", e, especialmente no caso dos atrasos variáveis, ocorrerão sempre diferenças nos tempos de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão, resultando em variações no tempo de chegada até o destino entre pacotes deste mesmo fluxo. Isso é o que chamamos de jitter. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das especificações auditivas e visuais do ser humano que interage através da aplicação afetada.

Redução do descarte de pacotes

É considerado “mortal” para tipos de tráfego tais como voz e vídeo, pois aplicações interativas como VoIP e videoconferência são tipicamente transportadas pelo protocolo UDP, o qual não possui mecanismos para retransmitir segmentos perdidos. Transmissões de dados podem gerar também uma lentidão grande em transmissões de dados críticos devido ao “recuo em massa” da janelas das transmissões TCP afetadas.

Atenuação dos efeitos decorrentes da fragmentação de pacotes e e recebimento de pacotes fora de ordem

Caso roteadores estejam fragmentando pacotes em uma rede, uma prática abominável nos dias atuais, e em adição aos projetos assimétricos de caminhos de rede, isto poderá provocar o aumento de processamento dos equipamentos, além da latência fim a fim e jitter.

O QoS é necessário também numa rede Wi-Fi (WLAN)?

Claro! E vou além: redes Wireless LAN (WLAN) também precisam de QoS, pois o meio “físico” da rede Wireless é completamente compartilhado, portanto sofisticados mecanismos de contenção e coordenação de transmissões são exigidos. Para iniciarmos aqui, todas as transmissões são half-duplex por natureza numa WLAN. O mecanismo de contenção do acesso ao meio físico nas redes WiFi é o CSMA/CA (Congestion Avoidance) para o chamado "airtime fairness”, e emprega uma infinidade de procedimentos e tecnologias, incluindo Distributed Coordination Function (DCF), Point Coordination Function (PCF), Short Inteframe Space (SIFS), Extended Interframe Space (EIFS), Distributed Interframe Space (DIFS), Reduced Interframe Space (RIFS), Clear Channel Assessment (CCA), Contention Window (aCWmin e aCWmax), Network Allocation Vector (NAV), etc. No caso das WLANs, implementamos os componentes de QoS conforme os padrões IEEE 802.11e / WMM e demais padões, onde mapeamos as transmissões da rede cabeada (as suas marcações) para marcações específicas na parte WLAN que possuem “melhor tempo sobre o ar” (ou tempo mais curto de contenção). As classes de tráfego da WLAN são mapeadas para as classes de tráfego da LAN, e vice-versa, durante a integração entre estas duas redes.

O QoS em ambiente WLAN está fora do escopo deste artigo. Talvez fique para outra oportunidade.

Conheça os tipos de QoS

O QoS no geral pode ser categorizado em três tipos, apresentados na tabela a seguir:

Estratégias de Quality of Service (QoS)

"Tipo" de QoS	Características
Best Effort	A primeira "pegadinha" aqui: o termo "best". O best effort é nada mais, nada menos, que "melhor esforço" ou "faça o que puder". Ou seja, não há quaisquer prioridades, e os todos os pacotes são tratados por igual e utilizando-se mecanismos de contenção do tipo “First In First Out” (FIFO)
Integrated Services (IntServ)	Nesta modalidade, as próprias aplicações nos hosts e servidores sinalizam os requerimentos de prioridades na rede, e os dispositivos (roteadores e switches que suportarem o IntServ) se encarregam de garantir estes requerimentos sinalizados pela aplicação. Não possui boa escalabilidade, pois os equipamentos de rede precisam manter o estado de sessão de todos os fluxos de tráfego (termo “microflow management”)), o que é completamente inviável para a maioria dos backbones das Operadoras atualmente;
Differentiated Services	As prioridades aqui são realizadas para agrupamentos de pacotes em classes de tráfego, e não para aplicações individuais, e também não são utilizados protocolos ou sinalizações. Ou seja, agrupamos as transmissões em classes de tráfego e definimos ações sobre cada uma destas classes de tráfego. A escalabilidade é, portanto, ilimitada (sem protocolos, sem sinalização, e sem microflow management). O “problema” é que a configuração de QoS tem que ser feita em todos os elementos de rede do chamado domínio DiffServ, que possui comportamento Per-Hop Behavior (PHB; ou QoS em todos os saltos/hops).

Conjunto de Ferramentas empregadas para QoS

O QoS não é uma tecnologia só, tampouco pode ser resolvido com um único recurso ou comando no seu equipamento. O QoS pode ser melhor definido como um conjunto de estratégias e ferramentas dissimilares onde cada qual desempenha a sua função no intuito de minimizarmos os problemas (já discutidos) dos meios de transmissão estatística.

As ferramentas do QoS podem ser categorizadas conforme demonstrado a seguir, no que chamamos de “QoS Toolkit” ou qualquer que seja o nome que você queira usar aqui.

Classificação

Consideramos aqui somente a arquitetura DiffServ, pois o IntServ não possui boa escalabilidade e foi literalmente descontinuado em função disto. Sabemos que o QoS precisa ser feito obrigatoriamente em todos os saltos, no trajeto de A para B, e vice-versa. Ao invés de executarmos políticas de QoS por pacote ou por aplicação, fazemos um agrupamento de tipos de transmissão em suas respectivas classes de tráfego.

A classificação tem que ser feita o mais próximo possível da origem da transmissão mas, na verdade, ela é realizada em todos os equipamentos de rede, pois, como executar uma ação sobre um determinado pacote sem sabermos primeiro do que se trata este pacote? Há diversas formas de classificação de pacotes para agrupamento destes nas chamadas “Classes de Tráfego”, e as opções variam de acordo com o tipo de equipamento e a plataforma utilizada. Alguns exemplos de ferramentas usadas para estes procedimentos de classificação:

• Access Control Lists (ACL) ou similar: classificar pacotes com base em instruções de cabeçalhos L3 e/ou L4. Em algumas plataformas VACLs (VLAN) podem ser usadas para incidência sobre endereços MAC (L2).
• Input interface: ou seja, com base na interface de "entrada", ou por onde o pacote foi recebido pelo roteador ou equipamento.
• Cabeçalho de Camada 2 (L2):
  • BECN/FECN para Frame Relay
  • MPLS EXP Bits para o MPLS Label
  • 802.1Q/p para o CoS nos quadros tagged do Ethernet)
  • Ou ainda nos endereços MAC de origem e destino
• Cabeçalho IP (L3): mais precisamente no byte ToS (IP Precedence ou DSCP) ou ainda nos endereços IP de origem e destino.
• QoS Group: ou recurso similar em alguns roteadores.
• Protocolos de Transporte (UDP/TCP): as portas de origem e destino para os protocolos de Camada 4
• Camada 7 (L7): algumas plataformas permitem a inspeção detalhada de todo o payload e com visibilidade completa da aplicação (L7) para, por exemplo, diferenciar uma aplicação/serviço de outra aplicação operando sobre um mesmo protocolo (ex: HTTP).
• QoS Policy Propagation via BGP (QPPB): o envio e propagação de policy e classificação pelo BGP.

Uma vez classificados os pacotes, saberemos exatamente a que tipo de transmissão cada um pertence ou se destina e com isto posicionaremos os pacotes classificados em suas classes de tráfego correspondentes, mas não antes sem nos certificarmos de que cada pacote já classificado pode ser facilmente (re)classificado pelos demais equipamentos da rede, portanto o próximo passo é procedermos com a marcação e/ou remarcação, caso isto seja exigido.

Marcação

Algumas classificações de pacotes só podem ser realizadas com certo esforço, o qual não gostaríamos de implementar em toda a rede, principalmente no Core. Pensando nisto, devemos então simplificar e padronizar as marcações dos pacotes para facilitar ainda mais a posterior classificação destes pacotes em todos os elementos de rede, incluindo no backbone, e através das ferramentas de marcação suportadas pela infraestrutura.

Como um pacote pode ser marcado ou "colorido"?

• Cabeçalho Ethernet: 802.1Q/p
• Cabeçalho IP: ToS byte (IP Precedence ou DSCP)
• MPLS Shim Header: MPLS EXP bits
• Internamente em alguns routers: (não através dos enlaces na rede): QoS Group.
• Em VPNs ou Túneis tipo GRE ou L2TP, há também ferramentas tais como QoS Preclassify, além de recursos tais como CAR, CBP, e QPPB, com estes ou outros nomes, conforme suportado por cada equipamento e fabricante.

Gerenciamento de Congestionamentos

Filas de tráfego são necessárias para organizar o tráfego de entrada e saída (filas input (onde suportadas) e filas output), ou seja, pacotes chegando (entrando) por uma interface e pacotes saindo por uma interface. Os tipos de filas suportadas dependem da plataforma ou do equipamento em questão (router ou switch). Por padrão, todas as filas de um router são FIFO (first in, first out), o que é péssimo em termos de assegurar prioridades, e ainda por cima pode promover o “starvation” de tráfego importante nas filas.

Realmente fica complicado elencar todas as tecnologias e procedimentos suportados, e por tantos os tipos de equipamentos disponíveis no mercado. Posso no entanto "generalizar" aqui e tentar fornecer o máximo de exemplos possíveis com os nomes e tecnologias de plataformas que eu domino. Fique a vontade para pesquisar na documentação do seu equipamento o que é suportado ou não.

É importante salientar que alguns tipos de estratégias de filas aqui são do gênero "legadas" e que mecanismos mais recentes encontram-se disponíveis.

Em roteadores, o que é comum:

• First In First Out (FIFO): não há QoS ou prioridades aqui. O primeiro pacote que for recebido na fila será o primeiro pacote a ser transmitido. É o típico regime "best effort".
• Custom Queueing (CQ): modalidade legada de regime de filas que permite a configuração manual de uma determinada quantidade de filas (ex: até 16) com extração por bytes por fila numa fração alternada sequencialmente (round robin).
• Priority Queueing (PQ): modalidade legada de regime de 4 filas com prioridades definidas (Alta, Média, Normal e Baixa prioridade). Possui o defeito de "matar" de fome as filas de menor prioridade em alguns casos.
• Fair Queueing (FQ): modalidade legada de regime de uma quantidade bem razoável de filas dinâmicas com o foco na prioridade e expedição de pacotes com menor payload e tempo de expedição (start time e finish time computados, etc.)
• Weighted Fair Queueing (WFQ): modalidade legada que herda os princípios da FQ, mas que acomoda um "peso" (fator de importância) que é condicionado às marcações presentes nos pacotes. Geralmente usada em classes de tráfego "default" no lugar do regime FIFO tradicional. É como se fosse "um QoS sem QoS".
• Class-Based Weighted Fair Queueing (CBWFQ): modalidade vigente que mescla os benefícios da CQ com os da WFQ. Alguns fabricantes tratam isto pelo nome de CBWFQ (Cisco, Juniper...).
• Strict Priority Queueing: modalidade vigente que incorpora os benefícios da PQ, enquanto eliminando seus defeitos, e mesclando isto em um regime CBWFQ. Ou seja, uma ou duas filas de baixa latência (alta prioridade) customizadas pelo administrador operando em regime de maior prioridade, porém sem sacrificar o funcionamento das demais filas. Neste tipo de fila é que mapeamos Voz (P1) e Vídeo (P2) numa policy de QoS.
  • Low Latency Queueing (LLQ): é basicamente como a Cisco nomeia o SPQ em suas soluções.
• Modified Deficit Round Robin (MDRR/P2PMDRR): mecanismo vigente que implementa variáveis tais como valor quântico e contador de déficit para servir as transmissões com respeito às suas importâncias, condicionadas aos valores de marcação dos pacotes.

Isto apenas para citar algumas destas estratégias de enfileiramento. Há ainda algumas plataformas mais avançadas que fazem uso de arquiteturas do tipo Virtual Output Queues (VoQ), como é o caso de switches de missão data center e até mesmo roteadores de borda carrier-grade, onde, neste caso, há um gerenciamento diferenciado dos buffers de filas de saída nas interfaces egress, antes do pacote ser arbitrado no switch fabric pela interface de entrada (ingress)

Já em switches, os regimes de filas na maioria os casos são mais simplificados e até mesmo engessados no que diz respeito a customizações e afins. Normalmente são empregados um ou mais dos seguintes:

• 04 (quatro) ou 08 (oito) filas de QoS por porta física
• Weighted Round Robin (WRR)
• Shaped Round Robin (SRR)
• Modified Deficit Round Robin (MDRR)

Honestamente, as capacidades e mecanismos suportados variam muito de equipamento para equipamento. Por exemplo, em roteadores mais simples (low end), uma única fila de QoS em hardware é suportada, portanto um regime CBWFQ + LLQ seria essencialmente mantido por software para fornecer a dinâmica de prioridades desejadas para as transmissões (ou seja, qual pacote terá acesso à fila "física"?). Em switches, o interessante é que há garantidas 4 ou 8 filas de tráfego baseadas em hardware - mantidas no pipeline de processamento lá no silício (ASIC) - e todo este trabalho pode ser executado sem envolvimento de software. Em roteadores mais "high end", principalmente os roteadores carrier-grade, dependendo dos módulos de portas (line cards) instalados, milhares de filas de QoS totalmente baseadas em hardware. Enfim, tudo depende da arquitetura do equipamento em questão.

Controle de Congestionamentos

Uma coisa é gerenciar quais pacotes terão a sua vez de transmissão, algo que é de responsabilidade das filas. Outra é controlar o entupimento ou o preenchimento destas filas. Eis aí a diferença entre gerenciamento de congestionamentos e controle de congestionamentos.

Sim, uma fila pode “entupir”. Quando isto ocorre, os novos pacotes que chegarem à interface de entrada (ingress ou input interface) e, após determinadas a adjacência e interface de saída, encontrarem a fila associada à interface de saída (egress ou output interface) completamente cheia, serão sumariamente descartados. O mecanismo padrão de descarte de pacotes nas próprias filas é o que chamamos de Tail Drop. Isto é péssimo para determinadas transmissões, pois seriamos incapazes aqui de proteger aplicações mais críticas quando estas estiverem compartilhando a mesma fila com outras aplicações não tão importantes assim. Consequentemente, os usuários da rede experimentam e percebem problemas associados a lentidões.

No entanto, é possível mudar este comportamento através da seleção e configuração de um mecanismo de prevenção de congestionamento de filas para que os descartes de pacotes nestas filas obedeçam uma lógica de descartes seletivos baseada na importância dos pacotes (low, medium, high), evitando-se ao máximo possível o entupimento da fila. Estes mecanismos seriam:

• Tail Drop: não há diferenciação aqui, pois não há um controle efetivo de entupimento da fila. Se uma fila de saída ficar completamente cheia, o próximo (novo) pacote que precisar ser posicionado nesta fila será sumariamente descartado.
• Weighted Random Early Detection (WRED): é um destes mecanismos mais sofisticados, e que pode inclusive receber auxílio de outro mecanismo, o Explicit Congestion Notification (ECN). A proposta aqui é executar um descarte seletivo de pacotes antes que a fila de saída fique comprometida, ou seja, antes de ficar entupida. Os protocolos de camadas superiores (ex: TCP e algumas aplicações no topo deste) reagem relativamente bem ao descarte "aqui e acolá" ou "every now and then" de pacotes de seus fluxos, e o impacto disto é relativamente baixo. O que é completamente diferente de um descarte "full" na interface, o que reduz substancialmente as janelas de transmissão em função do "recuo" do protocolo TCP. O que o WRED propõe-se a fazer é monitorar o preenchimento da fila com valores mínimo, médio e máximo, e ter thresholds definidos para cada importância de pacote (condicionado ao valor de marcação) e fazendo isto com dois objetivos:
  • Permitir que haja sempre (ou no melhor esforço possível) um "espaço" na fila para o recebimento de pacotes mais importantes ou críticos para a empresa.
  • Impedir o descarte completo na fila (evitando-se o tail drop).
  • O Explicit Congestion Notification (ECN) é um mecanismo adicional que pode ser usado para "educar" a pilha de protocolos do hosts, sinalizando-os para "maneirar" nas transmissões, ou eles terão pacotes descartados.
• Weighted Tail Drop (WTD): uma implementação de WRED mais frequentemente utilizada por switches.

Policiamento

Para manter o tráfego (uma classe ou um tipo específico de transmissão) operando sob uma taxa controlada/contratada, e com níveis de policiamento para taxa “no perfil”, “fora do perfil”, e “completamente fora do perfil”. Talvez seja a ferramenta de QoS mais conhecida entre os provedores de acesso à Internet (ISP) de pequeno e médio portes.

O tráfego excedente poderá ser descartado ou remarcado (prioridade mais baixa), enquanto o tráfego de violação poderá ser descartado. As ferramentas aqui incluem:

• Rate Limiting: um policiamento e taxa que, em alguns fabricantes, leva o nome de committed access rate (CAR).
• Class-Based Policing: uma versão bem mais sofisticada de policiamento, já que é embarcado e compatibilizado em regimes CBWFQ, além de suportar policiamento de uma ou duas taxas em uma ou duas cores de policiamento.
• Per-session QoS Policing: o policiamento de taxa executado por assinante em um concentrador BNG (PPPoE/IPoE), cada qual em um plano específico compartilhando a mesma taxa ou taxas completamente distintas.

Como regra geral, os clientes de um ISP deverão ter seus circuitos físicos ou lógicos sempre policiados para garantir que estes estejam utilizando no máximo o que lhes foi contratado. O policiamento de tráfego deverá ser feito o mais próximo possível da origem das transmissões. Em uma arquitetura de Rede de Acesso, a porta do equipamento switch ou roteador que receber o circuito físico do cliente deverá ser configurada para fazer esta limitação de taxa. Caso a porta física de entrada atenda múltiplos clientes e o dispositivo CPE não seja gerenciado pelo ISP, a configuração poderá ser feita em nível lógico (ex: VLAN do cliente no dispositivo de Acesso do ISP). A inobservância desta prática e a insistência em ativar o policiamento de tráfego a partir do ou somente no dispositivo PE, ao invés do dispositivo de Acesso, poderá desperdiçar muita banda uplink: o tráfego de todos os clientes desta rede de Acesso subiria e disputaria recursos de rede tais como banda e buffers, para ter o tráfego excedente descartado posteriormente pelo roteador PE. O que não seria uma medida muito inteligente. Procure fazer o policiamento da taxa contratada sempre o mais próximo possível do assinante.

Moldagem

Com esta técnica, as transmissões excedentes são mantidas em buffer e transmitidas após, quando houver a suficiência de "tokens". O objetivo é moldar o tráfego para que este consuma a banda máxima desejada, porém evitando-se na medida do possível a ocorrência de descartes. Esta estratégia poderá ser utilizada para moldar todo o tráfego de cliente diretamente a partir da porta de saída do dispositivo CPE, desde que este equipamento seja gerenciado pelo ISP. O shaping promoverá benefícios de conformidade de uso de Internet tanto na perspectiva do cliente quanto no do provedor. Não recomenda-se obviamente a moldagem de tráfego sensível a latência!

As ferramentas de shaping variam de nome conforme o fabricante e/ou equipamento, mas os nomes comuns são:

• Generic Traffic Shaping (GTS)
• Distributed Traffic Shaping (DTS)
• Class-Based Shaping (CBS)
• Frame-Relay Traffic Shaping (FRTS)
• Etc.