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

Fri May 15 15:48:16 -03 2015

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
>