Quem sou eu

Minha foto
Salvador, BA, Brazil
Analista de sistemas, expert em telecom, formado em Eng. Elétrica e nerd assumido

sexta-feira, 11 de novembro de 2011

Os indicadores de performance de rede no SGQ-SCM e SGQ-SMP (1)

Li e reli os dois novos regulamentos sobre indicadores da qualidade do SCM e do SMP, e, sinceramente, achei a redação confusa e, às vezes, contraditória. Então decidi publicar alguns posts dedicados a tentar fazer uma apresentação inteligível dos indicadores de qualidade da rede do SCM e dos indicadores de conexões de dados do SMP (não vou tratar dos indicadores de reação do usuário - SCM e SMP, nem dos indicadores de atendimento - SCM e SMP, nem dos indicadores das conexões de voz - só SMP, e nem dos indicadores de pesquisa - SCM e SMP).

Sempre que possível vou emparelhar os indicadores que medem coisas semelhantes para o SCM e para o SMP. E vale observar logo: estes regulamentos só afetam operadores SCM ou SMP com mais de 50K assinantes (ou acessos em serviço, na terminologia dos regulamentos). Ou seja: praticamente só as operadoras de telefonia fixa e móvel entram neste critério. Os pequenos e médios operadores SCM (creio que esta categoria não exista no SMP) não são afetados por estes regulamentos.

Qualquer problema de análise de performance começa pela definição do 5W1H:
  • WHAT: o que vai ser medido?
  • WHY: porque vamos medir isso?
  • WHO: quem fará a medição?
  • WHERE: onde será feita a medição?
  • WHEN: quando será feita a medição?
  • HOW: como faremos esta medição? 
Então vamos tentar organizar os indicadores de qualidade da rede para dar a melhor resposta possível a estas perguntas, com base no que está escrito nos regulamentos e com um pouco de bom senso.

Os dois regulamentos (art. 10 para o SCM e art. 24 para o SMP) prevêem que as operadoras tem que disponibilizar (para a Anatel e para os assinantes, no caso do SMP, e só para os assinantes no caso do SCM) software de medição do desempenho da rede, que deverá poder ser baixado por cada usuário interessado, e que deve ser capaz de medir os seguintes indicadores (e registrar - onde? - data/hora e local dos resultados obtidos, para possibilitar a formação de série histórica):
  • Taxa de transferência instantânea - indicadores SCM4 e SMP10. A taxa instantânea deve ser medida tanto no canal de download quanto no canal de upload;
  • Latência bidirecional (aquilo que comumente chamamos de round-trip time, medido com o programa ping) - indicador SCM6, mas sem indicador correspondente no SMP (aliás, não tem nem mesmo definição para o round-trip time no RGQ-SMP). O que levanta uma questão interessante: o software vai medir isso, mas a operadora não tem nenhuma meta estabelecida para este item de desempenho. Vai dar confusão.
  • Variação de latência (jitter) - indicador SCM7, e também sem indicador correspondente para o SMP. Valem as mesmas observações do caso da latência bidirecional.
  • Taxa de perda de pacotes (packet loss) - indicador SCM8, e também sem correspondente no SMP. Aqui temos os inconvenientes dos dois itens anteriores e mais um adicional: não é dada nenhuma definição, nem mesmo no regulamento do SCM, para este item o como calcular está completamente em aberto.
Outro fator de confusão ligado a este software de medição é que enquanto o regulamento do SCM especifica (no inciso I do art. 15) que a medição dos dados para o cálculo oficial dos indicadores deve ser feito com equipamento dedicado, na casa do assinante (na verdade de uma amostra estatisticamente significativa do conjunto dos assinantes - inciso II do art. 15 - com intervalo de confiança mínimo de 95% - por analogia com o item 4.3 do anexo III do regulamento do SCM). Já o SMP não fala nada sobre como fazer a medição, e ainda deixa aberta a possibilidade de ser usado o mesmo software que será disponibilizado para os assinantes. Muito mal definido.

Existe mais um indicador comum aos dois regulamentos: taxa de transferência média (SCM5 e SMP11). Novamente os regulamentos definem que as medidas devem ser feitas tanto no canal de download quanto no canal de upload.

E existem indicadores que são específicos para o SMP, e não tem correspondente no SCM. Talvez seja apenas a vontade de manter paralelismo com os indicadores do serviço de voz do SMP:
  • Taxa de completamento de conexões de dados (SMP8);
  • Taxa de queda das conexões de dados (SMP9);
Então podemos fazer uma tabela resumo sobre o que (what) temos que medir:


Vamos assumir que o porquê medir (why) seja auto-explicativo. E sabemos quem (who) vai medir. Será a tal da Entidade Aferidora da Qualidade, que é descrita nos artigos 33 a 37 do RGQ-SCM e nos artigos 26 a 30 do RGQ-SMP, mas com uma diferença: no SCM a Entidasde Aferidora é responsável pela coleta de dados e cálculo de todos os indicadores de rede (SCM4, SCM5, SCM6, SCM7 e SCM8), mas no SMP ela é responsável apenas pela coleta de dados e cálculo dos indicadores SMP10 e SMP11. Subentende-se, então, que a responsabilidade pela coleta de dados e cálculo dos indicadores SMP8 e SMP9 cabe às operadoras.

As questões de onde (where) e quando (when) medir também dão o que falar: tanto o SCM quanto o SMP pedem que os cálculos dos indicadores ocorra no PMT (período de maior tráfego - que é definido de forma invariável como sendo das 10:00 às 22:00 horas - o que, por si só, é uma incongruência estatística). Mas, enquanto no RGQ-SCM o art. 15 define que a medição deve ocorrer na casa dos usuários, com uma dispersão da amostrage tal que permita a representação estatisticamente significativa da diversidade do público usuário do serviço, no RGQ-SMP apenas é dito que o mesmo software que for disponibilizado para que os usuários façam suas próprias mediçoes também poderá ser usado para efetuar as medições para cálculo oficial dos indicadores. E não diz nada sobre como escolher uma amostra estatisticamente significativa dos usuários, que, no caso do SMP, tem uma dimensão a mais em relação ao SCM: a maior diversidade de equipamentos de acesso (smartphones e tablets, além dos desktops e notebooks típicos do SCM).

Para terminar esta etapa da análise, vou apenas sumarizar as metas a atingir em cada indicador, para os dois serviços (SCM e SMP).



(*) Tanto o indicador SCM6 (diretamente, pelo inciso III do art. 15 do RGQ-SCM) quanto o indicador SMP10 (indiretamente, por analogia ao que é dito sobre o software de medição a ser disponibilizado aos usuários no § 8º do art. 24 do RGQ-SMP) dizem que a medição deve ser efetuada entre o equipamento do usuário e o PTT. Só não especifica o critério para definir qual PTT usar nas medições, porque existem vários, públicos e privados.

Na próxima parte vou analisar com calma a questão do como (how) medir. Do svidanʹya tovarishchi.

7 comentários:

  1. Um PTT privado não parece um bom lugar para colocar uma medição, pois se trata de interconexão com uma ou poucas outras redes.

    Um PTT público já não; notar que os PTT públicos não são necessariamente operadoras por órgão neutro, podem ser comerciais. A Terremark, por exemplo, é uma matriz pública de troca de tráfego, mesmo que seja uma empresa com foco em rentabilizar essa matriz; o PTT que alguns chamavam de "PTT das TVs a cabo" outros "PTT da Telcomp" etc. também é um PTT público dentro do que se costuma chamar de public peering e private peering.

    Eu sei que pelo menos um desses PTTs que citei acima se posiciona como PTT privado, mas não há PTTs operadoras pelo governo que se possa então denominar de PTTs públicos para quem alguém se denomine privado.

    A confusão do termo público é infelizmente usual na LGT (interesse público x serviço público, por exemplo) e se repete no mercado como neste caso, então nos cabe ser repetitivos em textos ao descrever o que significa naquele contexto.

    ResponderExcluir
  2. Concordo com você Rubens. Meu feeling é que a preferência recairá sobre os PTTs operados pelo CGI.br, mas eles são 17 (conforme a página http://ptt.br).

    Então é necessário que o regulamento especifique claramente o critério para escolha de qual PTT será usado na medição.

    Imagino o cenário: o usuário usa o software para medir em outro lugar, em outro horário, e em outro PTT que os utilizados na medição oficial, e depois reclama na concessionária, na Anatel, no Procon...

    E depois quem vai provar que focinho de porco não é tomada?

    ResponderExcluir
  3. Como a medição é do SCM, e não de backbone Internet, me parece (mas isto precisa ser clarificado no regulamento) que a operadora pode alegar que os parâmetros são atendidos se para o PTT mais próximo (sendo que proximidade é tanto geodésica quanta topológica), a operadora está conforme.

    O SIMET do NIC.br hoje já faz o teste contra o PTT que der o melhor tempo de resposta.

    ResponderExcluir
  4. Pretendo discutir isso no próximo post, sobre o como (how) medir.

    O SIMET é um bom exemplo inicial de como fazer o software de medida. Mas a escolha do PTT que ele faz ainda é nebulosa. O que é considerado "melhor tempo de resposta"? Isso pode ser variável no tempo, e introduzir distorções nas medidas efetuadas.

    Para mim, por exemplo, embora eu more em Salvador (e tem um PTT do NIC.br aqui) ele mede meus dados em relação ao PTT de São Paulo.

    Meu provedor de acesso é a Oi. Duvido que eu esteja topologicamente mais "perto" do PTT SP do que do PTT SSA

    ResponderExcluir
  5. Retificando... Usei o SIMET duas vezes. A primeira execução foi contra o PTT SP, mas a segunda foi contra o PTT RJ 2. Ele abre a possibilidade do usuário escolher o PTT, mas só tem estes dois (mais o próprio NIC.br) na lista - pelo menos por enquanto.

    ResponderExcluir
  6. O melhor tempo de resposta era obtido uma medida expedita do RTT (latência bidirecional), por exemplo um pacote apenas enviado para todos os PTTs. Eu precisaria fazer uma nova captura de pacotes para ver se isso ainda é assim...

    Para o SIMET fazer um teste num PTT, a operadora precisa trocar tráfego com o AS do setor do NIC.br que mantém o SIMET (14026) no PTT em questão e a operadora precisa anunciar seu prefixo para o AS 14026. Pode ser que uma dessas duas questões não esteja acontecendo em SSA.

    ResponderExcluir
  7. Pode ser... Quem sabe a Oi tem um acordo de peering tão bom que vale a pena para ela entregar o tráfego daqui em SP.

    De qualquer forma, ainda vamos conversar muito sobre o que e como o SIMET se comporta, e as características desejáveis para o ferramental de medição oficial dos indicadores do SGQ-SCM e do SGQ-SMP, e para o software que vai ser disponibilizado para os assinantes.

    Breve...

    ResponderExcluir