Sistemas entre Pares e Redes Sobrepostas

Transcrição

1 Impacto do tráfego P2P de partilha de cheiros na Internet IST

2 1 2 3 Algoritmo Avaliação 4 Implementação Avaliação 5 Detalhes Soluções já propostas

3 Tipos de tráfego dominantes na Internet 1 1 CacheLogic Research: Peer to Peer in 2005

4 Peso do P2P 2 2 Ipoque: Internet Study 2007

5 Padrão diário de utilização 3 3 Ipoque: Internet Study 2007

6 Adopção do P2P 4 4 Ipoque: Internet Study 2007

7 Aplicações dominantes 5 5 Ipoque: Internet Study 2007

8 Tipos de cheiros transferidos 6 6 Ipoque: Internet Study 2007

9 Análise custo/benefício Custo: Benefício: O esgotar da capacidade pode obrigar o ISP a reforçar a capacidade da rede, aumentando custos Em links cobrados de acordo com o 95 o percentil, pode aumentar substancialmente os custos A congestão criada tem impacto nas outras aplicações, criando insatisfação junto dos clientes Motiva os utilizadores a aderir à banda larga Motiva os utilizadores a fazerem upgrade para velocidades de acesso mais altas sempre que estas cam disponíveis

10 Um problema diferente Tráfego P2P não tem uma origem denida, ao contrário do HTTP onde existem um conjunto de grandes sites bem conhecidos. Diculta a instalação de caches e torna difícil dimensionamento dos links. Tráfego P2P é contínuo no curto prazo, no HTTP utilizador pára para ler uma página antes de fazer o download da próxima. Diculta over-subscription Tráfego P2P é contínuo no longo prazo, não é necessária a presença do utilizador. Impede utilização dos padrões de uso diários para optimizar redes globais

11 Um problema diferente Tráfego P2P é simétrico. No modelo cliente servidor (HTTP, NNTP), cliente é essencialmente um consumidor de informação, não um produtor P2P pode consistir na troca de cheiros protegidos por direito de autor, o que pode ser concorrência desleal a outros serviços do ISP.

12 Questão Como é que os ISPs atacam os problemas anteriores?

13 Resposta dos ISPs Ritmos de upload baixos. Em termos globais baixam os ritmos de download. Os mecanismos de reciprocidade, baixam ainda mais o ritmo do download Imposição de limites de tráfego (total, distinção nacional/internacional). Os potenciais custos de um download desmotivam os utilizadores Instalação de caches especializadas e redirecção dos pedidos P2P para essas caches Bandwidth throttling para limitar peso do tráfego P2P: sempre ou apenas em situações de congestão Bandwidth throttling para limitar tráfego dos heavy hitters: baixar ritmo ao utilizador após exceder determinado valor de tráfego num determinado período de tempo Realizar aumentos de capacidade dos links

14 Limitações das respostas Ritmos de upload baixos: impacto nas outras aplicações, limitando uso de video-conferência, envio de com attachments, upload de fotos,... Imposição de limites de tráfego: impacto nos utilizadores de outras aplicações. Limita a atractividade das ofertas com largura de banda elevada Instalação de caches: potenciais problemas legais, ISPs passam a fazer download e a guardar conteúdos protegidos por direito de autor. Pode ser considerado como uma ajuda/incentivo ao download de conteúdos sujeitos a direito de autor

15 Limitações das respostas Caches e bandwidth throttling: exigem deep packet inspection Caches e bandwidth throttling: violam network neutrality, ao tratar diferentes tipos de tráfego de forma diferente Caches e bandwidth throttling: violam a privacidade do utilizador ao consultar os dados aplicacionais Aumentos de capacidade: protocolos P2P FS desenhados para consumir a largura de banda disponível

16 Possível solução Para funcionarem correctamente, cada utilizador tem de conseguir receber uma cópia completa do cheiro. Não há margem para reduzir este montante (para além de compressão) No entanto, de quanto mais perto vier o tráfego, menos links percorre Se cada pacote percorre menos links, em média deverão haver menos pacotes em cada link Estudo de soluções para minimizar impacto negativo na Internet do tráfego P2P de troca de cheiros tem-se concentrado na localidade das fontes: Ao ir buscar os dados localmente, ao mesmo ISP ou a um ISP com acordos de peering, reduz-se signicativamente os custos para o ISP A redução do número de hops atravessado pelos pacotes diminui congestão

17 Ono Algoritmo Avaliação Ono

18 Algoritmo Avaliação Sistema para privilegiar peers próximos para a troca de cheiros Funciona com o BitTorrent Utiliza Akamai para determinar quais os outros peers que cam próximos Implementado como plugin do Azureus, tendo estado (está?) instalado em centenas de milhares de peers

19 Akamai - Algoritmo Avaliação Akamai é uma rede de distribuição de conteúdos Dispõe de servidores instalados na periferia da Internet, tipicamente nas instalações dos ISPs nais Utiliza encaminhamento na rede overlay (como RON) para evitar congestão e aumentar a disponibilidade e os débitos alcançados Servidores com discos para fornecer cache local Clientes dos ISPs servidos localmente ou dos servidores mais próximos já com o conteúdo Utiliza DNS para dirigir o cliente para o servidor adequado Rede Akamai efectua medições que lhe permitem conhecer estado da Internet

20 Akamai - DNS Algoritmo Avaliação a Drafting Behind Akamai, AoJan Su, David R. Chones, Aleksandar Kuzmanovic e Fabián E. Bustamante a nome do site é CNAME para nome da Akamai Servidor escolhido usando: nome do site (conteúdo) e IP do cliente (ou do seu servidor de DNS) Devolvido servidor próximo, com o conteúdo e com pouca carga

21 Algoritmo Algoritmo Avaliação Considera que dois clientes a quem é atribuído o mesmo servidor Akamai estão próximos Periódicamente é feita a resolução DNS do servidor Akamai Cada nó calcula um ratio map com a frequência com que é direccionado para cada servidor. Para o nó a: Para determinar a proximidade entre dois nós, usa a proximidade coseno: Gera 0 se não houver servidor em comum e 1 se servidores e frequências identicos. Consideram próximos se valor 0.15 Ratio maps trocados pelo plugin Ono ou colocados numa DHT Tenta determinar valor para nós que não usam Ono fazendo as queries DNS por eles

22 Desvantagens Algoritmo Avaliação Peers escolhidos podem não estar no mesmo ISP Dependência da rede Akamai, sem que o serviço seja pago

23 Cenário Algoritmo Avaliação Plugin do Azureus recolhia dados: Débitos (upload e download) a cada 5s RTT para outros peers através de ping Caminhos para outros peers através de traceroute Compara valores para nós escolhidos pelo plugin para outros ao calha (não leva em conta a escolha que o mecanismo de reciprocidade faria)

24 Comprimento dos caminhos Algoritmo Avaliação 7 7 Taming the Torrent, David R. Chones e Fabián E. Bustamante

25 Atraso e perdas Algoritmo Avaliação 8 8 Taming the Torrent, David R. Chones e Fabián E. Bustamante

26 Débitos Algoritmo Avaliação 9 Média do ritmo de download é 31% melhor usando Ono e de upload 42%. 9 Taming the Torrent, David R. Chones e Fabián E. Bustamante

27 Algoritmo Avaliação Impacto do comportamento do ISP 10 O ISP da esquerda privilegia o tráfego local. O da direita trata o tráfego uniformemente, sendo o Ono prejudicado por limitar os peers disponíveis para o mecanismo de reciprocidade escolher. 10 Taming the Torrent, David R. Chones e Fabián E. Bustamante

28 Implementação Avaliação As imagens apresentadas nesta secção foram retiradas de Improving Trac Locality in BitTorrent via, Ruchir Bindal, Pei Cao, William Chan

29 Implementação Avaliação Principal objectivo, limitar tráfego entre ISPs, privilegiando troca de cheiros dentro do mesmo ISP Funciona forçando o cliente BT a comunicar principalmente com peers dentro do mesmo ISP Ao comunicar com o tracker, peer recebe maioritáriamente peers dentro do mesmo ISP Por ser implementado no tracker ou em trac shaper Continua a haver um conjunto de peers externos ao ISP por forma a garantir a terminação do download

30 BitTorrent vs BNS Implementação Avaliação

31 Implementação - Tracker Implementação Avaliação Tracker responde por forma a que dos 35 peers devolvidos, 35 K estejam no mesmo ISP Quando tracker não conhece um número suciente de peers do mesmo ISP, solicita ao peer que o contacte brevemente São sugeridos 3 métodos para o tracker identicar peers do mesmo ISP: Uso de mapas de topologia ou mapeamento em Autonomous System (AS) Colaboração por parte dos ISPs que envolvesse a publicação das suas gamas de IPs Indicação, pelo cliente, no cabeçalho do pedido HTTP ao tracker, de um identicador que fosse comum a cada ISP. Provávelmente fornecido pelo utilizador Desvantagem: requer modicação dos trackers e até dos clientes

32 Implementação - Trac shaper Implementação Avaliação Implementado em trac shapers (TS) junto dos edge routers do ISP TS observa comunicação com trackers, cando a conhecer peers interiores ao ISP que pertencem ao swarm de cada cheiro Manipulam respostas HTTP dos trackers, trocando peers externos por peers internos Quando surgem novos peers internos, podem fazer reset das ligações em curso para peers exteriores, para forçar peers antigos a realizar nova interrogação ao tracker Vantagens: Não requer alterações ao software cliente ou dos trackers Pode ser posto em prática por um ISP sem requerer a colaboração dos clientes

33 Desvantagens Implementação Avaliação Apenas funciona quando há um número suciente de peers dentro do ISP a trocar o mesmo cheiro: Oferece poucos resultados a ISPs pequenos Apenas funciona para os cheiros mais populares Usando os trac shaper, para ISPs grandes exige muita cooperação entre os trac shapers uma vez que não existirá um único

34 Cenário Implementação Avaliação Avaliação utilizando um simulador próprio com abstração de muito alto nível da rede 14 ISPs, cada um com 50 clientes Clientes com 100Kb/s de upload e 1Mb/s de download ISP todos ligados entre si ISPs não tinham limites de débito entre si Cada ISP tinha um limite global de débito para/de todos os outros. Pretendia simular uso de trac shaper Introduziram nós de elevada largura de banda, simétrica, directamente ligados a todos os ISPs. Pretendiam simular peers em universidades e empresas Estudo centrado em ash crowds Critérios de avaliação: tempo de download, redundância - número de cópias que entra em cada ISP (entre 1 a 50)

35 BNS vs trac shaping Implementação Avaliação No primeiro caso 1.0 são 5 312s Usada seed com 400Kb/s upload Redundância prevista N (1 N/G) = 50 (1 50/700) = 46.4 com N - número de peers dentro do ISP, G - total de peers Bottleneck faz com que tit-for-tat privilegie peers internos

36 Implementação Avaliação CDF tempo download para trac shaping

37 CDF tempo download para BNS Implementação Avaliação

38 Conclusões Implementação Avaliação BNS fornece melhores resultados para os ISP com menores custos para os utilizadores BNS pode ser combinado com trac shaping. Neste caso as vantagens são maiores, pois BNS permite utilizar peers locais para contornar bottleneck

39 Detalhes Soluções já propostas Application Layer Trac Optimization Imagens retiradas de Trac Localization for P2P-Applications: The Approach por Jan Seedorf, Sebastian Kiesel e Martin Stiemerling

40 História Detalhes Soluções já propostas Os trabalhos publicados sobre localização de tráfego P2P levaram o IETF a reconhecer a importância da cooperação entre camadas no contexto das comunicações P2P Em Maio de 2008 foi realizada uma workshop sobre infraestruturas P2P, onde foram identicadas 3 áreas de trabalho complementares: Aprovisionamento de QoS - não seguida Novas abordagens à congestão - criado o workgrup Low Extra Delay Background Transport Localidade de tráfego - criado workgroup Application Layer Trac Optimization ()

41 Objectivos Detalhes Soluções já propostas Objectivo principal: desenhar um protocolo pergunta-resposta para um serviço, que as aplicações P2P possam utilizar para obter informação que lhes permita seleccionar peers melhores que os obtidos por um processo aleatório Cenário win-win para clientes e ISPs: clientes deverão obter melhor desempenho, ISPs deverão conseguir baixar custos (ex: tráfego inter-isp)

42 Estado actual Detalhes Soluções já propostas Workgroup ainda no estágio de denição do problema Existem já algumas propostas individuais de solução

43 Cenário de uso Detalhes Soluções já propostas

44 Âmbito Detalhes Soluções já propostas Não dene como o servidor recebe a informação Não dene os protocolos das aplicações que o usam Apenas dene protocolo de comunicação entre servidor e cliente Inclui aspectos como segurança, privacidade e descoberta do serviço

45 Utilização directa por cliente Detalhes Soluções já propostas Cliente contacta serviço do seu ISP Perspectiva da rede partilhada por ambos Servidor poderá ser anunciado através de opção do DHCP ou PPP

46 Utilização por intermediário Detalhes Soluções já propostas Exemplo: tracker BitTorrent Servidor e cliente podem ter perspectivas diferentes da rede Cliente pode recorrer a vários servidores Servidor poderá ser descoberto através de DNS

47 Detalhes Soluções já propostas Para os ISPs: Maior controlo sobre o tráfego que percorre a sua rede Redução de custos Redução da congestão Para os utilizadores Maior velocidade de download Menores custos devido à selecção de peers em caminhos mais baratos (ex: custo diferente para tráfego nacional e internacional) Essencial garantir a adessão dos utilizadores para que o possa ter algum sucesso

48 Obstáculos Detalhes Soluções já propostas Privacidade: ISP pode ter relutância em divulgar informação que possibilite determinar a estrutura da sua rede ou os seus acordos Utilizador pode não querer revelar quais os seus parceiros de crime ou simplesmente considerar esses dados particulares Conança: Capacidade do ISP manipular o cliente, forcando-o a efectuar o download de peers que entregam conteúdo adulterado Embora os ISPs possam ter interesse ou sejam pressionados a manipular clientes, os utilizadores abandonarão o serviço caso achem que esta é uma prática que os afecte O esforço envolvido no processamento de cada pedido pode fazer com que os servidores sejam alvos fáceis de ataques Denial-of-Service

49 Passos comuns a todas as soluções Detalhes Soluções já propostas A aplicação, através dos seus protocolos, determina um conjunto de peers que lhe podem prestar o serviço A aplicação contacta o cliente (pode ser a própria aplicação), fornecendo-lhe a lista de peers. O cliente e o servidor, em conjunto, determinam os melhores candidatos O cliente devolve a lista de peers à aplicação, juntamente com aconselhamento. O aconselhamento pode ser expresso através da ordenação ou pontuação dos peers A aplicação combina os conselhos do com as suas preferências locais e contacta os peers. A qualquer momento, caso não esteja satisfeita com as escolhas, pode voltar a contactar o ou ignorar as suas recomendações

50 Propostas Detalhes Soluções já propostas Proxidor Modelo oráculo. Aplicação fornece lista de IPs. Servidor devolve-a ordenada por preferência. P4P Cliente pode fazer o download de mapas de rede (conjuntos de regiões da rede e respectivos parâmetros), cabendo-lhe a ele tomar as suas decisões em privado

51 Propostas Detalhes Soluções já propostas H12 Tenta balancear os dois modelos anteriores em termos de privacidade e quantidade de dados transferida. Cliente pode fornecer conjunto de regiões (em vez de IPs). O servidor pode responder com maior ou menor detalhe às interrogações, de acordo com a sua política de divulgação de informação.

52 Fim Detalhes Soluções já propostas Dúvidas?