[GTER] Cache de BitTorrent

[Provedor Bogus]

Por problemas no meu MUA, a mensagem abaixo não foi encaminhada à lista.

Estou reenviando.


---------- Mensagem encaminhada ----------
From: Provedor Bogus <provedorbogus at gmail.com>
To: Grupo de Trabalho de Engenharia e Operacao de Redes <
gter at eng.registro.br>
Date: Wed, 01 Jul 2009 14:54:28 -0300
Subject: Re: [GTER] Cache de BitTorrent

2009/6/27 Fabrício Cabral <fabriciofx at gmail.com> <fabriciofx at gmail.com>

> 2009/6/26 Provedor Bogus <provedorbogus at gmail.com>:
>
> > O tráfego é reconhecido através de análise de payload, mas, desenvolvemos
> um
> > algoritmo que otimiza bem
> > essa tarefa porque fica em kernel-mode.
>
>  Como você resolveu o problema de detectar tráfego bittorrent
> criptografado?


Pelo que verificamos, o tráfego criptografado é pequeno e ainda não vale a
pena investir em descriptografá-lo,
mas, há um hardware de custo mediano (US$ 560) que pode ajudar com essa
operação se no futuro isso valer a pena.
Por enquanto, o investimento ainda não compensaria.

Aliás, nenhum cache comercial (Oversi e PeerApp) lida com tráfego
criptografado.


> > A máquina supra-citada consegue
> > processar 400 mbps com 30% de carga.
> > Não fizemos muitos testes de estresse porque consideramos essa
> performance
> > muito razoável.
> > Nosso plano não é ter somente uma máquina para toda a rede e sim dividir
> a
> > carga entre duas ou três máquinas.
>
>  400 Mbps? De quanto é seu link internet? ;)


Esse throughput foi alcançado baixando algo do próprio cache e não da
Internet.



> > O cache de P2P difere em muito de um cache de Youtube, por exemplo.
> > No Youtube, muitas pessoas acessam vídeos de, em média, 8 mega. Um
> arquivo
> > pequeno.
> > No P2P, poucas pessoas baixam arquivos grandes, na nossa média, 1,5 giga.
> > Assim, o tempo para que o cache seja populado com apenas 3 arquivos é
> muito
> > maior.
> >
> > 1 arquivo de 1,5 giga dá pra guardar ~ 183 arquivos do Youtube.
> >
> > Qual das duas situações tem mais chance de ter um hit ? :-)
>
>  Depende. Você está esperando receber o arquivo *todo* do bittorrent pra só
> então poder servi-lo através do seu cache? Dado que você já tem um segmento
> (pedaço) do arquivo em seu cache e este segmento é solicitado, você já
> poderia
> servi-lo. Isto com certeza aumentaria o seu hit rate.


O cache todo funciona por partes, assim, ele estando de posse de uma
determinada parte, esta já
pode ser enviada para outras requisições.


 > A diversidade de conteúdo também é um problema, pois, dependem de buscas
> > individuais
> > dos clientes, diferente do Youtube em que vídeos são acessados por sites
> de
> > blogs conhecidos
> > (como o Kibeloco e o Buteco da Net) ou mesmo enviados como referência em
> > e-mails.
> > Eu nunca recebi um .torrent de alguém sugerindo que eu baixasse para dar
> uma
> > olhada. :-)
>
>  Não entendi este ponto. Na minha opinião, *todo* o conteúdo da sua rede
> depende
> dos seus usuários. Eles que é que vão determinar o seu tráfego. Você pode
> ter
> um tráfego pequeno de P2P em uma empresa por exemplo, mas grande de e-mail.
> No entando, o contrário seria o mais provável em usuários domésticos.
>

Exatamente. O que eu quis dizer é que sites de blogs conhecidos são muito
acessados
pelos usuários e consequentemente incrementam o hit ratio. O que não
acontece com P2P.



> > Temos cerca de 300 mbps só de tráfego Torrent e isso é insuficiente para
> > gerar um bom hit ratio.
>
>  Ainda acho que a questão do hit rate é de acordo com o conteúdo a ser
> baixado.
> Baixo hit rate, só se seus usuários estão baixando conteúdo muito diferente
> um
> dos outros, o que é meio improvável. O hit rate do tráfego web gira em
> torno de
> 30% e só não é maior (acredito eu), porque as páginas mais visitadas (como
> as
> de notícias) tem um keep-alive baixo e portanto, são descartadas logo do
> cache.


A diversidade de conteúdo do P2P é muito grande e popular o cache leva muito
tempo.
Diferente de uma página Web.
O usuário faz uma busca num indexador de Torrent e pode escolher qual das
várias opções
ele decidirá baixar.
Não achamos como comparar o "cacheability" destes dois tipos de tráfego.



> > Estamos com 5 TB ocupados e ainda estudando a política de replacement,
> mas,
> > temos muito
> > tempo para definí-la já que nem tão cedo os 45 TB da máquina serão
> ocupados.
> > :-)
>
>  Espaço não é problema *hoje*, mas um dia ele vai ser. ;) Além do mais, se
> você
> conseguir otimizar isso, o custo do seu equipamento vai cair. Já vi
> papers na Internet
> que demonstraram (pelo menos na época) que o cache P2P tende a se
> estabilizar
> quando chega em 500GB. Assim, um disco de 1TB seria mais que suficiente.


Fizemos alguns "trials" com outros caches e esse número só se estabilizou em
13 TB.
Mas, não consideramos que disco seja um problema. A política de replacement
é mais para
não sobrecarregar o filesystem da máquina com Torrents "velhos".
Espero vê-la funcionando bem pouco. :-)


> > Provavelmente ela será baseada em uma busca do INFOHASH nos sites
> mininova,
> > isohunt e
> > torrentz para definir a popularidade do Torrent e também a quantidade de
> > vezes que ele foi baixado
> > pelos nossos usuários. Através disso geraremos um rank que será usado
> para
> > eliminar
> > os arquivos de menor popularidade.
>
>  Tecnicamente parece ser uma boa idéia, mas eu não a utilizaria. Por
> dois motivos:
>
> 1. Você fica dependente destes sites. Se eles sairem do ar ou mudarem a
> página,
> como você vai pegar estas informações?


Se eles sairem do ar, existirão outros indexadores que poderão ser usados da
mesma forma
e podemos alterar o código rapidamente se mudarem a página. O cache
replacement não é
uma tarefa tão crítica que não possa falhar por cerca de 3 horas.
Além do mais, serão consultados vários indexadores. Se um falhar, ainda
haverá a resposta dos
outros.
Há a opção de mapear os infohash com as requisições de trackers, o que
eliminaria a necessidade
dos indexadores.


> 2. Isto pode implicar em problemas jurídicos, tendo em vista que seu cache
> é
> "espertinho" demais.


Não vejo como uma consulta a sites de indexação de Torrent possa configurar
um problema jurídico. Quem faz essa tarefa é a máquina de conteúdo que nesse
caso se
comportaria como um simples cliente do tracker, apenas para consulta da
popularidade do
arquivo, tal qual fazem as empresas de monitoramento de copyright. Nenhuma
parte do arquivo
será baixada.


> Veja que a linha que separa o que é legal do que é ilegal é muito tênue.
> Você
> não pode nem fazer prefetching do conteúdo, pois isto implicaria em
> "facilitar"
> para o usuário. Cache P2P só é pra repassar um conteúdo (leia-se bytes
> mesmo)
> que já foram encontrados e solicitados pelo usuário.


Essa é a idéia e por isso descartamos o uso do modelo da Oversi, por
exemplo.

Recebi alguns e-mails de pessoas que "duvidam" que tal solução tenha sido
desenvolvido
por uma empresa tupiniquim (fato que nos orgulhamos) então, em duas ou três
semanas vou
tentar disponibilizar uma máquina com VNC para demonstrações.

Um abraço !