Sistemas entre Pares e Redes Sobrepostas

(1)

Motivação Perspectiva dos ISPs À boleia da Akamai Biased Neighbor Selection ALTO

Sistemas entre Pares e Redes Sobrepostas

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

Ricardo Lopes Pereira ricardo.pereira@inesc-id.pt

IST

(2)

Motivação Perspectiva dos ISPs À boleia da Akamai Biased Neighbor Selection ALTO

1 Motivação

2 Perspectiva dos ISPs 3 À boleia da Akamai

Overview Algoritmo Avaliação

4 Biased Neighbor Selection

Overview Implementação Avaliação 5 ALTO Overview Detalhes Soluções já propostas

(3)

Motivação

Perspectiva dos ISPs À boleia da Akamai Biased Neighbor Selection ALTO

Tipos de tráfego dominantes na Internet

1

(4)

Motivação

Peso do P2P

2

(5)

Motivação

Padrão diário de utilização

3

(6)

Motivação

Adopção do P2P

4

(7)

Motivação

Aplicações dominantes

5

(8)

Motivação

Tipos de cheiros transferidos

6

(9)

Motivação

Perspectiva dos ISPs

À boleia da Akamai Biased Neighbor Selection ALTO

Análise custo/benefício

Custo:

O esgotar da capacidade pode obrigar o ISP a reforçar a capacidade da rede, aumentando custos

Em links cobrados de acordo com o 95o _{percentil, pode}

aumentar substancialmente os custos

A congestão criada tem impacto nas outras aplicações, criando insatisfação junto dos clientes

Benefício:

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)

Motivação

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)

Motivação

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)

Motivação

Questão

(13)

Motivação

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

(14)

Motivação

Limitações das respostas

Ritmos de upload baixos: impacto nas outras aplicações, limitando uso de video-conferência, envio de email 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)

Motivação

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)

Motivação

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)

Motivação Perspectiva dos ISPs

À boleia da Akamai

Biased Neighbor Selection ALTO Overview Algoritmo Avaliação

Ono

(18)

À boleia da Akamai

Biased Neighbor Selection ALTO

Overview

Algoritmo Avaliação

Overview

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)

À boleia da Akamai

Overview

Algoritmo Avaliação

Akamai - Overview

Akamai é uma rede de distribuição de conteúdos

Dispõe de 25.000 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)

À boleia da Akamai

Akamai - DNS

a

a_{Drafting Behind Akamai, AoJan Su,}

David R. Chones, Aleksandar Kuzmanovic e Fabián E. Bustamante

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)

À boleia da Akamai

Overview

Algoritmo

Avaliação

Algoritmo

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)

À boleia da Akamai

Overview

Algoritmo

Avaliação

Desvantagens

Peers escolhidos podem não estar no mesmo ISP

(23)

À boleia da Akamai

Overview Algoritmo

Avaliação

Cenário

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)

À boleia da Akamai

Overview Algoritmo

Avaliação

Comprimento dos caminhos

7

(25)

À boleia da Akamai

Atraso e perdas

8

(26)

À boleia da Akamai

Overview Algoritmo

Avaliação

Débitos

9 _{Média do ritmo de download é 31% melhor usando Ono e de upload}

42%.

(27)

À boleia da Akamai

Overview 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.

(28)

Motivação Perspectiva dos ISPs À boleia da Akamai

Biased Neighbor Selection

ALTO

Overview Implementação Avaliação

Biased Neighbor Selection

11

11_{As imagens apresentadas nesta secção foram retiradas de Improving}

Trac Locality in BitTorrent via Biased Neighbor Selection, Ruchir Bindal, Pei Cao, William Chan

(29)

ALTO

Overview

Implementação Avaliação

Overview

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)

ALTO

Overview

Implementação Avaliação

BitTorrent vs BNS

(31)

ALTO

Overview

Implementação

Avaliação

Implementação - Tracker

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)

ALTO

Overview

Implementação

Avaliação

Implementação - Trac shaper

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)

ALTO

Overview

Implementação

Avaliação

Desvantagens

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)

ALTO

Overview Implementação

Avaliação

Cenário

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)

ALTO

Avaliação

BNS vs trac shaping

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)

ALTO

Avaliação

(37)

ALTO

Avaliação

(38)

ALTO

Avaliação

Conclusões

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)

Motivação Perspectiva dos ISPs À boleia da Akamai Biased Neighbor Selection

ALTO

Overview Detalhes

Soluções já propostas

ALTO

Application Layer Trac Optimization

12

12_{Imagens retiradas de Trac Localization for P2P-Applications: The ALTO}

(40)

ALTO

Overview

Detalhes

História

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 (ALTO)

(41)

ALTO

Overview

Detalhes

Objectivos

Objectivo principal: desenhar um protocolo pergunta-resposta para um serviço ALTO, 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)

ALTO

Overview

Detalhes

Estado actual

Workgroup ainda no estágio de denição do problema Existem já algumas propostas individuais de solução

(43)

ALTO

Overview

Detalhes

Cenário de uso

(44)

ALTO

Overview

Detalhes

Âmbito

Não dene como o servidor ALTO recebe a informação Não dene os protocolos das aplicações que o usam

Apenas dene protocolo de comunicação entre servidor ALTO e cliente ALTO

Inclui aspectos como segurança, privacidade e descoberta do serviço

(45)

ALTO

Overview

Detalhes

Utilização directa por cliente

Cliente contacta serviço ALTO do seu ISP

Perspectiva da rede partilhada por ambos

Servidor poderá ser anunciado através de opção do DHCP ou PPP

(46)

ALTO

Overview

Detalhes

Utilização por intermediário

Exemplo: tracker BitTorrent Servidor ALTO e cliente ALTO podem ter perspectivas

diferentes da rede

Cliente pode recorrer a vários servidores ALTO

Servidor poderá ser descoberto através de DNS

(47)

ALTO Overview Detalhes Soluções já propostas

Motivação

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 ALTO possa ter algum sucesso

(48)

Obstáculos

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)

ALTO

Overview Detalhes

Passos comuns a todas as soluções

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 ALTO (pode ser a própria aplicação), fornecendo-lhe a lista de peers. O cliente e o servidor ALTO, em conjunto, determinam os melhores candidatos

O cliente ALTO 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 ALTO 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 ALTO ou ignorar as suas recomendações

(50)

Propostas

Proxidor

Modelo oráculo. Aplicação fornece lista de IPs. Servidor ALTO devolve-a ordenada por preferência.

P4P

Cliente ALTO 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

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)

Sistemas entre Pares e Redes Sobrepostas