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

[Roberto Bertó]

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
>