Sistemas entre Pares e Redes Sobrepostas

Sistemas entre Pares e Redes Sobrepostas

Obstáculos às redes P2P e Coral CDN

Ricardo Lopes Pereira [email protected]

IST

1 Obstáculos às rede P2P

Overview NAT

Contornar NAT

Impacto de NAT no BitTorrent

2 Coral CDN Overview Funcionamento DSHT DNS Proxy HTTP

Obstáculos P2P

Obstáculos

As aplicações P2P representam um novo paradigma de utilização da Internet

Redes dos ISPs foram desenhadas para lidar com tipo de tráfego diferentes

Os obstáculos às aplicações P2P incluem:

Ligações assimétricas, onde a capacidade de upload é muito menor que a da download. Impede os peers de contribuírem tanto quanto recebem

Firewalls e Network Address Translation. Impedem peers de receber ligações de outros peers

NAT

Técnica que se popularizou devido à escassez de endereços IPv4

Consiste na utilização de um único endereço IP público para fornecer acesso à Internet a vários aparelhos

Muito frequente devido à utilização dos routers wireless nos acesso à Internet de banda larga

Router mapeia ligações originadas no endereços IP privados no interior da rede em portos no seu endereço IP público

Obstáculos P2P

É, na maior parte dos casos, transparente para o cliente, mas cria problema quando as aplicações usam várias ligações (ex: FTP)

Impede a recepção de novas ligações por nós atrás de NAT, uma vez que o mapeamento ainda não existe no router. Este não sabe para quem se destina a nova ligação

Quando apenas um dos peers está atrás de NAT, pode ser esse a estabelecer a ligação. Quando ambos estão atrás de NAT, tal não é possível

Alternativas

Há estimativas que indicam que 70% dos nós da Internet estão atrás de NAT1

Chegada (para quando?) do IPv6 deverá acabar com problema uma vez que deixa de haver escassez de endereços IP. Depois a única motivação será segurança e o anonimato fornecido por NAT

NAT pode ser contornado:

Congurando manualmente mapeamentos de determinados portos para determinados IPs: não escalável

Possibilitando que as aplicações denam automáticamente os mapeamentos: levanta problemas de segurança. Viável no ambiente doméstico, onde UPnP é hoje suportado pela maioria dos routers à venda

Utilizando serviços especícos

Comunicação através de servidores intermédios

Peers atrás de NAT comunicam ambos com o servidor Servidor procede, a nível aplicacional, à troca de mensagens entre os peers

Solução não escalável uma vez que servidor tem de processar todo o tráfego entre os peers, eliminando as vantagens do modelo P2P

NAT hole punching

Técnica para abrir buracos num router NAT Funciona apenas para UDP

Peers que cam atrás de NAT enviam pacote UDP para servidor com endereço público

Servidor passa a conhecer endereços publicos e portos em ambos os NAT

Envia a cada peer o endereço do NAT do outro

Peers passam a enviar pacotes UDP directamente entre eles Não funciona com todos os tipos de NAT

NAT hole punching por tentativas

Quando hole punching iniciado com um terceiro não funciona (caso de NAT simétrico onde origem dos pacotes de resposta tem de ser igual ao destino dos pacotes originais)

É necessário ter uma ideia de qual o porto que o router NAT irá escolher (possível se forem sequenciais)

Cada um dos nós começa a enviar pacotes para o outro, usando o porto previsto

Primeiro pacote não entrará até que o peer também envie um pacote para abrir a rewall

Pode requerer várias tentativas

Interactive Connectivity Establishment - ICE

Assume que: nós não têm conhecimento de como estão ligados à Internet; existe um canal de comunicação entre os nós Nós comunicam com servidor ICE para determinar o seu estado e ter um canal de comunicação

Numa primeira fase, os nós comunicam com o servidor ICE para determinar o seu estado: com IP público, atrás de NAT (qual o endereço do router)

De seguida várias possibilidades de ligação são determinadas e comunicadas aos peers

Um dos peers, o controlador, escolhe a prioridade dos métodos de ligação e estes são tentados até se conseguir uma ligação: ligação directa (caso pelo menos um dos nós tenha IP público), NAT hole punching ou através de um servidor

Desenho de aplicações P2P considerando NAT

Peers podem ser divididos em peers completos (ou super-peers) que fazem parte do overlay

Os peers que não conseguem receber ligações funcionam apenas como clientes dos peers completos, não fazendo verdadeiramente parte da rede P2P

Esta abordagem exige que alguns dos peers (os completos) estejam dispostos a suportar os clientes, que não contribuem para o sucesso da aplicação

Skype utiliza uma abordagem semelhante, onde alguns dos peers encaminham tráfego para os que estão atrás de NAT

NAT em BT

Impacto de NAT no desempenho do BitTorrent

2_{Grácos retirados de The Impact of NAT on BitTorrent-like P2P Systems}

Impacto de NAT no BT

Peers atrás de NAT não conseguem receber ligações:

Visão do swarm é reduzida pois apenas podem ligar-se a peers com IP público

O seu upload apenas é dado aos peers com IP público Upload dos peers com IP público partilhado por todos, com e sem NAT

Não devido ao NAT mas por causa do cenários onde se usa NAT, tipicamente em cenários domésticos, peers com NAT tendem a ter uploads mais baixos

Peers com IP público vão preferir outros peers com elevada capacidade de upload, reduzindo mais a capacidade dos peers com NAT de realizar download

Cenário de simulação

1 seeder com 1 Mbps de upload partilha cheiro de 100MB 500 leechers entram em 5s

Leechers tem probabilidade α de estarem atrás de NAT (incontornável)

Ficheiro dividido em partes de 64KB

Leechers entram com 5% do cheiro e saem após terminar download

Peers têm 5 slots de upload e tracker fornece 50 peers

Download de 3Mbps e upload 384Kbps (no caso heterogéneo, peers com IP público tem 1Mbps de upload)

Para além da simulação foi também denido um modelo analítico

Tempo de download com upload homogéneo

Aumento de peers com NAT diminui desempenho global. Peers sem NAT beneciam do aumento de peers NAT (só os servem a eles)

Tempo de download com peers NAT com baixo upload

Desempenho deteriora mais rapidamente com introdução de peers com NAT.

Privilegiar peer com NAT no optimistic unchoking

Objectivo: modicar BitTorrent de modo a limitar discrepância de desempenho entre peers com IP público e peers atrás de NAT

Tit-for-tat considerado determinante para conseguir justiça e manter o desempenho global do sistema, pelo que não deveria ser alterado

Solução: Alterar a estratégia de selecção de peers para optimistic unchoking, fazendo com que os peers com IPs públicos favoreçam os peers atrás de NAT

Desempenho de peers atrás de NAT sobe signicativamente, sem que o desempenho dos peers com IP público seja muito afectado

Tempo de download, upload homogéneo, 20% NAT, biased

optimistic peer unchoking para NAT

Tempo de download, upload homogéneo, 40% NAT, biased

optimistic peer unchoking para NAT

Proxy HTTP

Coral CDN

Rede de distribuição de conteúdos

Coral CDN

3

3_{Imagens retiradas de Democratizing content publication with Coral por}

Proxy HTTP

O que é

Coral CDN é uma rede de distribuição de conteúdos para HTTP

Funciona com um proxy distribuído para sites HTTP,

permitindo a editores com poucos recursos publicar conteúdos muito populares

Sistema de DNS direcciona clientes para servidor Coral próximo do cliente

Proxies HTTP guardam conteúdo. Para servir cliente conteúdo é puxado de outro proxies, apenas sendo consultado o servidor original caso o conteúdo não esteja disponível

Custo de publicação de conteúdos pode ser obstáculo para editores com menos recursos. É frequente sites carem o-line ao serem slashdoted

Proxy HTTP

Quem corre servidores

Existem uma instância a correr no planet lab Servidores corridos por entidades voluntárias:

com o objectivo de diminuir o tráfego para as suas redes e melhorar o desempenho dos seus utilizadores (tal como ISPs alojam Akamai e mirrors de conteúdos populares). Nestes casos podem não enviar tráfego para fora da sua rede por bons samaritanos (universidades, etc...)

Proxy HTTP

Como usar (planet lab)

Basta suxar o endereço do site de .nyud.net para que conteúdo seja servidor por Coral

Os conteúdos são replicados em função da sua popularidade Quem usa:

Editores: podem alterar o URL de partes (ou todo) o seu site, passando assim a responsabilidade para o Coral. Ex:

coralizar as imagens de um site

Terceiros: ao divulgar um site, é possível fornecer o URL do Coral caso seja esperado um uxo de visitantes maior que o site pode processar

Clientes: podem utilizar URL Coral para aumentar o desempenho no acesso a sites lentos (mas populares para já estarem no Coral)

Proxy HTTP

Arquitectura

O Coral é constituído por 3 partes:

DSHT que fornece os serviços de indexação e clustering (proximidade)

Aplicação sobre DSHT: servidor DNS Aplicação sobre DSHT: proxy HTTP

Baseado no conceito de DSHT (Distributed Sloppy Hash Table) onde chave é não é guardada num local exacto mas em vários sítios

Desenho evita pontos quentes (muita carga) dentro da infraestrutura

Proxy HTTP

Funcionamento

1. Cliente resolve

www.x.com.nyud.net através do seu servidor DNS (resolver) 2. Servidor DNS contacta servidor DNS Coral

3. DNS Coral mede RTT e últimos hops para resolver 4. Servidor DNS procura

servidores DNS e proxy próximos do resolver

5. Servidor DNS retorna servidores próximos ou (se não existirem) aleatórios

Proxy HTTP

Funcionamento

6. Resolver retorna endereço de proxy coral

7. Browser envia pedido aos proxy. Se este tiver conteúdo retorna

8. Proxy procura conteúdo na DSHT Coral

9. Proxy puxa conteúdo de outro proxy ou do site original 10. Proxy guarda conteúdo e entrega-o ao browser

11. Proxy guarda na DSHT uma referência ao conteúdo em si

Proxy HTTP

Coral DSHT

Baseada no Kademlia

3 níveis de DSHT onde o nó está presente nos 3 níveis, em DSHT diferentes que formam clusters de nós próximos:

Nível 0 contém todos os nós

Nível 1 contém nós a 60ms de distância Nível 2 contém nós a 20ms de distância

ID dos nós é hash do IP

DSHT guarda soft-state (expira se não renovado):

URL - lista de nós que contém objecto

Proxy HTTP

Inserções na DSHT

A cada hop a busca aproxima-se do ID mais próximo da chave Procura termina ao chegar ao nó mais próximo ou a um nó com determinado número de entradas (para a chave) frescas e que tenha visto determinado ritmo de queries

Cada um dos hops atravessados é colocado numa pilha e inserção é tentada do topo para a base

Proxy HTTP

Procura na DSHT

A cada passo aproxima-se do nó mais próximo do valor

Se encontrar resultado pelo caminho termina busca Se não encontrar no primeiro nível (2) vai descendo

Proxy HTTP

DNS

nyud.net mapeado em http.L2.L1.L0.nyucd.net Todos os servidores são autoritários

Em cada resolução DNS segue a resposta (proxy) e um conjunto de servidores DNS

Servidores pertencem ao cluster do nível mais alto encontrado perto do resolver do cliente

TTL é de uma hora

Níveis permitem, que ao ser encontrado um cluster de nível superior, sejam alterados os servidores DNS pois suxo é mais longo

Proxy HTTP

Proxy HTTP

Respostas DNS de proxies com TTL baixo para contornar falhas

Proxy procura conteúdo na DSHT e apenas vai buscar ao servidor original caso não encontre

Ao começar download (seja de onde for), insere conteúdo na DSHT com TTL de 20s (renovado até terminar download), para defender de ash crowds

Ao terminar download insere TTL de uma hora

Cache local gerida de modo a evitar apagar objecto ainda referênciados no DSHT

Proxy HTTP

Fim