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

[Fernando Frediani]

Mais uma excelente proposta, o que mostra que a o envolvimento da 
comunidade sempre traz muita coisa boa para o projeto. Parabéns Kurt.
Pra levantar isso que você propôs precisa mais de boa vontade dos 
patrocinadores e das CDNs do que de dinheiro em si na minha opinião.

Fernando

On 15/05/2015 15:48, Kurt Kraut wrote:
> 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