José Ribamar Smolka Ramos
Telecomunicações
Artigos e Mensagens
WirelessBrasil
Março
2012
Índice Geral
09/03/12
• Continua o debate sobre o "processo de
escolha" da EAQ e "software de medição"
de J. R. Smolka smolka@terra.com.br por
yahoogrupos.com.br
para wirelessbr <wirelessbr@yahoogrupos.com.br>,
Celld-group <Celld-group@yahoogrupos.com.br>
data 8 de março de 2012 18:00
assunto [wireless.br] E continua o chororô
Boa tarde pessoal,
Conforme
publicado no Tele.síntese, O NIC.br não se conforma com a escolha da
PricewaterhouseCoopers para o papel de ECQ do RGQ-SCM e do RGQ-SMP.
E, coerentemente com esta postura, protocolou recurso junto à Anatel contra
o processo de seleção da EAQ questionando (segundo a reportagem) a lisura do
processo de medição proposto, porque ele - supostamente - será realizado com
servidores localizados dentro do AS (Autonomous System - as subdivisões
administrativas da Internet) de cada operadora. Este é um daqueles casos
que, parece, só desenhando. Então vamos desenhar.
Temos aqui uma operadora cuja rede IP interna é usada para prover tanto
acesso em banda larga fixa (SCM) quanto em banda larga móvel (SMP). As
linhas pontilhadas pretas englobam as redes de acesso para cada um destes
tipos de acesso. A linha pontilhada vermelha mostra o limite administrativo
do AS da operadora. Os fatos da vida são: dentro deste limite a operadora
pode intervir na rede, colocando mais capacidade, mexendo na configuração
dos elementos da rede, alterando a topologia, o que seja. Fora deste limite
ela não pode intervir de forma alguma.
Então, do ponto de vista regulatório e contratual, pode-se exigir que a
operadora de alguma forma se responsabilize sobre o que ocorre fora do seu
alcance administrativo? Para mim a resposta é um claro e sonoro NÃO!
Colocar o servidor de medição de desempenho dentro do AS da operadora
significa instalá-lo em algum dos pontos de referência marcados como "A" na
figura. Esta opção significa um grupo de servidores por operadora. A EAQ
terá que administrar um número maior de servidores (um grupo por operadora),
mas os resultados das medições serão os mais fidedignos para representar o
comportamento da rede da operadora, do acesso até a borda do AS.
Por razões de economia, a EAQ poderia optar por colocar seus servidores em
um AS independente, conectado em cada PTT de forma fisicamente próxima aos
roteadores de borda dos AS de todas as operadoras conectadas ali (idealmente
um único hop físico, tipo uma VLAN 1GbE conectando os roteadores de borda
das operadoras e o servidor de medição), nos pontos de referência marcados
como "B" na figura. Esta a é a segunda melhor opção e, creio, é a abordagem
usada no SIMET.
Colocar os servidores de medição em qualquer ponto topologicamente mais
afastado que os pontos "B" introduzirá distorções, porque o tráfego estará
sendo medido enquanto cursa através de mais de um AS, e só o AS de acesso
está sob o controle da operadora. Se algum dos demais AS envolvidos na rota
cursada introduzir latência restringindo banda, ou causar perda de pacotes
ou jitter, a medição ficará comprometida, a operadora "pagará o pato", e não
poderá fazer nada a respeito, a não ser apanhar calada. É esta asituação que
o NIC.br aponta como "com lisura"?
Gostaria de uma resposta cabal do NIC.br para esta pergunta, caso contrário
começarei a suspeitar da lisura dos posicionamentos adotados por eles.
[ ]'s
J. R.
Smolka
-------------------------------------
de J. R. Smolka smolka@terra.com.br por
yahoogrupos.com.br
responder a wirelessbr@yahoogrupos.com.br
para Wirelessbr <wirelessbr@yahoogrupos.com.br>
cc celld-group <Celld-group@yahoogrupos.com.br>
data 8 de março de 2012 23:03
assunto Re: [wireless.br] E continua o chororô
Oi Rubens,
Por partes, novamente.
Smolka, Está aqui um ponto em que minha leitura do conjunto
de matérias do assunto me fez entender diferente: eu entendi que há
duas críticas em paralelo: uma, sobre o processo de seleção do EAQ.
E outra que é sobre a questão dos pontos de medição... inclusive
porque digamos que o NIC.br conseguisse reverter essa escolha e ser
escolhido, a definição de pontos de medição ainda precisaria seguir
o regulamento.
Pode até ser. Meu entendimento da posição do
NIC.br era quanto à suposta "falta de lisura" em efetuar as medições por
dentro do AS, em vez de por fora. Minha discussão, até aqui, resumiu-se ao
aspecto técnico desta alegação.
Agora, se eles ainda por cima pretendem anular a escolha da EAQ, boa sorte.
Não vejo como isto possa ser feito, nem na esfera administrativa nem na
judicial. A escolha seguiu os parâmetros dos regulamentos, então me parece
um ato jurídico perfeito, do qual não cabe recurso. Mas, como dizem, o
jus sperneandi é livre.
Quanto à localização dos pontos de medição, os regulamentos estabelecem que
sempre será medido o trecho que vai do equipamento do usuário até o PTT
(embora não defina objetivamente *qual* PTT deve ser usado - gosto do
critério do pingtest: o servidor que apresentar o menor round-trip time
em relação ao usuário, medido via ping.
Um receio que eu tenho, e não sei se foi ou não o que embasou o
questionamento, é que os pontos de medição não sejam onde está "A"
na figura, mas do outro lado da nuvem da operadora. Por exemplo, uma
operadora informar a EAQ que ela deve instalar um ponto de medição
em cada bairro da cidade. Se isso ocorresse, gargalos e
indisponibilidades a que o serviço estará sujeito ao cruzar a
fronteira não seriam medidos.
Nisto os regulamentos são expressos. A medição
é sempre entre o usuário e um PTT. Então não cabe pensar em medições feitas,
por exemplo, junto ao BRAS (na rede fixa) ou junto ao PDSN (na rede móvel).
Este, creio, é um dos aspectos do modelo Indiano. Mas a Anatel não aderiu a
esta faceta.
Sim, essa é a abordagem usada no SIMET. Entre as opções A e B a
única diferença é de eventuais limites ou falhas dos roteadores de
borda. Coisa que já aconteceu em grandes operadoras brasileiras,
apesar de não ter mais notícias recentes disso, então não é um ponto
pelo qual as operadoras se interessariam por fazer um grande cavalo
de batalha. Porém, a diferença entre um ponto de medição na cidade
do Rio de Janeiro e um conjunto de pontos de medição na Barra da
Tijuca, Botafogo, Leblon e Ipanema é significativa.
Medir por bairro só faria sentido se você
estivesse medindo na saída dos BRAS ou GGSN. E já vimos que isto é contra os
regulamentos.
Concordo que a diferença entre medir nos pontos "A" ou "B" da figura (quem
"pegou o bonde andando", a figura está em minha mensagem anterior) é a
possibilidade de, medindo em "B", perceber a eventual indisponibilidade do
roteador de borda, porém:
a) A menos que o cliente de medição possua algum critério interno para
seleção do servidor de medição (o que pode complicar o caso dos usuários
móveis quando em roaming) se um servidor estiver indisponível (ICMP host
unreachable ou timeout nos pings de teste para escolha) ele
simplesmente será descartado em favor de algum servidor que esteja
funcionando;
b) O servidor escolhido para medição pode não ser o mesmo selecionado pelos
critérios de peering programados no eBGP. Como eventualmente alinhar
isso, para que os pacotes do teste sigam, de fato, a mesma rota que os
pacotes do usuário destinados à Internet. Algo como escolher o servidor
através de traceroute para algum host distante na Internet, e, a
partir do roteador de borda usado, escolher o servidor apropriado?
c) Em qualquer caso, (a) ou (b), a eventual queda de performance tem
que ser correlacionada offline (pelo NOC, provavelmente) para poder
ser informada aos usuários.
d) Embora a medição tenha que ser feita nos PTTs, não existe obrigatoriedade
que o tráfego seja cursado por lá. Apesar de toda a conveniência de usar um
PTT para o peering, podem haver casos onde seja economicamente mais
interessante para a operadora fazer o peering direto com outro AS,
por fora do PTT. Exemplos: Vivo/Telefónica (AS 26599/27699) com a Telefónica
Empresas (AS 10429), e dela com a TIWS (AS 12956); TIM (AS 26615) e Intelig
(AS 17379); e Claro (AS 22085) e Embratel (AS 4230) e também com a TIWS.
Coletei estes dados via
http://www.fixedorbit.com/search.htm. Um tempo atrás me lembro de
ter visto um site de informação sobre relacionamentos de peering
entre os AS na forma de um grafo orientado (usando a ferramenta
graphviz para gerar o
grafo, muito legal). Alguém por aí sabe a URI deste site?
De novo, a questão de lisura do
processo e de escolha e do ponto de medição me parecem distintas.
A não ser que um dos diretores do NIC.br
seja assinante destas listas, não dá para esperar uma resposta de
posicionamento. Talvez enviar esses questionamentos para o site que
publicou a notícia, que então poderia fazê-los com os mesmos que lá
falaram e inclusive publicar matéria complementar com os dois lados
?
Talvez. Normalmente nosso moderador,
o Hélio Rosa, repassa estas mensagens para jornalistas. Quem sabe de lá vem
alguma coisa.
[ ]'s
J. R.
Smolka
-------------------------------------
de J. R. Smolka smolka@terra.com.br por
yahoogrupos.com.br
para Celld-group@yahoogrupos.com.br
data 9 de março de 2012 17:43
assunto Re: [Celld-group] Re: [wireless.br] E continua
o chororô
Seria o BGP
PLAY?
Não. O BGP Play é parecido. Faz quase a
mesma coisa, mas o que estou procurando, quando usa o GraphViz para
renderizar o grafo, o efeito visual é bem melhor (e o único parâmetro de
entrada é o ASN que vai ficar na raiz do grafo).
[ ]'s
J. R. Smolka
------------------------------
de J. R. Smolka smolka@terra.com.br por
yahoogrupos.com.br
para wirelessbr@yahoogrupos.com.br,
Celld-group <Celld-group@yahoogrupos.com.br>
data 9 de março de 2012 10:21
assunto [Celld-group] Re: [wireless.br] E continua o chororô 2
Oi Horácio,
Uma pergunta de cada vez.
Se o serviço da operadora é conexão à
Internet, o ponto de medição deveria ser NA Internet, e não na rede
da Operadora...
a) O serviço é conexão à Internet, mas o que
está sendo medido é o desempenho da rede.
b) *NA* Internet pode significar qualquer coisa, desde a interface do
roteador de borda da operadora no PTT até o outro lado do mundo, e tudo isso
é simplesmente impermeável a qualquer ação tomada pela operadora para
influenciar na performance da rede, então...
c) Ou coloca-se o servidor de medição do lado "de cá" do roteador de borda,
dentro do AS da operadora a um hop de distância topológica para sair
dela; ou coloca-se o servidor de medição do lado "de lá" do roteador de
borda, dentro da infraestrutura do PTT a um hop de distância
topológica para entrar na rede da operadora.
Se um roteador de borda estiver
sobrecarregado ou defeituoso, a medição no ponto A não mostraria
isso, certo?
Correto.
Num caso extremo, a medição em A
indicaria acesso normal, e em B não indicaria tráfego algum!
Isso seria aceitável?
Como eu disse, o que esta sendo medido é o
desempenho da rede. O indicador de disponibilidade do serviço não é medido
pela ECQ. Ainda assim, este seria um modo muito primário de fazer a medição,
porque normalmente as operadoras (omo qualquer ISP) tem rotas alternativas
de peering para garantir a continuidade do serviço em caso de falha
de um roteador de borda.
Outra coisa, quem garante que esses pontos A seriam os usados pelo
cliente?
Este é o problema que mencionei na resposta ao
Rubens. E tem mais:
a) Como a parte cliente da aplicação de medição deve selecionar o servidor
apropriado para realizar o teste de performance? O que apresentar
menor latência? Ou o que estiver mais próximo topologicamente do roteador de
borda usado na saída para a Internet? O primeiro caso pode ser determinado
via ping do cliente para cada servidor em uma lista (que deve ser dinâmica);
e o segundo via traceroute para algum destino determinado na Internet.
Porém...
b) A depender do destino do pacote, ele pode ser encaminhado para a Internet
através de roteadores de borda diferentes. Esta escolha é determinada pelos
acordos de peering feitos pelo AS da operadora. Então, se a escolha
do servidor for feita pelo método do traceroute indicado em (a), você pode
estar testando o desempenho para uma rota de saída, enquanto o tráfego real
do usuário segue outra rota. E isto é normal. A Vivo e a Telefónica tem
acordos assim com a Telefónica Empresas, e esta com a TIWS (que administra o
backbone internacional da Telefónica); a Tim tem acordo com a
Intelig; A Claro com a Embratel; e a Oi já teve (e talvez ainda tenha) um
roteador de borda do AS dela localizado nos EUA. Estas situações são
consequência natural de estruturas corporativas de cada grupo econômico, e
aí, medir no PTT significa medir com pelo menos um AS intermediário - que
não é necessariamente permissionário nem do SCM nem do SMP (nem deve ser).
c} Os regulamentos obrigam que as medições sejam feitas "no PTT", mas não
dão o critério de escolha, e esquecem que muitas vezes os acordos de peering
das operadoras forçam o encaminhamento do tráfego Internet sem passar por
nenhum PTT. Logo a medição pode tornar-se intrinsecamente enganosa.
Nada impede a operadora de ter uma rota alternativa, usada apenas
para medições.
Em tese, sim. Se eu quisesse fraudar as
medições (porque é disso que estamos falando) eu provavelmente tiraria
partido dos mecanismos de MPLS-TE para criar uma rota específica só para o
tráfego de medição, através da rede de transporte IP/MPLS, entre a saída do
BRAS ou do GGSN e a chegada aos roteadores de borda.
Porém é muito menos trabalhoso simplesmente engenhar bem a rede para
apresentar boa performance natural do que ficar inventando fraudes.
Não acredito que isto seja um risco significativo. Uma operadora que fizesse
isto teria muito mais a perder do que a ganhar.
Além do mais, meu gut feeling é que, assim que o trabalho da ECQ gere
uma base de dados estatisticamente significativa, veremos que nas CNTP a
performance das redes não é tão ruim quanto dizem. O tempo dirá.
[ ]'s
J. R.
Smolka
-------------------------------------------
de J. R. Smolka smolka@terra.com.br por
yahoogrupos.com.br
para wirelessbr@yahoogrupos.com.br
data 9 de março de 2012 18:33
assunto Re: [wireless.br] E continua o chororô 2
O serviço é conexão à Internet, mas o que está sendo medido é o
desempenho da rede.
Certo, é um parâmetro, mas não mede o serviço oferecido...
As teles não vendem acesso à rede delas, mas sim à Internet!
Continuo com minha opinião. A
qualidade *do serviço* é medida por um conjunto de indicadores. O
desempenho *da rede* é medido por um subconjunto destes indicadores,
sendo que a disponibilidade *da rede* é medida por um dos indicadores
pertencente àquele subconjunto.
A questão da disponibilidade é tratada no art. 21 do RGQ-SCM. O RGQ-SMP
não menciona nenhuma medida de disponibilidade (porquê? Pergunte à
Anatel).
O indicador de disponibilidade é o SCM9. O alvo é obter disponibilidade
de 99%. Na falta de explicação melhor (alô, pessoal do GIPAQ... ô texto
ambíguo, sô) isto deve significar que o percentual de sucesso das
tentativas de conexão entre o cliente e o servidor da aplicação de
medição deve ser maior ou igual ao alvo. Ou não?
Isto levanta as seguintes questões:
a) Considera-se conexão mal-sucedida qualquer tentativa de acesso a um
servidor que não ocorra dentro de um prazo de timeout? Ou somente
quando nenhum servidor consegue ser acessado? Ou quando o servidor
associado ao roteador de saída usado por aquele usuário não puder ser
acessado?
b) E qual deve ser o tempo de timeout para considerar que a
conexão com o servidor falhou? E como compensar por eventuais falhas ou
problemas de desempenho internos do servidor?
A propósito, para aqueles que acham que os regulamentos são o máximo: o
item (c) do Inciso II do parágrafo 3º do art. 21 do RGQ-SCM (isso é que
dá entregar a redação a advogados) não faz sentido, porque o indicador
SCM9 não mede tempo, mas proporção de tentativas de acesso bem
sucedidas.
Aliás, na contribuição que fiz para a consulta pública do pedido de
impugnação feito pela Oi, eu falei que este indicador seria melhor
calculado a partir dos dados obtidos no sistema de gerência de falha.
Mas como a moda é achar que as operadoras são entidades malévolas, e que
tentarão todo e qualquer expediente para fraudar as medições... Vamos
com esta traquitana, que ainda por cima vai ser medida por amostragem.
Amostra esta que tem que ser escolhida para ser representativa da
população de usuários na localidade e na data definidos pelo calendário
de medição (ainda a definir), inclusive pela estratificação das
velocidades de acesso contratadas naquela localidade.
Pergunto eu: qual o significado deste número em termos da confiabilidade
que ele represente a experiência de uso dos usuários? Para mim é apenas
um exercício de ficção aritmética.
[ ]'s
J. R. Smolka
WirelessBrasil
BLOCO