thegoodfellas/blogset-br huggingface dataset:
Eu sei que ainda estou devendo para voces o exemplo pratico do algoritmo de planejamento de capacidade, mas a noticia que eu vi hoje, falando da preparacao da TIM para o uso do protocolo IPv6, me causou uma preocupacao: ate que ponto o pessoal de marketing esta consciente do que esta fazendo ao usar este tipo de migracao da rede como argumento para fazer posicionamento?Migrar o servico de acesso a internet de uma operadora celular 3G para IPv6 tem uma serie de aspectos peculiares, alem daqueles que afetam a migracao 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 movel a Internet atraves de uma rede celular 3G. A figura abaixo da um sumario disso.Uma conexao 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 conexao e mediada pelo Node-b onde o UE estiver concectado e pela RNC (Radio Network Controller) onde o Node-b estiver registrado. Como o UE e movel, tanto o Node-B quanto a RNC que atendem o UE podem mudar ao longo da duracao da conexao. Faz parte do processo de handover manter a conexao fisica UE-GGSN estavel durante as trocas de Node-b e/ou RNC.Logicamente a conexao UE-GGSN e associada a uma entidade chamada PDP (Packet Data Protocol) context. Na pratica o PDP context funciona como um tunel logico, e se comporta como se fosse uma interface de nivel 2 para cada um dos equipamentos nas extremidades.E isto e um problema por que? Porque, ate que se complete a transicao de todos os sites, servicos e aplicacoes da Internet para IPv6, nos teremos que conviver com duas Internet separadas logicamente: A Internet "classica" IPv4 e a nova Internet IPv6. O processo de transicao vai passar por duas etapas distintas, e nos estamos comecando a entrar na primeira delas. E nao tem prazo definido para a duracao de cada fase.A unica forma pratica (e recomendada pela IETF - Internet Engineering Task Force) para conviver com este processo de migracao e que todos os hosts conectados possuam as duas pilhas de protocolos, IPv4 e IPv6 funcionando simultaneamente. Esta estrategia e chamada de dual-stack, e funciona da seguinte forma (para entender a figura voce tem que ter familiaridade com o modelo TCP/IP)..Desta forma cada host pode ter acesso as duas "Internets" enquanto durar a transicao. Mas continua a regra: uma aplicacao v4 nao consegue dialogar diretamente com uma aplicacao v6, e vice-versa. Vejamos as consequencias disso para o modelo operacional da nossa rede de acesso 3G HSPA ou HSPA+.Cada PDP context so pode estar associado a um unico protocolo de nivel 3. Portanto se o UE e o GGSN tem que funcionar em modo dual-stack, cada conexao PSD vai precisar de dois PDP contexts: um para o IPv4 e outro para o IPv6. Isto vai ter consequencias em termos de memoria e capacidade
de processamento da platafoma que suporta o GGSN, e vai resultar em mais sinalizacao entre UE / Node-b / RNC / GGSN, o que pode ser problematico na HMM de algumas celulas. Portanto o planejamento de capacidade da interface aerea e do backhaul dos cell-sites tem que considerar esta carga extra.Outra coisa e que, em geral, os fornecedores de solucoes de GGSN cobram da operadora por numero maximo de PDP contexts abertos (ativos ou dormentes), entao tem que haver uma briga comercial feia aqui, senao o preco do GGSN vai quase dobrar de uma hora para outra.E, como dizem os anuncios das Organizacoes Tabajara (do Casseta e Planeta), nao e so somente isso: ainda e 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 estao prontos para desfrutar disso.Por ultimo temos a questao de como sera a conexao, fisica e logica, do GGSN as duas Intenets, v4 e v6. A solucao mais basica e: duas interfaces fisicas separadas (ou, pelo menos, duas interfaces logicas separadas sobre a mesma interface fisica), cada uma delas conectada a roteadores diferentes (ou portas fisicas ou logicas diferentes de um mesmo roteador), cada uma delas servindo como uplink para uma das Internets.Mas, como os diagramas da transicao mostram, cada etapa e formada por "ilhas" de uma das Internets conectadas via tunelamento atraves do "mar" da outra internet (neste momento o IPv4 e o mar, e o IPv6 as ilhas, depois os papeis se invertem). Entao existe a questao de quem vai prover o tunelamento do trafego IPv6 da operadora (na fase 1)?A resposta mais simples e: o fornecedor do(s) uplinks cuida disso. Neste caso, a depender do grau de separacao fisica e logica entre as interfaces e uplinks de acesso as Internets, a operadora pode nao ter que fazer nada ou pode ter que configurar seu(s) roteadores de borda com as Internets - ou o proprio GGSN, e isso vai ter que ser outro item de negociacao com o fornecedor - para fazer o tunelamento do trafego IPv6 sobre pacotes IPv4. O mecanismo de tunelamento recomendado no momento e o Teredo (RFC 4380, RFC 5991 e RFC 6081).A figura abaixo mostra o caso onde o tuelamento Teredo e implementado no roteador de borda com a Internet v4. Esta figura e apenas uma visao simplificada. Ainda teriam que ser acrescentados os inevitaveis Firewalls e servidores DPI (Deep Packet Inspection) e, caso a arquitetura de servicos da operadora os use, servidores CDN (Content Delivery Network).voces percebem que isto e apenas um arranhao no problema completo de projetar a migracao do acesso aos servicos de acesso a Internet (e aos servicos internos da operadora) para IPv6. E este e o motivo pelo qual achei engracado a TIM ficar tocando tambores em publico. Sera que ela ja resolveu dodos estes aspectos? Se algum dos leitores tiver conhecimento sobre o assunto e quiser entrar em contato comigo para conversar sobre isso eu agradeco.
No artigo anterior eu defendi a tese que a opcao menos ruim (porque boa, boa mesmo, de verdade, nao tem) para a migracao do servico de acesso movel a Internet atraves das redes de acesso celulares 3G (HSPA e HSPA+) era a abordagem dual-stack (ver RFC 4213).Nos comentarios daquele artigo o Rubens Kuhl e o Juliano defenderam que a melhor opcao e o uso do NAT64. Certamente que eu acho possivel usar o NAT64 neste contexto, mas tenho duvidas se ele vai funcionar tao bem.Antes de comecar a discutir pros e contras relativos de cada abordagem, pelo bem daqueles leitores que nao tenham familiaridade com o assunto (afinal este blog tem uma finalidade basicamente instrutiva), vou fazer uma breve apresentacao 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 enderecamento privado definidos na RFC 1918 permitiram um consideravel aumento da sobrevida do espaco de enderecamento do IPv4, mas tambem criaram uma sensacao de falsa seguranca, e muito pouca coisa concreta foi feita para que a transicao 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 nao existe motivo para o uso de NAT, como e destacado na RFC 4864. Ja a questao de como um host v6 pode estabelecer conexao com um host v4, e vice-versa, so pode ocorrer mediante alguma forma de NAT para fazer a "ponte" entre as duas Internets (v4 e v6).O NAT64 permite que aplicacoes em um host que seja single-stack IPv6 consigam acessar aplicacoes que residem em hosts tambem single-stack, porem IPv4. Os recursos necessarios para usar o NAT64 sao:Um Well-Known Prefix (WNP) IPv6. Conforme a secao 2.1 da RFC 6052, o WNP para o NAT64 e 64:ff9b::/96 (se voce ja penou pra entender a notacao dotted decimal dos enderecos IPv4, entao prepare-se, porque a notacao dos enterecos IPv6 e bem mais criptica. Sugiro dar uma olhada aqui).Servidor DNS que suporte as extensoes DNS64 (RFC 6052 e RFC 6146)A figura abaixo mostra o esquema geral de funcionamento do NAT64.O fluxo de mensagens mostrado e para quando o host de destino so 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 possuisse conectividade IPv6 haveria uma resposta valida para a query pelo registro AAAA no servidor DNS, e (mesmo que o host de destino fosse dual-stack e tambem houvesse uma resposta com o registro A associado) a conectividade IPv6 seria possivel - logo o gateway NAT64 nao seria usado.Bonito, porem vejo um problema serio nesta abordagem. Ele e muito bom quando os UEs estao querendo acessar servidores IPv4 no regime client-server habitual (ex.: web surfing e verificacao da caixa postal de e-mails). Mas a situacao muda quando a direcao do inicio da sessao e invertida (da Internet v4 para dentro da "ilha" IPv6 que e a rede interna da operadora). E, no
quadro de funcionamento peer-to-peer tipico das aplicacoes de telefonia (tanto na conexao bearer quanto na conexao de sinalizacao SIP) isto vai ocorrer a toda hora - Exemplo: o IMS de uma operadora, ainda usando IPv4, tentando negociar o estabelecimento de uma sessao com o IMS de outra operadora, que ja migrou a plataforma para IPv6.Ai a solucao sera o que? Incorporar suporte a NAT64 stateless, mais algum mecanismo de NAT traversal, tipo STUN ou TURN? Vai ficar complicado. E talvez nao escale bem.No geral ainda simpatizo mais com a solucao puramente dual-stack apresentada no post anterior. E certo que tambem e necessario o suporte do DNS64, mas fica muito mais simples para as aplicacoes decidirem como estabelecer conexao. Se ela recebe um registro AAAA, entao a conectividade e estabelecida pelo socket v6, e se recebe apenas um registro A, ela usa o socket v4. E nao ha obrigatoriedade que o servidor DNS64 tenha conectividade IPv6, como e o caso na solucao NAT64.Outro problema obvio para a solucao dual-stack no ambiente das redes de acesso HSPA/HSPA+ e que cada UE precisa receber enderecamento IPv4 e IPv6, so que nenhuma operadora tem (nem vai ter) pool de enderecos IPv4 publicos suficientes para atender a demanda de todos os clientes conectados. Neste caso creio que a saida menos ruim (porque tambem tem problemas de escalabilidade) e a proposta Dual-Stack Lite (DS-Lite, RFC 6333). Veja a figura abaixo.Na proposta DS-Lite o enderecamento IPv4 dos UEs (que sao dual-stack) e feito com enderecos de alguma das faixas privadas definidas na RFC 1918 (ex.: 10.0.0.0/8). O trafego IPv4 e destinado para a Internet v4 atraves de um Carrier-Grade NAT (CGN) gateway de forma muito parecida com o que ja e feito hoje. E o trafego IPv6 e encaminhado diretamente a Internet v6. Possivelmente a "ilha" IPv6 da operadora estara conectada as demais "ilhas" IPv6 por mecanismos de tunelamento sobre a Internet v4. Destes todos, o que me parece mais utilizado no momento e, como ja disse no post anterior, o Teredo (RFC 4380), mas tambem existem outras opcoes, como, por exemplo, o 6rd (RFC 5569 e RFC 5969).E, para nao alongar muito, se for o caso deixo para mais tarde a analise do SIIT (Stateless IP/ICMP Translation - RFC 6052, RFC 6144 e RFC 6145) no contexto das redes de acesso HSPA/HSPA+.Para fechar, entao. um resumao do problema, conforme a minha opiniao (o 3GPP e os fornecedores podem divergir - so que a operadora deve ter suas proprias ideias, nao andar a reboque do que dizem os fornecedores), e e o que eu recomendaria as operadoras:O grande fator decisivo da estrategia e o roadmap de disponibilidade do IPv6 pelos fornecedores dos UEs. Computadores convencionais nao sao problema, porque todos os sistemas operacionais relevantes (MS-Windows, Apple MacOS, Linux em varios "sabores", Solaris, HP-UX, AIX, zOS, etc.) ja oferecem suporte ao dual-stack. O problema sao os smartphones e os tablets. Todo o resto, para mim, e legacy.Se a questao da duplicidade dos PDP contexts nao for um problema, minha sugestao e: va para uma solucao dual-stack. Se o pool de
enderecos IPv4 apertar, ca para DS-Lite.Se UEs dual-stack forem escassos, ou a duplicidade dos PDP contexts for um problema, va 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 e isso. Mas este e o tipo do assunto que ainda pode render mais posts, entao ate a qualquer momento, em edicao extraordinaria.
Li e reli os dois novos regulamentos sobre indicadores da qualidade do SCM e do SMP, e, sinceramente, achei a redacao confusa e, as vezes, contraditoria. Entao decidi publicar alguns posts dedicados a tentar fazer uma apresentacao inteligivel dos indicadores de qualidade da rede do SCM e dos indicadores de conexoes de dados do SMP (nao vou tratar dos indicadores de reacao do usuario - SCM e SMP, nem dos indicadores de atendimento - SCM e SMP, nem dos indicadores das conexoes de voz - so SMP, e nem dos indicadores de pesquisa - SCM e SMP).Sempre que possivel vou emparelhar os indicadores que medem coisas semelhantes para o SCM e para o SMP. E vale observar logo: estes regulamentos so afetam operadores SCM ou SMP com mais de 50K assinantes (ou acessos em servico, na terminologia dos regulamentos). Ou seja: praticamente so as operadoras de telefonia fixa e movel entram neste criterio. Os pequenos e medios operadores SCM (creio que esta categoria nao exista no SMP) nao sao afetados por estes regulamentos.Qualquer problema de analise de performance comeca pela definicao do 5W1H:WHAT: o que vai ser medido?WHY: porque vamos medir isso?WHO: quem fara a medicao?WHERE: onde sera feita a medicao?WHEN: quando sera feita a medicao?HOW: como faremos esta medicao? Entao vamos tentar organizar os indicadores de qualidade da rede para dar a melhor resposta possivel a estas perguntas, com base no que esta escrito nos regulamentos e com um pouco de bom senso.Os dois regulamentos (art. 10 para o SCM e art. 24 para o SMP) preveem que as operadoras tem que disponibilizar (para a Anatel e para os assinantes, no caso do SMP, e so para os assinantes no caso do SCM) software de medicao do desempenho da rede, que devera poder ser baixado por cada usuario interessado, e que deve ser capaz de medir os seguintes indicadores (e registrar - onde? - data/hora e local dos resultados obtidos, para possibilitar a formacao de serie historica):Taxa de transferencia instantanea - indicadores SCM4 e SMP10. A taxa instantanea deve ser medida tanto no canal de download quanto no canal de upload;Latencia bidirecional (aquilo que comumente chamamos de round-trip time, medido com o programa ping) - indicador SCM6, mas sem indicador correspondente no SMP (alias, nao tem nem mesmo definicao para o round-trip time no RGQ-SMP). O que levanta uma questao interessante: o software vai medir isso, mas a operadora nao tem nenhuma meta estabelecida para este item de desempenho. Vai dar confusao.Variacao de latencia (jitter) - indicador SCM7, e tambem sem indicador correspondente para o SMP. Valem as mesmas observacoes do caso da latencia bidirecional.Taxa de perda de pacotes (packet loss) - indicador SCM8, e tambem sem correspondente no SMP. Aqui temos os inconvenientes dos dois itens anteriores e mais um adicional: nao e dada nenhuma definicao, nem mesmo no regulamento do SCM, para este item o como calcular esta completamente em aberto.Outro fator de confusao ligado a este software de medicao e que enquanto o regulamento do SCM especifica (no inciso I do art. 15) que a medicao dos dados
para o calculo 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 confianca minimo de 95% - por analogia com o item 4.3 do anexo III do regulamento do SCM). Ja o SMP nao fala nada sobre como fazer a medicao, e ainda deixa aberta a possibilidade de ser usado o mesmo software que sera disponibilizado para os assinantes. Muito mal definido.Existe mais um indicador comum aos dois regulamentos: taxa de transferencia media (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 sao especificos para o SMP, e nao tem correspondente no SCM. Talvez seja apenas a vontade de manter paralelismo com os indicadores do servico de voz do SMP:Taxa de completamento de conexoes de dados (SMP8);Taxa de queda das conexoes de dados (SMP9);Entao podemos fazer uma tabela resumo sobre o que (what) temos que medir:Vamos assumir que o porque medir (why) seja auto-explicativo. E sabemos quem (who) vai medir. Sera a tal da Entidade Aferidora da Qualidade, que e descrita nos artigos 33 a 37 do RGQ-SCM e nos artigos 26 a 30 do RGQ-SMP, mas com uma diferenca: no SCM a Entidasde Aferidora e responsavel pela coleta de dados e calculo de todos os indicadores de rede (SCM4, SCM5, SCM6, SCM7 e SCM8), mas no SMP ela e responsavel apenas pela coleta de dados e calculo dos indicadores SMP10 e SMP11. Subentende-se, entao, que a responsabilidade pela coleta de dados e calculo dos indicadores SMP8 e SMP9 cabe as operadoras.As questoes de onde (where) e quando (when) medir tambem dao o que falar: tanto o SCM quanto o SMP pedem que os calculos dos indicadores ocorra no PMT (periodo de maior trafego - que e definido de forma invariavel como sendo das 10:00 as 22:00 horas - o que, por si so, e uma incongruencia estatistica). Mas, enquanto no RGQ-SCM o art. 15 define que a medicao deve ocorrer na casa dos usuarios, com uma dispersao da amostrage tal que permita a representacao estatisticamente significativa da diversidade do publico usuario do servico, no RGQ-SMP apenas e dito que o mesmo software que for disponibilizado para que os usuarios facam suas proprias medicoes tambem podera ser usado para efetuar as medicoes para calculo oficial dos indicadores. E nao diz nada sobre como escolher uma amostra estatisticamente significativa dos usuarios, que, no caso do SMP, tem uma dimensao a mais em relacao ao SCM: a maior diversidade de equipamentos de acesso (smartphones e tablets, alem dos desktops e notebooks tipicos do SCM).Para terminar esta etapa da analise, vou apenas sumarizar as metas a atingir em cada indicador, para os dois servicos (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 e dito sobre o software de medicao a ser disponibilizado aos usuarios no 8o
do art. 24 do RGQ-SMP) dizem que a medicao deve ser efetuada entre o equipamento do usuario e o PTT. So nao especifica o criterio para definir qual PTT usar nas medicoes, porque existem varios, publicos e privados.Na proxima parte vou analisar com calma a questao do como (how) medir. Do svidanya tovarishchi.
rendendo mais baseados nos estaduais o palmeiras esta bem melhor e pode vencer em casa .Aposta: Vitoria do Palmeiras. Jogadores Destaques: Palmeiras - Marcos Assuncao , Cicinho , Henrique , Mauricio Ramos E Felipao / Portuguesa - Guilherme , Ananias , Ricardo Jesus E Weverton. SPT X FLA Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais o sport tem uma minima vantagem no flamengo mais o FLA nao deve decepcionar.Aposta: Empate.Jogadores Destaques: Sport - Magrao , Moacir , Bruno Aguiar , Marcelinho Paraiba E Rafael Jael / Flamengo - Felipe , Leo Moura , Junior Cesar , Kleberson ,Ronaldinho E Vagner Love. FIG X NAU Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais o figueirense como joga em casa podera sair com vitoria .Aposta: Vitoria do Figueirense. Jogadores Destques: Figueirense - Wilson , Pablo , Tulio , Aloisio E Julio Cesar / Nautico - Gideao , Ronaldo Alves , Ramon , Souza E Siloe.Domingo 20 De Maio BOT X SPO Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais podera ser um jogo muito acirrado pois os 2 times estao jogando muito bem.Aposta: Empate.jogadores Destaques: Botafogo - Jefferson , Fabio Ferreira , Antonio Carlos , Elkeson , Maicosuel , Renato E Loco Abreu / Sao Paulo - Denis , Bruno Cortez , Edson Silva , Rhodolfo , Cicero , Lucas , Fernandinho E Luis Fabiano. COR X FLU Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais esses times estao muito fortes esse ano promete um bom jogo e os estao ainda desputando a libertadore.Aposta: Empate. Jogadores Destaques: Corinthians - Chicao , Castan , Fabio Santos , Paulinho , Ralf , Danilo , Jorge Henrique , Emerson E Willian / Fluminense - Cavalieri , Carlinhos , Leandro Eusebio , Thiago Neves , Deco , Sobis E Fred. INT X CFC Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais o inter pode ganhar pois joga em casa e conta com a volta dos principais jogadores.Aposta: Vitoria Do Internacional.Jogadores Destaques: Internacional - Muriel , Nei , Rodrigo Moledo , Tinga , Datolo , Guinazu , Oscar , D'alessandro(se jogar) , Dagoberto E Leandro Damiao / Coritiba - Vanderlei , Emerson , Lincoln , Theco E Anderson Aquino. PON X CAM Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais o Atletico Mineiro podera vencer.Aposta: Vitoria Do Atletico Mineiro.Jogadores Destaques: Ponte Preta - Bruno , Cicinho , Ferron , Willian Magrao , Caio , Renato Caja E Roger / Atletico Mineiro - Giovanni , Marcos Rocha , Rever , Richarlyson , Bernard E Andre. VAS X GRE Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos
estaduais o vasco esta bem melhor e podera ganhar o jogo.Aposta: Vitoria Do Vasco Ou Empate. Jogadores Destaques: Vasco - Prass , Dede , Fagner , Juninho Pernambucano , Diego Souza , Felipe , Eder luis E Alecsandro / Gremio - Victor , Para , Naldo , Souza , Leo Gago , Bertoglio , Marcelo Moreno E Kleber. CRU X ACG Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais o atletico goianiense podera ganhar mesmo fora de casa.Aposta: Vitoria Do Atletico Goianiense Ou Empate. Jogadores Destaques: Cruzeiro - Fabio , Victorino , Alex Silva , Leandro Guerreiro , Everton , Montillo , Anselmo Ramon E Wellington Paulista / Atletico Go - Marcio , Feltri , Anderson , Bida , Felipe E Anselmo. BAH X SAN Analise: Como estamos na 1a rodada nao temos muita nocao de como os times estao rendendo mais baseados nos estaduais o santos tem uma imensa vantagem principalmente pelos seus grandes jogadores Neymar E Ganso.Aposta: Vitoria Do Santos.Jogadores Destaques: Bahia - Lomba , Titi , Rafael Donato , Lulinha , Gabriel E Junior / Santos - Rafael , Juan , Edu Dracena , Henrique , Arouca , Elano , Ganso , Alan Kardec E Neymar.