[GTER] Traffic Engineering

[Carlos Ribeiro]

A todos, um artigo para discussão, críticas e sugestões.
----

Traffic Engineering


Uma das 'buzzwords' associadas com MPLS é o famoso 'traffic engineering'. Mas 
afinal o que é isso? Se você chegou atrasado na festa e ainda não sabe se é 
para comer ou passar no cabelo, fique tranquilo: você certamente não está 
sozinho.

Vamos a uma definição simplista, suficiente para nossos fins: 'Traffic 
Engineering' é um conjunto de métodos e práticas, com o objetivo de otimizar 
o fluxo de tráfego dentro de uma rede. Os principais parâmetros para avaliar 
esta otimização são o balanceamento de tráfego entre múltiplas rotas 
alternativas; a disponibilidade de rotas alternativas corretamente 
dimensionadas, caso haja necessidade de reroteamento; e a obtenção de um 
comportamento mais previsível (de preferência, determinístico) no processo de 
encaminhamento dos pacotes dentro da rede.

A prática de Traffic Engineering é muito utilizada em grandes redes - aqueles 
backbones maravilhosos que se vê nos slides da Nanog. Porém, mesmo para estes 
grandes backbones, uma das reclamações recorrentes é a falta de uma base 
teórica para sustentar a atividade. Neste ponto, o pessoal do CAIDA e da 
própria NANOG vem fazendo um grande trabalho, mas que ainda é incipiente do 
ponto de vista educativo.

Um ponto crucial para o Traffic Engineering é o conceito de 'source routing', 
que permite a seleção de rotas no ponto de ingresso da rede. Para comparar, 
em uma rede IP convencional o roteamento é feito nó por nó ('per-hop'). O uso 
do 'source routing' permite um maior controle sobre o processo de 
encaminhamento dos pacotes dentro da rede, que por sua vez viabiliza a 
atividade de engenharia de tráfego mesmo em uma rede grande. Para que isso 
seja aplicado, porém, é importante em primeiro lugar conhecer profundamente o 
seu tráfego. Isso implica na necessidade não só de medir o tráfego, mas 
também de investigar adequadamente o tráfego, para que possamos determinar o 
que é que deve ser medido. 

Vejamos agora o cenário brasileiro. Alguns fatores colaboram para que a 
atividade de engenharia de tráfego seja relegada a um segundo plano por aqui, 
como por exemplo:

- A concentração de um grande volume de tráfego em uma única região (SP);
- A banda ainda relativamente modesta que trafega no backbone nacional (mesmo 
com todo crescimento, ainda estamos bem aquém dos nossos amigos do hemisfério 
norte).
- A quase absoluta ausência de SLAs para redes IP (digo SLAs *implementados*, 
não SLAs *assinados*. Esses tem de sobra).
- A pouca penetração dos acordos de peering direto ou multilateral (via PTTs).
- A falta de uma cultura adequada de medição do tráfego; não estamos falando 
de MRTG, mas de análise fina de tráfego por 'flow'. 

Apesar de historicamente estes fatores serem verdadeiros, vemos que vários 
deles estão mudando rapidamente. Com o aumento do tráfego, temos hoje no 
Brasil cada vez mais backbones de porte respeitável. Nossos problemas 
rapidamente se aproximam daqueles vividos nos EUA há um ou dois anos atrás, 
para não dizer agora.

Em meio a este cenário, continuamos gerenciando tráfego mais ou menos da 
mesma forma que fazíamos antes. Basicamente, nossa interferência sobre o 
tráfego ainda se restringe de forma geral ao ajuste manual de parâmetros do 
BGP4, feita em geral de forma empírica. Não há que se discutir aqui a 
competência individual, ou o valor da experiência do pessoal que mantém os 
roteadores rodando. No entanto, estes processos humanos tem seus limites de 
escalabilidade, e isso certamente será cada vez mais problemático.

Consideramos que é necessário que a discussão aberta sobre os mecanismos de  
'traffic engineering' seja fomentada, dentro da perspectiva de que se trata 
de uma atividade essencial à saúde do sistema como um todo. A discussão de 
políticas técnicas e administrativas deve ser encorajada, dentro de um 
espírito de colaboração aberto. Esperamos que o tema venha a merecer daqui 
por diante o carinho e a atenção que tanto merece.


Carlos Ribeiro
CTBC Telecom