[GTER] Compartilhamento de Cache no PTT

Sun May 17 10:22:10 -03 2015

Oi Fernando,

Conforme eu já havia conversado com você pessoalmente, penso que esse
modelo de cache distribuído provavelmente não terá um grau "decente"
de eficiência, nem mesmo nos PTT's menores, pelos motivos expostos
abaixo.

De uma maneira bem genérica (e empírica, já levando em conta o https,
que boa parte tem usado para entregar conteúdo) a distribuição do
acesso dos provedores brasileiros (75% a 85% talvez ?) se concentra
entre (me corrijam se estiver escrevendo bobagem):
Google AS 15169 - (maior parte: Youtube e Playstore, além é claro do buscador);
Akamai AS 20490 - (bancos, e-commerce, fotos FB, jogos, etc);
Facebook AS 32934 (imagina porque..);
Netflix AS 2906 - (alegria da criançada é ver a Galinha Pintadinha online);
Softlayer AS 36351 - (what's app e hosting em geral)
Limelight, Edgecast, Riotgames - (cdn's de jogos online)

O resto são casos pontuais ou acesso direto - nesse caso tem a parcela
de troca que é feita no PTT local - (os p2p - torrent e derivados;
sites de entretenimento adulto; bulk traffic: sites de governos, jogos
online via web, etc) e demandam acordos de peering
bilateral/multilateral ou a entrada em outros PTT's maiores ou quem
sabe fora do Brasil.

Esse resto talvez represente nem o restante dos 15% a 20% do que é
acessado. Diante disso a economia de banda nesse caso, ao meu ver, não
paga o que se investirá num projeto de cache distribuído "genérico".

Por outro lado uma sugestão que penso ser válida aos PTTs menores é
que os provedores locais se juntem, peçam nós de uma dessas CDNs (um
Google Cache se consegue fácil justificando pelo menos 2Gbps de
tráfego) para serem instalados dentro da estrutura do PTT
local/regional, e arquem com o custo de alimentar a CDN com trânsito
IP (GGC chega a uma eficiência de 85% por cento - ou seja, a cada
100Mbps servidos, ele precisa de 15 Mbps de trânsito). Um GGC de
última geração ocupa 6U de rack, e requer mais um switch 24 portas com
uplink 10G. E para esse(s) cache(s) de CDN compartilhado seriam
anunciados só os IP's de quem ajuda a pagar as contas.

Certamente outras CDNs tem um grau de eficiência (hit count) maior ou
igual ao que pode ser provido por caches baseados em soluções como o
Squid. Por isso, penso que esse modelo com CDNs "compartilhadas" é
mais sustentável a médio/longo-prazo que a instalação dos caches
"genéricos" sugeridos. A sua ideia não é ruim, mas não acredito que
escale bem no ambiente Service Provider.

Por fim, certamente a tarefa mais difícil seja a de conseguir consenso
entre provedores concorrentes no assunto dividir a conta do
trânsito/energia/espaço, seja para a CDN seja para cache genérico
distribuído. Tomara que eu esteja errado. :-(

Abs,
Humberto Galiza

Em 17 de maio de 2015 01:07, Fernando Frediani <fhfrediani at gmail.com> escreveu:
> Prezados,
>
> Henrique - Um provedor por menor que seja se estiver conectado a um PTT
> qualquer eu assumo que ele tem ali pelo menos um transporte de 100 Mb e
> tendo um link desse tamanho dá pra fazer algo razoavelmente bom sem o risco
> de saturar. Muito provavelmente o que estiver saindo pelo link com o PTT
> dele para servir um outro ISP seria equivalente ao que estaria entrando seja
> de outros caches seja de CDNs (se existir) e se o volume de entrada estiver
> próximo dos 70% já é hora de pensar em aumentar esse link.
>
> Lucas - Não tenho certeza a respeito de conteúdo em HTTPS. Muito tem se
> falado ultimamente mas não creio que tudo que é GGC, Akamai ou Netflix
> esteja obrigatoriamente vindo em HTTPS. Se fosse assim já teria matado
> qualquer produto de cache a algum tempo e embora o haja relatos de uma queda
> no Hit Ratio essa queda não foi de 30-40% para 2%. Tem que pesquisar melhor
> a respeito da mudanças que estão acontecendo e qual será a tendência. Não
> tenho certeza, mas acredito que não é bem assim e muita coisa ainda vem em
> HTTP. E tem outras coisas (Microsoft, Valve, Linux Mirrors, etc).
>
> Eduardo - A idéia de compartilhamento de cache é principalmente para PTTs
> Regionais ou menores aonde não existe CDN. Nada impede de se usar em um PTT
> como SP aonde elas existam e é possível colocar uma "blacklist" no seu cache
> para não gravar em disco o que venha deles então sobra mais espaço para
> conteúdo non-CDN.
>
> Enfim, se o cache já existe e possui um Hit Ratio que esteja valendo a pena
> rodar ele, já havendo tantos outros caches vizinhos que possam ser
> consultados ao mesmo tempo, a probabilidade aumenta exponencialmente de se
> encontrar o conteúdo ali do lado e economizar transito. O que o ISP tem a
> perder com algumas consultas rápidas via UDP a 1 - 2 ms de distancia ?
>
> Abraços
> Fernando
>
>
> On 16/05/2015 23:06, Eduardo Schoedler wrote:
>>
>> Cache https não existe.
>>
>> Tendo CDN da Akamai e o Google GGC, sua demanda de banda cai muito.
>>
>> Quase não precisa ter esses caches com encaminhamento de tráfego.
>>
>> --
>> Eduardo Schoedler
>>
>> Em sábado, 16 de maio de 2015, Lucas Willian Bocchi
>> <lucas.bocchi at gmail.com>
>> escreveu:
>>
>>> E cache ainda esta sendo efetivo em https?
>>> Em 16/05/2015 17:03, "Henrique Mattos" <henrique at stable.com.br
>>> <javascript:;>> escreveu:
>>>
>>>> Vejo um pequeno problema nisso que é justamente o pequeno provedor não
>>>> ter banda suficiente para fornecer esse conteúdo a seu vizinho,
>>>> geralmente os pequenos provedores que optam por essas soluções de
>>>> cache, infelizmente a maioria visa "economia de link".... com isso
>>>> acabam trabalhando com seus transportes ou conexões sempre próximo ao
>>>> limite...
>>>>
>>>> O maior problema é que justamente esses pequenos/médios e ate grandes,
>>>> não estão conectados aos PTT's mais próximos, e sim todo mundo
>>>> pendurado no PTT-SP, e como o custo $$$ é mais viável, continua se
>>>> empurrando com a barriga isso.
>>>>
>>>> Não sei como anda a realidade ai no Brasil... mas por aqui na região
>>>> sul do maranhão (sarneyquestão)... infelizmente os empresários aqui da
>>>> região não conseguem ver que podem se ajudar e somarem esforços para
>>>> atraírem players para os PTTs mais próximos...
>>>>
>>>>
>>>> Então vejo que o primeiro esforço seria realmente ter mais conexões
>>>> nos PTT's regionais, e para isso esta faltando algum incentivo, algo
>>>> que realmente valha a pena o pequeno ir para o PTT regional, antes de
>>>> procurar o transporte ate SP.
>>>>
>>>>
>>>> Nosso maior desafio é esse... criar uma internet livre e
>>>
>>> descentralizada...
>>>>
>>>>
>>>> Henrique Mattos
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Em 16 de maio de 2015 16:19, Fernando Frediani <fhfrediani at gmail.com
>>>
>>> <javascript:;>>
>>>>
>>>> escreveu:
>>>>>
>>>>> Pessoal, gostaria de opinião de vocês a respeito da viabilidade do
>>>>
>>>> seguinte.
>>>>>
>>>>> Seria mais voltado a quem utiliza algum tipo de cache (Thundercache,
>>>>> MARACache, SpeedR, etc) mas mesmo quem não utilize sinta-se a vontade
>>>>
>>>> para
>>>>>
>>>>> colocar sua opinião.
>>>>>
>>>>> Hoje diversos provedores principalmente de pequeno e médio porte
>>>
>>> utilizam
>>>>>
>>>>> cache local o que ajuda não apenas a reduzir custos de Transito mas
>>>>
>>>> também
>>>>>
>>>>> para melhorar a experiencia do usuário, especialmente em cidades do
>>>>
>>>> interior
>>>>>
>>>>> dos Estados em que os ISPs não estao ligados aos PTTs de SP, RJ ou RS.
>>>>>
>>>>> A idéia é o seguinte:
>>>>> Diversos provedores que utilizam cache e ligados aos PTTs Regionais
>>>>
>>>> (também
>>>>>
>>>>> a SP, RJ ou RS) poderiam formar um cluster desses caches através do
>>>>> compartilhamento de seus caches entre si aumentando drasticamente a
>>>>> quantidade de conteúdo que, se não presente de maneira local, estaria
>>>
>>> no
>>>>>
>>>>> cache do vizinho logo ali do lado. Várias tecnologias de cache hoje em
>>>>
>>>> dia
>>>>>
>>>>> possuem suporte nativo para formar um cluster desse tipo, inclusive
>>>>
>>>> existe
>>>>>
>>>>> protocolo próprio otimizado para este tipo de transação o ICP (Internet
>>>>> Cache Protocol) - http://en.wikipedia.org/wiki/Internet_Cache_Protocol
>>>>>
>>>>> De maneira simplificada fica assim:
>>>>> 1 - O usuário faz a requisição do conteúdo HTTP
>>>>> 2 - O provedor redireciona a requisição dele pro servidor de cache
>>>>
>>>> local. Se
>>>>>
>>>>> o conteúdo existe ali é servido ao usuário e a conexão termina ai.
>>>>> 3 - Caso o conteúdo não exista localmente o servidor de cache vai
>>>>
>>>> consultar
>>>>>
>>>>> seus vizinhos a 1 - 2 ms de distancia e caso algum deles possua é então
>>>>> servido ao usuário.
>>>>> 4 - Em ultimo caso o próprio servidor do provedor aonde o usuário
>>>>
>>>> requisitou
>>>>>
>>>>> o conteúdo originalmente vai buscar o conteúdo na sua origem, gravando
>>>>> localmente e servindo o usuário e a todos os outros colegas ISPs no
>>>>
>>>> futuro.
>>>>>
>>>>> Hoje um servidor de cache armazena cerca de 2 - 4 TB de conteúdo em
>>>>
>>>> média,
>>>>>
>>>>> imagine um cluster com 10x disso e de um conteúdo diversificado.
>>>>> Se isso for viável acredito que possa auxiliar de maneira
>>>
>>> significativa o
>>>>>
>>>>> desenvolvimento dos PTTs Regionais que não possuem CDN e onde os
>>>>
>>>> provedores
>>>>>
>>>>> menores ainda dependem fortemente do cache.
>>>>>
>>>>> Vocês acham que subir um site para organizar toda a informação
>>>
>>> necessária
>>>>>
>>>>> para os provedores que desejem compartilhar seus caches assim como
>>>>
>>>> utilizar
>>>>>
>>>>> o de alguém seria algo válido ? Algum ponto negativo de se formar uma
>>>>> estrutura dessas ?
>>>>>
>>>>> Obrigado a todos.
>>>>> Abraços.
>>>>>
>>>>> Fernando
>>
>>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter