WirelessBR

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

Série de Artigos sobre VoIP

VoIP - Introdução

J. R. Smolka 

Há algum tempo publiquei um artigo sobre técnicas de codificação de voz[1]. Minha motivação para escrever sobre aquele assunto teve raiz em uma troca de mensagens a respeito de VoIP. Depois disto, já há algum tempo, venho sendo gentilmente “cutucado” para publicar mais coisas nesta mesma linha. Então, finalmente,  

Já existe muita coisa escrita a respeito de VoIP tanto no ambiente empresarial (corporate VoIP) quanto nas operadoras de telecomunicações (carrier-class VoIP). Dois pontos me chamam a atenção, naquilo que tenho visto: primeiro, a maioria dos textos é extremamente sumária (e nem sempre correta) com relação aos fundamentos de TCP/IP que suportam VoIP, especialmente nas suposições sobre como a rede proverá (ou não) QoS. Segundo, VoIP é uma classe de aplicações que está bem no núcleo de uma histórica divergência de opiniões entre engenheiros de redes de computadores e engenheiros de redes de telefonia, e quase nunca estas diferenças filosóficas entre os dois grupos são levadas em conta nas análises da tecnologia. 

Então, para o bem dos thirty-four hundred da ComUnidade WirelessBRASIL[2], onde temos muitos leigos no assunto (alguns mais perdidos que cachorro que caiu do caminhão de mudança), e também para clarear os problemas filosóficos envolvidos na introdução de aplicações de transporte de voz em ambientes de rede Internet-like, resolvi iniciar uma série de artigos, começando com este aqui. Infelizmente não posso prometer muita regularidade na publicação. 

Como todo artigo técnico, este também está crivado de abreviaturas e acrônimos, e muitos termos em inglês, que só tem sentido para os iniciados. Isto é um fato da vida. Para quem sentir dificuldades, existem diversos sites na Internet que trazem definições sobre todos os termos que serão utilizados. Uma boa dica é fazer consultas no Google na forma “define: termo”. As eventuais definições disponíveis para o termo serão apresentadas. A Wikipedia também ajuda muito. 

Enfim... Vamos ao que interessa! 

Netheads vs Bellheads, dez anos depois: 

Recentemente encontrei, preservado on-line, um artigo que foi originalmente publicado na edição de outubro de 1996 da Wired magazine. O título é Netheads vs Bellheads[3], e trata sobre as divergências filosóficas que distinguem os engenheiros de redes de computadores (netheads) dos engenheiros de redes de telefonia (bellheads). Quando eu li a versão original, dez anos atrás, ela me chamou a atenção. Relendo o artigo agora, o que me impressionou é que, na essência, nada mudou nestes últimos dez anos! 

O foco visível de divergência, na época daquele artigo, era a provável adoção, pelas grandes operadoras de telefonia, da tecnologia ATM no core da infra-estrutura da Internet. Mas o autor segue adiante, colocando em primeiro plano o ponto fundamental que põe bellheads e netheads em confronto: a opção de uns por redes orientadas à conexão (connection-oriented) com tecnologia de comutação de circuitos (circuit switching); e dos outros por redes não orientadas à conexão (connectionless) baseadas em comutação de pacotes (packet switching). 

As diferenças entre estes pontos de vista sobre networking é quase religiosa em seu dogmatismo, porque refletem um desacordo fundamental sobre como administrar o tráfego na rede. Enquanto os dois lados tinham seus próprios playgrounds para brincar, estas divergências tendiam a ficar apenas na esfera acadêmica. Mas com a explosão de crescimento da Internet comercial, tudo mudou. As grandes empresas de telefonia assumiram o encargo de prover a infra-estrutura de suporte ao tráfego dos usuários da Internet, e os dois grupos passaram a conviver no mesmo espaço empresarial. Para entender melhor estas diferenças, vamos comentar as características gerais de cada uma das “escolas” de networking. 

Redes de comutação de circuitos presumem que novos usuários só podem ser admitidos na rede se existirem recursos disponíveis (essencialmente, banda de passagem livre) em quantidade suficiente para acomodar o novo tráfego, dentro dos parâmetros pré-estabelecidos de qualidade de serviço (QoS). 

Portanto, neste tipo de rede é necessário existir um procedimento formal de estabelecimento de chamada (call setup), em que novos usuários solicitam ao plano de controle da rede a reserva dos recursos necessários para o seu tráfego. Caso os recursos livres existam, eles são alocados rigidamente para aquela chamada, e definem uma rota fixa para o encaminhamento do tráfego através da rede – um circuito. 

Durante a chamada, também são necessários mecanismos de controle das chamadas (call control). A finalidade principal do controle de chamadas é a tarifação (billing) do tráfego, mas também verificar a ocorrência de eventos que interrompam a disponibilidade dos recursos alocados para a chamada. Neste caso, a conexão cai, e é necessário que os usuários façam um novo call setup para que um novo circuito seja estabelecido. 

A rede pública de telefonia (também conhecida como PSTN ou POTS) é o arquétipo desta arquitetura, e as técnicas para a sua administração estão enraizadas na teoria do tráfego telefônico, desenvolvida originalmente por Agner Krarup Erlang[4], no início do século XX. Toda esta teoria depende de um fato simples: o comportamento dos usuários (freqüência das tentativas de estabelecimento de chamadas e freqüência da duração das chamadas) é estatisticamente previsível. E, por ser previsível, é possível fazer engenharia de tráfego (traffic engineering). 

Toda esta estrutura fazia muito sentido no ambiente de comunicações analógicas, existente até a segunda metade do século XX, e foi extremamente bem-sucedida. Mas cabe a pergunta: esta abordagem continua sendo a mais eficiente em um ambiente de comunicações digitais? As investigações dos pesquisadores levaram a uma nova proposta: comutação de pacotes. 

A teoria das redes de comutação de pacotes propõe uma abordagem bem diferente. Em vez de criar circuitos, dedicados integralmente por toda a duração das chamadas, pacotes de bits de informação são trafegados periodicamente entre as partes que se comunicam. Novos usuários podem entrar livremente na rede, sem call setup, e a rota seguida por cada pacote de dados não é rígida, podendo ser modificada durante o curso da chamada. 

Em contrapartida, passa a existir a possibilidade de congestionamento, quando o tráfego de entrada em um nó da rede excede a capacidade de vazão de saída deste mesmo nó. Este ambiente, então, depende de mecanismos de controle de congestionamento (congestion control). 

Ainda assim, é normal para esta arquitetura que, eventualmente, pacotes sejam perdidos, duplicados, ou entregues ao destinatário fora de ordem. Isto torna necessário que existam mecanismos de controle de fluxo (flow control). 

O exemplo máximo desta arquitetura de rede é a Internet (com “i” maiúsculo). A Internet, tal como a conhecemos hoje, nasceu em 01/01/1983, quando o TCP/IP foi padronizado na ARPANET. O objetivo de uma rede TCP/IP é proporcionar uma forma aberta, flexível e adaptável de interconectar computadores. E a Internet demonstra isso, com uma história de vinte e três anos de sucesso, apesar de um crescimento mais que explosivo do número de redes e computadores conectados a ela. 

Embora a Internet seja o maior exemplo de aplicação da idéia de comutação de pacotes, e tenha sido essencialmente criada por netheads, várias outras arquiteturas de comutação de pacotes foram propostas e padronizadas na comunidade bellhead, com destaque para X.25 e ATM (ITU-T) e frame-relay (ANSI). Mas, assim como naquele comercial em que um presunto tenta imitar a marca de outro, mais famoso, e erra na ortografia do nome, estas propostas mostram logo o seu DNA bellhead: todas elas recorrem à idéia de circuitos virtuais (virtual circuits ou virtual paths, ou ambos). 

Muito bem... Como as operadoras de telefonia assumiram a tarefa de prover o backbone da Internet, os engenheiros encarregados da tarefa, com seu pesado passado bellhead, começaram a se perguntar: como vamos fazer engenharia de tráfego para esta rede? O comportamento do tráfego dos usuários não tem nenhuma semelhança com o tráfego telefônico convencional. Ocorre em rajadas (bursts) de pacotes, sem nenhum padrão estatístico na distribuição do número ou do tamanho dos pacotes na rajada. Havia, porém, a esperança de que, mesmo que um usuário tivesse um perfil de tráfego bursty, o agregado do tráfego de grandes grupos de usuários mostrasse algum padrão estatístico mais civilizado. Em 1993 os pesquisadores do Bell Labs (atual Telcordia) publicaram um artigo sobre uma investigação desta hipótese, e o resultado foi: o tráfego na Internet não se adapta a nenhum dos modelos estatísticos conhecidos, porque ele possui uma característica (auto-semelhança) que é típica de uma classe de objetos matemáticos conhecidos como fractais. O tráfego continua sendo bursty, não importa em qual escala de tempo ou volume você olhe. Então, quando se trata da Internet, ou, generalizando, grandes redes TCP/IP, esqueça a teoria de Erlang, e esqueça as formas convencionais de traffic engineering. 

Isto já é suficiente para manter acesa a fogueira de uma “guerra religiosa” por muito tempo, mas tem mais. O processo tradicional de evolução técnica das redes telefônicas é muito organizado e metódico. Proposições são encaminhadas à ITU-T, que forma comitês de estudo e, depois de cuidadosa deliberação e discussão (que pode demorar anos), são emitidas novas séries de recomendações. E os bellheads tradicionais gostam que seja assim. 

Na Internet, entretanto, o processo de evolução da rede é libertário, anárquico, sem procedimentos estabelecidos nem autoridade formal. Vale a famosa frase de David D. Clark[5]: 

“We reject kings, presidents and voting. We believe in rough consensus and running code”. 

A Internet está permanentemente no processo de “trocar o pneu com o caminhão andando”. Novas propostas, na forma de RFCs, são submetidas constantemente à IETF, e são objeto de discussão aberta a toda a comunidade de usuários – embora, para ser ouvido com seriedade, você precise ter uma reputação. Se a proposta é boa o suficiente para ganhar o consenso de um grupo grande o suficiente de usuários, e não ofende nenhum dos princípios básicos do funcionamento da rede, ele é adotado como um padrão. E se isto não acontecer, sua proposta não é jogada fora, porque ela pode servir de inspiração para alguma outra proposta mais elaborada, e porque ela pode ser útil para determinados nichos de usuários, que irão adotá-la mesmo assim. 

E, apesar disto tudo, nestes últimos dez anos o que eu vejo é uma progressiva “contaminação” da arquitetura TCP/IP por mecanismos que andam, falam e cheiram a bellhead. Oh sim... tudo em nome de razões técnicas muito válidas, e interesses comerciais (das operadoras e dos fornecedores de equipamentos) que não podem ser desprezados. Tudo isto eu entendo. O que eu não entendo é a aparente apatia da comunidade nethead em virar o jogo. 

Outra das grandes diferenças nas atitudes nethead e bellhead é a crença de onde deve estar a complexidade. A visão bellhead é simplificar ao máximo os dispositivos dos usuários, e jogar toda a complexidade para o core da rede. A abordagem nethead, ao contrário, prefere privilegiar as aplicações como “centro inteligente” do negócio, e simplificar, sempre que possível, a infra-estrutura da rede (KISS – keep it simple, stupid!). 

Especialmente no que tange a VoIP, estamos assumindo que voz é assim mesmo, e a rede é que vai ter que se adaptar a este tipo e tráfego. E não tenho visto (com raras exceções) muita iniciativa em melhorar a aplicação do usuário. Digo isto sem esquecer que o maior problema do VoIP não é a introdução de aplicações de telefonia em uma rede TCP/IP, mas garantir a convivência e a interoperação com a rede telefônica legacy. 

Enfim, retornando ao que disse no início desta seção, passaram-se dez anos, e nenhuma mudança significativa ocorreu. A esta altura, minha posição pessoal já deve estar muito clara: torço para o nethead futebol clube desde criancinha. Não acredito que redes físicas over-engineered substituam aplicações bem-escritas. E vejo as propostas de “hibridização” entre as visões bellhead e nethead do mundo apenas como pragmatismos comerciais, e não como uma terceira via de pensamento. 

Daqui em diante: 

No próximo artigo vamos fazer uma revisão decente dos aspectos básicos de funcionamento da arquitetura TCP/IP. 

A partir daí, em outros artigos iremos analisar as demais tecnologias essenciais para o funcionamento de aplicações VoIP, tanto em ambiente corporate quanto carrier-class. 

Para ser coerente com minhas posições pessoais, no resto desta série de artigos, estarei associando às soluções que iremos discutir um índice criado por mim: o headiness index (pat. pending). O headiness index é um número que varia de –5 (totalmente bellhead) a +5 (totalmente nethead), e indica o grau de influência de cada escola na especificação daquela tecnologia. 

Até lá, então...

José de Ribamar Smolka Ramos (smolka@terra.com.br) é engenheiro eletricista (UFBa 1982), com especialização em gestão da qualidade (CETEAD/UFBa 1994) e MBA executivo (FGV RJ/Grupo Telefonica 2001). 
Trabalha na área de Informática desde 1980, tendo atuado em empresas das áreas financeira, industrial e serviços, estando desde 1989 na área de telecomunicações. Desde 1995 dedica-se ao projeto, implantação e gestão operacional de infra-estruturas corporativas de comunicação de dados e serviços baseadas na arquitetura TCP/IP, envolvendo infra-estrutura LAN e WAN, acesso remoto e interconexão de redes.
Principais áreas de interesse técnico: segurança da informação, engenharia de tráfego e garantia de QoS na arquitetura TCP/IP e gerência de redes.
Atualmente é especialista técnico da Telebahia Celular S/A (Vivo), e (desde 1993) é professor do curso de bacharelado em Informática da Universidade Católica do Salvador, nas cadeiras de Linguagens para Aplicações Comerciais e Introdução aos Sistemas de Computação.
Uma coleção de suas "mensagens-artigos" em grupos de debates está disponível em: http://www.wirelessbrasil.org/jose_smolka/js01.html.