BLOCO
Blog dos Coordenadores ou Blog Comunitário
da
ComUnidade
WirelessBrasil
Setembro 2010
Índice Geral do
BLOCO
O conteúdo do BLOCO tem
forte vinculação com os debates nos Grupos de Discussão
Celld-group
e
WirelessBR.
Participe!
26/09/10
• O que realmente significa net neutrality?
(Artigo de José Smolka no e-Thesis)
Olá, ComUnidade
WirelessBRASIL!
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.
[Procure
"posts" antigos e novos sobre este tema no
Índice Geral do
BLOCO]
ComUnidade
WirelessBrasil