WirelessBR

Publicado em 18/05/06.    O download do arquivo correspondente em formato pdf  pode ser obtido aqui.

Série de artigos sobre VoIP
Terceiro artigo - Parte 01

Roteadores e QoS

J. R. Smolka 

Estamos indo bem. Este é o terceiro artigo da série VoIP, onde nosso objetivo é examinar os roteadores, que são máquinas com hardware e software especialmente projetados para máxima eficiência no papel de gateways, como sistemas de computação.

A discussão é genérica, e não pretende fazer nenhuma consideração ou comparação entre estratégias de implementação adotadas por este ou aquele fabricante de roteadores.

Embora os roteadores possam implementar uma enorme variedade de funções acessórias (ex.: agentes de gerência, servidores de proxy DHCP, etc.) vamos nos limitar a discutir os aspectos arquiteturais que influenciam o desempenho da sua função primordial: receber pacotes em uma interface, verificar por qual interface eles devem ser enviados e remeter os pacotes adiante pelas interfaces selecionadas.

Depois disso, vamos examinar os mecanismos de QoS disponíveis em redes TCP/IP, e entender qual é o papel desempenhado pelos roteadores em cada um deles.

Arquitetura lógica de um roteador:

Como qualquer sistema e computação, um roteador pode ser entendido como uma coleção de processos que trabalham sob o controle de um sistema operacional. Reduzindo ao básico, a estrutura de processos do roteador pode ser descrita como na figura 1.

Figura 1 - Arquitetura lógica de um roteador

 Os processos responsáveis pelos protocolos de aplicação suportam as funções do plano de controle que necessitem de recursos específicos de comunicação neste nível (ex.: agentes de gerência precisam do protocolo SNMP, dynamic routing necessita de algum dos protocolos desta categoria – RIP, OSPF, etc.). Como são protocolos de aplicação, suas mensagens precisam ser mediadas pelos protocolos de transporte (TCP ou UDP).

O plano de controle executa as tarefas de “arrumação da casa”, tais como: coleta de estatísticas de utilização de recursos, autenticação de usuários, implementação da interface de comandos (user shell) para usuários locais ou remotos, etc.

Embora todas as situações onde ocorram transferências de dados entre os processos operacionais e do plano de controle do roteador afetem, de uma forma ou de outra, a performance geral da máquina, a parte realmente crítica para um desempenho satisfatório, é a comunicação entre o processo responsável pelos algoritmos de roteamento (o protocolo IP propriamente dito) e os processos que administram as interfaces físicas do roteador, para encaminhar pacotes em direção aos links de transmissão. O modelo de trabalho entre estes processos pode ser entendido, esquematicamente, como na figura 2.

Figura 2 - Tráfego de pacotes entre IP e interfaces físicas
 

Os processos que controlam as interfaces físicas mantém filas para os pacotes que estão aguardando para ser transmitidos (TX queue) e que estão aguardando para ser encaminhados para tratamento pelo processo IP (RX queue). Pacotes que estão sendo transmitidos ocupam o enlace de transmissão (TX link), e pacotes que estão sendo recebidos ocupam o enlace de recepção (RX link)

O desempenho da comunicação entre os processos operacionais (e do plano de controle) do roteador é comandado, primeiro pelos mecanismos de inter-process communication que o seu sistema operacional implemente, e segundo pela forma de distribuição destes processos que a arquitetura de hardware permita (multiprocessamento, switching fabrics, etc.). Mas, onde provavelmente ocorrerá um desequilíbrio sensível na performance é no processo de remover pacotes da TX queue e colocá-los no TX link.

Pode parecer, à primeira vista, que quanto maior for a capacidade da interface menor será o desequilíbrio de desempenho. Entretanto é melhor lembrar que, se um roteador possui apenas interfaces de alta capacidade, é porque, provavelmente, ele tem um papel de entroncamento de alto volume de tráfego, e o problema pode acontecer sempre que ocorrer um pico de tráfego destinado a uma única interface. E se o roteador possui apenas uma interface de alta capacidade, o mais provável é que ela seja usada como uplink de concentração do tráfego das outras interfaces, e também está sujeita à ocorrência de sobrecarga.

De maneira geral, a capacidade de escoamento de tráfego nas interfaces é o fator individual mais importante para determinar o tempo que um pacote leva para entrar e sair de um roteador, chamado de latência (latency). Portanto, vamos olhar com atenção quais são as estratégias de administração das filas de transmissão.

Estratégias para as filas:

As filas são áreas de armazenamento em memória (buffers) com tamanho finito, embora configurável – dentro dos limites de disponibilidade física da máquina. Eventualmente a quantidade de pacotes aguardando processamento em uma fila esgota a capacidade de memória alocada (buffer overflow), e quaisquer novos pacotes que tentem usar aquela fila serão descartados (dropped). Quando isto acontece, o roteador está congestionado (congested), e o descarte indiscriminado de novos pacotes na fila congestionada é chamado tail drop.

Fora de congestionamento, os pacotes são alocados às filas e aguardam processamento. O tempo de espera de um pacote na fila depende de quantos pacotes já estão na fila, e da capacidade do elemento que retira pacotes da fila (o TX link, para a fila de transmissão, e o protocolo IP para a fila de recepção). Como não há como prever quantos pacotes estarão ocupando a fila em um determinado instante, o tempo de espera é variável, e, consequentemente, a latência também será.

Como, mesmo em um ambiente com headiness index[1] +5, existem pacotes para os quais queremos minimizar a latência e o risco de descarte em caso de congestionamento (ex.: pacotes dos protocolos de dynamic routing), portanto precisamos de algumas estratégias para tratar de forma diferente os desiguais.

Os objetivos são dois: diminuir a probabilidade de ocorrência de congestionamento (congestion avoidance), e, caso ele ocorra, minimizar as conseqüências do congestionamento (congestion control).

Com a implementação de algoritmos para congestion avoidance, queremos evitar a ocorrência de tail drop. O algoritmo básico é chamado RED (random early detection), e baseia-se no seguinte procedimento:

a)  Estabelece-se um limite máximo (threshold) para utilização do buffer. Enquanto a utilização estiver abaixo disto, nenhuma ação é tomada;

b) Quando a utilização excede o threshold, uma proporção definida dos pacotes que entram na fila são descartados, aleatoriamente. A proporção de tráfego descartado pode tornar-se mais agressiva, à medida que a utilização da fila se aproxima dos 100%. Se chegar ao ponto de haver buffer overflow, ocorrerá tail drop;

c)  O processo de descarte continua até que a utilização do buffer caia abaixo do threshold.

A idéia do RED é “suavizar” picos de tráfego de saída na interface, e dar uma certa previsibilidade da proporção do tráfego que será perdida em caso de congestionamento. Entretanto o descarte atinge, indiscriminadamente, tráfego prioritário ou não. Além disso, considerando que o tráfego usa principalmente TCP como protocolo de transporte, a forma de descarte adotada no RED faz com que todas as janelas, de todas as sessões TCP, sejam percebidas como perdidas e retransmitidas quase simultaneamente. O resultado final é que o roteador fica oscilando entre estados de baixo tráfego (após o descarte) e congestionamento (quando todas as sessões tentam retransmissão quase simultânea).

A alternativa é diferenciar a maneira como será feito o descarte se o threshold for atingido. Mantendo a proporção do tráfego total que é descartado, vamos fazer com que o descarte ocorra de forma desigual, afetando menos os fluxos (flows) de maior prioridade, e mais os flows de menor prioridade.

Mas, então, é necessário alguma forma de designação explícita do grau de importância de um pacote. Existe um byte no header IP para designação do TOS (type of service), cuja padronização original na RFC 791 previa que os três bits mais significativos servissem para indicar a prioridade do pacote (IP precedence bits), os próximos três bit fossem utilizados para definir a classe de serviço desejada (delay, throughput ou reliability), e os últimos dois bits ficassem reservados (currently unused). Mais tarde esta padronização foi alterada pela proposta DiffServ, que veremos depois.

Quando o descarte de pacotes tiver de ser iniciado, porque o threshold de utilização do buffer foi atingido, a proporção de pacotes descartados em cada configuração de TOS pode ser diferente, mantendo igual o percentual do tráfego total que será descartado. Em outras palavras, o administrador da rede pode alterar a probabilidade de descarte de tráfegos prioritários em caso de congestionamento. Esta variante do RED é chamada de WRED (weighted RED).

Apenas a capacidade de suavizar picos de tráfego e diminuir a probabilidade de ocorrência de tail drop não é o suficiente, entretanto. Dado que a ordem de entrada de pacotes com configurações TOS diferentes na fila não pode ser prevista, permanece o problema de garantir que cada flow class (identificada por uma configuração TOS) receba uma fração adequada da banda disponível no TX link.

O caso mais simples é conhecido como prioridade absoluta de transmissão (strict priority). Neste caso, os pacotes pertencentes à flow class especificada como strict priority “furam” a fila, e são transmitidos antes. Os pacotes das demais flow classes são atendidos, desde que não existam pacotes strict priority aguardando, em modo first came, first served[2] (FCFS).

A próxima alternativa é denominada fair queueing (FQ), que tenta garantir que cada flow class receba a mesma quantidade de banda do TX link. Para isso é utilizado um algoritmo conhecido como “balde de fichas” (token bucket), que funciona assim:

a)  Uma parte do algoritmo faz a geração periódica de tokens. Cada token representa o direito de transmitir uma certa quantidade de bits;

b) Cada flow class tem o direito de utilizar uma fração definida dos tokens gerados. Para que um pacote pertencente uma flow class seja transmitido tem de existir tokens suficientes disponíveis para esta flow class;

c)  Se existem tokens suficientes, o pacote é transmitido e os tokens são removidos do “balde”;

d)  Se não existirem tokens suficientes, então o pacote tem de aguardar na fila até que existam tokens para sua flow class em quantidade suficiente para que ele seja transmitido.

Também é fácil, desta forma, implementar uma variação do algoritmo, onde a quantidade total de tokens gerados não é distribuído de forma igual entre as flow classes. Assim, a “fatia” de banda do TX link que cada flow class pode utilizar pode ser desigual. Esta variante é chamada weighted fair queueing (WFQ).

A depender da realidade de tráfego em cada rede, strict priority, FQ ou WFQ podem ser suficientes para resolver o problema de repartição de banda do TX link entre as flow classes. No core de grandes redes (corporativas ou a Internet), geralmente a situação é mais complexa, e exige um pouco de tudo isto.

Os roteadores que suportam mecanismos de garantia de quality of service (QoS) implementam, além do WRED, uma mescla de strict priority com WFQ, chamada class-based weighted fair queueing (CBWFQ). Neste modo de operação, existe uma flow class com strict priority, e as demais flow classes são servidas via WFQ.

Um ponto importante a observar é que, embora seja possível implementar diferenças de tratamento entre flow classes, dentro da mesma flow class o tratamento sempre será FCFS. Assim, o grande trabalho de traffic engineering em redes TCP/IP está em adequar a banda total dos links físicos ao comportamento observado do tráfego agregado de cada flow class.

[Continua]