[GTER] PTT (e PTT-SP) - Envolvimento da comunidade

[Carlos Ribeiro]

Roberto,

É isso mesmo! Mais do que discutir o problema A ou B, trata-se de propor um
modelo de discussão mais abrangente, que permita discutir idéias,
tecnologias, arquiteturas, e não soluções pontuais.

Parte da ideia é resgatar uma característica muito forte que havia nessa
lista no seu começo, que está visível no nome da mesma: GTER significa
"Grupo de Trabalho de Engenharia de Redes", e a proposta inicial da lista
tinha muito disso, de discutir a arquitetura da Internet BR. Isso se perdeu
um pouco pelo caminho... E talvez seja interessante pelo menos pensar nisso
com seriedade.

Carlos Ribeiro
Em 15/05/2015 16:10, "Roberto Bertó" <roberto.berto at gmail.com> escreveu:

> Acho que o maior ponto do email do Carlos Ribeiro nao é uma discussao
> tecnica agora de como está o PTT, etc. Mas sim que precisamos ter mais
> espaço para discussoes.
>
> Em 15 de maio de 2015 15:48, Kurt Kraut <listas at kurtkraut.net> escreveu:
>
> > Aloha,
> >
> >
> > Como respiro o mundo das CDNs, costumo ver o mundo deste lado do balcão e
> > por isso eu gostaria de propor a solução do dilema do ovo da galinha
> pondo
> > as CDNs primeiro nos PTTs antes da demanda. Penso em aproveitar o próximo
> > PTT Fórum para nos reunirmos e as partes interessadas compartilharem suas
> > ideias do que aqui proponho como um programa de fomento na regionalização
> > dos PTTs.
> >
> > O que faria uma CDN habilitar um edge em um PTT que tem menos que
> 10gbit/s
> > de pico diário de tráfego?
> >
> > - Algum patrocinador que arque com espaço, climatização e energia
> elétrica
> > para os servidores da CDN até atingir o break even point.
> > - Algum patrocinador que arque trânsito até atingir o break even point.
> > - Algum patrocinador que ofereça remote hands até atingir o break even
> > point (trocar cabeamento, power-off, power-on, coisas simples).
> > - A CDN mandaria para o local o seu hardware (de patrimônio dela) e um
> > técnico próprio para fazer a instalação.
> >
> > E que break even point é esse? O ponto em que para a CDN, arcar com
> > trânsito, energia, colocation, enviar técnico de campo para local se
> > equipare, graças ao tráfego gerado nele, ao custo de manter esse edge num
> > dos grandes PTTs. Isso se traduz num número de gigabytes trafegados por
> mês
> > pelos edges da CDN naquele PTT/PoP. Atingido esse patamar, a operação se
> > paga, o patrocinador pode deixar de patrocinar (e se torna um fornecedor
> em
> > potencial).
> >
> > Para sistemas autônomos, ver que chegaram no PTT fisicamente próximo a
> ele
> > os ASNes das CDNs ou provedores de conteúdo com os quais ele já troca
> muito
> > tráfego via trânsito ou no PTT-SP, justifica muito mais o investimento,
> > esforço e tempo para se ligar a um PTT regional.
> >
> > Nesse programa, se em 1 ou 2 anos o break even point previamente
> combinado
> > entre o patrocinador e a CDN não for atingido, um beijo e abraço, mas o
> > patrocinador pode pedir para a CDN retirar os equipamentos dela ou
> > apresentar uma proposta comercial para mantê-los. Tudo claro
> transparente,
> > regido por minuta ou contrato de parceria, com prazos e break even
> > pré-determinado.
> >
> > Da mesma forma que dinheiro atrai dinheiro, tráfego atrai tráfego. Esse
> > programa faria o primeiro incremento de tráfego para se iniciar o ciclo
> > vicioso de mais ASN abordando, mais tráfego sendo trocado.
> >
> > Essa é a minha opinião e proposta para vossa apreciação.
> >
> >
> > Abraços,
> >
> >
> > Kurt Kraut
> >
> > Em 15 de maio de 2015 15:15, Rafael Possamai <rafael at gav.ufsc.br>
> > escreveu:
> >
> > > Carlos, interessante as perguntas que voce fez. Eu imagino que o
> problema
> > > se criou por causa de dois problemas: 1) falta de estrutura / custo
> para
> > > melhorar infraestrutura 2) eh muito facil vender produto/servico ruim
> no
> > > Brasil e quem se ferra geralmente eh o consumidor final.
> > >
> > > Entao, se nao tem estrutura (ou eu nao quero investir, pois o custo
> > brasil
> > > eh absurdo) e nao tenho motivacao externa para investir  (meu servico
> > > prestado de ADSL / DOCSIS eh uma porcaria, mas raramente eu levo uma
> > multa
> > > da ANATEL) - qual eh a motivacao de ir pra fora de SP e gastar dinheiro
> > > extra se por enquanto funciona (funciona no padrao de qualidade
> Brasil)?
> > >
> > > Talvez seja uma maneira pessimista de olhar o problema, mas gostaria de
> > > saber sua opiniao.
> > >
> > > 2015-05-15 12:50 GMT-05:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:
> > >
> > > > Rubens,
> > > >
> > > > Obrigado pelas considerações! Você tem razão em várias das suas
> > > colocações:
> > > >
> > > > 1) a concentração em SP não é boa para a Internet brasileira. Tanto
> > que a
> > > > Telbrax está entrando no PTT do RJ, já era para estar ativo, só não
> foi
> > > > ligado por conta de problemas pontuais.
> > > >
> > > > 2) Veja também que a equação econômica da Internet faz com que as
> > grandes
> > > > CDNs perpetuem a situação, ao colocar todos seus pontos de
> > distribuição a
> > > > partir de SP. É difícil viabilizar a disponibilização de conteúdo em
> > > outros
> > > > centros; BH é um bom exemplo porque as CDNs dizem que a latência não
> > > > justifica, da para concentrar tudo em SP, e elas não querem arcar
> com o
> > > > custo do upstream para alimentar seus sistemas.
> > > >
> > > > 3) sobre o eventual estouro de um PIX, por conta de um tráfego
> > excessivo,
> > > > concordo que são dos problemas diferentes. Ampliar um PIX ou a
> ligação
> > > > entre os PIXs é só uma parte do problema; porém ampliar capacidade em
> > > rack
> > > > também pode ser mais simples em um datacenter grande. Não é
> exatamente
> > o
> > > > mesmo problema, mas em alguns cenários a solução centralizada é mais
> > > > simples de ampliar (apesar de ter seus próprios defeitos).
> > > >
> > > > 4) Não estou criticando o modelo do PTT no Brasil, pelo contrário;
> > estou
> > > > apenas defendendo mais diálogo com a comunidade. Acho que os
> provedores
> > > > podem ser mais do que meros clientes do PTT, e o diálogo poderia
> > > maximizar
> > > > os resultados. Digo isso tanto com relação ao planejamento de
> > > arquitetura,
> > > > como com relação aos procedimentos operacionais.
> > > >
> > > > Atenciosamente,
> > > >
> > > > Carlos Ribeiro
> > > > Em 15/05/2015 13:14, "Rubens Kuhl" <rubensk at gmail.com> escreveu:
> > > >
> > > > > >
> > > > > > O que me chamou mais a atenção, recentemente, foi a explicação
> > > segundo
> > > > a
> > > > > > qual os problemas intermitentes com o Google Cache são
> decorrência
> > do
> > > > > > estouro de capacidade de alguns PIX do PTT de SP. (Se eu entendi
> > > errado
> > > > > me
> > > > > > desculpem...)
> > > > > >
> > > > > >
> > > > > Essa foi a teoria que alguém levantou, mas que não parece se
> > sustentar
> > > na
> > > > > prática. É muito mais comum o Google atingir limite de capacidade
> de
> > > seus
> > > > > servidores de SP do que do PIX aonde ele está ligado ou dos PIX
> aonde
> > > os
> > > > > "eyeballs" estão conectados recebendo o tráfego do Google. O Google
> > tem
> > > > um
> > > > > mix de serviços (vídeo, busca, e-mail, mobile app store, docs) que
> > > requer
> > > > > um bom número de RUs (rack-units) /Gbps... mesmo o vídeo que é o de
> > > maior
> > > > > relação ainda sim não é tanto asim.
> > > > >
> > > > > Diferente por exemplo de caras como Netflix, UPX, Globo.com etc.
> que
> > > com
> > > > um
> > > > > ou dois racks geram 100 Gbps fácil. Esses tem um poder muito alto
> de
> > > > > saturar o PIX alheio... e o Netflix em Porto Alegre teve um efeito
> > > > desses,
> > > > > por exemplo.
> > > > >
> > > > >
> > > > >
> > > > > O outro ponto só pode ser discutido depois de superado o ponto
> > inicial,
> > > > mas
> > > > > > vale a pena ser apresentado. O modelo de PTT no Brasil é
> > > elogiadissimo
> > > > > > mundo afora como uma solução inovadora, que aliou um pragmatismo
> > > > técnico
> > > > > e
> > > > > > comercial, com o modelo de abertura de pontos de interconexão
> (PIX)
> > > de
> > > > > > forma bastante democrática. Isso levou ao crescimento do PTT,
> > > > > especialmente
> > > > > > de SP, de forma exponencial.
> > > > > >
> > > > >
> > > > > Esse modelo, incluindo o do ccTLD nacional alavancar os IXs, foi
> > aliás
> > > > > recentemente replicado no Canadá.
> > > > >
> > > > > Eu pincei só algumas partes e não comentei o principal da sua
> > > mensagem, o
> > > > > que deixo para outros fazerem, mas gostaria de comentar o que eu
> acho
> > > que
> > > > > hoje é o maior problema do PTT.br em escala nacional: a busca
> > > desenfreada
> > > > > por se conectar apenas em SP. Enquanto na Europa muitos estão ao
> > mesmo
> > > > > tempo no AMS-IX, no LINX e no DE-CIX, aqui as diferenças de
> > > participação
> > > > > entre (por exemplo) SP, Rio e Belo Horizonte são muito
> grandes...isso
> > > > gera
> > > > > uma dependência de ponto único que não precisaria existir, pois
> > muitas
> > > > > redes de acesso vem buscar conteúdos, tipicamente muito mais ágeis
> do
> > > que
> > > > > uma rede de acesso. Cai o POP de uma operadora no PIX dela de SP e
> a
> > > > Caiu é
> > > > > inundada de mensagens "Caiu o PTT", mostrando como essa dependência
> > se
> > > > > manifesta.
> > > > >
> > > > >
> > > > > Rubens
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter