Proliferação de padrões concorrentes

Network capacity planning - exemplo de uso do algoritmo (parte 1)

Conforme prometido, vou mostrar um exemplo de aplicação do algoritmo de planejamento de capacidade mostrado no artigo anterior sobre a seguinte rede hipotética:

Adicionalmente vou mostrar uma implementação do algoritmo na linguagem C. O vetor de nós de comutação tem a seguinte estrutura lógica:

Que tem a seguinte implementação (sintaxe C):

Para entrada de dados no vetor de nós de comutação vamos usar no exemplo um arquivo CSV, onde cada registro representa um elemento do vetor:

A matriz de topologia tem a seguinte estrutura lógica:

Com a seguinte descrição da estrutura de dados em C:

De forma análoga ao que fizemos para o vetor de nós de comutação, os dados de entrada para a matriz de topologia são dados no seguinte arquivo CSV (que percorre a matriz linha a linha):

A matriz de rotas tem a seguinte estrutura lógica::

E o código C para a sua estrutura de dados é:

No arquivo CSV para carga inicial percorremos os valores nesta matriz linha a linha. Observe que o valor armazenado nos elementos da matriz não é o valor de índice do vetor de nós de comutação, mas o valor numérico inteiro do Id do nó de comutação. Assim, um valor zero nesta matriz indica a inexistência de rota entre o par de nós considerado.

Na próxima parte deste artigo vamos ver a estrutura lógica, o código C e os arquivos CSV usados para definir a matriz de interesse de tráfego, e estaremos em condição de definir a implementação C do algoritmo e ver os resultados da sua execução sobre os dados de entrada que fornecemos.

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.

To NAT or not to NAT? That's the question for HSPA/HSPA+

No artigo anterior eu defendi a tese que a opção menos ruim (porque boa, boa mesmo, de verdade, não tem) para a migração do serviço de acesso móvel à Internet através das redes de acesso celulares 3G (HSPA e HSPA+) era a abordagem dual-stack (ver RFC 4213).

Nos comentários daquele artigo o Rubens Kuhl e o Juliano defenderam que a melhor opção é o uso do NAT64. Certamente que eu acho possível usar o NAT64 neste contexto, mas tenho dúvidas se ele vai funcionar tão bem.

Antes de começar a discutir prós e contras relativos de cada abordagem, pelo bem daqueles leitores que não tenham familiaridade com o assunto (afinal este blog tem uma finalidade basicamente instrutiva), vou fazer uma breve apresentação do que se trata o NAT64.

NAT significa Network Address Translation. Na Internet v4 o uso extensivo de NAT (ver RFC 2663) e dos blocos de endereçamento privado definidos na RFC 1918 permitiram um considerável aumento da sobrevida do espaço de endereçamento do IPv4, mas também criaram uma sensação de falsa segurança, e muito pouca coisa concreta foi feita para que a transição IPv4-IPv6 ocorresse de fato. Resultado: muito tempo perdido, e agora vamos ter que fazer correndo o que podia ter sido feito com calma.

Na Internet v6 não existe motivo para o uso de NAT, como é destacado na RFC 4864. Já a questão de como um host v6 pode estabelecer conexão com um host v4, e vice-versa, só pode ocorrer mediante alguma forma de NAT para fazer a "ponte" entre as duas Internets (v4 e v6).

O NAT64 permite que aplicações em um host que seja single-stack IPv6 consigam acessar aplicações que residem em hosts também single-stack, porém IPv4. Os recursos necessários para usar o NAT64 são:

• Um Well-Known Prefix (WNP) IPv6. Conforme a seção 2.1 da RFC 6052, o WNP para o NAT64 é 64:ff9b::/96 (se você já penou pra entender a notação dotted decimal dos endereços IPv4, então prepare-se, porque a notação dos entereços IPv6 é bem mais críptica. Sugiro dar uma olhada aqui).
  
• Servidor DNS que suporte as extensões DNS64 (RFC 6052 e RFC 6146)

A figura abaixo mostra o esquema geral de funcionamento do NAT64.

O fluxo de mensagens mostrado é para quando o host de destino só possui conectividade IPv4 (o que fica evidente pela resposta de erro do servidor DNS para o servidor DNS64 quando ele pede o registro AAAA do host de destino). Se o host de destino possuísse conectividade IPv6 haveria uma resposta válida para a query pelo registro AAAA no servidor DNS, e (mesmo que o host de destino fosse dual-stack e também houvesse uma resposta com o registro A associado) a conectividade IPv6 seria possível - logo o gateway NAT64 não seria usado.

Bonito, porém vejo um problema sério nesta abordagem. Ele é muito bom quando os UEs estão querendo acessar servidores IPv4 no regime client-server habitual (ex.: web surfing e verificação da caixa postal de e-mails). Mas a situação muda quando a direção do início da sessão é invertida (da Internet v4 para dentro da "ilha" IPv6 que é a rede interna da operadora). E, no quadro de funcionamento peer-to-peer típico das aplicações de telefonia  (tanto na conexão bearer quanto na conexão de sinalização SIP) isto vai ocorrer a toda hora - Exemplo: o IMS de uma operadora, ainda usando IPv4, tentando negociar o estabelecimento de uma sessão com o IMS de outra operadora, que já migrou a plataforma para IPv6.

Aí a solução será o que? Incorporar suporte a NAT64 stateless, mais algum mecanismo de NAT traversal, tipo STUN ou TURN? Vai ficar complicado. E talvez não escale bem.

No geral ainda simpatizo mais com a solução puramente  dual-stack apresentada no post anterior. É certo que também é necessário o suporte do DNS64, mas fica muito mais simples para as aplicações decidirem como estabelecer conexão. Se ela recebe um registro AAAA, então a conectividade é estabelecida pelo socket v6, e se recebe apenas um registro A, ela usa o socket v4. E não há obrigatoriedade que o servidor DNS64 tenha conectividade IPv6, como é o caso na solução NAT64.

Outro problema óbvio para a solução dual-stack no ambiente das redes de acesso HSPA/HSPA+ é que cada UE precisa receber endereçamento IPv4 e IPv6, só que nenhuma operadora tem (nem vai ter) pool de endereços IPv4 públicos suficientes para atender à demanda de todos os clientes conectados. Neste caso creio que a saída menos ruim (porque também tem problemas de escalabilidade) é a proposta Dual-Stack Lite (DS-Lite, RFC 6333). Veja a figura abaixo.

Na proposta DS-Lite o endereçamento IPv4 dos UEs (que são dual-stack) é feito com endereços de alguma das faixas privadas definidas na RFC 1918 (ex.: 10.0.0.0/8). O tráfego IPv4 é destinado para a Internet v4 através de um Carrier-Grade NAT (CGN) gateway de forma muito parecida com o que já é feito hoje. E o tráfego IPv6 é encaminhado diretamente à Internet v6. Possivelmente a "ilha" IPv6 da operadora estará conectada às demais "ilhas" IPv6 por mecanismos de tunelamento sobre a Internet v4. Destes todos, o que me parece mais utilizado no momento é, como já disse no post anterior, o Teredo (RFC 4380), mas também existem outras opções, como, por exemplo, o 6rd (RFC 5569 e RFC 5969).

E, para não alongar muito, se for o caso deixo para mais tarde a análise do SIIT (Stateless IP/ICMP Translation - RFC 6052, RFC 6144 e RFC 6145) no contexto das redes de acesso HSPA/HSPA+.

Para fechar, então. um resumão do problema, conforme a minha opinião (o 3GPP e os fornecedores podem divergir - só que a operadora deve ter suas próprias idéias, não andar a reboque do que dizem os fornecedores), e é o que eu recomendaria às operadoras:

• O grande fator decisivo da estratégia é o roadmap de disponibilidade do IPv6 pelos fornecedores dos UEs. Computadores convencionais não são problema, porque todos os sistemas operacionais relevantes (MS-Windows, Apple MacOS, Linux em vários "sabores", Solaris, HP-UX, AIX, zOS, etc.) já oferecem suporte ao dual-stack. O problema são os smartphones e os tablets. Todo o resto, para mim, é legacy.
  
• Se a questão da duplicidade dos PDP contexts não for um problema, minha sugestão é: vá para uma solução dual-stack. Se o pool de endereços IPv4 apertar, cá para DS-Lite.
  
• Se UEs dual-stack forem escassos, ou a duplicidade dos PDP contexts for um problema, vá para o NAT64. Separe os UEs legacy para usarem apenas PDP contexts IPv4, e, para todos que suportarem, use apenas PDP contexts IPv6.

Por ora é isso. Mas este é o tipo do assunto que ainda pode render mais posts, então até a qualquer momento, em edição extraordinária.

IPv6 e as redes de acesso HSPA/HSPA+

Eu sei que ainda estou devendo para vocês o exemplo prático do algoritmo de planejamento de capacidade, mas a notícia que eu vi hoje, falando da preparação da TIM para o uso do protocolo IPv6, me causou uma preocupação: até que ponto o pessoal de marketing está consciente do que está fazendo ao usar este tipo de migração da rede como argumento para fazer posicionamento?

Migrar o serviço de acesso à internet de uma operadora celular 3G para IPv6 tem uma série de aspectos peculiares, além daqueles que afetam a migração de qualquer ISP para o IPv6. Talvez o maior deles seja o problema dos PDP contexts.

Para entender este problema temos que entender antes como funciona o acesso de um dispositivo móvel à Internet através de uma rede celular 3G. A figura abaixo dá um sumário disso.

Uma conexão PSD (Packet-Switching Domain) ocorre entre o UE (user equipment) e o GGSN (Gateway GPRS Support Node - eu sei... embora estejamos falando de HSPA e HSPA+, o nome do gateway ainda refere-se ao velho GPRS). Fisicamente essa conexão é mediada pelo Node-b onde o UE estiver concectado e pela RNC (Radio Network Controller) onde o Node-b estiver registrado. Como o UE é móvel, tanto o Node-B quanto a RNC que atendem o UE podem mudar ao longo da duração da conexão. Faz parte do processo de handover manter a conexão física UE-GGSN estável durante as trocas de Node-b e/ou RNC.

Logicamente a conexão UE-GGSN é associada a uma entidade chamada PDP (Packet Data Protocol) context. Na prática o PDP context funciona como um túnel lógico, e se comporta como se fosse uma interface de nível 2 para cada um dos equipamentos nas extremidades.

E isto é um problema por quê? Porquê, até que se complete a transição de todos os sites, serviços e aplicações da Internet para IPv6, nós teremos que conviver com duas Internet separadas logicamente: A Internet "clássica" IPv4 e a nova Internet IPv6. O processo de transição vai passar por duas etapas distintas, e nós estamos começando a entrar na primeira delas. E não tem prazo definido para a duração de cada fase.

A única forma prática (e recomendada pela IETF - Internet Engineering Task Force) para conviver com este processo de migração é que todos os hosts conectados possuam as duas pilhas de protocolos, IPv4 e IPv6 funcionando simultaneamente. Esta estratégia é chamada de dual-stack, e funciona da seguinte forma (para entender a figura você tem que ter familiaridade com o modelo TCP/IP)..

Desta forma cada host pode ter acesso às duas "Internets" enquanto durar a transição. Mas continua a regra: uma aplicação v4 não consegue dialogar diretamente com uma aplicação v6, e vice-versa. Vejamos as consequências disso para o modelo operacional da nossa rede de acesso 3G HSPA ou HSPA+.

Cada PDP context só pode estar associado a um único protocolo de nível 3. Portanto se o UE e o GGSN tem que funcionar em modo dual-stack, cada conexão PSD vai precisar de dois PDP contexts: um para o IPv4 e outro para o IPv6. Isto vai ter consequências em termos de memória e capacidade de processamento da platafoma que suporta o GGSN, e vai resultar em mais sinalização entre UE / Node-b / RNC / GGSN, o que pode ser problemático na HMM de algumas células. Portanto o planejamento de capacidade da interface aérea e do backhaul dos cell-sites tem que considerar esta carga extra.

Outra coisa é que, em geral, os fornecedores de soluções de GGSN cobram da operadora por número máximo de PDP contexts abertos (ativos ou dormentes), então tem que haver uma briga comercial feia aqui, senão o preço do GGSN vai quase dobrar de uma hora para outra.

E, como dizem os anúncios das Organizações Tabajara (do Casseta e Planeta), não é só  somente isso: ainda é muito incipiente a disponibilidade de UEs (exceto notebooks e desktops) capazes de funcionar em modo dual-stack. Mesmo que a operadora tenha todo o seu lado preparado e testado, poucos UEs estão prontos para desfrutar disso.

Por último temos a questão de como será a conexão, física e lógica, do GGSN às duas Intenets, v4 e v6. A solução mais básica é: duas interfaces físicas separadas (ou, pelo menos, duas interfaces lógicas separadas sobre a mesma interface física), cada uma delas conectada a roteadores diferentes (ou portas físicas ou lógicas diferentes de um mesmo roteador), cada uma delas servindo como uplink para uma das Internets.

Mas, como os diagramas da transição mostram, cada etapa é formada por "ilhas" de uma das Internets conectadas via tunelamento através do "mar" da outra internet (neste momento o IPv4 é o mar, e o IPv6 as ilhas, depois os papéis se invertem). Então existe a questão de quem vai prover o tunelamento do tráfego IPv6  da operadora (na fase 1)?

A resposta mais simples é: o fornecedor do(s) uplinks cuida disso. Neste caso, a depender do grau de separação física e lógica entre as interfaces e uplinks de acesso às Internets, a operadora pode não ter que fazer nada ou pode ter que configurar seu(s) roteadores de borda com as Internets - ou o próprio GGSN, e isso vai ter que ser outro item de negociação com o fornecedor - para fazer o tunelamento do tráfego IPv6 sobre pacotes IPv4. O mecanismo de tunelamento recomendado no momento é o Teredo (RFC 4380, RFC 5991 e RFC 6081).

A figura abaixo mostra o caso onde o tuelamento Teredo é implementado no roteador de borda com a Internet v4.

Esta figura é apenas uma visão simplificada. Ainda teriam que ser acrescentados os inevitáveis Firewalls e servidores DPI (Deep Packet Inspection) e, caso a arquitetura de serviços da operadora os use, servidores CDN (Content Delivery Network).

vocês percebem que isto é apenas um arranhão no problema completo de projetar a migração do acesso aos serviços de acesso a Internet (e aos serviços internos da operadora) para IPv6. E este é o motivo pelo qual achei engraçado a TIM ficar tocando tambores em público. Será que ela já resolveu dodos estes aspectos? Se algum dos leitores tiver conhecimento sobre o assunto e quiser entrar em contato comigo para conversar sobre isso eu agradeço.