José Ribamar Smolka Ramos ComUn

José Ribamar Smolka Ramos
Telecomunicações
Artigos e Mensagens

ComUnidade WirelessBrasil

Setembro 2010 Índice Geral

26/09/10

• O que realmente significa net neutrality? (Artigo de José Smolka no e-Thesis)

Em visita ao e-Thesis da nossa Jana de Paula, anoto textos do também nosso José Smolka. :-)

Este, de publicação recentíssima:

Fonte: e-Thesis
[22/09/10] O que realmente significa net neutrality? - por Jose Smolka (transcrito mais abaixo)

E estes, mais antigos, todos da "série" Eu detesto dizer 'eu avisei':

Fonte: e-Thesis
[12/07/10] Meditações... - por Jose Smolka

O susto que as operadoras celulares tomaram com o tráfego de dados em suas redes 3G (HSDPA ou HSPA) produziu muitas reações. Nem todas boas. A melhor, em minha opinião, foi acordarem para a necessidade de modernizar seus backhauls, ainda excessivamente montados sobre rádios PDH ou, no máximo, SDH (a maioria STM-1 ou STM-4 sobre enlaces rádio, e poucos STM-16 ou STM-32 sobre fibra ótica). Finalmente o movimento para capilarização de redes DWDM na longa distância e Metro Ethernet no espaço urbano ganhou corpo, e deve tornar-se o modelo preferencial para expansão e modernização do backhaul a partir de agora. (...)
Ler mais

Fonte: e-Thesis
[14/04/10] Bitpipe Wars - por Jose Smolka

Agora é oficial. Segundo anúncio da Ericsson na CTIA Wireless, em dezembro de 2009 o tráfego de dados superou o tráfego de voz, considerando o agregado de tráfego das várias redes que operam com seus equipamentos pelo mundo afora. E, em minha opinião, este overtake torna ainda mais urgentes, do posto de vista das operadoras móveis, a adoção de medidas para evitar que sejam relegadas ao papel de bitpipe. (...)
Ler mais

Fonte: e-Thesis
[21/07/08] NGN, IMS e SDP. Será suficiente? - por Jose Smolka

Se depender apenas do noticiário, especializado ou não, a indústria de telecomunicações (operadoras e seus fornecedores) vai muito bem, obrigado. Sob a batuta sábia e segura da dupla dinâmica TISPAN e 3GPP, as redes fixas e móveis estão em processo de migração para um ambiente all-IP quadruple-play, de acordo com o modelo NGN e IMS, e a oferta de banda larga fixa e móvel está em franco desenvolvimento, o que permitirá que serviços, classicamente considerados fora do escopo das redes de telefonia, tais como TV por assinatura ou broadcasting de TV e rádio, sejm incorporados ao portfólio, e ocorra uma explosão de oferta de novos serviços, que serão integrados à rede pelo SDP. Se tudo está tão bem, porque eu continuo a sentir, como Shakespeare, que "existe algo de podre no reino da Dinamarca"? (...)
Ler mais

Ao debate!

Boa leitura!
Um abraço cordial
Helio Rosa

--------------------------------

Fonte: e-Thesis
[22/09/10] O que realmente significa net neutrality? - por Jose Smolka

[Eu detesto dizer 'eu avisei' - Artigos]

Recentemente vi uma matéria do site TeleSíntese onde o sr. Bruno Ramos, Gerente Geral de Comunicações Móveis da Anatel, expressou a sua visão sobre a compatibilidade entre os conceitos de net neutrality e diferenciação da qualidade do serviço (QoS - Quality of Service) prestada aos assinantes. Deixando em aberto a possibilidade da declaração ter sido citada erradamente, truncada ou fora de contexto, fiquei com a sensação que nem todo mundo entendeu, ainda, do que se trata o problema da net neutrality.

O significado da palavra neutralidade, neste contexto, é literal: os provedores de acesso e trânsito não devem impor nenhuma discriminação ou privilégio ao tráfego originado/destinado dos/para os usuários/provedores de serviços, não importando se eles sejam ou não seus clientes

Isto não quer dizer que, para garantia de QoS, a rede não possa impor tratamento discriminatório aos pacotes de determinados tipos de aplicação. O ponto chave é que este tratamento discriminatório aplica-se aos pacotes de determinadas aplicações, e não a quem sejam seus originadores ou destinatários. Então, se pacotes de aplicações de vídeo merecem um trânsito preferencial para garantir a quaidade da experiência de uso dos seus usuários, isto deverá ser feito para todos os pacotes de aplicações de vídeo, não importando quem são os usuários ou provedores do serviço.

O que existe, entretanto, é um desconhecimento total, fora da comunidade técnica diretamente envolvida no projeto das redes, sobre quais são as limitações práticas dos mecanismos que existem para implementar a garantia de QoS. Some-se a isto a inexistência de meios formais para que os administradores dos autonomous systems (AS) que compõem a Internet garantam que quando o tráfego cruza suas fronteiras administrativas o tratamento de QoS dados aos pacotes será coerente fim a fim, e estão criadas as condições para uma grande confusão.

Apenas de passagem, já que estamos falando em tratamento fim a fim coerente, QoS não é o único a sofrer pela inexistência de melhores formas de negociação de acordos de peering entre AS. Um serviço decente de distribuição de vídeo pela Internet também necessita que haja cooperação dos vários AS para adoção de parâmetros comuns para o roteamento de tráfego multicast.

Vou me repetir, porque quero ser bem claro nisto: os padrões técnicos da comunidade TCP/IP, materializados nos request for comments (RFC) publicados pelos grupos de trabalho da Internet Engineering Task Force (IETF), para garantia de QoS (DiffServ - RFC 2474) e roteamento de tráfego multicast em grande escala (PIM-SM - RFC 4601) já existem, e sabemos que eles funcionam. O problema real é conseguir que os vários AS concordem em um conjunto comum de parâmetros para garantir que estes mecanismos sejam eficazes fim a fim.

Então, para que os nossos preclaros legisladores e reguladores (e também pretensos defensores dos consumidores) não comecem a sair por aí exigindo que o ângulo reto ferva a 90 graus, vou me dar ao trabalho de tentar explicar em termos não muito técnicos como estes dois mecanismos funcionam. Encarem isto como uma espécie de IP QoS and muiticasting for dummies.

Differentiated Services

Dada a natureza estatística das redes IP, é normal que não exista garantia dada pela rede para que : (a) pacotes não se percam em trânsito; (b) o tempo de trânsito dos pacotes seja sempre o menor possível; e que (c) o tempo de trânsito dos pacotes seja constante. O primeiro destes fatores é chamado de perda de pacots (packet loss), o segundo é chamado latência (delay) e o terceiro denomina-se variação da latência (jitter). As ferramentas para garantia de QoS tem a ver com o controle destes três fatores sobre o tráfego.

Para entender como estas coisas acontecem com os pacotes é essencial compreender como os pacotes transitam através da rede. A menos que os hosts de origem e destino do pacote sejam fisicamente adjacentes (neste caso a transmissão é feita diretamente entre eles) os pacotes seguem um trajeto em "saltos", usando hosts especializados na tarefa de fazer o encaminhamento (forwarding) dos pacotes: os roteadores (que, fisicamente, podem ser também switches). Cada roteador no caminho do pacote sabe apenas qual é o próximo "salto" na direção do host de destino, e o último roteador na rota (que é fisicamente adjacente ao host de destino) faz a entrega final do pacote. Durante o trânsito de um pacote através de um roteador ocorre o seguinte: (1) o pacote é lido na interface de entrada; (2) o endereço de destino do cabeçalho (header) IP é comparado com a tabela de roteamento (routing table) existente no roteador e uma interface de saída é selecionada; (3) o pacote é colocado na fila de transmissão da interface de saída selecionada; (4) o pacote é transmitido.

O delay entre dois hosts quaisquer da rede depende da velocidade de transmissão dos enlaces e do tempo de trânsito nos roteadores ao longo da rota. Estou supondo que a rota escolhida é a melhor possível (e, normalmente, os processos de negociação automática das rotas, como o OSPF ou o IS-IS, são muito bons nisso). Se a rota é mantida constante (o que é normalmente o caso) o tempo de transmissão nos enlaces é também constante, portanto a única fonte de jitter é a variação no tempo de trânsito através dos roteadores. E, nesta época de enlaces cada vez mais confiáveis por causa do uso intensivo de fibras ópticas, no trânsito através dos roteadores também está o maior risco de packet loss.

Porquê? Por causa do processo de enfileiramento dos pacotes nas interfaces de saída do roteador. Em cada interface de saída existe uma certa quantidade de memória (um buffer) para este armazenamento transitório até a efetiva transmissão do pacote. Como a posição que um pacote qualquer irá ocupar no buffer varia aleatoriamente, em função da disputa pelo acesso àquela mesma interface de saída por outros pacotes, se a regra de esvaziamento do buffer pela interface for simplesmente first-in first-out (FIFO), então cada pacote de um fluxo (flow) que passa por aquela interface sofrerá um tempo de trânsito aleatório. O efeito cumulativo disto ao longo de toda a rota é a razão do jitter. Caso ocorra de um pacote encontrar o buffer da interface cheio ele é descartado (dropped) pelo roteador, o que causa packet loss.

Então, para garantir QoS adequado para os flows dos diversos tipos de aplicação, precisamos de um mecanismo que permita: (a) identificar qual nível de QoS estará associado a cada pacote; e (b) garantir que cada roteador ao longo da rota tratará cada pacote da forma adequada ao nível de QoS associado a ele.

O DiffServ estabelece como criar códigos binários de 6 bits (DiffServ Code Points - DSCPs) que devem ser marcados no header de cada pacote IP que ingressa na rede. Obviamente esta é uma atividade extra a ser desempenhada nas interfaces de entrada dos roteadores de borda da rede, e, caso não haja cuidado com a complexidade das regras para marcação dos pacotes, pode tornar-se uma ofensora para o delay e jitter.

O que acontece com o pacote ao longo da rota depende do comportamento específico de cada roteador (per-hop behaviour) no tratamento dados aos pacotes em função do DSCP marcado neles. Não existe padrão para isto, e este é um ponto delicado para estabelecer regras comuns de QoS entre redes distintas, ou mesmo em uma única rede onde os roteadores sejam de fornecedores distintos. Como regra geral o per-hop behaviour envolve duas coisas: prioridade de posicionamento dos pacotes na fila do buffer da interface de saída; e prioridade para descarte caso o buffer da interface esteja próximo de transbordar (tail drop).

De forma bem simplificada (mas não muito longe da realidade) precisamos de DSCPs para identificar apenas um número limitado de situações: aplicações sensíveis a delay, jitter e packet loss, aplicações sensíveis a delay e jitter mas insensíveis a packet loss, aplicações insensíveis a delay e jitter mas sensíveis a packet loss, e aplicações insensíveis a delay, jitter e packet loss. O per-hop behaviour associado a estas classes de aplicação seria, então: pacotes marcados como sensíveis a delay e jitter "furam a fila" do buffer e são colocados à frente de todos os pacotes marcados como insensíveis a delay e jitter, porém atrás dos pacotes marcados como sensíveis a delay e jitter que já estejam enfileirados no buffer; caso o buffer encha acima de um limite de segurança (configurável) os pacotes marcados como insensíveis a packet loss passam a ser descartados até que a utilização do buffer volte ao nível aceitável.

Vale observar que a granuralidade destas duas variáveis (sensibilidade a delay/jitter e sensibilidade a packet loss) não pode ser muito fina, porque nem todo mundo dispõe da quantidade de bits necessária para representar todas as situações desejadas (o MPLS, por exemplo, usa 3 bits, o que dá um máximo de 8 classes de QoS representáveis), e porque quanto mais fina a granularidade maior o delay incorrido pela maior complexidade dos processos de marcação dos pacotes no ingresso na rede e per-hop behaviour. A consequência lógica é que é bastante razoável prover QoS diferenciado para algumas classes de aplicações, mas não é razoável imaginar que a identidade do usuário/provedor de serviço associada a um determinado flow de pacotes seja um dos fatores para definir a marcação e o per-hop behaviour dos pacotes.

Multicasting

É muito ineficiente, em termos de uso dos recursos da rede, determinadas aplicações serem acessada pelos usuários em modo unicast (um flow de pacotes para cada usuário). O desejável é que exista um mecanismo para que a distribuição dos pacotes destas aplicações seja feita de tal forma que o número de flows emitidos pelo provedor da aplicação seja lilitado apenas a pontos de redistribuição e replicação do tráfego, e assim sucessivamente até chegar aos usuários finais. Isto é multicasting.

Novamente precisamos de duas coisas para que um esquema deste tipo funcione: uma forma de criar endereços que identificam grupos de usuários associados a um determinado conteúdo a ser distribuído e permitir que os usuários associem-se ou removam-se destes grupos; e uma forma de construir/podar dinamicamente a árvore de distribuição e replicação dos pacotes, com a "raiz" no provedor de conteúdo e ramificando-se até as "folhas" nos usuários.

Tanto o IPv4 quanto o IPv6 possuem faixas de enrdereçamento reservadas para a identificação de grupos multicast (ver a RFC 3171 e RFC 4291). A forma dos hosts ingressarem em grupos multicast é diferente para o IPv4 e para o IPv6 (ver Internet Group Management Protocol, version 3 - IGMPv3 na RFC 3376 e Unicast-Prefix-based IPv6 Multicast Addresses na RFC 3306). Estas são as formas para solucionar a primeira parte do problema, como descrita no parágrafo anterior.

Quanto à segunda parte existe a RFC 4601 - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). O ponto principal deste protocolo é que cada AS pode designar um dos seus roteadores para funcionar como rendezvous point (RP) para o tráfego multicast de qualquer provedor de conteúdo, mesmo que ele não esteja dentro da sua esfera administrativa. Através do PIM-SM o RP pode estabelecer e "podar" árvores de distribuição envolvendo os roteadores designados (designated routers - DRs) para distribuição de trpafego multicast até os usuários finais.

Um exemplo dos problemas atuais

Um bom exemplo de como estas áreas podem gerar conflitos e dificuldades para uma interoperação plena (e, consequentemente, neutra) das diversas partes da rede são os conflitos que observei entre as definições de classes de QoS e multicasting feitas pelo 3GPP e sua interoperação com a rede IP/MPLS responsável pelo transporte dos pacotes entre os elementos da rede celular 3G.

Qualquer responsável pela rede de transporte IP/MPLS para os pacotes de dados originados/destinados nas/para as RNCs deve ter sentido isso: tanto no core CS quanto no core PS o delay máximo de ida e volta exigido (round-trip time) costumava ser de, no máximo 100 ms. Isto quando o round-trip-time considerado razoável para uma conversação era de 150 ms. Onde ficava o terço restante do round-trip time? Nas interfaces aéreas e no processamento interno dos elementos do core CS e PS, mas isso estava fora de discussão. Para quem quiser ver alguns dos pontos de atrito entre as especificações do 3GPP e da ITU-T, veja este paper.

Na interface aérea o 3GPP definiu quatro classes de serviço: cara efeito de granatia de QoS na interface aérea o 3GPP definiu quatro classes de serviço: conversational, streaming, interactive e background. Os nomes são bastante auto-explicativos quanto aos tipos de apicações enquadradas em cada classe. Porém os projetistas do 3GPP aparentemente só se preocuparam em garantir que estas classes de serviço fossem adequadamente reconhecidas e tratadas por serviços de transporte de camada 2, como indica este livro. Eu nunca vi nenhuma recomendação ou padrão de como RNCs, Media Gateways, SGSNs e GGSNs colocariam os DSCPs apropriados nos headers IP externos dos pacotes transportando os dados entre estes elementos. Ou será que eles nunca consideraram esta hipótese?

Situação semelhante ocorre no multicasting. O 3GPP definiu um padrão para distribuição de tráfego multicasting entre Media Gateways e RNCs, e entre GGSNs, SGSNs e RNCs. Este padrão chama-se Multimedia Broadcast and Multicast Service (MBMS). Novamente ninguém se preocupou em garantir que entre RNCs Media Gateways ou entre RNCs e GGSNs fossem usados os mecanismos de apoio ao multicasting na rede IP subjacente a eles. Resultado: se as rotas entre estes elementos sobre a rede IP/MPLS de transporte for relativamente longa haverá ineficiência na ocupação da rede e, consequentemente, mais CapEx e OpEx do que o estritamente necessário.

Então, para finalizar eu pergunto: se dentro da mesma rede, da mesma operadora, ocorre este tipo de coisa, imagine fazer tudo isto funcionar de forma transparente envolvendo várias operadoras. Este é o real problema de neutralidade da rede. O resto é fumaça.

ComUnidade WirelessBrasil BLOCO