VII Workshop de Redes Dinâmicas e Sistemas - SBRC 2011

Transcription

ANAIS
XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas
Distribuídos
30 de maio a 3 de junho de 2011
Campo Grande, MS
VII Workshop de Redes Dinâmicas
e Sistemas Peer-to-Peer (WP2P)
Editora
Sociedade Brasileira de Computação (SBC)
Organizadores
Nazareno Andrade (UFCG)
Fábio Moreira Costa (UFG)
Ronaldo Alves Ferreira (UFMS)
Realização
Faculdade de Computação
Universidade Federal de Mato Grosso do Sul (UFMS)
Promoção
Laboratório Nacional de Redes de Computadores (LARC)
ii
Anais
Copyright © 2011 da Sociedade Brasileira de Computação
Todos os direitos reservados
Capa: Venise Melo
Produção Editorial: Lucilene Vilela Gonçalves, Ronaldo Alves Ferreira
Cópias Adicionais:
Av. Bento Gonçalves, 9500 – Setor 4 – Prédio 43.412 – Sala 219
Bairro Agronomia – CEP 91.509-900 – Porto Alegre – RS
Fone: (51) 3308-6835
E-mail: sbc@sbc.org.br
Dados Internacionais de Catalogação na Publicação (CIP)
Workshop de Redes Dinâmicas e Sistemas Peer-to-Peer (7.: 2011 : Campo Grande,
MS).
Anais / VII Workshop de Redes Dinâmicas e Sistemas Peer-to-Peer; organizadores
Nazareno Andrade... et al. – Porto Alegre : SBC, c2011.
175 p.
ISSN 2177-496X
1. Redes de computadores. 2. Sistemas distribuídos. I. Andrade, Nazareno. II. Título.
VII Workshop de Redes Dinâmicas e Sistemas P2P
Promoção
Diretoria
Presidente
José Carlos Maldonado (USP)
Vice-Presidente
Marcelo Walter (UFRGS)
Diretor Administrativo
Luciano Paschoal Gaspary (UFRGS)
Diretor de Finanças
Paulo Cesar Masiero (USP)
Diretor de Eventos e Comissões Especiais
Lisandro Zambenedetti Granville (UFRGS)
Diretora de Educação
Mirella Moura Moro (UFMG)
Diretora de Publicações
Karin Breitman (PUC-Rio)
Diretora de Planejamento e Programas Especiais
Ana Carolina Salgado (UFPE)
Diretora de Secretarias Regionais
Thais Vasconcelos Batista (UFRN)
Diretor de Divulgação e Marketing
Altigran Soares da Silva (UFAM)
Diretor de Regulamentação da Profissão
Ricardo de Oliveira Anido (UNICAMP)
Diretor de Eventos Especiais
Carlos Eduardo Ferreira (USP)
Diretor de Cooperação com Sociedades Científicas
Marcelo Walter (UFRGS)
iii
iv
Anais
Promoção
Conselho
Mandato 2009-2013
Virgílio Almeida (UFMG)
Flávio Rech Wagner (UFRGS)
Silvio Romero de Lemos Meira (UFPE)
Itana Maria de Souza Gimenes (UEM)
Jacques Wainer (UNICAMP)
Mandato 2007-2011
Cláudia Maria Bauzer Medeiros (UNICAMP)
Roberto da Silva Bigonha (UFMG)
Cláudio Leonardo Lucchesi (UFMS)
Daltro José Nunes (UFRGS)
André Ponce de Leon F. de Carvalho (USP)
Suplentes – Mandato 2009-2011
Geraldo B. Xexeo (UFRJ)
Taisy Silva Weber (UFRGS)
Marta Lima de Queiroz Mattoso (UFRJ)
Raul Sidnei Wazlawick (PUCRS)
Renata Vieira (PUCRS)
Laboratório Nacional de Redes de Computadores (LARC)
Diretoria
Diretor do Conselho Técnico-Científico
Artur Ziviani (LNCC)
Diretor Executivo
Célio Vinicius Neves de Albuquerque (UFF)
Vice-Diretora do Conselho Técnico-Científico
Flávia Coimbra Delicato (UFRN)
Vice-Diretor Executivo
Membros Institucionais
CEFET-CE, CEFET-PR, IME, INPE/MCT, LNCC, PUCPR, PUC-RIO, SESU/MEC,
UECEM UERJ, UFAM, UFBA, UFC, UFCG, UFES, UFF, UFMG, UFMS, UFPA,
UFPB, UFPE, UFPR, UFRGS, UFRJ, UFRN, UFSC, UFSCAR, UNICAMP,
UNIFACS, USP
Realização
Comitê de Organização
Coordenação Geral
Ronaldo Alves Ferreira (UFMS)
Coordenação do Comitê de Programa
Artur Ziviani (LNCC)
Bruno Schulze (LNCC)
Coordenação de Palestras e Tutoriais
Nelson Luis Saldanha da Fonseca (UNICAMP)
Coordenação de Painéis e Debates
José Augusto Suruagy Monteiro (UNIFACS)
Coordenação de Minicursos
Fabíola Gonçalves Pereira Greve (UFBA)
Coordenação de Workshops
Fábio Moreira Costa (UFG)
Coordenação do Salão de Ferramentas
Luis Carlos Erpen De Bona (UFPR)
Comitê Consultivo
Antônio Jorge Gomes Abelém (UFPA)
Carlos André Guimarães Ferraz (UFPE)
Francisco Vilar Brasileiro (UFCG)
Luci Pirmez (UFRJ)
Marinho Pilla Barcellos (UFRGS)
Paulo André da Silva Gonçalves (UFPE)
Thais Vasconcelos Batista (UFRN)
v
vi
Anais
Realização
Organização Local
Brivaldo Alves da Silva Jr. (UFMS)
Edson Norberto Cáceres (UFMS)
Eduardo Carlos Souza Martins (UFMS/POP-MS)
Hana Karina Sales Rubinstejn (UFMS)
Irineu Sotoma (UFMS)
Kátia Mara França (UFMS)
Luciano Gonda (UFMS)
Lucilene Vilela Gonçalves (POP-MS)
Márcio Aparecido Inácio da Silva (UFMS)
Marcos Paulo Moro (UFGD)
Massashi Emilson Oshiro (POP-MS)
Nalvo Franco de Almeida Jr. (UFMS)
Péricles Christian Moraes Lopes (UFMS)
Renato Porfírio Ishii (UFMS)
vii
Mensagem do Coordenador Geral
Sejam bem-vindos ao XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas
Distribuídos (SBRC 2011) em Campo Grande, MS. É um prazer e uma distinção
organizar um simpósio de tamanha relevância para a Computação no Brasil, mais ainda
por ser a primeira vez que a Região Centro-Oeste tem o privilégio de sediá-lo. O SBRC
é um evento anual promovido pela Sociedade Brasileira de Computação (SBC) e pelo
Laboratório Nacional de Redes de Computadores (LARC). Ao longo dos seus quase
trinta anos, o S BRC tornou-se o mais importante evento científico nacional em Redes
de Computadores e Sistemas Distribuídos e um dos maiores da área de Informática no
país.
O SBRC 2011 está com uma programação bastante rica, de qualidade diferenciada e que
consiste em: 18 sessões técnicas de artigos completos que abordam o qu e há de mais
novo nas áreas de redes de computadores e sistemas distribuídos; três sessões técnicas
para apresentação de ferramentas selecionadas para o Salão de Ferramentas; cinco
minicursos, com quatro horas de duração, sobre temas atuais; três palestras e três
tutoriais com pesquisadores de alto prestígio internacional; e três painéis sobre assuntos
de interesse da comunidade. Além dessas já tradicionais atividades do simpósio,
ocorrerão em paralelo oito workshops: XVI Workshop de Gerência e Operação de
Redes e Serviços (WGRS), XII Workshop da Rede Nacional de Ensino e Pesquisa
(WRNP), XII Workshop de Testes e Tolerância a Falhas (WTF), IX Workshop em
Clouds, Grids e Aplicações (WCGA), VII Workshop de Redes Dinâmicas e Sistemas
P2P (WP2P), II Workshop de Pesquisa Experimental da Internet do Futuro (WPEIF), I
Workshop on A utonomic Distributed Systems (WoSIDA) e I Workshop de Redes de
Acesso em Banda Larga (WRA).
O desafio de organizar um evento como o SBRC só pode ser cumprido com a ajuda de
um grupo especial. Eu tive a f elicidade de contar com a co laboração de inúmeras
pessoas ao longo desta jornada. Meus sinceros agradecimentos aos membros dos
Comitês de Organização Geral e Local por realizarem um trabalho de excelente
qualidade e com muita eficiência, a qualidade da programação deste simpósio é fruto do
trabalho dedicado dessas pessoas. Sou grato a Faculdade de Computação da UFMS por
ter sido uma facilitadora ao longo de todo o pr ocesso de organização, desde a nossa
proposta inicial até o fechamento da programação. Gostaria de agradecer, também, ao
Comitê Gestor da Internet no Brasil (CGI.br), às agências governamentais de fomento e
aos patrocinadores por reconhecerem a importância do S BRC e investirem recursos
financeiros fundamentais para a realização do evento. Com o apoio financeiro recebido,
foi possível manter os custos de inscrição baixos e oferecer um programa social de alta
qualidade.
Em nome do Comitê Organizador, agradeço a todos os participantes pela presença em
mais esta edição do SBRC e d esejo uma semana produtiva, agradável e com
estabelecimento de novas parcerias e amizades.
Ronaldo Alves Ferreira
Coordenador Geral do SBRC 2011
viii
Anais
Mensagem do Coordenador de Workshops do SBRC 2011
Os workshops são uma parte tradicional do que hoje faz do SBRC o principal evento da
área no país, sendo responsáveis por atrair uma parcela cada vez mais expressiva de
participantes para o S impósio todos os anos. O SBRC 2011 pr ocurou manter essa
tradição, com a r ealização de workshops já considerados parte do circuito nacional de
divulgação científica nas várias subáreas de Redes de Computadores e S istemas
Distribuídos, como o WTF (Workshop de Testes e Tolerância a Falhas), o W CGA
(Workshop em Clouds, Grids e Aplicações), o WGRS (Workshop de Gerência e
Operação de Redes e Serviços) e o WP2P (Workshop de Redes Dinâmicas e Sistemas
P2P). Incluímos também nesta lista de iniciativas bem sucedidas o WRNP (Workshop
da Rede Nacional de Ensino e Pesquisa), que cumpre o importantíssimo papel de fazer a
ponte entre as comunidades técnica e científica da área.
Como novidade em 2011, e reconhecendo o s urgimento e o fortalecimento de novas
linhas de pesquisa de expressiva importância dentro da comunidade brasileira de Redes
e Sistemas Distribuídos, procuramos incentivar a criação de novos workshops dentro do
Simpósio. Foi com esse intuito que introduzimos pela primeira vez no SBRC a chamada
aberta de workshops, por meio da qual, membros da comunidade foram convidados a
submeter propostas de workshops inéditos para realização em conjunto com o S BRC
2011. Em resposta à chamada, recebemos nove propostas de alta qualidade, das quais
oito foram aceitas e seus respectivos proponentes convidados a organizarem os
workshops no SBRC em Campo Grande. Das oito propostas aceitas, cinco tratavam dos
workshops já tradicionais acima mencionados, e uma referia-se à segunda edição de um
workshop mais recentemente criado, mas que teve sua primeira edição realizada de
forma muito bem sucedida no S BRC 2010, o WPEIF (Workshop de Pesquisa
Experimental da Internet do Futuro). As outras duas propostas foram resultado direto da
chamada aberta de workshops e resultaram na adição de dois novos eventos ao leque do
SBRC, o WRA (Workshop de Redes de Acesso em Banda Larga) e o WoSiDA
(Workshop on A utonomic Distributed Systems), ambos com ótima aceitação pela
comunidade, a julgar pelos números de submissões de trabalhos recebidos.
Esperamos que 2011 s eja mais um ano de sucesso para os workshops do S BRC, em
particular para aqueles criados nesta edição do Simpósio, e para que eles continuem
contribuindo como importantes fatores de agregação para os avanços promovidos pela
comunidade científica da área de Redes e Sistemas Distribuídos no Brasil.
Aproveitamos para agradecer o inestimável apoio recebido de diversos membros da
comunidade e, em particular, da Organização Geral do SBRC 2011.
A todos, um excelente SBRC em Campo Grande!
Fábio M. Costa
Coordenador de Workshops do SBRC 2011
ix
Mensagem do Coordenador do WP2P
O Workshop de Redes Dinâmicas e S istemas P2P é u m fórum para a ap resentação de
resultados e t rocas de experiências da comunidade brasileira da área. Em sua sétima
edição neste ano, o workshop tem se consolidado como um importante catalizador dessa
comunidade.
Neste ano, o W P2P contou com 16 s ubmissões. Cada artigo recebeu três revisões de
membros do c omitê de programa ou de revisores tutelados por estes. Ao fim do
processo, com o objetivo de maximizar as oportunidades de discussão e assim fortalecer
a área, 12 artigos foram selecionados para apresentação no w orkshop. A seleção dos
artigos é composta de uma salutar variedade de temas e ab ordagens, e cer tamente
proporcionará à comunidade bastante material para discussões produtivas.
Os méritos do W P2P são resultado dos esforços de três grupos a quem gostaria de
agradecer: os autores de todos os artigos submetidas, os membros do comitê de
programa e os organizadores do S BRC 2011, na pessoa de Ronaldo Ferreira, como
coordenador geral, e Fábio Costa, como coordenador dos workshops. Meu obrigado à
dedicação destes três grupos na feitura de um SBRC e de um WP2P de qualidade.
Um bom workshop a todos.
Nazareno Andrade
Coordenador do WP2P 2011
x
Anais
Comitê de Programa do WP2P
Alexandre Sztajnberg (UERJ)
Carlos Kamienski (UFABC)
Daniel Figueiredo (UFRJ)
Djamel Sadok (UFPE)
Eduardo de Almeida (UFPA)
Elias P. Duarte Jr. (UFPR)
Fabíola Greve (UFBA)
Francisco Brasileiro (UFCG)
Joni da Silva Fraga (UFSC)
Jussara Almeida (UFMG)
Luis Carlos De Bona (UFPR)
Marinho Barcellos (UFRGS)
Paulo Andre da Silva Gonçalves (UFPE)
Ronaldo Ferreira (UFMS)
Rossana Andrade (UFC)
Revisores do WP2P
Alexandre Sztajnberg (UERJ)
Amadeu Barbosa Jr. (PUC-Rio)
Carlos Kamienski (UFABC)
Daniel Figueiredo (UFRJ)
Djamel Sadok (UFPE)
Eduardo de Almeida (UFPA)
Elias P. Duarte Jr. (UFPR)
Erich Dimitry Silvestre (UFPR)
Fabíola Greve (UFBA)
Jéferson Nobre (UFRGS)
Joni da Silva Fraga (UFSC)
Jussara Almeida (UFMG)
Lesandro Ponciano (UFCG)
Luis Carlos De Bona (UFPR)
Marcos Barreto (UFBA)
Marinho Barcellos (UFRGS)
Matheus Gaudencio (UFCG)
Paulo Andre da Silva Gonçalves (UFPE)
Rodrigo Brandão Mansilha (UFRGS)
Rossana Andrade (UFC)
Roverli Ziwich (UFPR)
Thiago Pereira (UFCG)
Vinicius Moll (UFSC)
xi
xii
Anais
xiii
Sumário
Sessão Técnica 1 – Plataformas de Distribuição de Vídeo e Experimentos .............. 1
Análise de Desempenho no Uso de Pré-Busca para Distribuição de Vídeo Sobre
Redes P2P
Renan Manola, Magnos Martinello, Roberta Lima Gomes (UFES) e Cesar
Marcondes (UFSCar) ................................................................................................... 3
Análise de Desempenho de Redes P2P com Protocolo "Push/Pull" para
Distribuição de Vídeo na Presença de Nós Não-Cooperativos
Flávia Marinho de Lima e Alexandre Sztajnberg (UERJ).......................................... 17
PlanetMon: Um Arcabouço para Execução e Monitoração de Experimentos no
Planet-Lab
Vinicius K. Ruoso, Luis C. E. De Bona e Elias P. Duarte Jr. (UFPR)....................... 31
Sessão Técnica 2 - BitTorrent ...................................................................................... 45
Eficiência de Download em Comunidades BitTorrent
Jaindson Santana e Nazareno Andrade (UFCG) ....................................................... 47
BitPS: Um Esquema de Precificação para Sistemas Par-a-Par Baseados em
BitTorrent
Gabriel de Godoy Correa e Castro e Humberto T. Marques-Neto (PUC-Minas) ..... 57
Um Mecanismo Orientado a ISP para Escolha Tendenciosa de Pares no
BiTorrent
Alejandra Klachquin e Daniel R. Figueiredo (COPPE/UFRJ) .................................. 71
Sessão Técnica 3 – Redes Veiculares e Direções de Pesquisa ................................... 85
Análise Sobre o Impacto da Densidade, da Carga e do Padrão de Mobilidade
Sobre o Desempenho de Protocolos de Roteamento para Redes Veiculares
Bruno G. Mateus (UFC), Carina T. de Oliveira (Université Joseph Fourier) e
Rossana M. C. Andrade (UFC) .................................................................................. 87
Sobre as Deficiências na Sinergia entre BitTorrent e MANETs e Alternativas
Viáveis
Sidney Doria e Marco Aurélio Spohn (UFCG) ........................................................ 101
Redes Centradas na Informação: Uma Comparação de Abordagens
Bruno Magalhães Martins e Antônio Marcos Alberti (Inatel) ................................. 115
Sessão Técnica 4 – Segurança e Desempenho .......................................................... 129
Distribuição de Conteúdo Multimídia em Tempo Real com Transporte de Fluxos
Controlados e Não Confiáveis entre Pares
Leandro M. de Sales (UFAL), Hyggo O. de Almeida, Angelo Perkusich (UFCG) e
Rafael A. Silva (UFAL) ............................................................................................. 131
Aumentando a Segurança de um Protocolo de Distribuição de Conteúdo P2P
para MANETs
Sidney Doria e Marco Aurélio Spohn (UFCG) ........................................................ 147
Agregação de Pacotes em Ambientes com Enlaces de Baixa Capacidade de
Transmissão
P. H. Azevêdo Filho, M. F. Caetano e J. L. Bordim (UnB) ...................................... 161
Índice por Autor ......................................................................................................... 175
VII Workshop de Redes Dinâmicas e
Sistemas P2P
♦
Sessão Técnica 1
Plataformas de Distribuição de
Vídeo e Experimentos
3
Análise de desempenho no uso de pré-busca para distribuição
de vídeo sobre redes P2P
Renan Manola1, Magnos Martinello1 , Roberta Lima gomes1, Cesar Marcondes2
Departamento de Informática – Universidade Federal do Espírito Santo (UFES)
Av. Fernando Ferrari, 514 – 29.075-910 – Vitória – ES – Brasil
1
Departamento de Computação (DC)
Universidade Federal de São Carlos (UFSCar) – São Carlos, SP - Brasil.
2
{rmanola, magnos, rgomes}@inf.ufes.br, marcondes@dc.ufscar.br
Abstract. P2P Streaming systems have consolidated their importance in recent
years, this is mainly due to substantial gains and therefore economic savings
in terms of server`s bandwidth. In this paper, we evaluate how this technology
can boost the bandwidth gains of multimedia content distribution over the
Internet using prefetch policy, as well as the impact of this policy on the video
discontinuity perceived by customers. The main contribution of this paper is to
show, through realistic packet-level Internet-like simulations, that the use of
P2P prefetching can save the server upload from 43% up to 73%.
Resumo. Sistemas P2P VoD consolidaram sua importância nos últimos anos.
Tal consolidação é decorrente dos elevados ganhos que se pode ter em termos
de economia na banda de transmissão dos servidores. Neste artigo, avalia-se
como esta tecnologia pode potencializar os ganhos de distribuição de
conteúdo multimídia na Internet fazendo uso de política de pré-busca
(prefetching), como também, o impacto na descontinuidade dos vídeos
assistidos pelos clientes. A principal contribuição deste artigo consiste em
mostrar, por meio de simulações realísticas da Internet a nível de pacotes,
que o uso da pré-busca pode economizar o upload do servidor de 43% a 73%.
1. Introdução
A Internet está assumindo um papel cada vez maior na distribuição de conteúdo
multimídia. Youtube1 e NetFlix2 são exemplos de serviços que operam sobre a Internet
sendo responsáveis por uma proporção considerável do tráfego nos EUA [Huang, 2007].
Devido à popularidade desses serviços, a exigência de banda requerida para suportá-los,
aliado a uma tendência de crescimento na demanda e aumento na qualidade dos vídeos, a
distribuição baseada no modelo cliente-servidor tornou-se proibitiva para satisfazer tais
exigências de requisitos.
Uma forma alternativa para projetar sistemas de distribuição de vídeo em larga
escala na Internet tem sido baseada em redes P2P, tanto para vídeo ao vivo como vídeo
sob-demanda (Video on-Demand – VoD). Alguns exemplos de aplicações como
1 http://www.youtube.com
2 http://www.netflix.com
4
Anais
PPLive3, TVU4, SOPCast5 ou PPStream6 têm oferecido uma gama de canais usando P2P
para comunidades de milhares de usuários. Particularmente, a distribuição de vídeo sob
demanda auxiliada por P2P (Peer-assisted VoD, ou P2P VoD), tem mostrado ser uma
solução promissora, portanto, sendo alvo de um considerável corpo de pesquisa nos
últimos anos [Huang, 2007] [He, 2009] [Gao, 2010].
Um dos focos de investigação encontrado na literatura é a redução de banda de
transmissão nos servidores de vídeo sob demanda, no qual os pares participantes da rede
P2P auxiliam o servidor na entrega de conteúdo. No sistema P2P VoD, quando os pares
não conseguem redistribuir o vídeo entre si de forma autossuficiente, estes são
diretamente auxiliados pelo servidor. O objetivo é garantir a diferença sem degradação
na qualidade, de modo que cada par receba o vídeo na mesma taxa de codificação.
Quando os pares são capazes de satisfazer tal demanda, não apenas o servidor reduz
drasticamente sua banda de upload, mas principalmente, os pares podem efetuar prébusca (prefetch) com base na banda adicional de outros pares.
É interessante notar que geralmente, nos trabalhos existentes, se abstrai diferentes
variáveis de rede. Por exemplo, não se leva em conta atrasos e congestionamento nos
enlaces, perdas, bandas assimétricas de download/upload, o protocolo da camada de
transporte e a perspectiva do usuário [Bial, 2010] [Huang, 2007]. Neste trabalho, uma
análise baseada em simulação a nível de pacotes é apresentada permitindo compreender
diversos compromissos na distribuição de vídeo baseada em redes P2P, considerando
múltiplas variáveis de rede em uma única abordagem. Para tanto, foi implementado em
simulação um algoritmo de pré-busca abordado em [Huang, 2007], com o objetivo de
estudar o desempenho deste, não só do ponto de vista de economia de banda dos
servidores, como também na percepção da qualidade do vídeo (em termos de
continuidade e tempo de (re)inicio de reprodução) por parte dos clientes. Um dos
diferenciais desta abordagem é a simulação completa da pilha TCP/IP incluindo tráfego
de fundo (geração de congestionamento na rede), permitindo representar um cenário
mais realístico.
O artigo se organiza da seguinte forma: na Seção 2 são descritos alguns trabalhos
relacionados, discutindo-se como tais trabalhos contribuíram para as pesquisas em
distribuição de vídeo P2P. Na Seção 3 é abordado o funcionamento da arquitetura de
distribuição P2P VoD e também a política de pré-busca implementada na simulação. Na
Seção 4 são exibidas as decisões que foram tomadas na concepção do ambiente de
simulação, tal como topologia, quantidade de pares e taxas de transmissão. Em seguida,
na Seção 5, são descritas as simulações que foram realizadas e a análise dos resultados
obtidos. Por fim, conclui-se, na Seção 6, listando os principais resultados e pontos-chave
encontrados neste trabalho.
2. Trabalhos Relacionados
Os sistemas de distribuição de vídeo P2P podem ser categorizados considerando as duas
arquiteturas básicas de distribuição: árvore e malha. A principal diferença encontra-se na
forma como os pares se organizam para transmitir o vídeo [Sentinelli, 2007]. Na
arquitetura em árvore, os pares se organizam em uma ou múltiplas árvores de
distribuição, o servidor localiza-se na raiz e existe uma relação estrita de pai e filho,
3
4
5
6
http://download.pptv.com
http://www.tvunetworks.com
http://www.sopcast.com
http://www.ppstream.com
5
sendo que o par-filho recebe o vídeo apenas do seu respectivo pai. Os principais
exemplos de sistemas nesta arquitetura são: Narada [Chu, 2010], NICE 7 e ZiGZag
[Tran, 2003]. Existem propostas cujas métricas de seleção de pares referem-se ao tempo
de reprodução (playback time) dos participantes [Sharma, 2005]. A ideia básica é que os
filhos estejam em pontos de reprodução anteriores em relação aos pais. No entanto,
dependendo do número e do tipo de interações, a frequência de reconstrução da árvore
pode ser alta, o que gera sobrecarga de controle e gera um impacto na continuidade de
recepção do vídeo [Moraes, 2010].
Tratando-se da arquitetura em malha, os pares se organizam em uma malha de
distribuição e compartilham os “pedaços” (chunks) de um determinado vídeo que estão
espalhados pela rede. Os pares podem tanto receber quanto encaminhar os pedaços de
um vídeo para outros pares uma vez que satisfeitas as condições impostas no algoritmo
P2P sendo usado. Nesta arquitetura, é necessário que os pares conheçam quais pedaços
de vídeo estão localizados em quais outros pares. Alguns exemplos de sistemas são:
PPLive, SopCast, PPStream e TVAnts [Sentinelli, 2007].
Outro critério de classificação comumente utilizado nos sistemas de distribuição
de vídeo P2P refere-se às estratégias de escalonamento dos dados: push-based ou pullbased [Gao et al 2010]. No caso da estratégia push-based, a continuidade de reprodução
(playback) é priorizada, no entanto, pode haver recepção de dados redundantes uma vez
que o par não solicita explicitamente que parte do vídeo irá receber. Essa característica
tende a gerar mais sobrecarga e desperdício de recursos se não for bem tratada pela
aplicação. Sistemas baseados na estratégia pull-based tendem a ser mais robustos ao
problema mencionado anteriormente, uma vez que o par especifica o que deseja receber.
Adicionalmente, os sistemas pull-based são mais resilientes aos pares dinâmicos (peerchurn) pois são capazes de identificá-los mais rapidamente do que na estratégia pushbased. Para conseguir saber qual par possui qual informação, os pares trocam mapas de
buffer entre si, esta troca pode gerar sobrecarga de controle caso os parâmetros
envolvidos não sejam bem configurados.
Há ainda outros trabalhos que abordam a pré-busca como forma de economizar
banda de upload do servidor. No trabalho de [Shen, 2009], optou-se por dividir o vídeo
em vários fluxos de qualidades iguais, com auxilio da codificação de rede, propondo-se
dois algoritmos de pré-busca: off-line e heurístico. O algoritmo offline busca mostrar o
limite teórico para minimizar a distorção entre a recepção de várias sub-streams. O
algoritmo heurístico é a implementação prática do que se objetiva obter no algoritmo
offline, sendo que se sabe menos informações a priori. No trabalho de [Biao, 2010] fezuso de uma nova topologia de distribuição com uma pré-busca contendo um buffer
máximo atribuído para cada par. Assim que o par atinge o nível do buffer, a pré-busca é
enviada para outro.
Duas políticas de pré-busca foram propostas em [Huang, 2007], a política
water-leveling, que consiste em igualar o buffer de vídeo de todos os pares, realizando
uma alusão ao que ocorre quando recipientes de água são ligados entre si pelo fundo e o
nível de todos eles cresce igualmente. A segunda política trata-se da greedy, onde os
pares enviam a pré-busca apenas aos imediatamente posteriores na ordem de chegada no
sistema. A política water-leveling foi a escolhida para ser implementada pelo fato de
considerar uma justiça coletiva ao comparar o buffer de recepção de mais de um par, e
escolher o que possui o menor buffer.
7 http://www.cs.umd.edu/projects/nice
6
Anais
O presente trabalho adota, por simplicidade de implementação, o escalonamento
de dados P2P do tipo push-based em conjunto com a política de pré-busca proposta em
[Huang, 2007]. Este trabalho distingue-se dos anteriores ao avaliar o desempenho da
pré-busca em um simulador de redes sob condições mais realistas, incluindo atrasos,
perdas nos enlaces e tráfego de fundo. Esta abordagem permite compreender
compromissos de projeto num sistema P2P de distribuição de vídeo, considerando as
perspectivas do servidor, da rede e particularmente a continuidade de reprodução de
vídeo percebido pelos usuários.
3. Fundamentação Teórica
A arquitetura P2P VoD utilizada nas simulações é descrita em [Huang, 2007] pelo nome
de no-prefetching. Nesta arquitetura, os pares que ingressam no sistema de distribuição
de vídeo são servidos pelos que ingressaram imediatamente antes deles. Caso não exista
capacidade de upload suficiente no par ingressante imediatamente anterior ao que acaba
de chegar, ou seja, o penúltimo par, o servidor auxilia enviando a diferença de taxa de
transmissão que é necessária para suprir o par que acaba de chegar (último) com uma
taxa de recepção, no mínimo, igual à taxa de codificação do vídeo. Este mecanismo pode
ser melhor compreendido pela Figura 1.
Figura 1. Rede sobreposta construída na arquitetura no-prefetching.
A Figura 1 supõe que a qualidade do vídeo é de 300Kbps e as capacidades de
upload dos pares que vão chegando, de 1 a 7, são respectivamente: 100Kbps, 200Kbps,
400Kbps, 500Kbps, 100Kbps, 400Kbps e 100Kbps. O ganho de escalabilidade no
sistema de distribuição de vídeo que se consegue obter com esta abordagem é grande se
comparada à distribuição no modelo cliente-servidor. Esta afirmação é decorrente do
fato que se fosse usado o modelo cliente-servidor, o servidor acabaria servindo uma taxa
de upload de 2100Kbps na situação final (300Kbps x 7 clientes). Como foi usado um
algoritmo P2P, o servidor gastou uma banda de upload de apenas 800Kbps na situação
final, o que representa uma economia de, aproximadamente, 62%. As setas em verde,
apontando para fora da figura, indicam banda de upload remanescente que os pares
possuem e não estão sendo usadas. Estas capacidades podem ser alocadas para enviar
conteúdo que será tocado pelos clientes no futuro. Por exemplo, os pares 3 e 5 poderiam
usar suas capacidades de upload para enviar conteúdo extra ao par 6. Com isso, o
servidor não precisaria enviar conteúdo ao par 6 quando este possuir um buffer de vídeo
razoável. Estas capacidades remanescentes também poderiam ser utilizadas quando
houvesse algum momento de intenso congestionamento e as taxas não pudessem ser
7
entregues como deveriam.
Tendo uma visão geral sobre o sistema, existem três estados possíveis no que
tange a capacidade agregada do mesmo de se autossustentar. O modo surplus ocorre
quando a somatória de todas as taxas de upload (U) dos pares supera a somatória de
todas as taxas de download (D), ou seja, U/D > 1. Já no modo deficit, o sistema não
possui upload suficiente para seu autossustento, assim U/D < 1. O modo balanceado
indica que tais taxas são iguais.
As simulações realizadas abordaram estes diferentes cenários. Como será melhor
explicado na próxima seção, foram simulados pares com diferentes capacidades de
upload. Adicionalmente, fixou-se uma quantidade de pares total no sistema de
distribuição P2P e variou-se a porcentagem dos que possuem capacidades de upload
maior e menor. O objetivo de tal variação é de simular os três estados possíveis (surplus,
deficit e balanceado) em relação a capacidade agregada do sistema.
4. Ambiente de Simulação
As simulações se deram por meio de um ambiente de simulação de redes bem
conhecido, o Network Simulator 2 [NS2, 2010]. A topologia de rede adotada nas
simulações foi uma variante da topologia parking lot que denominamos com o nome de
double parking lot, tratando-se do parking lot duplicado. A parking lot é uma topologia
que permite experimentar o fenômeno de múltiplos gargalos e inter-relacionamento de
fluxos de uma direção e outra direção. Ela é considerada como sendo mais realista que
topologias como, por exemplo, a topologia dumbbell, conhecida por ter um único ponto
de congestionamento [Wei, 2005].
Figura 2. Topologia double parking lot usada nas simulações.
A topologia double parking lot tem a vantagem de simular um ambiente em que
os pacotes podem ter rotas diferentes apresentando a mesma distância em saltos. A
Figura 2 ilustra um backbone nesta topologia.
Para (i) construção da topologia, (ii) geração automática de atrasos nos links e
(iii) geração de tráfego de fundo sintético, foi usada uma ferramenta criada para este fim,
denominada TCP Suite [Shimonishi, 2007]. Ela consiste em uma série de scripts que
auxiliam, principalmente, em permitir simular diferentes algoritmos TCP em redes com
múltiplos fluxos e comportamento parecido. Os parâmetros usados nas simulações
podem ser descritos de acordo com a tabela a seguir. Vale ressaltar que os valores dos
parâmetros referentes à qualidade do vídeo e às características dos pares foram baseados
no trabalho [Huang, 2007].
Os parâmetros para os atrasos do backbone foram configurados segundo o
padrão TCP Suite, que é um valor extraído de uma distribuição exponencial com média
de 15 msecs. Ou seja, para passar pelo backbone, o atraso seria em média de 30 a 45
msecs (2 ou 3 saltos). As velocidades dos enlaces do backbone estão com 100Mbps.
8
Anais
Além disso, são usados dois tripos de tráfego de fundo, segundo o padrão TCP Suite,
para gerar um congestionamento moderado no backbone. São 120 conexões longas
caracterizadas por transferência de arquivos grandes pela rede (como DVDs), e 200
conexões curtas, caracterizadas por transferência de páginas web. O tamanho dos
arquivos segue uma distribuição de Pareto (seguindo a estatística da Internet) [Crovella,
1997] e os tempos entre chegadas de novas conexões curtas é regulado por uma
distribuição exponencial representando períodos de thinking time, quando os usuários
não estão requisitando novas páginas web.
Tipo de pares 2
Características do par tipo 1
Características do par tipo 2
Upload/Download
256Kbps/756Kbps
Upload/Download
756Kbps/2.268Mbps
Qualidade do Vídeo 512Kbps
Quantidade de pares 60
Tráfego de fundo (conexões longas) 120
Tráfego de fundo (conexões curtas) 200
Enlaces de backbone 100Mbps
Número de nós do backbone 6
Tabela 1: Descrição dos parâmetros usados nas simulações.
A Tabela 1 exibe perfis de par P2P, o de tipo 1, que possui um upload maior e o
de tipo 2 que possui um upload menor. Com relação à infraestrutura P2P colocada sobre
esta topologia e o tráfego descrito anteriormente, temos a seguinte parametrização: (i) o
intervalo entre o tempo de chegada dos pares P2P ao sistema segue uma distribuição
exponencial com λ=0,15; (ii) os pares foram posicionados no backbone de forma
aleatória, ou seja, cada par possui chance igual de ser alocado em qualquer nó de
backbone, desde que seja diferente do nó alocado para o servidor de conteúdo.
Os experimentos foram realizados com objetivo de analisar:
1. Os ganhos obtidos quando o sistema encontra-se em um estado ideal (sem
tráfego de fundo) e quando o tráfego de fundo está presente;
2. O impacto da ordem em que os pares chegam ao sistema, podendo esta ser de 4
tipos: melhor ordem, ordem média, pior ordem e ordem aleatória;
3. O impacto de diferentes protocolos de transporte, a saber: UDP e TCP.
As possibilidades de diferentes ordens de chegada podem ser melhor visualizadas
na Figura 3. A variação nesta característica é importante pois permite explicitar em quais
cenários se observa o desempenho ótimo do algoritmo de pré-busca e também
demonstrar os efeitos da ordem de chegada aleatória nos distintos cenários simulados.
Na Figura 3, os círculos escurecidos correspondem a pares do tipo 1 (upload
maior) e os círculos de fundo branco correspondem a pares do tipo 2 (upload menor).
Os números dentro dos círculos correspondem à ordem em que os mesmos chegam ao
sistema. Como em uma dada simulação existe uma quantidade de pares do tipo 1 e outra
9
quantidade de pares do tipo 2, a primeira ordem de chegada a se pensar é a melhor
ordem. Na melhor ordem, os pares que possuem banda de upload maior chegam
primeiro ao sistema, dessa forma, enquanto tais pares de upload maior não terminam de
chegar, não é imposta carga no servidor. Nesta ordem, os pares de upload menor
chegam apenas depois que todos os pares de upload maior já estiverem no sistema. A
ordem média de chegada indica que os pares chegam ao sistema de forma intercalada,
esta ordem simula um caso médio onde a capacidade agregada do sistema fica variando
constantemente de surplus para deficit, e vice-versa. A pior ordem de chegada sugere
que , inicialmente, os pares de banda menor de upload chegam primeiro ao sistema,
consistindo o oposto à melhor ordem. Na pior ordem, inicialmente é imposta uma grande
demanda no servidor pois todos os pares iniciais precisarão da complementação de
banda para que o vídeo seja enviado em taxa igual a sua taxa de codificação aos novos
pares que vão chegando. Por fim, existe a ordem de chegada aleatória, que embora não
tenha sido exemplificada na Figura 3, esta indica que não existe qualquer suposição
sobre em que ordem os pares podem chegar, sendo completamente aleatório.
Figura 3: Tipos de ordens de chegada usadas nas simulações.
Nas simulações é usado por padrão o protocolo de transporte UDP nos pares
P2P, por permitir envio de fluxos com taxas contínuas, simulando um fluxo de vídeo
CBR (Constant Bit Rate) neste protocolo de transporte. A exceção ocorre nas
simulações que visam mostrar o impacto de diferentes protocolos de transporte. Por
padrão também são simuladas as conexões de fundo geradas pelo TCP Suite que usam a
versão TCP NewReno, por esta ser uma implementação amplamente empregada em
diferentes sistemas operacionais.
5. Análise dos Resultados
A metodologia de análise adotada neste trabalho baseia-se tanto no ponto de vista do
servidor, quanto na percepção de continuidade do vídeo pelo usuário. Esta abordagem
também procura investigar o impacto que as diferentes escolhas do sistema P2P podem
causar na rede. Assim, as análises são feitas considerando (i) o impacto da ordem de
chegada dos pares na economia de banda do servidor, comparando-se as políticas de
water-leveling e no-prefetching; (ii) como o tráfego de fundo pode impactar na
economia de banda; (iii) a distribuição de vídeo sobre diferentes protocolos de camada
de transporte (TCP e UDP), observando as perdas ocorridas nos enlaces de backbone;
(iv) o uso da política de pré-busca avaliando-se a descontinuidade de recepção do vídeo
nos clientes (frequência de paradas e o tempo entre paradas).
5.1. Variações na ordem de chegada dos pares
Conforme descrito previamente, os pares possuem capacidades de upload e download
10
Anais
diferentes, caracterizando uma banda assimétrica. Desta forma, mesmo quando o sistema
encontra-se em um modo surplus, a ordem de chegada pode impactar tanto positiva
quanto negativamente. É importante ressaltar que nestes experimentos houve inserção de
tráfego de fundo, afim de torná-los mais realísticos.
Nas Figuras 4 e 5, o eixo Y representa a razão entre a taxa média de upload do
servidor durante a simulação e a taxa de codificação do vídeo. O eixo X representa a
razão entre as demandas e ofertas. No caso das Figuras 4(a) e 5(a), o eixo X representa
a razão oferta sobre demanda, indicando que quando tal razão é 1 o sistema está no
modo balanceado onde existe um mesmo número de pares do tipo 1 e 2. À medida que o
eixo X aumenta de valor, representa-se casos onde os pares do tipo 1 concentram-se em
maior proporção do que os de tipo de 2, o que caracteriza o cenário surplus. Já nos
gráficos do tipo (b), o eixo X representa a razão: demanda sobre oferta, indicando que à
medida que tal razão aumenta, existem mais pares do tipo 2 do que 1, gradativamente,
caracterizando o cenário deficit.
Figura 4: Desempenhos na melhor ordem de chegada (a) modo surplus; (b)
modo deficit.
Figura 5: Desempenhos na ordem média de chegada (a) modo surplus; (b)
modo deficit.
Embora pareça contra intuitivo, na comparação entre as Figuras 4 e 5, percebe-se
que é melhor para o servidor quando os pares chegam ao sistema de forma intercalada
(ordem média), do que quando chegam na melhor ordem. Isto ocorre pois pares do tipo
1 começam mandando pré-busca aos imediatamente posteriores na ordem de chegada, os
fluxos suplementares só são transmitidos para os pares mais recentes em duas hipóteses:
11
(1) quando ele termina de transferir o vídeo inteiro, (2) quando o seu ponto de tocar o
vídeo (playback point) iguala-se ao do par imediatamente anterior. Desta forma, na
melhor ordem, os pares do tipo 1 ficam um tempo inicial considerável servindo a prébusca aos imediatamente posteriores a eles, neste caso, a outros pares tipo 1 do sistema.
Com isso, sobra pouco tempo para os pares tipo 1 servirem a taxa extra aos que são de
tipo 2. Do ponto de vista do servidor, somente os pares imediatamente posteriores aos
de tipo 2 são importantes para receberem a pré-busca, pois quando os mesmos possuem
um reservatório de vídeo (buffer level) razoável, tal reservatário é usado para
economizar banda do servidor.
Já na ordem média de chegada, como o pares são intercalados, normalmente os
de tipo 2 são melhor servidos pela pré-busca. A ordem de chegada do pior caso faz com
que o desempenho do water-leveling seja igual ao no-prefetching uma vez que os pares
iniciais são sempre de tipo 2, quando só pares de tipo 1 começam a chegar, eles apenas
podem ajudar os posteriores a eles, que também serão de tipo 1, dessa forma, o ganho
desses pares não potencializa economia de banda no servidor, por serem sempre
imediatamente posteriores a pares de tipo 1 e não assistidos pelo servidor.
A Figura 4 evidencia que o desempenho do water-leveling não foi muito melhor
do que o no-prefetching, em ambos casos surplus (a) e deficit (b) pelos motivos
explicados anteriormente. Na Figura 5, percebe-se uma grande economia pelo uso da
pré-busca, os maiores ganhos são no modo balanceado e surplus (x >= 1 na Figura 5a),
o upload do servidor chega a ser até 3,8 vezes menor no caso balanceado (economia de
73%) e checou a 6,19 vezes no caso surplus (economia de 83%).
5.2. Impacto do Tráfego de Fundo
Pela Figura 6 pode-se perceber que o servidor atinge uma economia média de 35,71%
quando existe tráfego de fundo. Quando o mesmo está ausente, sua economia aumenta
para 36,82%. Pelo fato dos fluxos UDP não possuírem mecanismos de controle de
congestionamento, por mais que o tráfego de fundo tenha sido intenso, o mesmo
apresentou pouco impacto sobre a distribuição de vídeo, comparando-se com a
simulação sem o mesmo.
Figura 6: Desempenhos usando UDP na ordem de chegada aleatória com e
sem tráfego de fundo (a) modo surplus; (b) modo deficit.
Além das comparações feitas, este experimento exibe o desempenho da ordem de
chegada aleatória, usando o UDP. Analisando os gráficos percebe-se que o waterleveling apresenta uma economia máxima quando o sistema encontra-se no modo
surplus, com o upload do servidor sendo 2,7 vezes menor (economia de 63%). Já no
12
Anais
modo balanceado, o upload do servidor foi 1,7 vezes menor (economia de 42,9%).
5.3. Impacto da Camada de Transporte
Nas simulações usando o protocolo TCP, ao contrário do UDP, a aplicação não controla
a taxa de transmissão do vídeo, visto que a janela de transmissão vai ser regulada pelos
mecanismos de congestionamento e fluxo (minimo entre as janelas). Apesar disso, ainda
assim é importante avaliar o comportamento deste protocolo, dado o seu amplo uso na
Internet em sistemas tradicionais (cliente-servidor e P2P) de VoD.
Figura 7: Desempenhos usando a ordem de chegada aleatória, variando a
camada de transporte TCP e UDP no modo surplus.
O protocolo TCP apresentou um comportamento moderadamente variável. Tal
variação é devida à capacidade dos fluxos deste protocolo se ajustar a diferentes
situações de congestionamento da rede. Portanto, o tráfego de fundo causa razoável
impacto no desempenho da transmissão de vídeo por meio de TCP. Nas comparações
em modo deficit, no desempenho do TCP tanto usando no-prefetching quanto o waterleveling, se mostraram muito próximos do caso no-prefetching em UDP. Outro aspecto
relevante a ser considerado na comparação desses dois protocolos de transporte são as
perdas de pacotes. Como o UDP não é amigável com os fluxos TCP, é intuitivo pensar
que ele possa ser um causador de maiores perdas.
Figura 8: Perdas nos links do backbone usando (a) tcp e (b) udp.
A Figura 8 mostra a comparação entre as perdas relativas a simulações de dois
cenários usando TCP e UDP. As perdas referem-se aos enlaces de backbone por onde
trafegam tanto os vídeos do sistema quanto o tráfego de fundo. Para tal análise, fez-se
13
uso do cenário em que espera-se haver maior tráfego de dados, ou seja, usando-se a prébusca com 55 pares de tipo 1 e 5 pares de tipo 2. Espera-se que haja maior tráfego de
dados pois neste cenário existe o maior número de pares do tipo 1 (com upload maior),
portanto, nesta situação será gerada uma quantidade maior de pré-busca em relação aos
outros cenários. Contrariamente ao esperado, os resultados demonstram que as
diferenças nas perdas foram na mesma ordem de grandeza. Neste caso, o esperado seria
uma perda de proporções maiores nos links de backbone quando se usa o UDP em
relação ao TCP, uma vez que o UDP não possui controle de fluxo e nem de
congestionamento. Apenas no link_3->4 (que na topologia parking lot é a conexão
entre o nó 3 e 4 da Figura 2), que a diferença foi 17% (400 e 450Mb) quando o UDP foi
usado na camada de transporte.
5.4. Percepção de Qualidade pelo Cliente
Neste caso, para cada par é registrada a quantidade de vezes que o vídeo parou de tocar,
representado por um diagrama de frequências. Adicionalmente, é armazenado o tempo
que o vídeo permaneceu parado, representado pelo diagrama boxplot - onde a mediana é
o centro do box, os quartis representam os contornos e os outliers ficam do lado de fora.
Figura 9: Frequência das paradas no playback do vídeo na ordem de
chegada aleatória usando UDP no modo balanceado (a) no-prefetching (b)
water-leveling.
Figura 10: Continuidade no playback do vídeo na ordem de chegada
aleatória usando UDP no modo balanceado (a) no-prefetching (b) waterleveling.
No ponto de vista do cliente, é indesejável que o playback do vídeo tenha muitas
14
Anais
interrupções, no entanto, quando as mesmas ocorrem, a ideia é que o playback retorne o
mais rápido possível (Figuras 9 à 12).
Na análise desta seção foram usados os resultados de simulações no modo
balanceado, ou seja, quando existem 30 pares com banda de upload alta e 30 pares com
banda de upload baixa. Na Figura 9, avaliamos como a política de pré-busca waterleveling pode melhorar de forma considerável a quantidade de interrupções nos pares
quando se usa o UDP. É possível afirmar que a política de pré-busca melhorou bastante
o número de interrupções no vídeo em comparação ao P2P no-prefetching (onde não há
pré-busca). Na Figura 10 é possível ver que o tempo decorrido dentre o vídeo parado até
voltar a tocar, foi em geral, muito baixo (menor que 0,2 s). Esses resultadores indicam
que quando houveram interrupções, as mesmas duraram muito pouco em ambos casos
(no-prefetching e water-leveling).
Figura 11: Continuidade no playback do vídeo na ordem de chegada aleatória
usando TCP no modo balanceado (a) no-prefetching (b) water-leveling.
Figura 12: Frequência das paradas no playback do vídeo na ordem de chegada
aleatória usando TCP no modo balanceado (a) no-prefetching (b) waterleveling.
A Figura 11 mostra como o water-leveling reduziu bastante o a quantidade de
interrupções no playback do vídeo quando a camada de transporte é o TCP, no entanto,
vários pares ainda ficaram com interrupções na ordem de grandeza em 100, o que não é
considerado aceitável. Na Figura 12, são exibidos os tempos decorridos entre uma
interrupção e a continuação da vídeo.
Também percebe-se que houve redução neste tempo com a adoção do waterleveling, no entanto, tal redução não foi muito acentuada. As reduções mais
15
significativas na continuidade ocorreram em apenas 5 pares, o que representa menos de
9% de todos os pares do sistema.
6. Conclusões e Trabalhos Futuros
O presente trabalho visa investigar compromissos de projeto para um sistema P2P de
distribuição de vídeo, considerando as perspectivas do servidor, da rede e
particularmente a continuidade de reprodução de vídeo percebido pelos usuários. O
trabalho parte das políticas de pré-busca propostas em [Huang, 2007], distinguindo-se
ao avaliar o desempenho da pré-busca em um simulador de redes sob condições mais
realistas, incluindo atrasos, perdas nos enlaces, tráfego de fundo e distintos protocolos
da camada de transporte.
Do ponto de vista do servidor, os resultados obtidos nas simulações sugerem que
o maior ganho na taxa de upload do servidor proporcionado pela pré-busca foi uma
economia de 3,8 vezes (economia de 73%), no modo balanceado. No entanto, esta
economia é condicionada ao uso do UDP como protocolo de transporte e quando os
pares chegam de forma intercalada no sistema. No caso da ordem de chegada aleatória,
usando-se também UDP, a economia de banda obtida no servidor foi de praticamente
duas 2 vezes (42,9%), que corresponde a um ganho menor do que apresentado em
[Huang, 2007]. Ressalta-se ainda que a ordem de chegada aleatória tende a ser um
cenário mais próximo ao que acontece em redes P2P na Internet. O uso do TCP como
protocolo de transporte mostrou que não houve um ganho significativo no servidor
quando se usa a pré-busca. No ponto de vista da rede, as perdas ocasionadas pelo uso do
UDP não foram muito distantes das perdas ocorridas usando o TCP, portanto, concluise que é viável o uso do UDP na distribuição de vídeo sob este ponto de vista. A análise
que aborda o impacto do trafego de fundo (quando se usa UDP) também aponta para
esta mesma conclusão, ou seja, o UDP é mais recomendado neste aspecto por ter não ter
ocasionado perda de desempenho considerável na economia do servidor quando se
comparou a presença ou ausência de tráfego de fundo.
Na análise de continuidade do vídeo percebido pelos clientes, os resultados
mostram que a escolha da camada de transporte teve mais impacto do que o uso da prébusca. No entanto, por mais que as interrupções no playback do vídeo ocorridas usando
o UDP tenham durado muito pouco, as mesmas são suficientes para gerar insatisfação
do usuário. Neste contexto, pode-se concluir que o uso da pré-busca beneficia bastante
ambos o provedor de conteúdo e os clientes.
Como trabalhos futuros, um dos aspectos que pretende-se incluir na simulação é
o peer-churn, que permitirá representar modelos de entrada/saída de pares. Outro
aspecto a ser considerado é a implementação de operações de VCR, ou seja, a
capacidade de usuários que estão assistindo um vídeo avançarem e retrocederem na
reprodução.
Referências
Sharma, A., Bestavros, A. and Matta, I. (2005) “dPAM: a distributed prefetching
protocol for scalable asynchronous multicast in P2P systems”, In Proceedings of
Conference of the IEEE Computer and Communications (INFOCOM), vol. 2, pp.
1139-1150.
Sentinelli, A., Marfia, G., Gerla, M. and Kleinrock, L. (2007) “Will IPTV Ride the Peerto-Peer Stream?”In IEEE Communications Magazine.
16
Anais
Moraes, I. M. e Duarte, O. C. M. B. (2010) “Seleção de Parceiros em Sistemas Par-aPar de Vídeo sob Demanda”, Em XXVIII Simpósio Brasileiro de Redes de
Computadores (SBRC), pp. 219-232, Gramado, RS, Brasil.
Shen, Y., Liu, Z., Panwar, S., Ross, K. W. and Wang, Y. (2009) “On the design of
prefetching strategies in a peer-driven Video on-demand systems”. In Proceedings of
IEEE International conference on Multimedia and Expo.
Huang, C., Li, J. and Ross, K. W. (2007) “Peer-Assisted VoD: Making Internet Video
Distribution Cheap”, In International workshop on Peer-To-Peer Systems (IPTPS).
He, Y. and Guan, L. (2009) "Prefetching Optimization in P2P VoD Applications", In
Advances in Multimedia (MMEDIA), pp. 110-115.
Gao, L., Xie, H., Zhang, Z., Wang, R. and Lu, Y. (2010) “The Design of a P2P videoon-demand prototype system”, In Computer Science and Information Technology
(ICCSIT), pp 473-477.
Shimonishi, H., Sanadidi, M. and Murase, T. (2007) “Assessing Interactions among
Legacy and High-Speed TCP Protocols”, In Proceedings Workshop on Protocols for
Fast Long-Delay Networks (PFLDNet).
NS2, The network simulator–ns-2. http://www.isi.edu/nsnam/ns/. Página acessada em 1
de Dezembro de 2010.
Biao, C., Zhen, L. and Yaohua, L. (2010) “A Special Topology for Files Pre-Fetch in
Large Scale Video on Demand”, In Biomedical Engineering and Computer Science
(ICBECS), pp.1-4, 23-25.
Chu, Y., Rao, S. G. and Zhang, H. (2000) “A case for end system multicast”, In
Proceedings of ACM Sigmetrics.
Tran, D. A., Hua, K. A. and Do, T. (2003) “ZIGZAG: an efficient peer-to-peer scheme
for media streaming”, In Twenty-Second Annual Joint Conference of the IEEE
Computer and Communications (INFOCOM), vol.2, pp. 1283-1292.
Wei, D., Cao, P. and Low, S. (2005) “Time for a TCP benchmark Suite?”, Caltech,
Tech. Rep.
Crovella, M. E. and Bestavros, A. (1997) “Self-similarity in world wide web traffic:
Evidence and possible causes”, In IEEE/ACM Transactions on Networking,
5(6):835–846.
17
Análise de desempenho de redes p2p com protocolo
“push/pull” para distribuição de vídeo na presença de nós
não-cooperativos
Flávia Marinho de Lima1, Alexandre Sztajnberg1
Programa de Pós-Graduação em Eletrônica - Universidade do Estado do Rio de Janeiro
R. S. F. Xavier, 524/5º 22550-013 - Rio de Janeiro – RJ – Brasil
1
flaviamarinho@yahoo.com, alexszt@uerj.br
Abstract. P2P (peer to peer) architectures are being used as an infrastructure
for video stream distribution on the Internet. The idea is that the several nodes
of the overlay network should cooperate distributing and forwarding video
chunks, making available their local resources to the network. In this way, it
is important to investigate what happens to the quality of service of the video
distribution when the infrastructure provided by the P2P network is
“contaminated” with free-riding nodes, which are not willing to cooperate,
since the basis of this architecture is cooperation. In this work, we evaluate
how the presence of uncooperative nodes can affect the quality of the video
stream distribution on push-pull P2P networks. The evaluation was performed
using the PeerSim simulator.
Resumo. A arquitetura P2P (peer-to-peer) vem sendo considerada como
infraestrutura para a distribuição de fluxos de vídeo na Internet. A idéia é a
de que os vários nós integrantes da rede sobreposta distribuem e encaminham
pedaços de vídeo de forma cooperativa, dividindo as tarefas, e colocando à
disposição da rede seus recursos locais. Dentro deste contexto, é importante
investigar o que ocorre com a qualidade do serviço de distribuição de vídeo
quando a infraestrutura provida pelas redes P2P é “contaminada” por nós
que não estejam dispostos a cooperar, já que a base desta arquitetura é a
cooperação. Neste trabalho, é feito um estudo para verificar como a presença
de nós não-cooperativos pode afetar a qualidade da distribuição de fluxo de
vídeo em redes P2P com protocolo push-pull. A avaliação foi realizada
utilizando-se o simulador PeerSim.
1. Introdução
A distribuição de vídeo pela Internet traz grandes desafios, pois é um serviço que requer
(i) servidores com grande capacidade de processamento e armazenamento, e (ii) grande
largura de banda, baixo retardo e variação de retardo (jitter) e poucas perdas. É também
um serviço que apresenta requisitos de escalabilidade, pois se estima uma quantidade
grande de usuários simultâneos, e flexibilidade, uma vez que estes usuários devem
receber os fluxos de vídeo de acordo com sua capacidade de banda e recursos
computacionais para tratamento e exibição dos mesmos. Tornar disponível uma solução
que contemple todas estas características é importante para que se possa oferecer ao
usuário um serviço de qualidade, mas não é tarefa trivial, dado que a arquitetura da
Internet não foi concebida com esta finalidade.
18
Anais
Neste contexto, as redes par-a-par, ou peer to peer (P2P)1, vem sendo
consideradas como solução potencial para a distribuição de vídeo na Internet, devido às
suas características de escalabilidade e distribuição de responsabilidades. A idéia básica
é a de que os vários nós integrantes da rede P2P distribuem e encaminham pedaços de
vídeo de forma cooperativa, dividindo as tarefas, e colocando à disposição da rede seus
recursos locais. Com isso diminui-se a necessidade de canais reais com grandes bandas
e servidores com grande capacidade de processamento e armazenamento. Nesta
abordagem, quanto maior o número de nós, maior é a capacidade de distribuição de
vídeo, pois mais recursos são compartilhados, sem a dependência de um único servidor
ou federação de servidores, o que torna as redes P2P robustas para este serviço.
Entretanto, mesmo com características favoráveis, a distribuição de vídeo nas
redes P2P também apresenta desafios. É frequente que alguns nós, geralmente nós com
mais recursos que os demais, fiquem sobrecarregados porque nem todos os nós
participantes querem cooperar. De certa forma, com a existência de muitos nós com
comportamento não-cooperativo, as redes P2P passam a apresentar características de
um sistema centralizado, podendo apresentar um desempenho ainda pior, pois os nós
sobrecarregados não são necessariamente especializados para a atividade de
armazenamento e distribuição de vídeo, tornando-se gargalos.
Estudos empíricos têm mostrado que nós que atuam como parasitas na rede,
consumindo recursos, sem contribuir, são maioria em redes P2P voltadas para o
compartilhamento de arquivos [Adar e Huberman, 2000] [Saroiu, 2003], prejudicando
os usuários cooperativos. No caso da aplicação de distribuição de vídeo este
comportamento é ainda mais nocivo, uma vez que os usuários não estão em busca
apenas da disponibilidade do arquivo contendo o vídeo, mas também esperam um
mínimo de qualidade na obtenção e exibição do mesmo.
Neste trabalho analisamos o impacto causado pela ação de nós com
comportamento não-cooperativo, no desempenho da distribuição de fluxos de vídeo em
redes P2P que usam o protocolo de difusão de pedaços push/pull proposto em [Cigno,
2008]. Numa primeira etapa, simulações são realizadas aumentando-se gradativamente
o número de nós maliciosos na rede. Assim, é possível avaliar a influência da
porcentagem de nós não-cooperativos, no sistema como um todo. Os resultados
comprovam que o desempenho do protocolo push/pull diminui à medida que a
porcentagem de nós maliciosos aumenta. Numa segunda etapa introduzimos no modelo
a possibilidade de cada nó escolher os seus vizinhos na formação do grafo, baseado em
uma “reputação” inicial, considerando se o nó candidato a vizinho é ou não cooperativo.
Com isso, a escolha deixa de ser 100% aleatória, garantindo uma certa qualidade de
vizinhança. Após as simulações, uma melhora no desempenho da rede, como um todo, é
constatada e os nós cooperativos são em geral ativados mais rapidamente. Entretanto, os
nós não-cooperativos ainda são beneficiados. Diante destes resultados identificamos a
necessidade de criação de um mecanismo de incentivo à cooperação.
Este artigo está organizado da seguinte forma. A próxima seção discute os
conceitos do protocolo push/pull. A Seção 3 discute trabalhos relacionados. Na Seção 4,
apresentam-se o simulador PeerSim e as métricas usadas na simulação. A Seção 5
apresenta os resultados da primeira etapa da avaliação. Na Seção 6 o mecanismo de
controle de admissão de vizinhos é apresentado e avaliado. A Seção 7 conclui o artigo.
1 Redes sobrepostas (overlay), que executam sobre redes como a Internet, com nós virtuais, sendo
interligados por canais de comunicação também virtuais.
19
2. Conceitos Básicos
Uma das formas de se transmitir arquivos ou fluxos de vídeo em redes P2P pela Internet
requer a divisão do conteúdo em pedaços, ou chunks, a fim de transmiti-los de maneira
independente uns dos outros. O BitTorrent [Hales, 2005] utiliza este método para
compartilhamento de arquivos em redes P2P, e alguns sistemas de distribuição de vídeo,
como o CoolStreaming [Xinyan, 2005], também utilizam este método, dividindo um
fluxo de vídeo em vários pedaços para então transmiti-los.
2.1. Modelos de difusão de pedaços em redes P2P
Para os sistemas que utilizam a divisão em pedaços para a transmissão do conteúdo, o
mecanismo de difusão dos pedaços entre os nós da rede P2P é ponto de relevância.
Existem três modelos de difusão de pedaços que se destacam na literatura: o modelo
push, o modelo pull, e o modelo baseado no estado de cada nó. Além disso, alguns
trabalhos propõem modelos híbridos.
No modelo push, os pedaços são enviados de um nó pai para nós filhos, sem o
nó pai questionar se os nós filhos precisam ou não daquele pedaço. Caso um nó filho,
possua mais de um nó pai, fica fácil perceber que o mesmo pedaço pode chegar várias
vezes ao mesmo nó, ao passo que um determinado pedaço pode demorar ou nunca
chegar. O método push é, portanto, mais indicado em redes estruturadas, com topologia
baseada em árvore [Tran, 2004] [Venkataraman, 2006] [Sung, 2006].
O modelo pull apresenta comportamento oposto ao do modelo push. Neste, um
nó filho faz a requisição de um pedaço ao nó pai sem saber se ele o possui. Aqui não há
problema de duplicação, mas existe o problema de starvation, pois um filho pode nunca
encontrar um nó pai que possua o pedaço que ele esteja procurando. Em geral, o modelo
pull está associado a sistemas não estruturados, onde um nó filho pode ser suprido por
vários nós pai, diminuindo assim a probabilidade de ocorrer starvation. Até onde foi
investigado, na prática é difícil existirem sistemas que utilizem exclusivamente o
modelo pull para distribuição de vídeo.
No modelo baseado no estado [Pai, 2005] [Xinyan, 2005] [Pianese, 2006], os
nós trocam informações entre si para saber o que cada nó vizinho possui, e assim pedirlhe ou enviar-lhe um determinado pedaço. Cada nó possui o seu mapa de buffer que
mantém um índice dos pedaços que o mesmo possui, e ainda uma lista dos pedaços que
estão na eminência de serem reproduzidos. Os nós fazem a troca do mapa de buffer com
os seus nós vizinhos. Como os nós têm consciência do que cada um possui, eles podem
fazer a requisição de pedaços de maneira otimizada.
Alguns trabalhos propõem modelos híbridos para a distribuição de pedaços. Um
desses modelos é o Interleave [Sanghavi, 2007] que combina os modelos push e pull, e
adiciona um mecanismo de política de seleção de pedaços, sem nenhuma troca de
informações entre os nós sobre os pedaços que cada um possui. Este modelo foi
projetado e analisado principalmente para transferência de arquivos.
O trabalho [Cigno, 2008] analisou o desempenho do modelo Interleave em
detalhe, e ampliou seu escopo para permitir redes P2P com comportamentos diversos e
para comprovar se era possível transmitir vídeo com este modelo de difusão de pedaços.
Os resultados mostraram que era possível não só ter bom desempenho para distribuição
de arquivos, como também para a distribuição de vídeo sem manter quaisquer
informações sobre os pedaços.
20
Anais
2.2. O modelo de difusão de pedaços push/pull
O modelo de rede P2P para distribuição de vídeo proposto em [Cigno, 2008] possui
apenas uma única fonte, que divide o conteúdo do vídeo em pedaços para serem
distribuídos entre os nós da rede sobreposta de forma independente. Os pedaços são
gerados a uma taxa constante pela fonte e cada pedaço possui um identificador único
que reflete a sua ordem de criação.
A rede sobreposta é do tipo não-estruturada, com topologia em malha e
simétrica, ou seja, se um nó N é vizinho de V, então V é vizinho de N. Cada nó N da
rede possui uma lista com a referência para todos os seus nós vizinhos e pode contatar
ativamente estes nós e apenas eles.
Cada nó alterna seu estado entre os modos push e pull. Apenas o nó fonte não
alterna o seu estado, ele permanece sempre com o estado push, pois o nó fonte não
precisa requisitar pedaços, ele já os possui.
Durante o estado push, um nó N realiza as seguintes atividades:
1. seleciona um vizinho V aleatoriamente, e o pedaço K com o identificador mais alto,
ou seja o k mais recente, entre os diversos pedaços recebidos dos seus vizinhos;
2. em seguida, envia uma mensagem ao vizinho V selecionado aleatoriamente,
questionando se este deseja K;
3. se o nó V não possui K e tiver banda de download disponível, o nó V envia uma
mensagem a N aceitando a oferta, e o nó N envia o pedaço K ao nó V;
4. caso contrário, o nó N aborta o processo.
Durante o estado pull, um nó N realiza as seguintes atividades:
1. envia uma mensagem de requisição de pedaço a um nó vizinho V aleatório,
solicitando o pedaço K com o identificador mais baixo que não possua;
2. se o nó V possuir o pedaço K e tiver banda de upload disponível, o nó V envia uma
mensagem ao nó N aceitando a requisição;
3. caso contrário, o nó V rejeita a requisição.
A política de seleção de pedaços é uma parte muito importante em sistemas de
distribuição de vídeos, pois cada pedaço tem um tempo máximo de retardo tolerado
para iniciar a sua reprodução. Se um pedaço de fluxo de vídeo chegar após o seu tempo
de reprodução, haverá uma descontinuidade no vídeo. Algoritmos para selecionar os
pedaços, tal qual o mais raro primeiro, não podem ser implementados apenas com
modelos push/pull, pois, como visto, é necessário conhecimento prévio do que os outros
nós possuem. O modelo sugerido por [Cigno, 2008] adotou a mesma política de seleção
de pedaços empregada em [Sanghavi, 2007]:
1. Durante o estado push, o nó N envia o pedaço com o identificador mais alto entre os
diversos pedaços recebidos via estado push de seus vizinhos.
2. Durante o estado pull, o nó N requisita o pedaço com o identificador mais baixo que
não possua. Essa política ajuda o nó N a preencher buracos na sequência de pedaços.
É possível observar que essa política de seleção não necessita de um prévio
conhecimento do que outro nó possui. Um nó muda de um estado para outro, ou depois
de uma requisição ser aceita e o pedaço correspondente terminar de ser transferido, ou
21
depois de receber um número máximo de negações às suas requisições. Este
comportamento mantém o sistema rodando suavemente, e evita starvation. Além disso,
as informações trocadas pelos nós vizinhos são as mínimas possíveis, apenas mensagens
de keep-alive e mensagens de requisições e respostas do protocolo push/pull são usadas.
A maior vantagem em se utilizar um protocolo de difusão baseado nos modelos
push/pull é a sua simplicidade, relacionada ao fato deste poder trabalhar sem qualquer
suposição em relação ao comportamento de cada nó. Nenhuma sinalização é necessária
para coordenar os nós, fazendo com que este protocolo seja, em tese, adequado a redes
muito dinâmicas, ou seja, com muitas entradas e saídas de nós. Por outro lado,
protocolos baseados em estado buscam melhorar o desempenho e a eficiência,
aumentando o risco de se tornarem frágeis e propensos a falhas em redes heterogêneas e
dinâmicas, com nós com comportamento variável.
Para alguns casos, como transmissão de vídeo por difusão, onde, em geral, todos
os usuários estão interessados no mesmo recurso em um espaço curto de tempo, talvez
um protocolo mais simples seja suficiente para atender todos os requisitos do serviço de
vídeo de maneira eficiente. Para outros casos, como transmissão de vídeo sob demanda,
onde os usuários interessados no vídeo estão em diferentes momentos de reprodução do
mesmo, provavelmente um protocolo baseado em estado seja mais eficaz, pois cada
usuário saberá exatamente a quem recorrer para obter os pedaços de vídeo desejados,
sem correr o risco de pedir para um usuário que não o tenha.
3. Trabalhos relacionados
Existem vários trabalhos relacionados ao uso de redes P2P para distribuição de vídeo
[Tran, 2003] [Habib, 2004] [Xinyan, 2005] [Carlsson, 2007] [Cigno, 2008] [Moraes,
2008] [Moraes, 2009]. Nenhum deles, entretanto, faz um estudo específico sobre o
comportamento de uma rede que utilize o protocolo de difusão push/pull face a
presença de nós com comportamento não-cooperativo.
[Sanghavi, 2007] propôs o protocolo Interleave para difundir os pedaços entre os
nós da rede. Este protocolo combina os modelos push e pull, alternando os estados dos
nós entre um ou outro, e foi criado com o propósito de aumentar o desempenho de
serviço de distribuição de arquivos. O autor também adotou uma política de seleção de
pedaços, conforme mencionado na seção anterior. O trabalho comprovou que o
protocolo podia ser utilizado satisfatoriamente para serviço de distribuição de arquivos.
Alguns trabalhos propõem a combinação dos modelos push e pull, utilizando o
mecanismo push para distribuir rapidamente os pedaços, e o mecanismo pull para
preencher os “buracos” no buffer de reprodução. Não há uma alternância entre os dois
modelos, por exemplo, [Locher, 2007].
Mais próximo de nosso trabalho, [Cigno, 2008] fez um estudo do protocolo
push/pull com a finalidade de avaliar o comportamento e desempenho do mesmo na
tarefa de distribuição de fluxo de vídeo na Internet. Para atingir seus objetivos, variou
parâmetros como: quantidade de nós, quantidade de vizinhos por nó, quantidade de
pedaços a serem distribuídos e banda de upload. Os resultados foram comparados aos
obtidos em [Sanghavi, 2007] e apresentaram indícios de que era possível ter bom
desempenho para transmissão de vídeo utilizando um modelo de rede P2P que
combinasse os modelos push e pull.
Até aqui as discussões apresentadas consideraram que todos os nós atuam de
22
Anais
forma cooperativa na rede. Grande parte dos sistemas P2P conta com isto, já que
deveria ser do interesse do nó participante cooperar com os demais, pois a qualidade
dos serviços que ele utiliza depende do desempenho da rede como um todo.
Estudos mostram que em sistemas de compartilhamento de arquivos, o tempo
total para baixar arquivos e a taxa de falhas de toda a rede aumentam a medida que os
nós deixam de compartilhar seus recursos [Adar e Huberman, 2000]. Em redes sem fio
ad hoc, a latência de pacotes e a taxa de perda aumentam para todos, quando os nós se
recusam a encaminhar pacotes de controle sobre o comportamento dos outros nós
[Marti et al, 2000].
Seria natural raciocinar que é interessante para um determinado nó cooperar para
maximizar os seus resultados. Mas, isso não é o que ocorre de fato. Estudos têm
mostrado que nós que atuam como parasitas, consumindo recursos sem contribuir, são
maioria em redes P2P para compartilhamento de arquivos [Adar e Huberman, 2000]
[Saroiu et al, 2003]. Não apenas usuários egoístas ou parasitas prejudicam o
desempenho de uma rede P2P. Usuários mal intencionados, que querem realmente
degradar o serviço oferecido pela rede, ou usuários mentirosos, que querem trapacear,
também prejudicam o desempenho da rede.
Seria desejável que o desempenho das aplicações em redes P2P se mantivesse
estável, mesmo diante de nós não-cooperativos. A infraestrutura provida e os protocolos
utilizados deveriam ser robustos o suficiente para que as aplicações fossem
minimamente afetadas por nós com comportamento malicioso. Alguns trabalhos
relacionados ao uso de redes P2P para distribuição de vídeo abordam esse problema.
[Habib e Chuang, 2004] propõe um mecanismo de seleção de vizinhos baseado
em um ranking para distribuição de vídeo na Internet com nós com interesses
assimétricos. O mecanismo estimula o incentivo à cooperação através da diferenciação
de serviços. Nós cooperativos da rede são recompensados com flexibilidade e escolha
na seleção dos vizinhos, resultando em alta qualidade na reprodução do vídeo. Os nós
não-cooperativos têm limitadas opções na seleção de vizinhos, obtendo uma baixa
qualidade de vídeo. Os autores verificaram que o mecanismo pode prover qualidade de
vídeo próxima ao ótimo, quando todos os nós são cooperativos, desde que as fontes de
vídeo não estejam conectadas por enlaces no limite de sua banda. Os autores também
afirmam que o mecanismo de incentivo proposto não é necessário quando a rede está
totalmente disponível e não é efetiva quando o congestionamento é alto.
[Chu et al, 2004] propõe um modelo de taxação, onde nós com mais recursos
contribuem com mais banda no sistema. Nós com recursos limitados são subsidiados
pelo sistema. O modelo é aplicado no contexto de distribuição de vídeo onde o
distribuidor do vídeo impõe a taxação para os demais nós para obter o máximo de
cooperação de cada um. Este esquema é usado quando um número alto de usuários está
interessado em uma mesma sessão de vídeo, e estes usuário estão dispostos a cooperar
de maneira síncrona, mesmo que com alguma sobrecarga, para que a qualidade do
vídeo recebido seja satisfatória.
[Hoong e Matsuo, 2008] propõe o protocolo PALMS (P2P Unstructured Live
Media Streaming) que faz uso dos modelos push, pull e conhecimento do estado do
mapa de buffer de cada nó para difusão dos pedaços de vídeo em conjunto com um
mecanismo de incentivo à cooperação baseado na pontuação do nó. A pontuação é
função da razão entre bytes transmitidos e bytes recebidos. A seleção do vizinho
depende da pontuação do nó solicitante e do nó candidato a vizinho. Um nó solicitante
23
só pode selecionar nós com pontuações menores ou iguais à dele, assim cada nó fica
estimulado a cooperar mais a fim de poder selecionar melhores parceiros para aumentar
a qualidade do vídeo reproduzido. Com este mecanismo os autores obtiveram resultados
satisfatórios, mesmo diante da existência de nós não-cooperativos na rede.
4. Ambiente da simulação
O ponto fundamental deste trabalho trata do estudo do comportamento de uma rede
sobreposta em malha que utilize o método de difusão de pedaços baseado no modelo
push/pull, diante de nós que podem ou não estarem dispostos a cooperar. O objetivo é
mensurar o quanto a presença de nós maliciosos pode prejudicar o desempenho da rede
P2P na distribuição de vídeo. Devido às dificuldades inerentes aos testes reais com
muitos nós, optou-se por simular a rede sobreposta em um simulador de rede P2P.
4.1. O simulador PeerSim
As simulações foram realizadas no simulador PeerSim [PeerSim] utilizando o módulo
P4S [P4S], desenvolvidos em Java. O PeerSim suporta dois modelos de simulação:
orientado a ciclos e o orientado a eventos. Para este trabalho foi escolhido o modelo de
simulação orientado a eventos, pois era preciso que o ambiente fosse o mais próximo
possível da realidade.
Em nossas simulações utilizamos grafos simétricos. Para isso, utilizamos a
classe peersim.dynamics.WirekOutUnd, a mesma utilizada pelo trabalho [Cigno, 2008]
para distribuição de vídeo. Esta classe cria um grafo simétrico com cada nó possuindo
um número fixo de vizinhos, e a escolha de cada vizinho é aleatória.
Para facilitar o estudo do protocolo de difusão baseado no modelo push/pull,
utilizou-se o módulo P4S, criado para simular a distribuição de arquivos e a distribuição
de vídeo em redes P2P em malha. O módulo P4S provê a classe p4s.core.Alternate que
simula um protocolo de difusão que combina os modelos push e pull.
Para introduzir as características de nós não-cooperativos na primeira etapa da
simulação foi necessário criar o código para nós com tal comportamento. Na segunda
etapa introduzimos um controle na formação das vizinhanças, limitando a quantidade de
nós não-cooperativos que um nó cooperativo poderia ter.
4.2. Infraestrutura da simulação
Para modelar um nó com comportamento não-cooperativo, modificamos a seqüência
das atividades realizadas pelo nó no estado push porque de acordo com os resultados de
[Cigno, 2008] o número de pedaços recebidos via push é ligeiramente maior do que
recebido via pull. Com isso o nó não-cooperativo nesta simulação prejudica seus
vizinhos porque não envia pedaços de forma voluntária aos mesmos, entretanto quando
é solicitado a enviar um pedaço, o nó não-cooperativo age corretamente. Pode-se dizer
então, que o nó não-cooperativo neste caso não é 100% prejudicial, não tem a finalidade
de prejudicar totalmente a rede e sim de se beneficiar em relação aos outros nós, de
certa forma age de maneira egoísta.
A diferença da seqüência original é a introdução de mais uma condição no
estado push. O nó que vai enviar voluntariamente um pedaço deve, agora, além de
possuir um número de conexões ativas menor que o número máximo de conexões
possíveis e banda de upload disponível, ser também um nó cooperativo. Caso contrário,
24
Anais
sendo um nó não-cooperativo, o mesmo passa para o estado pull diretamente, sem
enviar nenhum pedaço.
Na simulação a rede sobreposta é composta por um nó fonte que gera os pedaços
a uma taxa constante. Os nós são inicializados ao mesmo tempo e seus vizinhos são
escolhidos de forma aleatória e simétrica, conforme já explicado. Os nós entram na rede
como nós passivos, ou seja, não podem solicitar nenhum pedaço a um de seus vizinhos
até que fiquem no modo ativo, para que isso ocorra, o nó precisa receber o seu primeiro
pedaço via método push. Uma vez aceitos na rede, os nós não saem desta, ou seja, não
há churn.
Após a inicialização dos nós, o nó fonte começa a enviar pedaços para os seus
vizinhos, ativando-os. A partir daí, outros nós também são ativados e portanto ficam
aptos a pedir e enviar pedaços. A simulação chega ao fim quando todos os nós
obtiverem todos os pedaços ou o tempo limite estiver esgotado.
Dois tipos de vídeo e respectivos parâmetros, utilizados em [Costa, 2004] e em
[Moraes, 2009], foram adotados em nossas simulações. Um deles, obtido a partir da TV
UOL - entretenimento de 5 min e o outro do servidor eTeach, Univ. de Wisconsin educacional de 20 min. A Tabela 1 resume estes parâmetros.
Tabela 1. Parâmetros considerados em todas as simulações
Entretenimento
Educativo
Número de nós participantes
200
200
Tamanho do vídeo (pedaços)
30
120
Tamanho do vídeo (minutos)
5
20
Taxa de transmissão do vídeo (Kb/s)
350
350
Duração do pedaço de vídeo (s)
10
10
437,5
437,5
Tamanho do pedaço do vídeo (kB)
Além dos parâmetros da Tabela 1, definiu-se a banda de upload 600 kb/s para
todos os nós, e o número de vizinhos de cada nó igual a 12, essas escolhas foram
baseadas nos resultados de [Cigno, 2008], onde a rede tornava-se estável. Foram
realizadas 300 rodadas de simulação, variando a porcentagem de nós não-cooperativos
na rede em 0%, 5%, 10%, 15% e 20%.
4.3. Métricas escolhidas
Quatro métricas foram escolhidas para verificar o desempenho do protocolo push/pull
em presença de nós não-cooperativos durante a simulação:
Tempo máximo, tempo que o último nó a terminar de reproduzir o vídeo leva para
obter todos os pedaços.
Qualidade do sistema de vídeo, definida em [Habib, 2004] como:
T
∑ Zi
Q=
i= 1
(1)
T
onde T é o número total de pedaços envolvidos na distribuição de vídeo e Z i é a variável
que representa o fato do pedaço ter chegado ou não antes do seu tempo de reprodução.
25
Caso o pedaço tenha chegado antes do seu tempo de reprodução, a variável Z i recebe 1,
do contrário Zi recebe 0, o que representa descontinuidade no vídeo.
Índice de continuidade, definido em [Moraes, 2009], representa o quanto o usuário
obteve o vídeo de forma contínua, ou seja, sem interrupções. Quando um pedaço chega
após o seu tempo de reprodução, significa que o usuário ficou provavelmente com a
imagem do último quadro congelada até a chegada deste pedaço ou que um timeout
ocorreu, gerando descontinuidade na reprodução do vídeo e desconforto ao usuário.
O tempo total em que a reprodução do vídeo fica parada aguardando o pedaço
atrasado chegar para reproduzi-lo é chamado de tempo de espera. De posse do tempo de
espera do nó é possível calcular o índice de continuidade do mesmo. Tem-se que:
c=
tr −te
tr
(2)
onde tr é o tempo total de reprodução do vídeo. Quanto maior o índice de continuidade,
mais tempo em que o usuário assistiu ao vídeo sem interrupções. Um índice igual a
100% significa que não houve interrupções na reprodução de vídeo de um dado nó.
Atraso inicial, na reprodução do vídeo. A estratégia definida para o momento certo de
inicializar a reprodução de um vídeo tem importância fundamental no sucesso da
qualidade do vídeo ao longo da reprodução. [Carlsson, 2007] apresenta algumas
políticas de como determinar o melhor momento para iniciar o vídeo.
O simulador P4S/PeerSim não possui um escalonador para a reprodução de
vídeo. Como era importante visualizar a tendência do atraso inicial e da perda de
continuidade da rede P2P em face a adição de nós não-cooperativos, definimos uma
política simples para inicializar o vídeo: aguardar a chegada dos três primeiros pedaços,
(0, 1 e 2). Esta política é aplicada aos arquivos de resultado das simulações. [Lima,
2010] oferece uma discussão ampla do problema e seus efeitos na distribuição de vídeo.
5. Avaliação do comportamento de nós maliciosos
Devido a limitação de espaço, apresentaremos apenas os gráficos referentes à simulação
do cenário com 120 pedaços. As Figuras 1(a), 1(b), 2(a) e 2(b) apresentam os gráficos
de desempenho para as métricas tempo máximo, índice de continuidade (ICO),
qualidade do sistema de vídeo (Q) e atraso inicial, respectivamente.
Tempo Máximo
Nós C
Nós NC
Tempo Máximo (min)
21,75
Índice de continuidade (ICO)
ICO
22
21,5
1
Nós C
Nós NC
0,99
0,98
21,25
0,97
21
0,96
20,75
0,95
20,5
0,94
20,25
0,93
20
0%
5%
10%
15%
20%
Nós não-cooperativos
0%
5%
10%
15%
20%
Figura 1. Desempenho: (a) tempo máximo e (b) índice de continuidade
O eixo y dos gráficos das figuras 1 e 2(a) representam as médias das métricas
avaliadas obtidas pela rede com um intervalo de confiança de 90%, já o eixo x
representa a porcentagem de nós não-cooperativos na rede sobreposta. Barras cinzas
26
Anais
correspondem ao desempenho dos nós cooperativos (nós C), barras brancas
correspondem ao desempenho dos nós não-cooperativos (nós NC).
Observa-se, na Figura 1(a), que o tempo máximo dos nós cooperativos e nãocooperativos são muito próximos, com pequena vantagem para os nós não-cooperativos.
O melhor desempenho dos nós da rede ocorre quando a quantidade de nós nãocooperativos é igual a zero, e o desempenho piora a medida que a percentagem de nós
não-cooperativos na rede aumenta. No melhor caso, todos os nós terminaram em até 21
min e no pior caso em até 21 min e 21 seg, lembrando que o vídeo é de 20 min e que há
um atraso inicial para a reprodução do vídeo.
A Figura 1(b) apresenta o desempenho da rede com relação a métrica ICO.
Observa-se uma degradação do ICO à medida que a porcentagem de nós nãocooperativos aumenta. Assim como na métrica anterior, o melhor desempenho também
foi para a rede sem nós não-cooperativos. O ICO para o melhor caso é de 0,99, ou seja,
em 20 min de reprodução de vídeo houve em média 12 seg de interrupção. Já para o
pior caso, que também corresponde a rede com 20% de nós não-cooperativos, o ICO é
igual a 0,95, ou seja, média de 60 seg de interrupção. Para esta situação verifica-se uma
diferença de 4 pontos percentuais.
O melhor desempenho da métrica ICO para os nós não-cooperativos era
esperado, pois como os mesmos não perdem tempo no estado push, trocando de
imediato para o estado pull, tendem a preencher mais rapidamente os “buracos” do seu
buffer de reprodução, desde que, possuam nós cooperativos como seus vizinhos.
Tempo (seg)
Qualidade do Sistema (Q)
Q
90
0,99
Nós C
0,98
Nós NC
0,97
85
80
75
Ativação e atraso inicial
A tivação Nós C
A traso Nós C
A tivação Nós NC
A traso Nós NC
70
0,96
65
0,95
60
0,94
55
50
0,93
45
0,92
40
0,91
35
0,9
30
0%
5%
10%
15%
20%
0%
5%
10%
15%
20%
Figura 2. Desempenho: (a) qualidade do sistema de vídeo e (b) atraso inicial
A Figura 2(a) apresenta o desempenho da rede com relação a métrica qualidade
(Q). Percebe-se que o comportamento dos nós não-cooperativos e cooperativos ficam
praticamente iguais. Além disso, ocorre uma degradação da qualidade à medida que a
porcentagem de nós não-cooperativos aumenta, conforme ocorreu com as métricas
anteriores. O melhor Q é de 0,97, ou seja, de 120 pedaços apenas 3,6 pedaços chegaram
atrasados em cada nó. No pior caso, novamente quando a rede possui 20% de nós nãocooperativos, o Q obtido é de 0,95, isto é, de 120 pedaços em média 6 pedaços
chegaram atrasados em cada nó. Neste caso, houve uma perda de 2 pontos percentuais.
A Figura 2(b) apresenta o desempenho para o atraso inicial. Para analisar esta
métrica, decidimos inserir também o comportamento do tempo de ativação dos nós, pois
como discutido anteriormente, o nó só começa a participar da rede de forma efetiva
apenas após receber o primeiro pedaço, a partir daí o nó pode solicitar e enviar pedaços.
Por isso, acreditávamos que o tempo de ativação influenciava a métrica atraso inicial, só
não sabíamos o quanto.
27
O gráfico da Figura 2(b) possui quatro grupos de barras: cinzas e brancas,
correspondem ao desempenho dos nós cooperativos e não-cooperativos com relação à
métrica ativação; barra hachuradas horizontalmente e hachuradas com ângulo de 45 o
correspondem ao desempenho dos nós cooperativos e não-cooperativos, com relação ao
atraso inicial, respectivamente.
Percebe-se que o desempenho das redes com relação a esta métrica vai se
degradando à medida que a porcentagem de nós não-cooperativos aumenta. As curvas
dos nós cooperativos e não-cooperativo são muito similares. O melhor valor para tempo
de ativação fica próximo a 40 seg. e o pior caso, com 20% de nós não-cooperativos,
próximo a 50 seg, ou seja, uma diferença de 10 seg. O melhor valor para o atraso inicial
fica próximo a 70 seg. e o pior valor próximo a 82 seg, uma diferença de 12 seg.
Pode ser notado que o tempo de ativação de um nó é responsável por mais da
metade do atraso inicial do mesmo, o que é muito representativo. Seria de interesse
estudar modificações no mecanismo de ativação do nó para otimizar o atraso inicial.
Vale a pena comentar outros dois pontos observados durante as simulações.
Com valores mais altos para porcentagem de nós não-cooperativos, como 50% por
exemplo, a simulação fica impraticável, pois vários nós sequer são ativados, além do
desempenho das redes ficar bastante degradado. Além disso, em alguns casos, ocorreu
de nós cooperativos não ativarem, o que é um ponto bastante negativo.
6. Controle de admissão
Na segunda parte das simulações introduziu-se um mecanismo de controle de admissão
de vizinhos na formação do grafo, onde nós cooperativos possam selecionar vizinhos
cooperativos e rejeitar vizinhos não-cooperativos. A idéia básica é a de criar um
mecanismo que possibilite o nó fazer sua escolha baseada em uma reputação prévia do
nó candidato a vizinho, neste caso, ou um nó cooperativo ou um nó não-cooperativo,
tornando a seleção de vizinhos menos aleatória.
No simulador utilizamos o atributo criado anteriormente que identificava se o nó
é cooperativo ou não-cooperativo. Para cada nó cooperativo foi criado um contador de
vizinhos não-cooperativos utilizado na rotina de formação do grafo. Também foi
definido um parâmetro para especificar a % máxima de nós não-cooperativos que um nó
cooperativo está disposto a aceitar. Quando este contador atinge um determinado limiar,
o nó cooperativo passa a rejeitar nós não-cooperativos como vizinhos. Repetimos as
mesmas simulações, mantendo-se os parâmetros apresentados na Tabela 1 e as métricas
usadas na primeira etapa para comparar os resultados.
6.1. Resultados
Para permitir a comparação com os resultados da primeira etapa, apenas apresentaremos
os gráficos referentes à simulação com 15% de nós não-cooperativos na rede, com
distribuição de 120 pedaços. O trabalho [Lima, 2010] apresenta os outros resultados.
O eixo y dos gráficos das Figuras de 3 a 4 representam as médias das métricas
obtidas pela rede com um intervalo de confiança de 90%, já o eixo x representa a
porcentagem máxima de nós não-cooperativos permitidos na lista de vizinhos de cada
nó cooperativo.
Cada gráfico possui quatro grupos de blocos, o grupo de blocos cinzas
corresponde ao desempenho dos nós cooperativos; já o grupo de blocos brancos
28
Anais
corresponde ao desempenho dos nós não-cooperativos ambos com o mecanismo (nós C
e nós NC - CM); os grupos com barras hachuradas horizontalmente e com barras
hachuradas com ângulo de 45 graus correspondem ao desempenho dos nós cooperativos
e não-cooperativos respectivamente, sem o mecanismo (nós C e nós NC - SM).
A Figura 3(a) apresenta o desempenho da rede com relação ao tempo máximo.
Observa-se que para uma configuração com 10% de vizinhos não-cooperativos, o tempo
máximo para nós maliciosos aumentou em comparação com as simulações anteriores
sob mesmas condições, ou seja, uma rede com 15% de nós maliciosos como um todo. O
tempo máximo ficou próximo a 24,5±1,5 min, ao passo que nas simulações sem
mecanismo o valor era próximo a 21 min. Percebeu-se, não só neste cenário, mas nos
demais também, que a variação foi pequena em termos gerais, entretanto com uma
punição considerável para os nós não-cooperativos, para limiares baixo de admissão.
Tempo Máximo
Nós C – CM
Nós C – SM
25
Nós NC – CM
Nós NC – SM
24
Tempo Máximo (min)
Índice de continuidade (ICO)
ICO
26
1,00
Nós C – CM
Nós C – SM
0,99
Nós NC – CM
Nós NC – SM
0,98
23
0,97
22
0,96
21
0,95
20
0,94
0,93
19
10%
20%
30%
10%
50%
20%
Vizinhos não-cooperativos
30%
50%
Figura 3. Desempenho: (a) tempo máximo e (b) índice de continuidade
No gráfico da Figura 3(b) podemos visualizar a curva da métrica ICO.
Verificam-se que os nós não-cooperativos continuaram tendo melhor desempenho em
comparação com nós cooperativos. Entretanto, podemos notar que a rede como um todo
obteve uma melhora com a adição do mecanismo de admissão.
Qualidade do sistema (Q)
Q
0,99
Nós C – CM
Nós C – SM
Nós NC – CM
Nós NC – SM
0,98
Tempo (seg)
90
Atraso inicial
Nós C – CM
Nós C – SM
Nós NC – CM
85
Nós NC – SM
80
0,97
75
70
0,96
65
0,95
60
0,94
55
0,93
50
45
0,92
40
0,91
35
0,9
30
10%
20%
30%
50%
10%
20%
30%
50%
Figura 4. Desempenho: (a) qualidade do sistema de vídeo e (b) atraso inicial
A Figura 4(a) mostra que não houve melhora substancial na qualidade de vídeo
com a adição do mecanismo de admissão. A Figura 4(b) apresenta o desempenho da
rede sob o ponto de vista da métrica atraso inicial. Aqui notamos que há momentos em
que os nós não-cooperativos são punidos e os nós cooperativos beneficiados.
29
Na Figura 4(b), para porcentagem de vizinhos igual a 10%, o atraso inicial dos
nós cooperativos próximo a 77±2 seg, e dos nós não-cooperativos próximo a 85±3 seg.
Sem o mecanismo, o atraso inicial para os nós cooperativos ficou próximo a 80 seg e
para os nós não-cooperativos próximo a 78 seg, resultado que pode ser considerado uma
melhora para os nós cooperativos e uma punição para os nós não-cooperativos.
7. Conclusão
O presente trabalho investigou como nós não-cooperativos afetam a qualidade da
aplicação de distribuição de fluxos de vídeo em redes P2P que fazem uso de protocolos
de difusão de pedaços push/pull [Cigno, 2008] onde co-existem nós cooperativos e não
cooperativos. Utilizamos o simulador PeerSim e o módulo P4S, fazendo alterações e
acréscimos necessários para incluir os aspectos sendo investigados.
Os resultados comprovaram que o desempenho da aplicação tende a diminuir à
medida que a porcentagem de nós não-cooperativos aumenta. Observamos, também,
que em geral os resultados dos nós não-cooperativos foram melhores do que os
resultados dos nós cooperativos, ressaltando um outro lado do problema. Além disso,
alguns nós cooperativos não foram ativados em algumas rodadas de simulação.
Com a adição de um mecanismo de seleção inicial dos vizinhos, o desempenho
da aplicação melhorou para até 20% de nós não-cooperativos na lista de vizinhos dos
nós cooperativos. A distribuição de nós não-cooperativos tornou-se mais homogênea,
não sobrecarregando um nó cooperativo. Não se observou mais o problema de nós
cooperativos não serem ativados. Este fenômeno ocorreu apenas com os nós nãocooperativos, o que funciona como um mecanismo de punição. Entretanto, o controle de
admissão não conseguiu solucionar um problema: o fato de nós não-cooperativos
ativados continuarem tendo melhores resultados do que nós cooperativos. Este
problema está relacionado ao fato da formação do grafo ser estático. Desta forma, o
bom desempenho dos nós fica condicionado à formação inicial do grafo.
Assim, estamos trabalhando em uma proposta de mecanismo dinâmico de
atualização da lista de vizinhos de cada nó, a fim de introduzi-lo no simulador e estudar
seus efeitos. Acreditamos que este mecanismo proporcionará o efeito de justiça
desejado, introduzindo uma punição aos nós não-cooperativos que, ao longo da
execução da aplicação, vão estar ligados a menos nós cooperativos, tendo a qualidade
do vídeo recebido degradada. Isso serviria de incentivo para o nó não-cooperativo
mudar seu comportamento.
Além do trabalho iniciado, um estudo do desempenho do protocolo push/pull na
presença de nós não-cooperativos com gradações diferentes é considerado. Por
exemplo, um nó poderia ser muito, pouco ou mediamente não-cooperativo.
Adicionalmente o comportamento do estado pull ou até mesmo os dois estados ao
mesmo tempo poderiam ser modificados e avaliados. Neste último caso, um nó com
esta característica seria muito nocivo à rede, já que não contribuiria de maneira alguma.
Por fim, um outro ponto de investigação é o tamanho ideal do pedaço para
manter uma boa relação entre as métricas índice de continuidade e atraso inicial, pois
pedaços pequenos podem acarretar em atraso inicial pequeno, mas desempenho pobre
com várias pequenas interrupções. Já pedaços grandes podem acarretar em atraso inicial
alto, mas um bom desempenho ao longo da reprodução.
Agradecimento. Os autores agradecem o apoio parcial da FAPERJ.
30
Anais
Referências
ADAR, E., HUBERMAN, B.. “Free riding on Gnutella”. First Monday. Vol. 5, No.10. Outubro,
2000.
CARLSSON, N., EAGER, D. “Peer-assisted on-demand streaming of stored media using
BitTorrent-like protocols”. IFIP-Tc6, Maio, 2007.
CIGNO, R., RUSSO, A., CARRA, D. “On Some Fundamental Properties of P2P Push/Pull
Protocols”, HUT-ICCE 2008, pp. 67-73, Junho, 2008.
COSTA, C., CUNHA, I., BORGES, A. “Analyzing client interactivity in streaming media”. 13 th
ACM Int. Conf on WWW, Maio 17 - 20, 2004.
HABIB, A., CHUANG, J., “Incentive mechanism for peer-to-peer media streaming”. IWQOS
2004, pp. 171-180, Junho, 2004.
HALES, D. E., PATARIN, S. “Computacional sociology for system in the wild: the case of
BitTorrent”, IEEE Distributed Systems Online, 2005.
HOONG, P. K., MATSUO, H. “Push-Pull Incentive-based P2P Live Media Streaming System”.
WTOC 7, 33-42, Fevereiro, 2008.
LIMA, F. M, “Análise de desempenho de redes p2p com protocolo “push/pull” para distribuição
de vídeo na presença de nós não-cooperativos”, Dissert. de Mestrado, UERJ, Agosto, 2010.
LOCHER, T., MEIER, R., SCHMID, S. et all. “Push-to-Pull Peer-to-Peer Live Streaming”. 21st
Int. Symp. on Distributed Computing (DISC). Setembro, 2007.
MARTI, S., GIULI, T. J., LAI, K., BAKER, M. “Mitigating routing misbehavior in mobile ad
hoc networks”. 6th International Conference on Mobile Computing and Networking, 2000.
MORAES, I., CAMPISTA, M., MOREIRA, et al. “Distribuição de Vídeo sobre Redes Par-aPar: Arquiteturas, Mecanismos e Desafios”. Minicurso, Cap. 3, SBRC. Maio, 2008.
MORAES, I.. “Distribuição de vídeo sobre redes par-a-par”, Tese de Doutorado, COPPE
Elétrica, UFRJ. Dezembro, 2009.
P4S. “P4S: P2P 4 Streaming System”, http://www.dit.unitn.it/networking/P4S-main.html.
[04/2010].
PAI, V., KUMAR, K., TAMILMANI, K., et al. “Chainsaw: Eliminating Trees from Overlay
Multicast”. IPTPS. February, 2005.
PEERSIM. “PeerSim: A Peer-to-Peer Simulator”, http://peersim.sourceforge.net/. [04/2010]
PIANESE, F., KELLER, J., BIERSACK, W. “PULSE, a Flexible P2P Live Streaming System”.
IEEE Global Internet Symposium. Abril, 2006.
SANGHAVI, B.S., HAJEK, B., MASSOULIE, L. “Gossiping with multiple messages”. IEEE
INFOCOM 2007. Dezembro, 2007.
SAROIU, S., GUMMADI, K. P., et al, “Measuring and analyzing the characteristics of Napster
and Gnutella hosts”. Multimedia Systems, No.9, pp.170-184, Springer. Agosto, 2003.
SUNG, Y., BISHOP, M., RAO, S. “Enabling Contribution Awareness in an Overlay
Broascasting System”. SIGCOMM. Setembro, 2006.
TRAN, D. A., HUA, K. A., DO, T. T. “ZIGZAG: An efficient peer-to-peer scheme for media
streaming”. IEEE INFOCOM 2003. Vol. 2, pp. 1283-1292, 2003.
TRAN, D. A., HUA, K. A., DO, T. T. “A Peer-to-Peer Architecture for Media Streaming”.
IEEE JSAC. Vol. 22, No.1, pp. 121-133, Janeiro 2004.
VENKATARAMAN, V., FRANCIS, P. “Chunkyspread: Multi-tree Unstructured Peer-to-Peer
Multicast”. IPTPS. Fevereiro, 2006.
XINYAN, Z., JIANGCHUAN, L., et al., “CoolStreaming/DONet: A Data-driven Overlay
Network for Peer-to-Peer Live Media Streaming”. INFOCOM. Vol.3, pp.2102-2111, 2005.
31
PlanetMon: Um Arcabouço para Execução e
Monitoração de Experimentos no Planet-Lab
Vinicius K. Ruoso, Luis C. E. De Bona, Elias P. Duarte Jr.
1
Departamento de Informática – Universidade Federal do Paraná (UFPR)
Caixa Postal 19.081 – 81531-980 – Curitiba – PR – Brasil
{vkr07,bona,elias}@inf.ufpr.br
Abstract. Testbeds are platforms for executing large-scale experiments. PlanetLab is one of the largest testbeds available worldwide. Executing an experiment
on Planet-Lab, and evaluating results is laborious process. In order to make
this task simpler, this paper presents a framework to configure, implement and
monitor experiments on Planet-Lab. Through a portal and a API, the researcher
can manage and monitor the experiment execution. In particular, the system has
a graphical interface that allows the virtual topology created by the application
to be visualized. Experimental results are presented, including the execution of
Pastry on nodes spread in three continents.
Resumo. Os testbeds são plataformas para experimentação de grandes projetos em desenvolvimento. O Planet-Lab é um dos maiores testbeds disponı́veis
no mundo. Realizar experimentos no Planet-Lab e analisar dados sobre sua
execução é um processo trabalhoso. Visando tornar tal tarefa mais simples, este
trabalho apresenta um arcabouço para configurar, executar e monitorar experimentos no Planet-Lab. Através de um portal e uma API, o pesquisador pode
controlar e monitorar a execução de sua aplicação. Em particular, o sistema
tem uma interface gráfica que permite visualizar a topologia virtual criada pela
aplicação. Resultados experimentais são apresentados, incluindo a execução
do Pastry em nodos de três continentes.
1. Introdução
As aplicações e sistemas baseados em rede têm uma grande importância para indivı́duos e
comunidades. A necessidade de desenvolvimento de novas tecnologias e aplicações para
redes, em particular a Internet, é constante. Para avaliar essas aplicações é necessário
realizar experimentos em uma infraestrutura de rede que reflita o ambiente real de uso. O
Planet-Lab [Peterson et al. 2002] é uma plataforma global para instalar e avaliar serviços
de redes. Ele já foi usado para avaliar uma grande diversidade de serviços de escala planetária, incluindo distribuição de conteúdos, anycast, DHTs (Distributed Hash Table),
serviços de DNS (Domain Name System) robusto, distribuição de arquivos em larga escala, diagnóstico de falhas e anomalias, e notificação de eventos.
A arquitetura do Planet-Lab baseia-se na estrutura de nodos, sites e slices
[Planet-Lab User Guide 2010]. Um nodo é um servidor dedicado que executa componentes dos serviços do Planet-Lab. Os sites são locais fı́sicos onde nodos do Planet-Lab
estão localizados, em geral universidades e grandes organizações. Um slice é um conjunto
de recursos alocados distribuı́dos pelo Planet-Lab. Para os usuário isto significa acesso
32
Anais
via um terminal virtual remoto seguro (Secure Shell - SSH [OpenSSH 2010]) a um conjunto de nodos. Estas máquinas contam com vários aplicativos padrão, porém o suporte à
compilação e à execução, por exemplo a linguagem Java, não é nativo.
Como o Planet-Lab é composto por nodos de todos os continentes, ocorrem vários
problemas, como a presença de falhas permanentes, temporárias e intermitentes nos nodos, problemas de conexão, e timeout devido à alta latência. Tendo isso em vista, fazer
o deploy da aplicação, instalar o ambiente de execução (i.e. suporte à linguagem, bibliotecas, etc.), inicializar o experimento e coletar informações, são tarefas trabalhosas. Em
particular, a maior dificuldade é realizar tais operações em centenas de nodos.
Após a realização de um experimento, o pesquisador deve coletar informações sobre sua execução e analisá-las como um todo. Fazer o cruzamento destes dados empı́ricos
não é uma tarefa simples, e é possı́vel não chegar a uma conclusão relevante ao final do
processo. Em caso de aplicações que criam um overlay sobre a rede, visualizar a topologia
virtual criada facilita o trabalho de analisar o comportamento da execução do algoritmo.
Realizar um experimento é um processo que demanda muito esforço e tempo por
parte de um pesquisador. Contornar todos os problemas encontrados e analisar os dados
de seu experimento é uma tarefa difı́cil. Visando aumentar a produtividade de um pesquisador ao realizar tais experimentos, criamos um arcabouço para execução e monitoramento de experimentos, em particular para a geração de mapas de topologias virtuais. Existem
ferramentas disponı́veis no sı́tio do Planet-Lab para realizar algumas destas tarefas, por
exemplo o [CoDeploy 2010], [Nixes 2010] e [ParallelSSH 2010], porém nenhuma delas
oferece uma solução para todos os problemas citados.
O arcabouço criado, chamado PlanetMon, permite realizar as tarefas essenciais
para a execução de um experimento no Planet-Lab, incluindo o deploy da aplicação, a
instalação do ambiente de execução e a coleta de dados. Além disso, é possı́vel monitorar o comportamento dos nodos durante a execução do experimento, visualizando a
topologia virtual criada através de um mapa. Os nodos utilizam uma API para realizar a
comunicação com um gerador de mapas de topologias. Analisar o mapa de execução de
uma aplicação de forma visual e em tempo real é mais simples do que recuperar arquivos
de logs e cruzar informações. Este mapa corresponde ao grafo que representa a topologia
virtual criada; nodos do sistema são vértices e arestas correspondem a uma interação entre os nodos. A API permite que o usuário associe sentido à uma interação entre nodos,
sendo possı́vel personalizar sua cor, opacidade e espessura. Por exemplo, uma aresta pode
significar uma conexão entre os vértices.
O arcabouço é disponibilizado como um portal que permite o pesquisador enviar
sua aplicação e configurar seus parâmetros de execução, informar qual o seu slice e em
quais nodos o experimento deve ser executado, e efetivamente executar seu experimento.
No mesmo momento que se prepara o ambiente de execução, a API do PlanetMon também
é instalada.
Para validar o sistema foi criado uma aplicação que cria uma topologia em
formato de estrela. Também, foram realizados experimentos utilizando o Pastry
[Rowstron and Druschel 2001], uma plataforma para desenvolvimento de sistemas P2P
(Peer-to-Peer).
O restante deste artigo está organizado da seguinte maneira. A seção 2 demonstra
33
as caracterı́sticas do arcabouço. A seção 3 mostra o gerador de topologias virtuais em detalhes. A seção 4 apresenta os experimentos realizados para validação e testes do sistema.
Por fim, a seção 5 conclui o trabalho.
2. O Arcabouço
Com a intenção de facilitar o processo de execução de um experimento nós definimos um
arcabouço, composto por uma API e um gerador de mapas de topologias. Ele é capaz de
instalar e preparar o ambiente de execução da aplicação. Também é possı́vel controlar a
execução do experimento em cada nodo, assim como em conjuntos de nodos. Visualizar
a topologia gerada pela aplicação é outro serviço oferecido que permite a avaliação em
tempo de execução do experimento.
O arcabouço é disponibilizado na forma de um portal Web, acessı́vel em
http://planetmon.inf.ufpr.br. O portal, desenvolvido em Ruby on Rails, recebe do usuário
todas todas as informações necessárias sobre o ambiente de execução da aplicação. Além
disso, o sistema é configurado para preparar todos os nodos e disparar o experimento.
Durante a execução do experimento, o portal é responsável por coletar as informações da
topologia virtual e oferecer um mapa para sua visualização. Assim o foco de um pesquisador ao realizar testes utilizando esta plataforma é a sua própria aplicação.
Um script capaz de recuperar dados sobre o Planet-Lab é executado de tempos em
tempos para atualizar o banco de dados de sites e nodos disponı́veis. Além disso, o portal
possui um sistema de login que permite que cada pesquisador tenha acesso a um ambiente
exclusivo.
Figura 1. Visualização da página principal do portal.
A figura 1 mostra a tela principal do portal, após efetuado login. É possı́vel visualizar as abas disponı́veis, que são: Dashboard, Application, Slice, SDI Control, Map
e Settings. Algumas abas são responsáveis pela configuração do uso do portal, enquanto
outras estão ligadas ao controle de execução do experimento e visualização de resultados.
Na aba Dashboard estão algumas informações sobre o portal e sobre a quantidade
de nodos e sites disponı́veis para utilização, assim como estatı́sticas do servidor do portal
e dicas de utilização do mesmo. Por outro lado, a aba Settings permite que o usuário
configure suas informações, incluindo sua senha de acesso e endereço de email e, ou
exclua a sua conta do portal.
A aba Application requisita informações sobre a aplicação a ser executada. Para
isso é necessário descrever qual será o ambiente de execução utilizado, assim como o
modo em que a API do PlanetMon será utilizada. A API do PlanetMon é responsável por
reportar a situação da topologia virtual. Existem algumas maneiras de utilizar esta API,
34
Anais
as quais são detalhadas na subseção 3.1. Também é necessário enviar a aplicação em si,
empacotada em um arquivo tar, automaticamente extraido após o deploy em cada nodo.
Na aba Slice é necessário que o pesquisador informe o nome de seu slice, assim
como em quais nodos o experimento deve ser executado. Isso é necessário para que
o sistema possa se conectar aos nodos que fazem parte do experimento. Outro passo
importante que deve ser feito nesta aba é o download da chave pública criado para cada
usuário. Esta chave deve ser inserida no sı́tio do Planet-Lab, finalizando as configurações
necessárias para que o portal tenha possibilidade de executar o experimento.
Controlar o experimento é uma tarefa importante para o usuário, a qual pode ser
realizada na aba SDI Control. O sistema, ao ser iniciado, automaticamente instala as dependências necessárias e envia a aplicação para execução. Após isso, o usuário dispara o
processo de execução de seu experimento. Este processo pode ser interrompido a qualquer momento em qualquer nodo, eliminando toda a execução do experimento no nodo
em questão. Também é possı́vel enviar comandos para um conjunto de nodos que fazem
parte do experimento. Detalhes sobre os processos de instalação a execução do experimento podem ser vistos e controlados pelo usuário, tornando a experiência de controlar
sua execução mais simples.
O portal oferece a possibilidade de visualizar detalhes sobre a execução do experimento e do gerador de mapas de topologias virtuais. Para isso, na aba SDI Control
existe a possibilidade de observar o processo de execução do experimento, através da
visualização da página de infomações dos nodos. A figura 2 mostra esta visualização durante a execução de um experimento. As colunas Java Installation, Application deploy,
Stats e Application status correspondem ao estado da instalação do ambiente Java, ao estado da instalação da aplicação, ao estado da instalação da API do PlanetMon, e ao estado
da execução da aplicação, respectivamente.
Figura 2. Exemplo de visualização do SDI.
A visualização do resultado da utilização do gerador de mapas tolopologias virtuais fica disponı́vel na aba MAP do portal. A figura 3 apresenta um exemplo desta
visualização durante a execução de um experimento. As alterações realizadas na topologia através da API do PlanetMon são refletidas em tempo real pelo mapa disponı́vel no
portal. Os nodos são representados por pontos, e uma interação entre eles é representada
como uma reta ligando ambos. Esta reta pode ser personalizada para refletir uma situação
da aplicação, assim como a cor dos pontos dos nodos.
3. Gerador de Mapas de Topologias
O Gerador de Mapas de Topologias desenvolvido neste trabalho permite monitorar o comportamento dos nodos durante a execução de uma aplicação, através de uma mapa. Os
35
Figura 3. Exemplo de visualização do mapa dentro do portal.
nodos utilizam uma API para realizar a comunicação com o gerador de mapas. O mapa
corresponde ao grafo que representa a topologia virtual criada; nodos do sistema são
vértices e arestas correspondem a uma interação entre os nodos. As arestas deste mapa
podem representar, por exemplo, conexões entre nodos. Entretanto podem ter significados
distintos para cada aplicação executada, assim como suas cores, opacidade e espessura.
A figura 4 apresenta a arquitetura adotada para o gerador de mapas de topologias
virtuais. Um servidor central, chamado monitor, monitora todos os nodos do Planet-Lab
que fazem parte de um ambiente de execução. Em cada nodo existe uma aplicação e a API
do PlanetMon sendo executados. No momento em que a API é acionada pela aplicação
do usuário, mensagens são enviadas através de uma conexão com o monitor, quer repassa
tais informações para o gerador de mapas. O gerador de mapas as processa e atualiza o
mapa propriamente dito. A cada mensagem recebida o gerador se encarrega de atualizar
as informações recebidas no mapa em si. Estas operações são realizadas sobre arquivos
XML (eXtensible Markup Language) [RFC Editor 2001] que são utilizados pela interface
de visualização.
O gerador de mapas de topologias faz a monitoração de experimentos utilizando o
Sistema de Diagnóstico Instantâneo (SDI [Ribas et al. 2009]). O SDI provê um modo de
executar scripts de diagnóstico e qualquer outro tipo de script em uma rede ou na Internet,
e cria páginas Web contendo informações sumarizadas. O SDI também é capaz de indentificar de qual nodo cada mensagem é originada, tornando as mensagens geradas pela API
mais simples. Portanto, cada mensagem é composta apenas de uma ação (adicionar, remover e atualizar), um nodo (identificado pelo seu nome ou endereço IP) e os atributos
da ligação entre eles, visto que o nodo de origem não é necessário nestas mensagens.
Além do SDI, que é utilizado em todas as comunicações que ocorrem entre o
arcabouço e os nodos do Planet-Lab, o arcabouço utiliza a API Central do Planet-Lab
[PLCAPI 2010] e a API do Google Maps [Google Maps API 2010].
A partir da API Central do Planet-Lab é possı́vel extrair certos dados sobre os
sites e nodos disponı́veis. Além disso, é possı́vel obter as coordenadas geográficas de
cada site, tornando possı́vel a visualização da rede em um mapa. De acordo com esta
API, foi possı́vel resgatar as informações de 1087 nodos em 513 sites. A distribuição dos
nodos dentre os sites, que pode ser visto na tabela 1, demonstra que a maioria dos nodos
não estão concentrados em alguns grandes sites.
36
Anais
Figura 4. Arquitetura do Gerador de Mapas de Topologias Virtuais.
Para efetivamente termos uma interface gráfica de visualização dos mapas das topologias virtuais criadas no Planet-Lab, utilizamos a API do Google Maps. Esta API oferece uma grande quantidade de recursos para criar overlays (desenhos e sı́mbolos) sobre
um mapa. Dentre eles, utilizamos pontos para representar nodos e linhas para representar
ligações, das quais é possı́vel personalizar a cor, opacidade e espessura.
Tabela 1. Distribuição dos nodos do Planet-Lab através de seus sites.
Número de nodos = N
1
2
3
4
5
6
7
9
11
14
16
17
Sites com N nodos
8
315
37
31
10
10
3
1
1
1
2
1
As aplicações utilizadas nos experimentos devem ser capazes de se comunicar
com o gerador de mapas de topologia. A API do PlanetMon foi criada para isso. Ela
provê uma interface simples de implementar em qualquer aplicação e envia mensagens
para o monitor contento tais informações.
37
Tabela 2. API do PlanetMon.
Método
addnode(node)
removenode(node)
updateattrs(node,attributes)
startwave()
endwave()
Ação
Adiciona uma ligação com o nodo node.
Ex. addnode(’planetlab1.c3sl.ufpr.br’)
Remove a ligação com o nodo node.
Ex. removenode(’200.17.202.194’)
Atualiza os atributos da ligação com o nodo node.
Ex. updateattrs(’planetlab1.c3sl.ufpr.br’,
{’mycolor’: ’blue’, ’opacity’: 0.8})
Inicia uma nova onda.
Finaliza a onda atual.
3.1. API do PlanetMon
A API do PlanetMon é utilizada para interagir com o monitor dos nodos, ou seja, para
monitorar as topologias virtuais. A API provê operações para manipular todos os atributos
relacionados a uma interação entre nodos e, ainda, a inserção e exclusão de nodos de
modo dinâmico. Vale também notar que esta API é executada em cada nodo monitorado,
e cada um deles envia mensagens ao monitor relatando quais suas interações e atributos
correspondentes. A cada mensagem um nodo informa com qual nodo está interagindo,
além dos atributos desta interação. É considerado que um nodo pode ser representado
tanto pelo seu nome quanto pelo seu endereço IP.
A API funciona com base em um arquivo criado localmente. A tarefa da API é
essencialmente escrever mensagens neste arquivo. Tais modificações são enviadas para
o monitor através de sua conexão, refletindo tal operação no mapa da topologia virtual.
Existem três maneiras de utilizar a API do PlanetMon.
A primeira maneira é através de uma inclusão de biblioteca. No caso, a API foi
implementada em Python, por isso apenas programas nesta linguagem podem utilizar a
API desta maneira. Para sua utilização é necessário criar uma classe, e utilizar os métodos
definidos nela. A API se encarega de realizar quaisquer outras operações necessárias para
o funcionamento do gerador de mapas. Os métodos definidos são exibidas na tabela 2.
Outra maneira é utilizar a API é através um daemon que recebe mensagens via
sockets. Assim, qualquer linguagem que tenha suporte à sockets pode ser utilizada para
interagir com a API. Este daemon, escrito em Python, se comunica com a API através
do modo citado anteriormente. Como a utilização de sockets é especı́fica para linguagens
diferentes de Python, o formato das mensagens utilizadas é diferenciada. Este formato é
descrito na tabela 3, assim como os métodos que tais mensagens correpondem.
Ainda existe uma outra forma de utilização da API do PlanetMon: através de um
script automático de monitoração do estado das conexões da rede. Este script utiliza
o comando netstat para obter tais informações, e as repassa para a API. O netstat é o
comando padrão para mostrar informações sobre as comunicações de rede de um nodo
no Planet-Lab. Os métodos citados anteriormente permitem que o usuário tenha mais
controle sobre o que o gerador de topologias irá desenhar, o que não é o caso quando se
utiliza o monitor de conexões.
38
Anais
Tabela 3. API do PlanetMon via sockets.
Mensagem
ADD+node+
REM+node+
UPDATEATTRS+node+attributes
STARTWAVE++
ENDWAVE++
Método associado
addnode(node)
removenode(node)
updateattrs(node,attributes)
startwave()
endwave()
Ao utilizar o método updateattrs os atributos a serem atualizados devem ser passados no formato de um dicionário. As chaves aceitas são: mycolor (cor do nodo em si,
especificada em texto); color (cor da ligação entre os nodos, especificada em formato hexadecimal); opacity (opacidade da ligação entre os nodos, numérico entre 0 e 1) e weight
(grossura da ligação entre os nodos, numérico).
Não necessariamente é preciso que a API retorne informações apenas das conexões atuais dos nodos. Em termos de visualização, uma conexão é representada por
uma linha entre dois pontos, porém a semântica desta linha pode ser diferente para diferentes tipos de aplicações ou para cada estratégia de monitoramento da execução. Por
exemplo, pode-se definir que linhas azuis significam que um nodo está pedindo um arquivo para outro, e que linhas verdes signifiquem que o pedido foi aceito, entre outras
diversas possibilidades. Assim como as ligações entre os nodos, os nodos em si podem
ter suas cores alteradas, atribuindo cores para cada situação em que o nodo se encontra
(conectando, perguntando, recebendo, etc). A API é flexı́vel para permitir uma grande
possibilidade de experiências de uso.
É possı́vel utilizar a API do PlanetMon através do conceito de ondas. A figura
5 demonstra um exemplo desta utilização. Cada onda é equivalente a uma leitura de um
estado, composto por um conjunto de nodos. Na caixa “Estado 1” os nodos A,B,C,D,E
e F foram adicionados utilizando o método addnode. Estes nodos pertencem a uma onda
pois foram adicionados entre a chamada dos métodos startwave e endwave. A cada novo
nodo inserido uma mensagem é enviada para o gerador de mapas. Na caixa “Estado 2”,
correspondente a uma nova onda, os nodos A,D,E e F foram adicionados. No momento
em que o método endwave é chamado, automaticamente são geradas mensagens para
remover aqueles nodos que estavam em uma onda anterior e que não estão na onda atual.
Este comportamento é importante para aplicações que têm apenas informações sobre o
estado atual, dispensando o tratamento de caches para remoção de nodos. O script de
monitoração das conexões de rede utiliza este conceito.
4. Resultados Experimentais
Para validar o gerador de mapas de topologias virtuais foram executados experimentos
com duas aplicações: o Free Pastry, além de uma aplicação cliente-servidor que cria
uma topologia em forma de estrela. A subseção 4.1 apresenta os resultados obtidos com
a execução da aplicação que cria uma topologia em forma de estrela. Na subseção 4.2
o funcionamento e os resultados da execução do Free Pastry são mostrados. Todos os
outros componentes do arcabouço foram testados durante estes experimentos, incluindo
o deploy, a instalação e configuração do ambiente de execução. Utilizando o portal, tais
operações foram realizadas de uma maneira simples.
39
Figura 5. Conceito de Ondas.
4.1. Validação do Monitor de Topologias Virtuais
A aplicação cliente-servidor desenvolvida para criar uma topologia em forma de estrela
foi escrita em Python e utiliza a API do PlanetMon incluı́da como um módulo. Um servidor aguarda conexões de candidatos a vértices da estrela, os quais enviam sua latitude e
longitude ao se conectar. Após receber cinco requisições, o servidor envia para os clientes sua posição na estrela e os endereços de cada nodo da topologia. Assim que o cliente
recebe estas informações, a API é utilizada para refletir a situação no mapa. Nodos que se
conectam ao servidor posteriormente à criação da estrela, são ignorados. O resultado da
execução deste experimento pode ser visto na figura 6. A execução ocorreu como esperado, visto que o mapa refletiu a topologia criada pela aplicação. Foram utilizados todos
os nodos disponı́veis no momento na região dos Estados Unidos da América.
Figura 6. Exemplo de execução da aplicação que gera uma topologia em forma
de estrela.
4.2. Pastry: Uma Plataforma P2P
O Pastry [Rowstron and Druschel 2001] é uma plataforma escalável para localização descentralizada de objetos e roteamento para sistemas P2P de larga escala. Uma rede P2P
pode ser caracterizada como um sistema distribuı́do no qual cada nodo tem iguais capacidades e responsabilidades. Caracterı́sticas das redes P2P incluem controle descentralizado, auto-organização, adaptação e escalabilidade. Aplicações P2P na Internet foram
popularizadas através de softwares de compartilhamento de arquivos.
Um sistema Pastry é uma rede overlay auto-organizável de nodos, onde cada nodo
faz roteamento de requisições de clientes e interage com instâncias locais de uma ou mais
40
Anais
aplicações. Cada nodo que faz parte da rede criada pelo Pastry recebe um nodeId. O
nodeId é usado para indicar a posição do nodo em um espaço de nodeIds circular. Este
identificador é atribuı́do randomicamente quando um nodo entra na rede. O Pastry assume
que este número aleatório é gerado de forma uniforme.
Assumindo uma rede de N nodos, o Pastry faz o roteamento entre eles em menos
de dlog2b N e (b é um parâmetro de execução com valor tı́pico 4) em operação normal.
Um nodo que executa o Pastry contém um neighborhood set, um leaf set e uma tabela
de roteamento. Um neighborhood set M contém os |M | nodeIds e o endereço IP dos
nodos que estão mais próximos (de acordo com a métrica de proximidade) do nodo local.
Este conjunto geralmente não é utilizado no processo de roteamento, porém ele é útil em
manter propriedades de localidade. Um leaf set L é um conjunto de nodos com os |L|/2
maiores nodeIds numericamente próximos, e os |L|/2 menores nodeIds numericamente
próximos, relativamente ao nodo atual. Este conjunto é utilizado durante o roteamento de
mensagens. Tamanhos tı́picos para |M | e |L| são 2b ou 2 × 2b .
Os experimentos realizados utilizando o Pastry não utilizam todas as caracterı́sticas e funcionalidades oferecidas pela plataforma. Uma pequena aplicação que envia
algumas mensagens foi utilizada. Isso se deve ao fato de que o foco deste trabalho é analisar a topologia criada a partir da execução de uma aplicação como o Pastry. Como critério
para definir se um nodo está conectado com outro é usado o leaf set de cada nodo do Pastry. Existe uma implementação do Pastry chamada Free Pastry [Free Pastry 2010], a qual
foi utilizada para testes em sua versão 2.1-alpha3.
Figura 7. Topologia criada pelo Free Pastry em nodos brasileiros e europeus.
Durante os experimentos envolvendo o Free Pastry a API do PlanetMon foi utilizada através de sockets, pois a plataforma utilizada é implementada em Java. Utilizando
41
ondas, a cada segundo a leaf set de cada nodo é checada e as alterações são refletidas
no mapa. A figura 8 demostra os resultados desta execução em função do tempo. Foram utilizados 39 nodos em sites distindos da América do Norte. Após a execução do
experimento, o grafo correspondente à representação da topologia presente no mapa foi
extraı́do. Foi possı́vel constatar que os graus máximos obedecem o tamanho da leaf set
(por padrão, 24) e que a distância entre todos os nodos não passou de 2, o que mostra que
a propriedade de roteamento em dlog2b N e foi respeitada. A figura 7 apresenta o mesmo
experimento executado sobre 6 nodos localizados no Brasil e 25 nodos na Europa.
5. Conclusão
Excutar experimentos no Planet-Lab é uma tarefa que demanda muito esforço e tempo.
Desde o envio da aplicação até a coleta de dados, muitos problemas podem complicar o
processo. Contornar todos os problemas que podem ser encontrados é uma tarefa difı́cil.
Neste trabalho desenvolvemos um arcabouço para instalação, configuração e
execução de experimentos em um testbed, o Planet-Lab. Com a utilização do portal e
da API, é possı́vel executar um experimento e coletar seus resultados de uma maneira
simples e produtiva. A visualização das topologias criadas pelas aplicações é feita através
de um mapa global baseado no Planet-Lab.
Para validar o sistema foi criada uma aplicação que cria uma topologia em formato de estrela, e os resultados mostraram que o gerador de mapas foi executado como
esperado. Também foram realizados experimentos utilizando o Pastry, um substrato para
aplicações P2P, os quais possibilitaram a constatação das propriedades do sistema.
Trabalhos futuros podem incluir novas maneiras de visualizar aplicações em
execução, não necessariamente atreladas a um mapa. Expandir o uso da API do Google
Maps para utilizar melhor seus recursos poderia melhorar a visualização das topologias.
Além disso, suporte a injeção de falhas durante a execução de um experimento é outro
recurso útil para testar aplicações distribuı́das.
Referências
CoDeploy (2010). CoDeploy. Disponı́vel em: http://codeen.cs.princeton.
edu/codeploy/. Acesso em nov. 2010.
Free Pastry (2010). Free Pastry. Disponı́vel em: http://www.freepastry.org.
Acesso em nov. 2010.
Google Maps API (2010).
Google Maps API.
Disponı́vel em: http:
//code.google.com/intl/pt-BR/apis/maps/documentation/
javascript/v2/index.html. Acesso em nov. 2010.
Nixes (2010).
Nixes.
Disponı́vel em:
http://www.aqualab.cs.
northwestern.edu/nixes.html. Acesso em nov. 2010.
OpenSSH (2010). OpenSSH. Disponı́vel em: http://www.openssh.org/. Acesso
em nov. 2010.
ParallelSSH (2010). ParallelSSH. Disponı́vel em: http://www.theether.org/
pssh/. Acesso em nov. 2010.
42
Anais
Figura 8. Mapas gerados durante a execução do Free Pastry.
43
Peterson, L., Anderson, T., Culler, D., and Roscoe, T. (2002). A blueprint for introducing
disruptive technology into the internet. HotNets-I 02.
Planet-Lab User Guide (2010). Planet-Lab User Guide. Disponı́vel em: http://www.
planet-lab.org/doc/guides/user. Acesso em nov. 2010.
PLCAPI (2010). Planet-Lab Central API documentation. Disponı́vel em: http://
www.planet-lab.org/doc/plc_api. Acesso em nov. 2010.
RFC Editor (2001). Canonical XML Version 1.0. Disponı́vel em: http://www.
rfc-editor.org/rfc/rfc3076.txt. Acesso em mar. 2010.
Ribas, B. C., Pasqualin, D. G., and Ruoso, V. K. (2009). SDI - Sistema de Diagnóstico
Instantâneo. Workshop de Software Livre.
Rowstron, A. and Druschel, P. (2001). Pastry: Scalable, distributed object location and
routing for large-scale peer-to-peer systems. IFIP/ACM International Conference on
Distributed Systems Platforms (Middleware), pages 329–350.
44
Anais
Sistemas P2P
♦
Sessão Técnica 2
BitTorrent
47
Eficiência de download em comunidades BitTorrent
Jaindson Santana , Nazareno Andrade
1
Laboratório de Sistemas Distribuídos
Universidade Federal de Campina Grande (UFCG)
Av. Aprígio Veloso, 882 – Bloco CO – Campina Grande – PB – Brazil
{jaindson, nazareno}@dsc.ufcg.edu.br
Resumo. Bittorrent é o sistema de compartilhamento de arquivos mais utilizado
atualmente. Uma prática comum entre os usuários deste sistema é a criação das
comunidades Bittorrent. Diversos estudos já mediram a velocidade de download dos usuários destas comunidades. No entanto, estes estudos não fornecem
evidências conclusivas sobre que características dos usuários e dos enxames
determinam os resultados observados. Trabalhos anteriores não examinaram
o efeito destas características, examinaram o efeito de apenas uma característica, ou usaram um espaço amostral pequeno de enxames e usuários. Este
artigo apresenta os resultados de um trabalho em andamento para analisar a
velocidade de download dos usuários de comunidades Bittorrent, utilizando um
espaço amostral significativamente maior que os trabalhos anteriores, e examinando o efeito de múltiplas características de enxames, usuários e comunidades
na velocidade de download.
Abstract. Nowdays, Bittorrent is the most used file sharing system. A common
behaviour among its users is the creation of Bittorrent communities. Some studies have already analyzed the download speed of these users. However, such
studies do not provide conclusive evidence about the characteristics of users
and swarms that determine the results obtained. Previous studies did not analyze the effect of these characteristics, they did analyze the effect but for only
one characteristic, or they used only a small sample of users and torrents. This
paper provides the results of an ongoing work that analyzes the download speed
of users of a Bittorrent community. The main differences between this work and
previous ones are: the size of the sample is significantly larger and multiple
characteristics of torrents, users and communities are used to study their effects
on download speed.
1. Introdução
Estudos de tráfego na Internet mostram que o BitTorrent (BT) é um dos sistemas de compartilhamento de arquivos mais utilizados e que é responsável também por parte significativa deste tráfego [Shalunov 2003] [Karagiannis et al. 2004b] [Karagiannis et al. 2004a]
[Parker 2005] [Champagne 2008] [Hendrik Schulze 2009]. O BT permite o compartilhamento de um arquivo por um grupo de usuários, formando o que se chama de enxame.
Um grupo de usuários que compartilham vários arquivos ao longo do tempo é denominado uma comunidade BT. Tipicamente, cada comunidade usa um site na Internet como
ponto de encontro de seus usuários e principal meio de comunicação ([Bitsoup.org 2009],
[etree.org 2009], [filelist.ro 2009], [easytree.org 2009], [alluvion.org 2009]).
48
Anais
Este artigo apresenta resultados de um trabalho em andamento para investigar que
características dos enxames e comunidades influenciam o download experimentado pelos
seus usuários. A velocidade de download é um dos aspectos fundamentais para definir a
qualidade de serviço num sistema de compartilhamento de arquivos. Contudo, analisar
o valor absoluto da velocidade de download não reflete necessariamente a qualidade de
serviço experimentada pelos usuários. Isso se deve ao fato da velocidade de download ser
limitada pela capacidade de download de cada usuário. Se dois usuários estão baixando
um arquivo a uma mesma velocidade, mas o primeiro está saturando a sua capacidade e
o segundo não, o primeiro experimenta a melhor qualidade de serviço que ele pode experimentar, enquanto o segundo não. Levando este problema em conta, este trabalho usa
como métrica a eficiência de download dos usuários, que consiste em medir a utilização
da banda do usuário ao longo do tempo que ele permaneceu online no sistema.
Trabalhos anteriores já se propuseram a fazer análise da velocidade se focando
em outros aspectos, como a influência de variações do protocolo BT. Outros realizaram
uma análise semelhante à que propomos, mas não utilizaram características do enxame ou
consideraram uma amostra reduzida de enxames. Este trabalho se propõe a realizar uma
análise explorando múltiplas características de enxames e utilizando um espaço amostral
maior de enxames e usuários.
Como resultado deste trabalho espera-se obter indícios de como as características
dos enxames e comunidades influenciam o download experimentado pelos usuários. A
partir disso seria possível explorar estas características de modo a melhorar a qualidade
de serviço oferecida aos usuários.
As contribuições deste artigo são: (i) proposição de um método para estudo da
velocidade de download dos usuários numa comunidade; e (ii) análise inicial de quais
características presentes nos usuários e enxames das comunidades influenciam na velocidade de download experimentada por seus usuários, utilizando uma amostra de usuários
e enxames significativamente maior que trabalhos anteriores. O artigo está organizado
da seguinte forma: na Seção 2 são apresentados os trabalhos relacionados; na Seção 3
é descrito o funcionamento do BT; na Seção 4 é abordada a metodologia utilizada neste
trabalho; nas Seções 5 e 6 são apresentados os resultados preliminares; por fim, na Seção
7 são descritas as conclusões e trabalhos futuros.
2. Trabalhos relacionados
Nesta seção serão abordados trabalhos que também fizeram uma análise da velocidade de
download dos usuários, destacando no que eles diferem do presente trabalho. Em poucas
palavras há trabalhos que exploram menos caracteristicas e enxames, enquanto outros não
tentam explicar os resultados a partir das características observadas.
Bellissimo et al. [Bellissimo et al. 2004] e Meulpolder et al. [Meulpolder et al. 2010]
expõem a velocidade de download em múltiplos enxames, mas não associam o comportamento observado a características dos enxames.
Andrade et al. [Andrade et al. 2005] e Locher et al. [Locher et al. 2006] realizaram trabalhos com constatações semelhantes. Em ambos os trabalhos foram observados o comportamento de usuários freerider1 e concluído que, em cenários onde a
1
No contexto de P2P, freerider é aquele usuário que nada contribui para o sistema ou que não contribui
49
quantidade de seeders é grande, a velocidade de download experimentada pelos freeriders
se equipara ou até mesmo atinge valor maior que a velocidade obtida pelos que contribuem com o sistema. Nestes trabalhos tentou-se explicar a velocidade de download
obtida pelos usuários considerando apenas a característica deles serem freerider ou não.
Rasti et al. [Rasti and Rejaie 2007] observaram a distribuição da velocidade de
download dos usuários de três enxames, e buscaram explicar seu comportamento com
base em algumas características no nível de usuário e enxame. Como resultado foi visto
que nenhuma das características conseguiam explicar bem o comportamento observado.
Note, no entanto, que a quantidade de enxames utilizada é relativamente pequena comparada a amostra de enxames utilizada neste trabalho.
3. Funcionamento BT
Nesta seção será explicada a nomenclatura e o funcionamento do BT, conhecimentos
importantes para entender como é calculada a eficiência de download. Mais detalhes
sobre o funcionamento do BT podem ser obtidos no trabalho de Cohen [Cohen 2003].
Para uma melhor clareza na explicação, segue uma definição dos termos utilizados
[Legout et al. 2007]:
• Comunidade BT. Normas e mecanismos que determinam regras para o compartilhamento de conteúdo, além do conjunto de pessoas que se agrupam com objetivo
de compartilhar conteúdos de interesse em comum. Normalmente utilizam um
site com fórum como ponto de encontro para divulgação das normas e novos conteúdos. Geralmente estabelecem uma identificação forte2 para cada usuário da
comunidade.
• Usuário da comunidade BT. Uma pessoa que participa da comunidade BT.
• Peer. Representa um usuário da comunidade fazendo parte de um enxame.
• Enxame. Conjunto de todos os peers interessados em obter um mesmo conteúdo.
Desta forma os peers que participam de um mesmo enxame compartilham o conteúdo entre si.
• Sessão do peer. Período de tempo que o peer participa de forma ativa no enxame.
Ou seja, ele está distribuindo e/ou obtendo o conteúdo neste período. O peer pode
ter diversas sessões ao longo de sua participação no enxame.
• Tracker. Entidade centralizada responsável pelo serviço de descoberta de peers e
coleta de estatísticas relativas a participação e estado dos peers no enxame.
• Pedaços e Blocos. O arquivo sendo compartilhado é particionado em pedaços, que
por sua vez são particionadas novamente em blocos. O bloco é a menor unidade
de troca entre os peers. No entanto, os peers só podem trocar pedaços completos
entre si.
• Torrent. Consiste num arquivo de metadado contendo todas as informações necessárias para obter o arquivo: quantidade de pedaços, identificação única para
todos os pedaços (usado na verificação de integridade dos pedaços), e endereço
para contactar o tracker.
uma parcela significativa comparado com o quanto ele obteve do sistema.
2
Forma única de identificar um usuário da comunidade. Por meio dela é possível ter conhecimento da
contribuição do usuário na comunidade.
50
Anais
• Seeder. Peer que possui uma cópia completa do arquivo. Neste caso ele permanece no enxame participando de forma altruísta, ou seja, fazendo apenas upload
de blocos.
• Leecher. Peer que possui apenas uma cópia parcial do arquivo e participa do
enxame fazendo upload e download de blocos.
Quando um usuário quer compartilhar um arquivo ele deve primeiramente criar
o arquivo torrent contendo os metadados do arquivo em questão. Em seguida, deve
disponibilizá-lo para que outros usuários possam descobrí-lo e a partir disso entrar no
enxame. Inicialmente, apenas quem publicou o arquivo possui a cópia completa. Desta
forma, apenas ele envia parte do arquivo aos demais. À medida que os novos peers obtêm
partes do arquivo eles passam a compartilhar também com os demais, dividindo assim a
carga de distribuição entre todos os usuários do enxame.
4. Metodologia
O estudo do comportamento das comunidades foi feito com base em dados coletados
periodicamente contendo informações sobre o estado dos peers e dos enxames. Este conjunto de dados define o comportamento da comunidade, e com base nestas informações
é feita a reconstituição do comportamento dos usuários. A partir disto é possível saber,
por exemplo, as sessões que um usuário teve nos enxames que participou e as velocidades
de download experimentadas por ele nestas sessões. A Tabela 1 mostra a população total
de usuários, a quantidade de enxames e o período de observação da comunidade utilizada
neste trabalho.
Tabela 1. Características da comunidade
Comunidade
Bitsoup [Bitsoup.org 2009]
#Usuários
84026
#Enxames
13741
Período
29/04/2007 - 02/07/2007 (64 dias)
Conforme foi mencionado na Seção 1, para estudar a velocidade de download
dos usuários foi estabelecida a métrica eficiência de download. Esta métrica leva em
conta a quantidade de tempo que cada usuário ficou online enquanto leecher. Dado este
tempo, é analisada a razão entre a quantidade de dados de fato obtidos pelo usuário e
a quantidade de dados que poderia ter sido obtido caso o usuário experimentasse sua
velocidade máxima de download (capacidade de download do usuário).
O cálculo da eficiência utiliza portanto as seguintes informações: capacidade de
download dos usuários, velocidade de download dos usuários nas sessões que ele participou como leecher e a duração destas sessões. Além disto, a eficiência de uma comunidade pode ser analisada segundo três pontos de vista: considerando a eficiência de cada
usuário, de cada enxame ou da comunidade como um todo.
A eficiência de um usuário u, representada por M (u), é calculada da seguinte
51
forma:
M (u) =
Du =
Du
Pu
X
Du,t
t∈T (u)
Du,t =
X
∆Is,u,t × Vs,u,t
s∈S(u,t)
Pu =
X
Pu,t
t∈T (u)
Pu,t =
X
∆Is,u,t × C(u)
s∈S( u,t)
Onde:
•
•
•
•
•
•
•
•
•
Du : download que o usuário u fez em todos os enxames;
Pu : download potencial de u em todos os enxames;
Du,t : download que o usuário u fez no enxame t;
Pu,t : download potencial do usuário u no enxame t;
∆Is,u,t : duração da sessão s do usuário u no enxame t;
Vs,u,t : velocidade de download do usuário u na sessão s do enxame t;
C(u): capacidade de download do usuário u;
T (u): conjunto de todos os enxames que u participou;
S(u, t): conjunto de todas as sessões do usuário u no enxame t.
Enquanto que a eficiência de um enxame t, representada por M (t), é calculada da
seguinte forma:
M (t) =
Dt =
Dt
Pt
X
Du,t
u∈U (t)
Pt =
X
Pu,t
u∈U (t)
Onde:
• Dt : download que os usuários fizeram no enxame t;
• Pt : download potencial dos usuários no enxame t;
• U (t): conjunto de todos os usuários no enxame t.
E a eficiência de uma comunidade c, representada por M (c), é calculada da seguinte
forma:
52
Anais
P
u∈U (c)
Du
u∈U (c)
Pu
M (c) = P
P
t∈T (c)
= P
t∈T (c)
Dt
Pt
Onde:
• U (c): conjunto de todos os usuários da comunidade c;
• T (c): conjunto de todos os enxames da comunidade c.
Note que no cálculo da eficiência de um usuário é levado em conta todos os enxames que ele participou, enquanto que no cálculo da eficiência de um enxame é levado em
conta todos os usuários que participaram dele. A eficiência da comunidade, por sua vez,
leva em consideração todos os usuários.
Com base nestas métricas é possível comparar comunidades entre si segundo os
três pontos de vista ou analisar comportamentos diferentes dentro de uma mesma comunidade.
Além disso, é possível examinar a relação entre os valores de eficiência obtidos e
as características dos usuários, enxames e das comunidades. Neste trabalho serão analisadas a relação com as seguintes características:
• população do enxame;
• tamanho do arquivo;
5. Estimativa da capacidade de download
Embora os dados coletados da comunidade possuam bastante informação sobre os usuários,
nele não consta suas capacidades de download. Conforme visto na Seção 4, esta é uma
informação necessária no cálculo da eficiência. Para mitigar este problema, em vez de
utilizar a capacidade real de download do usuário (informação desconhecida) é utilizada
uma estimativa dela.
Esta estimativa é calculada para cada usuário com base nas velocidade de download medidas entre coletas consecutivas. Esta velocidade consiste na razão entre a quantidade de download realizada em todos os enxames que o usuário estava participando no
período entre as duas coletas, e o tamanho da janela de tempo entre elas. O valor da
estimativa será o maior valor encontrado. A Figura 1 mostra a estimativa da capacidade
de download dos usuários da comunidade Bitsoup. A partir dela é possível observar que
80% dos usuários possuem capacidade de download máxima de 443KB/s enquanto 8%
possuem capacidade zero. Capacidade zero significa que os usuários não foram capazes
de realizar nenhum download enquanto estiveram online.
6. Análise da eficiência
Nesta seção serão abordados os resultados obtidos para eficiência dos usuários e enxames. Além disto, será mostrada uma análise inicial de como se comporta a eficiência
dos enxames em relação ao tamanho do arquivo sendo compartilhado e a população do
enxame.
53
1.0
0.8
FDA
0.6
0.4
0.2
0.0
10^−2
10^0
10^2
10^4
Capacidade de download (KB/s)
Figura 1. Estimativa da capacidade de download dos usuários da comunidade
Bitsoup
A Figura 2 mostra o gráfico da função distribuição acumulada (FDA) da eficiência dos usuários e dos enxames. Os usuários com capacidade de download zero foram
removidos da análise, uma vez que sem esta informação não é possível calcular a eficiência. No geral, a partir da figura pode-se concluir que a eficiência dos usuários é melhor
que a eficiência dos enxames. Enquanto a mediana da eficiência dos usuários é de 7, 6%,
a mediana da eficiência dos enxames é de 1, 3%. No entanto, as duas métrica possuem
um valor muito baixo. No caso da eficiência dos usuários isto implica que a velocidade
média (contabilizando todo período que permaneceu online como leecher) de 50% dos
usuários é igual ou inferior a 7, 6% de sua capacidade de download.
A Figura 3 mostra o gráfico de dispersão entre a eficiência de download dos enxames e duas características: tamanho do arquivo sendo compartilhado e a população no
enxame. Rasti et al. [Rasti and Rejaie 2007] concluíram que não seria possível explicar
de forma satisfatória a velocidade de download dos usuários na amostra de enxames que
eles analisaram. A Figura 3 mostra que, nos dados analisados, tanto o tamanho do arquivo
quanto o tamanho da população possuem uma correlação positiva com a eficiência dos enxames (o coeficiente de correlação tau de Kendall na Figura 3(a) é de 0.49, enquanto na
Figura 3(b) é de 0.20). Isto é um indício de que o uso de uma amostra maior de usuários
e enxames pode fazer diferença. Note que em ambos é possível observar alguma tendência, sugerindo que há uma relação entre a eficiência dos enxames e as duas características
apresentadas.
Com base nestes resultados, os próximos passos do trabalho consistem em observar outras características que também poderiam explicar as eficiências e explorar técnicas
de análise multivariada a fim de observar a influência das características agindo em conjunto.
54
Anais
0.8
0.8
0.6
0.6
FDA
1.0
FDA
1.0
0.4
0.4
0.2
0.2
0.0
0.0
0.2
0.4
0.6
0.8
Eficiência de download
(a) Usuários
0.1
0.2
0.3
0.4
0.5
(b) Enxames
Figura 2. Gráfico da eficiência dos usuários e dos enxames
7. Conclusão e trabalhos futuros
Este trabalho propôs um método para analisar a velocidade de download de usuários de
comunidades BT que considera a influência da capacidade de download dos usuários,
resultando na criação das métricas de eficiência para comunidades, usuários e enxames.
Além disto, realizou uma análise inicial destas métricas numa comunidade. A partir de
uma análise inicial dos gráficos de dispersão entre a eficiência dos enxames e suas características foi possível observar indícios de que as características dos enxames afetam suas
eficiências. Os próximos passos deste trabalho são: uso de outras comunidades; e análise
de mais características e técnicas que possam explicar o comportamento observado com
base nas características, como uma análise multivariada.
Referências
alluvion.org (2009). alluvion.org tracker - promoting responsible use of bittorrent technology. Disponível em: http://alluvion.org/. Acesso em: Março de 2011.
Andrade, N., Mowbray, M., Lima, A., Wagner, G., and Ripeanu, M. (2005). Influences
on cooperation in bittorrent communities. In P2PECON ’05: Proceedings of the 2005
ACM SIGCOMM workshop on Economics of peer-to-peer systems, pages 111–115,
New York, NY, USA. ACM.
Bellissimo, A., Shenoy, P., and Levine, B. N. (2004). Exploring the use of BitTorrent as the basis for a large trace repository. Technical Report 04-41, Department of Computer Science, University of Massachusetts. Disponível em:
http://lass.cs.umass.edu/ lass/papers/pdf/TR04-41.pdf. Acesso em: Março de 2011.
Bitsoup.org (2009). Bitsoup.org the best site for your torrent appetite. Disponível em:
http://www.bitsoup.org/. Acesso em: Março de 2011.
Champagne, B. (2008). Disponível em: http://www.bigchampagne.com/. Acesso em:
Março de 2011.
10^−4
10^−6
10^−2
10^0
55
10^−10
10^−8
10^−2
10^−4
10^−6
10^−8
10^−10
10^0
10^−4
10^−2
10^0
10^2
Tamanho do arquivo (MB)
(a) Tamanho do arquivo (MB)
10^4
10^0
10^1
10^2
10^3
10^4
População
(b) População
Figura 3. Gráfico de dispersão entre a eficiência de download dos enxames e
duas características
Cohen, B. (2003). Incentives build robustness in bittorrent. Technical report, bittorrent.org. Disponível em: http://www.bittorrent.org/bittorrentecon.pdf. Acesso em:
Março de 2011.
easytree.org (2009).
www.dimeadozen.org - eztorrent v0.6.3.
http://www.dimeadozen.org/. Acesso em: Março de 2011.
Disponível em:
etree.org (2009). bt.etree.org - community tracker. Disponível em: http://bt.etree.org/.
Acesso em: Março de 2011.
filelist.ro (2009). filelist.ro. Disponível em: http://filelist.ro/. Acesso em: Março de 2011.
Hendrik Schulze, K. M. (2009). The impact of p2p file sharing, voice over ip, instant
messaging, one-click hosting and media streaming on the internet. Disponível em:
http://www.ipoque.com/resources/internet-studies/internet-study-2008_2009. Acesso
em: Março de 2011.
Karagiannis, T., Broido, A., Brownlee, N., Claffy, K. C., and Faloutsos, M. (2004a). Is
p2p dying or just hiding? In Proceedings of the GLOBECOM 2004 Conference, Dallas,
Texas. IEEE Computer Society Press.
Karagiannis, T., Broido, A., Faloutsos, M., and Claffy, K. (2004b). Transport layer identification of p2p traffic. In IMC ’04: Proceedings of the 4th ACM SIGCOMM conference
on Internet measurement, pages 121–134, New York, NY, USA. ACM.
Legout, A., Liogkas, N., Kohler, E., and Zhang, L. (2007). Clustering and sharing incentives in bittorrent systems. In SIGMETRICS ’07: Proceedings of the 2007 ACM
SIGMETRICS international conference on Measurement and modeling of computer
systems, pages 301–312, New York, NY, USA. ACM.
Locher, T., Moor, P., Schmid, S., and Wattenhofer, R. (2006). Free riding in bittorrent
is cheap. In Fifth Workshop on Hot Topics in Networks (HotNets-V), Irvine, CA,
56
Anais
US. Disponível em: http://www.sigcomm.org/HotNets-V/program.html. Acesso em:
Março de 2011.
Meulpolder, M., D’Acunto, L., Capotă, M., Wojciechowski, M., Pouwelse, J. A., Epema,
D. H. J., and Sips, H. J. (2010). Public and private bittorrent communities: a measurement study. In Proceedings of the 9th international conference on Peer-to-peer
systems, IPTPS’10, pages 10–10, Berkeley, CA, USA. USENIX Association.
Parker, A. (2005). The true picture of peer-to-peer file-sharing, panel presentation.
Disponível em: http://2005.iwcw.org/slides/Panel/Andrewwcw2005.zip. Acesso em:
Março de 2011.
Rasti, A. and Rejaie, R. (2007). Understanding peer-level performance in bittorrent: A
measurement study. In Proceedings of 16th International Conference on Computer
Communications and Networks, pages 109–114.
Shalunov, S. (2003).
Internet2 netflow weekly reports.
Disponível em:
http://www.internet2.edu/presentations/fall-03/20031013-NetFlow-Shalunov.pdf.
Acesso em: Março de 2011.
57
BitPS: um esquema de precificação para sistemas par-a-par
baseados em BitTorrent.
Gabriel de Godoy Correa e Castro1 , Humberto T. Marques-Neto1
1
Departamento de Ciência da Computação
Pontifícia Universidade Católica de Minas Gerais (PUC Minas)
30.535-901 - Belo Horizonte - Brasil
gabrielgodoy@acm.org, humberto@pucminas.br
Abstract. Due to peer-to-peer (P2P) architecture and its popularity, it’s expected that users seek to maximize their use over the use of other users. A kind
of these users is known as free rider, that don’t share their resources with the
system in the same proportion in which he consumes it, generating a imbalance
in the system. So this work presents a pricing scheme, named BitTorrent Pricing
Scheme (BitPS), which can foster the collaboration among users of one P2P system based on BitTorrent private tracker. In BitPS, the virtual price is variable
and depends on system workload. The usage of BitPS can reduce the problem
of free-riding and make this peer-to-peer system fairer than its default usage.
Resumo. Devido à arquitetura e popularidade dos sistemas par-a-par (P2P),
é esperado que os usuários tentem maximizar seu uso em detrimento dos outros usuários. Um tipo desses usuários é conhecido como free-rider, que não
compartilha seus recursos no sistema na mesma proporção em que consome, gerando um desequilíbrio no sistema. Assim este trabalho apresenta um esquema
de precificação denominado BitTorrent Pricing Scheme (BitPS), que pode promover a colaboração entre usuários do sistema P2P BitTorrent usando trackers
privados. Com esse esquema, usuários deverão pagar um preço virtual proporcional ao seu uso do sistema. O uso do BitPS pode reduzir o problema de
free-riding e tornar o BitTorrent um pouco mais justo que o uso normal.
1. Introdução
Estudos mostram que sistemas par-a-par (P2P) são responsáveis por mais de 60% da
carga de trabalho da Internet, o que pode corresponder a 3,3 exabytes de tráfego mensal [Ipoque 2009, Cisco 2010]. Algumas aplicações, como os softwares de mensagem eletrônica (ex.: Windows Live Messenger e Skype) e computação distribuída (ex.:
SETI@home e Folding@home) são sistemas P2P típicos. Além disso, o maior consumo de banda provém dos sistemas par-a-par de trocas de arquivo, como BitTorrent, e-Mule e Gnutella [Ipoque 2009]. Considerando a alta carga de trabalho dos sistemas P2P de troca de arquivo, estudos sobre esses sistemas são feitos para melhorar sua eficiência e tentar torná-los mais justos do ponto de vista de seus usuários
[Sirivianos et al. 2007, Feldman and Chuang 2005, Garcia and Hoepman 2004].
Sistemas P2P dependem da disponibilidade de seus usuários compartilhando seus
recursos com outros da rede, geralmente, formada por este tipo de sistema. Contudo,
58
Anais
alguns usuários não agem de maneira colaborativa, isto é, eles não compartilham seus recursos na mesma proporção com que eles utilizam os recursos do sistema, acarretando em
um desquilibrio de recursos no sistema. Este problema é denominado, na literatura, como
free-riding. Mecanismos que promovem a colaboração entre usuários P2P podem evitar
esse tipo de comportamento anormal, ou seja, podem inibir a ação free-rider. Alguns
desses mecanismos possuem características similares a modelos estudados pela Teoria
dos Jogos [Fudenberg and Tirole 1991], que são largamente utilizados na economia para
entender o relacionamento entre dois usuários que trocam bens e serviços. O tit-for-tat1
[Axelrod 1985] é um exemplo de conceito da Teoria dos Jogos aplicada em sistemas P2P
(ex.: BitTorrent [Cohen 2003]). Seguindo o princípio de “retribuição equivalente”, usuários P2P devem prover uma determinada quantidade de recursos, dependendo do quanto
eles obtiveram do sistema.
Outra forma de evitar um uso injusto do sistema P2P é a adoção de esquemas de
precificação. O uso de esquemas de precificação em sistemas par-a-par pode ser feito de
duas formas: explícita ou implícita [Mansfield and Yohe 2000]. A precificação explícita
se refere diretamente ao uso monetário de dinheiro real ou virtual. Por outro lado, a precificação implícita envolve bens intangíveis como, por exemplo, a reputação dos usuários.
Mecanismos de reputação consideram dados do histórico de transações do usuário para
determinar sua confiabilidade e permitir que outros usuários decidam se obterão recursos
daquele usuário. Existem algumas propostas de precificação em sistemas P2P que usam
protocolos de micropagamentos [Yu et al. 2004] ou que usam um sistema de pagamento
para controlar o quanto um usuário pode cobrar por um recurso [Liang and Shi 2005].
Esses e outros exemplos serão discutidos na sessão 2.4.
Este trabalho apresenta um esquema de precificação capaz de encorajar a colaboração entre usuários de trackers privados de BitTorrent. O esquema de precificação
proposto, aqui chamado BitTorrent Pricing Scheme (BitPS), é uma adaptação do Broadband Pricing Scheme (BPS) proposto em [Marques-Neto et al. 2007] e estendido em
[Marques-Neto et al. 2010]. Ambos, BPS e BitPS, são detalhados nas seções 2.2 e 3,
respectivamente. O BitPS pode ser utilizado para complementar o mecanismo de reputação já utilizado no BitTorrent, que determina a confiabilidade do usuário baseado no
seu histórico de compartilhamento de recursos. Então, o BitPS pode melhorar a eficiência do BitTorrent, oferecendo um incentivo visível para a contribuição de recursos com
o sistema P2P, atenuando o problema de free-riding. Em resumo, o objetivo desse trabalho é apresentar uma nova forma de encorajar a colaboração em trackers privados de
BitTorrent, tornando-o uma implementação mais justa que a normal, do ponto de vista
tanto dos usuários quanto do sistema. Isso é possível, uma vez que o BitPS incentiva o
usuário a agir como um usuário normal dentro do sistema que utiliza um tracker privado
de BitTorrent.
Para demonstrar as melhorias realizáveis com o uso do esquema de precificação proposto, foi utilizado o BitTorrent Simulator feito pela Microsoft Research
[Research 2005]. Esse simulador foi adaptado para utilizar o BitPS e o Dandelion
[Sirivianos et al. 2007], dada sua proximidade do BitTorrent. O Dandelion é melhor explicado na Seção 2.4. Os resultados da simulação, com e sem o uso do novo esquema
de precificação, e suas comparações com a implementação do Dandelion são analisadas
1
A regra do “Olho por olho”
59
na Seção 4. Os resultados, também discutidos na Seção 4, mostram que o BitPS torna
o sistema mais justo e homogêneo. Além disso, a Seção 2 apresenta e discute trabalhos
relacionados. Finalmente, na Seção 5, as conclusões desse trabalho são apresentadas.
2. Contextualização e trabalhos relacionados
2.1. Algumas Contribuições da Economia para Sistemas P2P
A primeira contribuição da economia para sistemas P2P é o Equilíbrio de Nash, frequentemente mencionado na literatura de Teoria dos Jogos [Fudenberg and Tirole 1991]. O
Equilíbrio de Nash pode auxiliar na explicação de como um sistema P2P pode se tornar
mais estável. De acordo com a Teoria dos Jogos, nenhum dos participantes do jogo possui
algo a ganhar mudando suas estratégias, ou seja, o equilíbrio ocorre quando um vendedor não consegue ganhar mais e um comprador não consegue barganhar mais. Sistemas
P2P devem monitorar e entender o comportamento do usuário para atingir esse tipo de
equilíbrio.
Outro conceito de Teoria dos Jogos que pode ser utilizado nos sistemas par-a-par
é o Dilema do Prisioneiro. Neste dilema, dois prisioneiros têm a oportunidade de terem suas sentenças diminuídas se cooperarem em delatar o outro. Entretanto, se ambos
escolherem delatar o outro, ambas as sentenças são aumentadas e, se nenhum delatar,
eles mantêm a sentença já definida [Fudenberg and Tirole 1991]. Isso gera uma matriz de
recompensa que pode ser aplicada a sistemas P2P. Em outras palavras, se ninguém contribui, ninguém consegue o recurso. A aplicação do Dilema do prisioneiro em sistemas
P2P foi estudada e analisada por [Lai et al. 2003] e [Feldman et al. 2004].
Na economia, precificação é o processo de determinar o que um produtor ou provedor receberá por um produto ou serviço oferecido. Esse retorno deve ser suficientemente positivo para permitir que esse produtor ou provedor permaneça atuando no mercado. O estabelecimento do preço de um produto ou serviço considera a combinação de
variáveis internas como custos e margem de lucro, e variáveis externas como a disponibilidade do produto ou serviço [Mansfield and Yohe 2000]. Aplicando um esquema de
precificação em sistemas P2P, é possível interferir no controle da a carga de trabalho de
alguns recursos.
2.2. BroadBand Pricing Scheme (BPS)
O Broadband Pricing Scheme (BPS) foi proposto para prover benefícios tanto para os
usuários quanto para os provedores de acesso a Internet (ISP na sigla em inglês pata
Internet Service Provider) de banda larga [Marques-Neto et al. 2007]. No BPS, o uso da
rede possui um preço para cada tempo do dia, que é calculado proporcional ao histórico
da carga de trabalho dos servidores do ISP em um período específico. Como no BPS cada
byte trafegado é cobrado dependendo do preço da hora, seu uso pode acarretar em uma
melhor distribuição do uso da Internet durante as horas do dia.
No BPS, cada usuário possui uma quantidade de créditos, chamado budget, suficiente para usar a Internet de acordo com o limite de sua assinatura. Como o preço de
uso é diferente para cada hora do dia, o usuário pode adiar ações que demandam mais
recursos da rede, como bandwidth, por períodos em que o preço é menor. O BPS estima
a quantidade de budget que o usuário precisará até a próxima recarga do budget baseado
no seu histórico de consumo.
60
Anais
Em resumo, com o BPS existe um incentivo para que os usuários façam um uso
da Internet de banda larga em horas, historicamente, com cargas de trabalho baixa na
infraestrutura. Eventualmente, a carga de trabalho do servidor poderia ser distribuída
pelas horas do dia, permitindo que o ISP otimize o uso de seus recursos e ofereça mais
assinaturas de seus serviços para novos usuários. Considerando que usuários de sistemas
P2P, apesar de não serem maioria, correspondem por mais de 50% do uso do serviço,
o BPS é capaz de contribuir com um uso da Internet mais justo do ponto de vista dos
usuários e rentável para o ISP [Marques-Neto et al. 2007].
2.3. BitTorrent
Em um sistema par-a-par os usuários podem agir tanto como clientes quanto como servidores de um recurso. Eles provêm novas informações, ou replicam, ou entregam informações geradas por outro usuário da rede [Parameswaran et al. 2001]. O envolvimento dos
usuários como servidores de informação garante a replicação do conteúdo de uma forma
mais econômica, tornando desnecessário o uso de servidores robustos para prover a informação para muitos usuários [Karagiannis et al. 2005]. No sistema par-a-par BitTorrent
[Cohen 2003], arquivos (recursos) são trocados diretamente entre usuários e dados dos
nós conectados são organizados por uma unidade centralizadora conhecida como tracker.
O tracker pode ser público (i.e.: legaltorrents e mininova) ou privados.
A construção de um tracker de BitTorrent é, em geral, equivalente com a de
uma website. Ele pode ser feito com uma linguagem como PHP e um gerenciador de
banco de dados como MySQL. Além disso, também é possível sua alteração, restringindo
acesso para alguns clientes ou para alguns IPs específicos, permitindo a implementação
de incentivos ou realizando a manutenção da proporção de troca entre os usuários. Algumas implementações de tracker público e privado do BitTorrent são apresentadas em
[Danomac 2006] e [TBsource and YeOK 2011].
Para facilitar a troca de arquivos entre usuários de BitTorrent, eles são divididos
em pequenos pedaços, de forma que o arquivo pode ser recuperado fora da ordem, não
dependendo somente de um único usuário, que pode não possuir recursos suficientes para
responder a um grupo de demandas. No BitTorrent existem duas categorias de usuários:
seeders e leechers. Os seeders são aqueles que só realizam o upload do arquivo. Enquanto
que os leechers realizam upload e download do arquivo simultaneamente [Cohen 2003].
Apesar do protocolo do BitTorrent ser considerado tit-for-tat, não há incentivo explícito
para os seeders [Locher et al. 2006] e [Piatek et al. 2007]
O BitTorrent utiliza de um mecanismo de reputação em que usuários que realizam
mais transferências simultaneamente, que possuem velocidade de transferência baixa ou
que possuem restrições, recebem menor prioridade para utilizar o sistema. Com esse
mecanismo, é esperado que todos os usuários ofereçam recursos aos outros. Contudo
isso geralmente não ocorre e torna o sistema dependente de usuários altruístas, ou seja,
aqueles contribuem mais que requerem.
Assim, em trackers públicos, os seeders existem por puro altruísmo, isto é, eles
contribuem com recursos sem a intenção de receber algo em troca. No entanto, em trackers privados normalmente é necessário manter um equilíbrio entre o que se consegue e
o que se contribui [Salmon et al. 2008], podendo o usuário ter sua conta revogada e, portanto, ficar impossibilitado de realizar downloads. Mas, geralmente, não são oferecidos
61
outros incentivos para que o usuário colabore com o sistema, o que poderia permitir que
a rede pudesse ficar ativa por mais tempo.
2.4. Trabalhos relacionados
O Dandelion é um sistema de troca de arquivos P2P similar ao BitTorrent
[Sirivianos et al. 2007]. Ele também divide os arquivos em pedaços para acelerar a transmissão. A diferença entre o BitTorrent e o Dandelion é que, no segundo, existe um banco
de crédito. No Dandelion, cada transmissão de arquivo custa uma determinada quantia de
créditos. Quando o usuário para quem é transferido não consegue oferecer mais recursos,
a quantia que ele paga pela transmissão do arquivo é transferida para o usuário de quem
ele requisitou o pedaço do arquivo. Em outras palavras, o Dandelion utiliza um híbrido de
tit-for-tat e mecanismo de micropagamento. Ele também utiliza um sistema criptográfico
para prevenir ataques ao sistema durante a validação de uma transferência. O Dandelion
será simulado e analisado na Seção 4.
Usando um esquema de precificação similar, mas propondo um mecanismo de
micropagamentos para sistemas P2P, o trabalho apresentado por [Yu et al. 2004] utiliza
um preço que depende da qualidade do serviço e da relação entre oferta e demanda da
informação buscada no sistema. O preço da informação é estimado periodicamente, dependendo de quantos usuários receberam recursos de volta no passado, o que o torna
dinâmico.
O sistema proposto em [Wongrujira and Seneviratne 2005] é um mecanismo de
precificação para sistemas P2P baseado em um mercado virtual no lugar de micropagamentos. Esse sistema utiliza um mecanismo de incentivo de troca de tokens, em que os
próprios usuários estabelecem seu preço para compartilhar seus recursos. O sistema considera regras de mercado e da economia para justificar o usuário poder estabelecer seu
próprio preço, uma vez que ele não colocará seu preço muito alto já que ninguém requererá seu recurso. Além disso, esse trabalho também utiliza um mecanismo de reputação,
dando prioridade para transferências de usuários com reputação alta.
O trabalho apresentado por [Feldman and Chuang 2005] realiza um estudo do
free-riding em que usuários não contribuem com recursos para o sistema e analisa algumas maneiras de atenuar ou eliminar tais problemas. Nesse trabalho os autores propõem
pagamentos monetários como incentivos para a contribuição dos usuários. Eles também
analisam os problemas e dificuldades da necessidade de uma unidade centralizadora confiável, o que pode aumentar o custo do sistema a um ponto impraticável. Outro ponto
discutido é sobre a reciprocidade, que seria o tit-for-tat implementado de uma maneira
mais robusta que no BitTorrent. Nessa proposta, um dos problemas dessa escolha é como
tratar um novo usuário que ainda não foi exposto pelo sistema. Como o novo usuário
ainda não contribuiu nada, ele pode ser impedido de realizar requisições.
Já em [Xia and Muppala 2010] é apresentado um método para atenuar o freeriding no BitTorrent e, assim, tornar o sistema mais justo. Esse método consiste em um
nó manter a reputação de seus vizinhos e divulgar essas reputações para que seja possível
a localização e isolamento de usuários considerados free-riders, impedindo-os de realizar
downloads. Cada peer é inicialmente tratado como um possível free-rider portanto, antes
de ser reconhecido e tratado como um usuário regular do sistema, recebe o tratamento de
um free-rider, o que pode prejudicar novos usuários.
62
Anais
Todas essas propostas de esquemas de precificação requerem a criação de um novo
e específico sistema P2P, portanto, não podem ser aplicados diretamente a uma base de
usuários já estabelecida como a do BitTorrent. Já o BitPS, o esquema de precificação
proposto nesse trabalho (vide Seção 3), utiliza a arquitetura existente do BitTorrent, que
já possui uma base de usuários estabelecida de mais de 160 milhões [BitTorrent 2011].
Desta forma, proposta apresentada neste trabalho pode utilizar o mesmo ambiente utilizado pelo BitTorrent com alguns ajustes nas configurações padrão e simples implementações. Apesar de ser possível a utilização dos programas atuais de BitTorrent, há a necessidade de configurá-los para que possam tirar proveito máximo do BitPS. A vantagem do
BitPS comparado com as outras propostas é que ele não requer a criação de um programa
completamente novo.
3. BitTorrent Pricing Scheme
3.1. Variáveis do BitPS
As variáveis usadas no BitPS são descritas na Tabela 1. Cada uma delas pode ser modificada pelo administrador do sistema sendo que algumas delas, como os limiares inferior
e superior, devem ser anunciadas pelo tracker. O budget é a quantidade de crédito que o
usuário pode gastar realizando downloads dos arquivos e é atualizado após cada processo
de transferência. Os três níveis de preço definem a quantidade que o usuário cobra pela
transferência de um byte. Esses níveis são definidos pelo administrador. Finalmente, os
dois limiares também são configurados pelo administrador e definem qual o preço cobrado
pelo usuário no momento da transferência. Cada limiar é uma porcentagem da capacidade
do que o sistema do usuário pode realizar. A variável onSale serve para, caso o usuário
não possua budget possa realizar uma transmissão, ou seja, diminuir seu preço, assim se
tornar mais competitivo no sistema.
Tabela 1. Variáveis Constituintes do BitPS
Nome
Budget
Preço Baixo
Preço Médio
Preço Alto
Limiar Inferior
Limiar Superior
onSale
Decrição
A quantidade de crédito do usuário, que é usado em
cada processo de transferência de arquivo.
A quantidade de crédito do usuário que é cobrada
pela transferência de um byte quando ele
está abaixo do Limiar Inferior.
está entre o Limiar Inferior e o Limiar Superior.
está acima do Limiar Superior.
O limite inferior de carga do sistema do usuário.
O limite superior de carga do sistema do usuário.
O percentual pela qual o usuário irá reduzir seu
preço.
63
3.2. Visão geral do BitPS
O BitTorrent Pricing Scheme (BitPS) pode incentivar a colaboração entre usuários de BitTorrent o que poderia torná-lo mais justo para os usuários, fornecendo um incentivo às
suas contribuições para o sistema. Como esse esquema também torna difícil o acesso para
usuários que não contribuem, espera-se que ele iniba a presença de usuários free-riders
no sistema. O BitPS funciona com a estrutura de um tracker privado, o qual requer registro. Isso não permite que o usuário crie diversas contas para tirar proveito do sistema,
mantendo o uso do sistema equânime. Além disso, para não permitir que o usuário registre diversas vezes simultaneamente, o tracker pode utilizar métodos de verificação de
identidade como, por exemplo, o registro de um endereço de email. Ademais, também é
possível bloquear o registro por endereços de IP iguais.
Como ocorre no BPS, no BitPS cada usuário possui uma quantidade de créditos
virtuais, denominado budget. Quando um novo usuário é criado, o tracker lhe atribui
uma quantia de budget para que ele possa iniciar seu uso do sistema. O budget inicial é
calculado utilizando um fator que é a média dos tamanhos dos arquivos disponíveis no
sistema e uma quantia de créditos fixa estipulada na configuração do tracker. A cada
transmissão de arquivos (recursos do sistema) entre usuários, uma quantidade de budget é
transferida de um usuário para o outro como forma de pagamento pelo recurso adquirido.
Essa quantidade é dependente de quantos bytes foram transferidos e qual o preço utilizado
pelo transmissor no momento.
Existem três níveis de preço cobrado pela transmissão de um byte. Eles podem
ser definidos pelo administrador do tracker durante a configuração do sistema e assumem
valores entre zero e dois. Cada nível corresponde a um tipo de utilização do sistema: alta,
média e baixa. O preço cobrado do usuário pelo uso do sistema depende do uso de sua
capacidade de transmissão, de forma a manter o uso do seu sistema balanceado. Como o
preço é cobrado em função do número de bytes requisitados, o valor cobrado é a quantidade de bytes requeridos multiplicados pelo preço cobrado pelo usuário transmissor, na
hora dessa transmissão.
O tracker privado (controlador do budget do usuário) é responsável por executar as
transferências de budget entre os usuários ao fim de uma transmissão de arquivo. Apesar
de que isso pode permitir o free-riding, é possível barrar no tracker clientes desconhecidos
ou que são reconhecidamente maliciosos. Ademais, também é possível realizar um teste
periódico de verificação para, caso um usuário realize uma transmissão de um recurso,
mas não informe o fim de uma transmissão, ser caracterizado como um cliente free-rider.
Assim, o cliente de BitTorrent padrão deve ser alterado de forma que ele informe o fim de
uma transmissão para o tracker privado.
Como usuário deve possuir budget suficiente para poder requisitar um pedaço de
recurso, é possível a existência de usuários incapacitados de terminar uma transmissão.
Esse problema é diminuído pela possibilidade de um usuário reduzir seu preço, utilizando
a variável onSale, quando não possuir budget suficiente e, assim, se tornar um usuário
competitivo no sistema. Mas, se o usuário do BitPS ainda não puder finalizar a transmissão, pode realizar uma recarga do budget no tracker. Essa recarga pode ser realizada se,
após um período de tempo, o usuário possuir budget inferior ao valor inicial do sistema
e possuir uma boa reputação, determinado por seu histórico de contribuição com outros
usuários do sistema.
64
Anais
Para manter o sistema balanceado, no BitPS, os usuários requisitam o pedaço do
arquivo desejado do usuário com o qual está conectado que possuir o menor preço do
recurso. Apesar disso acrescentar um overhead na transmissão, pode também aumentar
a concorrência e tornar o sistema mais justo. Esse comportamento pode distribuir as
requisições de pedaços de arquivo, uma vez que, o preço dos recursos dos usuários é
ajustado de acordo com o uso de sua capacidade de transmissão. Os preços dos usuários
conectados são anunciados periodicamente para todos os usuários pelo tracker e cada
usuário os mantém armazenado em seus clientes.
3.3. Descrição da transferência de um arquivo
A Figura 1 mostra o processo de transferência de um arquivo no BitPS. A principal diferença para o BitTorrent comum é a informação trocada entre o tracker e o cliente. Considerando que o Cliente A possui o arquivo torrent, que tem as informações do recurso
desejado, ele requisita as informações dos peers (seeders e leechers) para o tracker. O
tracker retorna a lista com os peers disponíveis realizando download e upload do arquivo
desejado e todas as informações necessárias, como endereço e preço dos clientes, para
que o Cliente A também o faça. Então, o Cliente A localiza o Cliente B, usando os mecanismos de BitTorrent, e requisita a lista de pedaços de arquivos disponíveis. O Cliente
B envia a lista de pedaços de arquivos disponíveis, o Cliente A requisita o pedaço que
necessita e o Cliente B o transfere para o Cliente A. No fim da transferência o Cliente A
comunica ao tracker para que ele atualize a informação do budget dos clientes.
000000000
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3, 5
4, 6
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000 000 000 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000000000000000000
1,
7
1. Pedido: Informação de um Torrent
2. Resposta: Lista dos peers
3. Pedido: Lista de pedaços
4. Resposta: Anúncio dos pedaços
5. Pedido: Pedaço do arquivo
6. Transferência de um pedaço
7. Atualização de Informações .
000 000 000 000
Cliente A
2
Cliente B
000 000 000
Tracker BitPS
Figura 1. Processo de Transferência de um arquivo no BitPS.
3.4. Compatibilidade e Segurança
Para permitir o uso de clientes atuais de BitTorrent, aproveitando dessa base de usuários,
o BitPS possui um método compatível com sua utilização. Esse método é ativado pelo
tracker de forma automática, não sendo necessária alteração de configuração do usuário
ou do administrador do sistema.
Se um usuário conectar ao sistema utilizando um cliente não adaptado ao BitPS,
o sistema pode funcionar de maneira similar a um tracker privado de BitTorrent. Mas, o
budget será utilizado realizando as operações de pagamento nos intervalos de atualização
do BitTorrent com um preço fixo. Se o usuário não possuir mais budget para realizar
a transferência do arquivo, o tracker, responsável por indicar ao cliente a localização
de outros usuários, pode não indicar outros seeders, indicando somente leechers. Isto
65
permite que o usuário ainda realize uploads e possa recuperar budget, mas, minimizando
as chances dele contrair mais dívidas.
Como um tracker privado cria um sistema fechado, sendo necessário registro,
ataques de replicação de usuários podem ser dificultados. Aproveitando as vantagens
do sistema BitTorrent, é possível diminuir ataques de clientes maliciosos. Também é
possível requerer que as mensagens de comunicação de fim de troca de informação, as
quais geram transferência de budget entre usuários, sejam assinadas digitalmente com
uma chave distribuída aos clientes pelo tracker no início da sessão de comunicação. Essa
assinatura deve ser acompanhada do tempo em que a transmissão foi realizada, sendo esse
tempo de ambos participantes da transmissão e cada um encriptado com sua respectiva
chave de sessão. Dessa forma é possível tornar a rede mais segura, impedindo ataques de
repetição, por exemplo.
4. Simulações e Resultados
As simulações foram realizadas com uma versão adaptada do BitTorrent Simulator da
Microsoft Research [Research 2005]. Esse simulador foi escolhido por recriar exatamente
as transferências entre usuários P2P. Outras opções, como a apresentada em [Eger 2007],
não foram escolhidas devido a seus altos níveis de complexidade para alterar e adaptar
ao contexto necessário. A adaptação do simulador da Microsoft Research foi feita para
que as transferências realizadas entre os participantes da rede considerassem o budget e
o preço como descritos na Seção 3, adicionando, portanto, o mecanismo do BitPS no
BitTorrent. O Dandelion, descrito na Seção 2.4 também foi implementado no simulador.
As simulações foram realizadas utilizando os mesmos parâmetros utilizados em
[Bharambe et al. 2006] que também utilizam o mesmo simulador da Microsoft Research.
Considera-se por simulação, a transmissão de um arquivo de 100MB em uma rede de
aproximadamente 1000 usuários. Foram realizadas 20 simulações, alterando em cada uma
o tempo que o sistema permanecia funcionando e o tempo de chegada entre cada usuário,
permanecendo com o mesmo número de usuários. O primeiro tempo de simulação é de
uma hora, e para cada simulação é acrescido uma hora. Ou seja, na ultima simulação 1000
usuários realizaram a transmissão de um arquivo de 100MB por um período de 20 horas,
sendo que cada usuário é introduzido no sistema aproximadamente um minuto após o
anterior.
Os limiares de capacidade dos usuários foram definidos como 70% e 80%, o que
significa dizer que para carga inferior a 70% foi utilizado um preço inferior e para carga
superior a 80% foi utilizado um preço superior. Os preços de transferência foram definidos como: um (1) para carga de trabalho inferior a 70%; um e meio (1.5) para carga de
trabalho entre 70% e 80% e dois (2) para carga de trabalho superior a 80%. Se o usuário
não possuísse budget suficiente, seu preço seria alterado pela variável onSale, definida
como 75% do preço atual. O budget inicial de cada usuário foi um valor atribuído entre
30% e 100% do necessário para se realizar a transferência, de forma que houvesse necessidade contínua de arrecadação de budget pelo usuário para realizar a transferência. Dos
dados produzidos pelo simulador foram utilizados o tempo de entrada e saída de cada
usuário, bem como a contribuição de cada um. Os parâmetros utilizados nessa configuração foram escolhidos após vários testes e verificou-se que estes permitiam um melhor
funcionamento do simulador no contexto desse trabalho. Cada simulação utilizando as
66
Anais
configurações descritas anteriormente foi realizada dez vezes para assegurar a integridade
dos dados.
Após as simulações realizadas os usuários foram classificados em: (i) usuários
Egoístas, que são similares a usuários free-riders, os quais contribuem com até 60% do
recurso consumido; (ii) usuários Normais, que contribuem com o sistema de uma forma
balanceada e desejável, ou seja, entre 60% e 100% do recurso consumido; (iii) usuários
Altruístas, os quais contribuem com mais do que o desejado com o sistema, que, em termos quantitativos, contribuem com mais de 100% dos recursos consumidos. Essa caracterização dos usuários foi realizada baseada na média dos valores utilizados em trackers
privados para dividir seus usuários [Salmon et al. 2008].
4.1. Análise dos usuários
A Tabela 2 mostra o percentual médio dos usuários de cada sistema simulado divididos
por classes. Em média, o percentual de usuários classificados como Egoístas diminui de
57,4% no BitTorrent para 47% no BitPS. O percentual deste tipo de usuário no Dandelion
é 56,1%, próximo ao do BitTorrent. O percentual de usuários classificados como Normais
vai de 17,2% no BitTorrent para 31,9% no BitPS. Novamente, o percentual de usuários
do Dandelion é próximo do BitTorrent, sendo de 17,5%. Esses dados indicam que há
um maior balanceamento do sistema, com mais usuários contribuindo de uma forma mais
igualitária o que consumiram. Ou seja, há uma migração de usuários para a categoria de
Normais, este fato também é verificado pela variação de usuários classificados como Altruístas: no Dandelion é 26,4%, 25,4% no BitTorrent e 21,1% no BitPS. Esses resultados
podem ser explicados pelo fato do BitPS forçar os usuários a contribuírem para realizar uma transferência de arquivo, diminuindo o número de usuários Egoístas. E assim o
sistema não depende somente de usuários contribuindo mais do que o necessário, o que
diminui também o número de usuários Altruístas.
Tabela 2. Percentual médio de usuários no sistema com desvio padrão – em %.
Categoria BitTorrent
Egoístas 57,4 (4,7)
Normais 17,2 (4,9)
Altruístas 25,4 (3,0)
BitPS
47,0 (5,2)
31,9 (3,0)
21,1 (5,1)
Dandelion
56,1 (4,6)
17,5 (4,4)
26,4 (3,1)
Figura 2. Variação do percentual de usuários Egoístas
67
O gráfico da Figura 2 representa o número de usuários Egoístas durante todas
as 20 simulações. Sua análise mostra que, desde a primeira simulação, o percentual do
BitPS é inferior ao dos outros dois sistemas. Esse percentual inferior ocorre devido à
impossibilidade de um usuário receber o arquivo sem devolver parte dele caso o usuário
não possua budget suficiente. Ou seja, sua reputação no sistema é baixa, o que lhe impede
de realizar a transferência do arquivo. Como mencionado anteriormente, o Dandelion
possui uma performance similar ao BitTorrent, pois esse sistema não se preocupa se o
sistema é justo na visão do usuário.
Figura 3. Variação do percentual de usuários Normais.
No gráfico da Figura 3, o número de usuários Normais se mantêm superior durante
todas simulações no sistema BitPS, se comparados com o BitTorrent e com o Dandelion.
Tal fato acontece devido a que no BitPS, o usuário precisa contribuir caso queira terminar
sua transmissão e continuar no sistema. Já no BitTorrent e no Dandelion, os usuários não
precisam contribuir. Portanto, poucos usuários têm que contribuir para balancear contra
os que não contribuem. Em um sistema, o balanço desejado é que o número de usuários
Normais seja o mais alto possível, demonstrando uma homogeneidade do sistema.
Figura 4. Variação do percentual de usuários Altruístas.
Finalmente, no gráfico da Figura 4, que representa o número de usuários Altruístas
em todas as simulações, começa similar, mas no BitPS se torna inferior a medida que o
68
Anais
tempo de entrada de cada usuário aumenta. Contudo, nas simulações com tempo maior há
uma convergência do número de usuários, levando a uma similaridade no final. O menor
número de usuários Altruístas no BitPS pode ser explicado pelo fato de que um usuário que contribui perto de sua capacidade total possui um preço maior, sendo, portanto,
um provedor menos viável, diminuindo sua participação na rede. Isso torna o sistema
mais homogêneo, uma vez que, um número maior de usuários contribui razoavelmente,
diferente do BitTorrent e do Dandelion em que poucos usuários contribuem muito com o
sistema.
4.2. Análise do tempo
A Tabela 3 contém o tempo médio, em segundos, gasto por usuário para realizar a transferência de um arquivo em cada sistema analisado. De acordo com essa tabela, é possível
verificar que o BitPS gasta um tempo maior que o BitTorrent. Isso pode ser desfavorável
ao usuário, apesar de esperado, dado o tempo que o usuário necessita para conseguir o
budget e realizar a transferência. O Dandelion possui uma performance similar ao BitTorrent, algo também esperado pelos resultados descritos em [Sirivianos et al. 2009].
Como foi necessário que o usuário arrecadasse budget para realizar a transferência, o tempo do BitPS é substancialmente superior, mas caso o usuário já possuísse budget
suficiente a tendência seria que o tempo diminuísse, podendo se tornar equivalente ao BitTorrent.
Tabela 3. Tempo médio gasto por usuário para transferência de um arquivo – em
segundos.
Tempo
BitTorrent
1047,84
BitPS Dandelion
1462,85 1058,12
5. Conclusões
Algumas soluções para o problema de free-riding usando mecanismos de precificação em sistemas par-a-par já foram propostas na literatura [Feldman and Chuang 2005],
[Feldman et al. 2006]. Este trabalho apresenta um esquema de precificação capaz de encorajar a colaboração entre usuários de um tracker privado de BitTorrent. Esse esquema é
nomeado BitPS (BitTorrent Pricing Scheme), cujo uso pode ser feito junto com os mecanismos de reputação já aplicado no BitTorrent. Os resultados das simulações demonstram
que, com o BitPS, há uma atenuação do free-riding e um balanceamento do sistema,
tornando-o mais justo que o mecanismo padrão de reputação. Com o uso do BitPS, os
percentuais de usuários Egoístas e de usuários Altruístas diminuem e os Normais aumentam. Isso se deve ao fato de que para poder realizar uma transferência o usuário necessita
de budget e para consegui-lo ele deve contribuir com recursos no sistema, diminuindo os
usuários Egoístas. Como mais usuários contribuirão, há menos necessidade de usuários
que contribuem além do que consumiram, diminuindo, desse modo, o número de usuários
Altruístas. Por outro lado, o percentual de usuários Normais a medida que se aumenta o
tempo de simulação. Isso caracteriza um balanceamento do sistema, o que torna a rede
mais justa do ponto de vista do usuário e do sistema, apesar de ser necessário um maior
tempo médio para as transferências.
69
Referências
Axelrod, R. (1985). The Evolution of Cooperation. Basic Books.
Bharambe, A. R., Herley, C., and Padmanabhan, V. N. (2006). Analyzing and improving a bittorrent networks performance mechanisms. In INFOCOM 2006. 25th IEEE
International Conference on Computer Communications., pages 1–12. IEEE.
BitTorrent
(2011).
What
is
bittorrent?
http://www.bittorrent.com/btusers/what-is-bittorrent.
|
bittorrent.
Cisco (2010). Cisco visual networking index: Forecast and methodology, 2009-2014.
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11481360.html.
Cohen, B. (2003). Incentives build robustness in bittorrent. In 1st Workshop on Economics
of Peer-to-Peer Systems. Berkeley.
Danomac (2006). Phpbttracker+. http://phpbttrkplus.sourceforge.net/.
Eger, K. (2007).
Simulation of bittorrent
harburg.de/et6/research/bittorrentsim/index.html.
with
ns-2.
www.tu-
Feldman, M. and Chuang, J. (2005). Overcoming free-riding behavior in peer-to-peer
systems. ACM Sigecom Exchanges, 6.
Feldman, M., Chuang, J., Papadimitriou, C., and Stoica, I. (2006). Free-riding and whitewashing in peer-to-peer systems. IEEE Journal on Selected Areas in Communications, 24:1010–1019.
Feldman, M., Lai, K., Stoica, I., and Chuang, J. (2004). Robust incentive techniques
for peer-to-peer networks. In EC ’04: Proceedings of the 5th ACM conference on
Electronic commerce, pages 102–111, New York, NY, USA. ACM.
Fudenberg, D. and Tirole, J. (1991). Game theory. The MIT Press, Cambridge.
Garcia, F. D. and Hoepman, J.-H. (2004). Off-line karma: Towards a decentralized currency for peer-to-peer and grid applications (extended abstract). In Workshop on Secure
Multiparty Computations (SMP), Amsterdam, The Netherlands.
Ipoque (2008/2009). ipoque :: Bandwidth management with deep packet inspection.
http://www.ipoque.com/resources/internet-studies/internet-study-2008_2009.
Karagiannis, T., Rodriguez, P., and Papagiannaki, K. (2005). Should internet service
providers fear peer-assisted content distribution? In IMC ’05: Proceedings of the
5th ACM SIGCOMM conference on Internet Measurement, pages 6–6, Berkeley, CA,
USA. USENIX Association.
Lai, K., Feldman, M., Stoica, I., and Chuang, J. (2003). Incentives for cooperation in peerto-peer networks. In 1st Workshop on Economics of Peer-to-Peer Systems. Berkeley.
Liang, Z. and Shi, W. (2005). Enforcing cooperative resource sharing in untrusted p2p
computing environments. Mobile Networks and Applications, 10(6):971–983.
Locher, T., Moor, P., Schmid, S., and Wattenhofer, R. (2006). Free riding in bittorrent
is cheap. In In Proceedings of the 5th Workshop on Hot Topics in Networks (HotNets
’06).
70
Anais
Mansfield, E. and Yohe, G. (2000). Microeconomics: theory and applications. W. W.
Norton Company, New York.
Marques-Neto, H. T., Almeida, V. A. F., and Almeida, J. M. (2007). Pricing broadband
internet adaptive services. 15th International Symposium on Modeling, Analysis, and
Simulation of Computer and Telecommunication Systems, 2007. MASCOTS’07., pages
158–165.
Marques-Neto, H. T., Almeida, V. A. F., and Almeida, J. M. (2010). Precificação de
tráfego de internet de banda larga baseada no comportamento do usuário. XXVIII
Simposio Brasileiro de Redes de Computadores e Sistemas Distribuidos.
Parameswaran, M., Susarla, A., and Whinston, A. B. (2001). P2p networking: an information sharing alternative. Computer, 34:31–38.
Piatek, M., Isdal, T., Anderson, T., Krishnamurthy, A., and Venkataramani, A. (2007). Do
incentives build robustness in BitTorrent? In NSDI’07, Cambridge, MA.
Research, M. (2005).
Bittorrent simulator.
http://research.microsoft.com/enus/downloads/20d68689-9a8d-44c0-80cd-66dfa4b0504b/.
Salmon, R., Tran, J., and Abhari, A. (2008). Simulating a file sharing system based on bittorrent. In SpringSim ’08: Proceedings of the 2008 Spring simulation multiconference,
pages 1–5, San Diego, CA, USA. Society for Computer Simulation International.
Sirivianos, M., Park, J. H., Yang, X., and Jarecki, S. (2007). Dandelion: cooperative content distribution with robust incentives. In ATC’07: 2007 USENIX Annual Technical
Conference on Proceedings of the USENIX Annual Technical Conference, pages 1–14,
Berkeley, CA, USA. USENIX Association.
Sirivianos, M., Yang, X., and Jarecki, S. (2009). Robust and efficient incentives for
cooperative content distribution. IEEE/ACM Trans. Netw., 17:1766–1779.
TBsource and YeOK (2011).
Tbsource
http://sourceforge.net/projects/tbsource/.
php/mysql
bit-torrent
tracker.
Wongrujira, K. and Seneviratne, A. (2005). Monetary incentive with reputation for virtual
market-place based p2p. In CoNEXT ’05: Proceedings of the 2005 ACM conference on
Emerging network experiment and technology, pages 135–145, New York, NY, USA.
ACM.
Xia, R. L. and Muppala, J. K. (2010). Discovering free-riders before trading: A simple
approach. Parallel and Distributed Systems, International Conference on, 0:806–811.
Yu, B., Li, C., Singh, M. P., and Sycara, K. (2004). A dynamic pricing mechanisms for
p2p referral systems. In AAMAS ’04: Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems, pages 1426–1427, Washington, DC, USA. IEEE Computer Society.
71
Um mecanismo orientado a ISP para escolha tendenciosa de
pares no BitTorrent
Alejandra Klachquin1 , Daniel R. Figueiredo1
1
Programa de Engenharia de Sistemas e Computação – COPPE/UFRJ
Caixa Postal 68.511 – 21.941-972 – Rio de Janeiro, RJ – Brasil
alejandra@land.ufrj.br, daniel@land.ufrj.br
Abstract. BitTorrent is one of the most popular peer-to-peer (P2P) file sharing
applications used on the Internet and is responsible for a significant amount of
traffic between ISPs (Internet Service Provider) networks. A big challenge for
ISPs today is controlling traffic generated by P2P applications, whose traffic
pattern depends directly on the P2P network. Neighbor selection mechanisms
play a central role in P2P network structure as it determines with which peers a
given peer will communicate. In this work, we propose a simple biased neighbor
selection mechanism that considers the location of peers with respect to a single
ISP. A theoretical analysis and detailed BitTorrent simulations show the advantages and disadvantages of this mechanism. To mitigate its negative effects, we
propose a simple modification to the BitTorrent protocol, which impose the peers
to stay connected a small amount of time after completing the download.
Resumo. O BitTorrent é um dos aplicativos peer-to-peer (P2P) mais populares
da Internet e responsável por boa fração de tráfego nas redes dos ISPs (Internet Service Providers). Um dos grandes desafios dos ISPs está em controlar o
tráfego gerado por aplicativos P2P, cujo padrão de tráfego é influenciado diretamente pela estrutura da rede P2P. O mecanismo de seleção de vizinhos possui papel central na formação da topologia da rede, pois determina com quais
outros peers um determinado peer irá se comunicar. Neste trabalho apresentamos uma proposta simples para seleção tendenciosa de vizinhos, que leva em
consideração a localização dos peers com relação a um único ISP. Através de
uma avaliação teórica e de resultados de simulação detalhada do BitTorrent,
mostramos as vantagens e desvantagens deste mecanismo. Para mitigar seus
efeitos negativos, apresentamos uma simples modificação no protocolo BitTorrent, onde os peers passam a ser obrigados a permanecer um pequeno perı́odo
de tempo a mais conectados após concluı́rem o download.
1. Introdução
Aplicativos baseados na arquitetura peer-to-peer (P2P) vêm tendo um grande impacto
na Internet, não somente pela variedade de aplicativos e enorme número de usuários,
mas também pela grande quantidade de tráfego gerada por alguns destes aplicativos. Por
exemplo, o BitTorrent (BT) é um aplicativo para compartilhamento de arquivos usado
diariamente por milhões de usuários e responsável por uma boa fração do tráfego nas
redes dos ISPs (Internet Service Providers) [H. Schulze and K. Mochalski 2009].
Neste contexto (e.g., BT), usuários correspondem a peers que formam uma rede
e participam ativamente do processo de disseminação de conteúdo; baixando e subindo
72
Anais
blocos de um arquivo entre si. Como todos estes usuários pertencem a algum ISP (Internet
Service Provider), o tráfego gerado pelo aplicativo necessariamente atravessa as redes dos
ISPs, dando origem a um grande volume de dados.
Um dos maiores desafios enfrentados por ISPs de hoje está na redução
do tráfego P2P em suas redes, principalmente nos enlaces entre ISPs, que são
geralmente mais custosos e possuem uma maior utilização.
Diversas técnicas
vêm sendo propostas para atacar este problema e podemos dividi-las em três categorias: caching de conteúdo, shaping de tráfego, e modificação na aplicação
[Sandvine Co. 2004, Saleh and Hefeeda 2006, Shen et al. 2007, Aggarwal et al. 2007,
Bindal et al. 2006, Choffnes and Bustamante 2008, Xie et al. 2008].
A ideia de caching é armazenar conteúdo pertinente à aplicação P2P dentro do ISP
e redirecionar os pedidos dos peers internos ao ISP a este repositório. Neste caso, o ISP
deve manter e operar esta infraestrutura, que além do custo e das dificuldades técnicas,
pode acarretar em problemas legais (por exemplo, se o conteúdo armazenado for ilegal).
A ideia de shaping de tráfego é simplesmente policiar e limitar a banda para o tráfego P2P
nos enlaces entre IPSs. Por fim, a última técnica se baseia na modificação dos aplicativos
P2P para que os mesmos tenham conhecimento dos ISPs e tomem decisões neste sentido.
Parte do problema do tráfego gerado pelos aplicativos P2P é que eles não consideram o contexto ou as preferências dos ISPs em seu processo de seleção de peers para
solicitar/oferecer serviço. Por exemplo, um peer do BT pode igualmente solicitar um
bloco de dados tanto a um peer interno ao seu ISP quanto a um peer externo. Entretanto,
seria melhor para o ISP se UM peer interno fosse escolhido, reduzindo assim a quantidade
de tráfego pelo enlace entre ISPs.
Existem algumas propostas na literatura para modificação dos aplicativos de
forma a levarem em consideração a localização dos peers com relação aos ISPs
[Aggarwal et al. 2007, Bindal et al. 2006]. No caso do BT, existem propostas de
modificação apenas de uma entidade central, chamada de tracker (descrita na Seção 2)
[Bindal et al. 2006]. Esta última abordagem é bastante vantajosa pois funciona independente das muitas variações dos aplicativos BT utilizadas pelos usuários. Entretanto, tal
modificação pode trazer vantagens e desvantagens para os usuários do BT assim como
para o ISP.
Neste artigo, iremos propor uma técnica simples que modifica o comportamento
do tracker no BT com o objetivo de reduzir o tráfego entre ISPs. Nossa técnica é inspirada
na proposta de Bindal et. al [Bindal et al. 2006], porém mais fácil de ser implementada,
não sendo necessário a cooperação entre ISPs (mais detalhes na Seção 3). Avaliamos a
técnica proposta caracterizando o desempenho tanto dos usuários (i.e., tempo médio de
download), quanto do ISP (i.e., redução no tráfego inter-ISP). A avaliação é feita primeiro de forma aproximada, utilizando um modelo analı́tico simplificado, e em seguida
utilizando um simulador detalhado do BT. Nossos resultados indicam que a escolha dos
parâmetros da técnica possui um impacto fundamental em seu desempenho, podendo ser
extremamente prejudicial para os usuários em alguns casos. Em seguida, propomos uma
simples modificação no BT que oferece um desempenho superior aos usuários sem denegrir as vantagens obtidas pelo ISP.
73
O restante deste artigo está organizado da seguinte maneira. Na Seção 2 descrevemos o funcionamento do BT e na Seção 3 apresentamos nossa proposta para escolha
tendenciosa de peers. Uma avaliação simplificada do processo de seleção de vizinhos é
apresentada na Seção 4. O simulador utilizado na avaliação da proposta assim como as
medidas de interesse estão descritas na Seção 5. Os resultados obtidos são apresentados
na Seção 6. A proposta de modificação no BT é apresentada na Seção 7 juntamente com
seus resultados. Finalmente, na Seção 8, apresentamos a conclusão do trabalho.
2. BitTorrent e trabalhos relacionados
Para descrever o funcionamento do BT, iremos primeiramente definir os componentes que
constituem o aplicativo e a rede que o mesmo forma para distribuir conteúdo:
1. Peer: um usuário do aplicativo BT (na verdade, seu computador).
2. Swarm: é o conjunto de peers que estão participando da distribuição de um determinado conteúdo.
3. Seed: é um peer que possui um determinado conteúdo por completo.
4. Leecher: é um peer que possui apenas parte de um conteúdo.
5. Tracker: é um servidor que mantém uma lista com todos os peers presentes no
swarm. Entre outras atribuições, o tracker deve enviar uma lista de peers que
já fazem parte do swarm a todo peer que se junta ao swarm. Além disso, os
peers periodicamente enviam informações a respeito do andamento do download
ao tracker e eventualmente podem requisitar mais peers.
6. Torrent: é um pequeno arquivo que contém metadados a respeito do conteúdo a
ser distribuı́do, além de possuir o endereço (IP ou URL) de um ou mais trackers
que irão coordenar seus respectivos swarms.
7. Pedaços: o conteúdo a ser distribuı́do é dividido em pedaços de tamanho fixo (e.g.,
128KB), que por sua vez são divididos em blocos (e.g., 16KB). Ao adquirir todos
os blocos referentes a um determinado pedaço, um peer torna-se apto a disseminálos.
Tendo em vista essa terminologia, a rede de distribuição é criada a partir de um
usuário, o seed original, que irá publicar o conteúdo na rede através do torrent. Peers
interessados no conteúdo obtém o arquivo torrent e, com isso, contactam o tracker, o qual
irá adicioná-los ao swarm e enviar-lhes uma lista contendo o endereço de no máximo
L peers participantes do mesmo swarm. Para selecionar esses peers, o tracker utiliza
uma polı́tica completamente aleatória. Em particular, a probabilidade de um determinado
peer do swarm ser escolhido é igual para todo peer, não sendo levado em consideração
nenhum fator diferenciador entre os peers. Um novo peer estabelece conexão com os
peers da lista recebida do tracker, tornando-se vizinhos. É apenas através destes vizinhos
que um peer irá obter e oferecer blocos do conteúdo sendo distribuı́do. Por fim, caso o
número de vizinhos de um peer encontre-se abaixo de um determinado valor, uma nova
lista de peers é requisitada ao tracker. Mais detalhes sobre o funcionamento do BT podem
ser encontrados na literatura.
Repare que a seleção dos vizinhos feita pelo tracker original do BT é totalmente
aleatória e não utiliza qualquer critério de localização do peer. Um dos motivos para esta
polı́tica é dar maior diversidade na rede P2P formada pelos vizinhos, deixando a rede
mais conectada. Em contrapartida, esta mesma polı́tica pode gerar grandes distorções
74
Anais
com relação aos vizinhos de um peer e seus respectivos ISPs. Por exemplo, considere
um swarm formado por peers pertencentes a apenas dois ISPs, cada um com o mesmo
número de peers. Intuitivamente, metade dos vizinhos de um peer estará localizada no
ISP diferente ao seu. Dessa forma, muitos blocos serão trocados entre os peers de ISPs
distintos, o que é ruim para os ISPs, pois aumenta o tráfego nos enlaces inter-ISPs que
são geralmente mais custosos e mais sobrecarregados.
Com o objetivo de evitar estes cenários, diversos mecanismos de seleção
de vizinhos foram propostos na literatura [Bindal et al. 2006, Aggarwal et al. 2007,
Choffnes and Bustamante 2008, Lin et al. 2010, Le-Blond et al. 2010]. Esses métodos
levam em consideração diversas informações pertinentes aos peers e aos ISPs de forma a
realizar uma escolha de vizinhos que seja mais apropriada, ou seja, que atenda aos interesses do ISP e dos usuários. Desta forma, a polı́tica de seleção deixa de ser aleatória e
passa a ser o que chamamos de tendenciosa.
Em [Lin et al. 2010], o protocolo BT é modificado de forma que um peer somente
requisita um pedaço a peers externos ao seu ISP caso seus vizinhos internos não possuam
esse pedaço. Por outro lado, [Bindal et al. 2006] e [Le-Blond et al. 2010] modificam o
tracker de forma a limitar o número de peers externos que os usuários do ISP podem
conectar-se. [Aggarwal et al. 2007] e [Choffnes and Bustamante 2008] apresentam uma
proposta similar, porém os peers são classificados através de um oráculo, que prevê, por
exemplo, a distância entre os peers. Um estudo complementar a estes mecanismos é realizado em [Wang et al. 2010], que apresenta um método para estabelecer quantos e quais
trackers devem ser modificados com maior prioridade, a fim de implementar a seleção
tendenciosa de pares com maior eficiência. Neste trabalho, apresentamos uma proposta
similar a [Bindal et al. 2006] e [Le-Blond et al. 2010], porém mais simples. Em nosso
mecanismo não é necessária a utilização de informações que escapam ao domı́nio do ISP
e tampouco requer conhecer o número de conexões entre peers internos e externos ao
ISP.
3. Proposta de um mecanismo de escolha tendenciosa
Iremos propor um mecanismo simples de escolha tendenciosa que modifica somente o
tracker que será operado pelo ISP que deseja reduzir o tráfego BT em sua rede. Nosso
mecanismo requer apenas que o tracker seja capaz de distinguir entre peers internos e
externos ao ISP, o que é bem razoável, dado que o ISP está operando o tracker (e.g., esta
distinção poderia ser feita com base na faixa de endereços IPs). Esta informação é bastante
reduzida, quando comparado a propostas que requerem que os trackers tenham conhecimento dos diferentes ISPs dos peers que participam de um swarm. Propostas que utilizam
informações mais detalhada assumem uma cooperação entre os ISPs, o que nem sempre
é viável, pois ISPs em geral não querem revelar seus interesses a outros ISPs. Por fim, repare que um ISP tem todo interesse em operar um tracker que incorpore suas preferências,
conforme sugerido em recentes trabalhos [Wang et al. 2010, Le-Blond et al. 2010], pois
isto irá reduzir a quantidade de tráfego em sua rede.
Intuitivamente, o tracker será modificado para isolar os peers internos dos peers
externos ao ISP. O objetivo é manter o tráfego P2P o máximo possı́vel entre os peers
internos. Entretanto, este isolamento nem sempre poderá ser total, por exemplo, quando o
75
seed for externo ao ISP, ou quando tivermos poucos peers internos ao ISP. Assumiremos
que o tracker conhece o conjunto de peers internos e externos conectados no swarm.
No mecanismo proposto, a forma com a qual o tracker escolhe os vizinhos depende do peer ser interno ou externo. Seja L o número de vizinhos que o tracker deve
escolher para cada peer que entra no swarm. Ao ser contactado por um peer externo, o
tracker seleciona L vizinhos do conjunto de peers externos ao ISP, de forma aleatória com
distribuição uniforme. Desta forma, um peer externo nunca estabelece conexão com um
peer interno. Seja k > 0 um parâmetro do método que determina o número de vizinhos
externos que um peer interno irá receber ao solicitar uma lista de vizinhos para o tracker.
Logo, ao ser contactado por um peer interno, o tracker seleciona L − k vizinhos do conjunto de peers internos ao ISP e outros k vizinhos do conjunto dos externos. Repare que
um peer interno pode estabelecer conexão com um peer externo e eventualmente trocar
blocos com ele. Por fim, a escolha dos L − k vizinhos internos assim como a escolha
dos k vizinhos externos continuam sendo realizada de forma aleatória com distribuição
uniforme entre os peers de cada conjunto. Ou seja, todo peer interno ou externo tem igual
probabilidade de ser escolhido para compor a lista de vizinhos dado seus respectivos conjuntos.
TRACKER
TRACKER
Swarm:
Peers Externos
Swarm:
Peers Externos
p1
p2
p1
p2
k peers
L peers
p3
p3
.
.
.
.
.
.
Peers Internos
Peers Internos
L-k peers
(a) Peers internos ao ISP.
(b) Peers externos ao ISP.
Figura 1. Polı́tica de escolha de peers do BT modificado baseado na localização
dos peers com relação ao tracker (internos ou externos ao ISP).
A figura 1 ilustra o mecanismo de escolha tendenciosa proposta. Repare que a
escolha de vizinhos feita pelo tracker depende da localização do peer, sendo feita de
acordo com a figura 1(a) caso o peer seja interno, ou de acordo com a figura 1(b) caso o
peer seja externo.
4. Avaliação teórica
Faremos nesta seção uma avaliação simplificada do método de escolha de vizinhos proposto neste trabalho. Esta avaliação tem como objetivo caracterizar os vizinhos dos peers
internos e externos, assim como os vizinhos do seed. Esta avaliação servirá como base
para compreender os resultados obtidos com simulações detalhadas, que serão apresentados na Seção 5.
Seja nI o número de peers internos ao ISP, nE o número de peers externos, L
o número de vizinhos da lista de peers retornada pelo tracker, e k o número de vizinhos
externos que o tracker deve selecionar para um peer interno. Iremos assumir no que segue
que o swarm possui apenas um seed e que este peer é externo ao ISP. Considere a polı́tica
tendenciosa de seleção de vizinhos de um determinado peer e defina os seguintes eventos:
76
Anais
•
•
•
•
INS: um peer interno não possui o seed como vizinho.
ENS: um peer externo não possui o seed como vizinho.
LNS: um peer não possui o seed como vizinho.
NSSj : j-ésimo peer externo ao ISP para integrar a lista de vizinhos não é o seed.
Estamos interessados em calcular a probabilidade de um peer interno ter o seed
como vizinho, ou seja, PI ; e também a probabilidade de um peer externo ter o seed como
vizinho, ou seja, PE . Assim temos:
PI = 1 − P [INS] = 1 − (P [NSS1 ] ∩ . . . ∩ P [NSSk ]) =
k
nE
PE = 1 − P [ENS] = 1 − (P [NSS1 ] ∩ . . . ∩ P [NSSL ]) =
L
nE
A diferença entre PI e PE está no número de sorteios para peers externos, que é
quando o seed pode ser selecionado, que são respectivamente, k e L. Considerando que k
é menor do que L, temos que PI < PE . Esse resultado é intuitivo, já que, quanto menor o
valor de k, menor será o número de vizinhos externos que um peer interno irá conhecer,
diminuindo assim a probabilidade de um peer interno ter o seed como vizinho. Isto possui
implicações diretas no desempenho dos peers, uma vez que o seed possui todo o conteúdo
e divide sua banda igualmente entre seus vizinhos.
A partir de PI e PE , podemos obter o número médio de vizinhos do seed, uma
vez que a seleção de vizinhos é independente e identicamente distribuı́da entre os peers.
Desta forma, temos que o número médio de vizinhos do seed que são internos ao ISP é
dado por EI = nI PI = knnEI . De forma análoga, temos que o número médio de vizinhos
do seed que são externos ao ISP é dado por EE = nE PE = L.
Podemos ver que EE é constante, sempre igual a L. Para os externos, quanto maior
for o tamanho da lista de vizinhos, maior a chance que ela contenha o seed. Entretanto,
EI varia de acordo com os parâmetros do sistema. A quantidade de vizinhos internos do
seed depende de k e da relação entre nI e nE . Quanto mais internos houver no swarm
maior o número de internos que tem o seed como vizinho. Por outro lado, quanto mais
externos houver, menor será o número médio de internos que tem o seed como vizinho.
Novamente, isto possui implicação direta no desempenho dos peers.
Por fim, podemos somar EE e EI para obter o número médio de vizinhos do seed,
ou seja ET = L + knnEI . Iremos comparar este valor com o BT original, para caracterizar
o número de vizinhos do seed em ambos os casos.
No BT original, no qual a seleção de peers é aleatória e uniforme, todos os peers
têm a mesma probabilidade de ter o seed como vizinho. Seja PA a probabilidade de um
peer ter o seed como vizinho no BT original. De forma análoga ao desenvolvimento
L
acima, temos que PA = 1 − P [LNS] = 1 − (P [NSS1 ] ∩ . . . ∩ P [NSSL ]) = nI +n
. De
E
forma análoga, podemos obter o número médio de vizinhos do seed no BT original, que
é dado por EA = (nI + nE ) PA = L.
Ao comparar ET com EA , podemos ver claramente que o seed possui mais vizinhos quando o tracker implementa a seleção de peers tendenciosa. Intuitivamente, isto
ocorre por que peers externos só podem ter como vizinho outros peers externos, aumentando a chance do seed ser escolhido por estes.
77
A partir dos resultados acima, podemos calcular a fração média de banda do seed
para todos os peers internos ao ISP no mecanismo tendencioso e original. Essa medida
de interesse é importante, pois o seed além de possuir todo o conteúdo, pode ter uma
velocidade de upload maior que dos leechers, influenciando dessa forma no tempo de
download. Como o seed divide sua banda de upload de maneira uniforme entre todos os
seus vizinhos, a fração média de banda que cada vizinho recebe é simplesmente dada pelo
inverso do número médio de vizinhos que ele possui. No caso do BT tendencioso, temos
nI
que BI = EI E1T = k nIk+L
.
nE
No BT original, a fração de vizinhos do seed que são internos é dada por nI /(nI +
nE ), já que todos os peers são tratados igualmente. Logo, o número médio de vizinhos do
seed que são internos, é dado por EA nI /(nI + nE ). Com isto, obtemos a fração média de
banda do seed para cada vizinho no BT original, dada por BA = 1/EA EA nI /(nI + nE )
I
= nI n+n
.
E
Por fim, repare que BI < BA para alguns valores de k, nI e nE , em particular,
quando k é pequeno ou quando nE > nI , que são casos de interesse. Nestes casos, a
fração de banda que os peers internos recebem do seed será sempre menor no mecanismo
tendencioso. Este fato terá impacto direto no desempenho dos peers internos, que será
refletido no aumento do tempo médio de download. A próxima seção caracteriza esta e
outras observações utilizando simulações detalhadas.
5. Simulador BT e medidas de interesse
Para avaliar o desempenho do BT original e a proposta para seleção tendenciosa de vizinhos, utilizamos um simulador do aplicativo desenvolvido com a ferramenta Tangram-II
[Rocha et al. 2009]. O simulador desenvolvido é uma fiel implementação do protocolo de
referência BT 4.0.0, contendo todos os seus mecanismos (TFT, strict priority, rarest first,
end game, optimistic unchoke, etc), assim como troca e formato de mensagens (choke,
unchoke, have, block request, interest, network exit, peer list, etc). Além disso, para este
trabalho desenvolvemos uma nova versão do tracker que implementa a seleção tendenciosa de vizinhos, conforme descrito na Seção 3.
O seguinte cenário será considerado nas simulações. O seed é um peer externo e
entra no swarm no instante de tempo zero e um determinado número de leechers internos
e externos ao ISP entram no swarm de acordo com um processo de Poisson com média
de 1/10 unidade de tempo entre chegadas. Após todas as chegadas, o tracker começa
a atender aos pedidos de listas de vizinhos de cada peer. Esta decisão foi feita para
considerar o cenário flash-crowd e permitir uma melhor avaliação do mecanismo sendo
proposto. Dessa forma, todos os pedidos de lista de vizinhos que forem requisitados ao
tracker antes da chegada de todos os peers serão ignorados. Por fim, os leechers saem
do swarm assim que completam o download do último pedaço, apenas terminando de
transferir os blocos pendentes em sua lista de uploads até o momento do término.
Consideramos o cenário sem seeds internos para avaliar o pior caso para o ISP.
Um cenário aonde há pelo menos um seed interno não é muito interessante, pois esse
seed seria capaz de servir todos os peers internos sozinho, sem a necessidade de adquirir
informação externa. Neste caso, o ISP poderia até impor uma separação total entre os
peers externos e internos, fazendo k = 0.
78
Anais
O simulador desenvolvido possui muitos parâmetros que podem ser instanciados para avaliar diferentes configurações do BT. Para a avaliação que segue, alguns
parâmetros foram fixados, enquanto outros tiveram seus valores variados. Os parâmetros
e valores utilizados estão nas Tabelas 11 e 2. É importante ressaltar que uma única rodada
de simulação com 160 peers leva em torno de 1h em uma máquina Core i5. Desta forma,
os cenários que podem ser avaliados ficam bem limitados com relação ao tamanho do
swarm, pois em geral são necessárias muitas rodadas para garantir uma boa estimativa
das medidas de interesse.
Tabela 1. Parâmetros fixos.
Parâmetros
Tamanho da lista de peers enviada pelo tracker
Número mı́nimo de vizinhos
Número máximo de vizinhos
Taxa de upload de leechers
Taxa de upload do seed
Tamanho do arquivo a ser disseminado
Subdivisão de cada pedaço
Tamanho de um bloco
Valores
20
20
80
64 Kbps
200 Kbps
100 pedaços
16 blocos
64 KB
Tabela 2. Parâmetros variados ao longo das simulações.
Parâmetros
Valores
k
1, 3, 5, 7, 10
Número de leechers no swarm
90, 120, 160
Proporção entre grupos (Externos – Internos) 50% + 1 seed –50%
5.1. Medidas de interesse
Para avaliar o desempenho do BT e do mecanismo de seleção tendenciosa tanto para os
peers quanto para os ISPs, iremos considerar as seguintes medidas de interesse:
1. Redução de tráfego: Para avaliar a redução de tráfego inter-ISPs iremos utilizar
uma métrica chamada redundância. A redundância é a média do número de vezes
que um bloco entra ou sai do ISP. Assim, teremos tanto a redundância de fora para
dentro do ISP como de dentro para fora. Note que todo bloco precisa necessariamente entrar ao menos uma vez no ISP, dado que o seed é externo ao ISP.
2. Tempo de download: Para avaliar o desempenho dos peers, iremos considerar o
tempo médio de download, que é uma medida diretamente relacionada à qualidade
de serviço do aplicativo. O tempo de download de um peer é dado pelo intervalo
de tempo entre a primeira vez que este peer demonstra interesse pelo conteúdo
(envia uma mensagem a um de seus vizinhos) e o momento em que ele consegue
adquirir o conteúdo por completo. Para estimar o tempo médio de download,
iremos utilizar apenas os 50% primeiros peers a terminarem o download. Isso é
feito porque alguns leechers podem permanecer muito tempo sem possuir algum
vizinho capaz de transmitir o último pedaço do conteúdo, ocasionando grande
variabilidade no tempo de download.
1
Como descrito em [Liogkas et al. 2006], seeds possuem habitualmente taxa de upload alta em
comparação a leechers.
79
3. Fração de término: Para avaliar o desempenho percebido pelos usuários, iremos
considerar a fração de peers que terminam satisfatoriamente o download. Nem
sempre todos os peers irão concluir o download, mesmo quando temos um seed
presente no swarm. Isto pode ocorrer quando ocorre uma situação de deadlock,
que será explicada na Seção 6.3.
Para obter as medidas de interesse acima, foram realizadas 108 rodadas do simulador para cada conjunto de parâmetros. Utilizando estas rodadas, obtemos a média
amostral e o intervalo de confiança de 95%, que são reportados nos gráficos a seguir.
6. Avaliação do desempenho
Nesta seção apresentamos a avaliação do mecanismo proposto e uma comparação com o
mecanismo original. Um dos parâmetros fundamentais do mecanismo é o valor de k, que
indica o número de vizinhos externos que cada vizinho interno recebe do tracker em sua
lista de vizinhos. Os valores para k igual a zero se referem a resultados obtidos com o
BT original (sem modificações no tracker). Além disso, para cada valor de k os gráficos
apresentam os resultados para os três diferentes tamanhos de swarm considerados (90,
120 e 160 leechers).
6.1. Redução de tráfego inter-ISP
45
90
120
160
40
Redundancia - INTERNOS->EXTERNOS
Redundancia - EXTERNOS->INTERNOS
45
35
30
25
20
15
10
5
0
90
120
160
40
35
30
25
20
15
10
5
0
0
1
3
5
7
Externos permitidos (parametro k)
(a) Direção externo → interno.
10
0
1
3
5
7
10
(b) Direção interno → externo.
Figura 2. Redundância do tráfego no enlace inter-ISP para diferentes valores de
k e diferentes tamanhos de swarm (ponto k = 0 representa BT original).
Os gráficos na Figura 2 apresentam os resultados da redundância do tráfego BT.
Podemos notar uma grande redução na quantidade de tráfego redundante que entra e sai
do ISP quando utilizamos o mecanismo de escolha tendenciosa de pares para todos os
valores de k. Para valores pequenos, k = 1, a redução em ambos os sentidos chega a mais
de 75%, trazendo grandes benefı́cios para o ISP. Podemos observar ainda que à medida
que k aumenta, a redundância média também aumenta, o que é intuitivo, uma vez que
peers internos terão mais vizinhos que são externos. Podemos notar ainda que a redução
da redundância é maior no sentido interno → externo, ou seja mais peers internos deixam
de enviar blocos aos peers externos. Isto ocorre por que o seed é um peer externo ao ISP,
e necessariamente a informação precisa fluir nesta direção, além do seed ter uma maior
capacidade de upload que os outros leechers. Em todo o caso, os resultados ilustram a
vantagem que o mecanismo de seleção tendenciosa de vizinhos traz para os ISPs.
80
Anais
600
90
120
160
580
Tempo de download (seg) - INTERNOS
Tempo de download (seg) - EXTERNOS
600
560
540
520
500
480
460
440
90
120
160
580
560
540
520
500
480
460
440
0
1
3
5
7
(a) Dentre os peers externos.
10
0
1
3
5
7
10
(b) Dentre os peers internos.
Figura 3. Tempo médio de download dos peers em seus respectivos conjuntos
(ponto k = 0 representa BT original).
6.2. Tempo de download
Os gráficos na Figura 3 apresentam o tempo médio de download para os peers externos
e internos ao ISP. Considerando o conjunto de peers externos ao ISP (Figura 3.(a)), podemos ver que houve uma boa redução do tempo médio de download para valores de k
pequeno independente do tamanho de swarm quando comparado ao BT original. Ou seja,
o mecanismo acaba beneficiando os peers externos ao ISP. Entretanto, ao aumentarmos k,
o tempo médio de download se aproxima do BT original. Intuitivamente, isto ocorre pois
com o aumento de k o seed passa a ser mais compartilhado com peers internos, reduzindo
a banda do seed para os peers externos, conforme vimos na análise da Seção 4.
Considerando o conjunto dos peers internos (Figura 3.(b)), podemos observar um
comportamento bem diferente. Em particular, o tempo médio de download aumentou
significativamente para valores de k baixo, independente do tamanho do swarm, quando
comparado com o BT original. Para valores de k mais altos (k = 10) este aumento
é menor, mas ainda assim perceptı́vel. Este é um resultado bastante negativo, pois o
mecanismo tendencioso impõe um pior desempenho aos usuários do ISP.
Por fim, podemos observar que para k pequeno há uma inversão da relação do
tempo médio de download e o tamanho do swarm. Neste caso, o tempo médio de download é menor para swarms maiores. Intuitivamente, isto ocorre pois para k pequenos é
melhor que o grupo dos internos seja maior, pois isto aumenta as chances de um deles
estar conectado ao seed, como vimos na análise da Seção 4. Note que isto não ocorre para
o conjunto dos externos, onde um swarm maior sempre possui um maior tempo médio de
download.
6.3. Fração de término
A fração de término do download poderá ser diferente de zero caso ocorra uma situação
de deadlock. Um deadlock irá ocorrer quando os leechers formarem um componente conexo na rede de vizinhos, no qual cada um possui ao menos L vizinhos para os outros
peers, todos têm pelo menos um pedaço em comum faltando e o seed não faz parte deste
componente conexo. Nesse caso, cada peer possui o número mı́nimo de vizinhos estabelecido pelo protocolo e nenhum deles irão solicitar mais vizinhos ao tracker. Como ao
81
menos um pedaço está faltando na componente conexa, após certo tempo todos os leechers ficarão aguardando em deadlock pelo pedaço que nenhum deles possui, e não irão
concluir o download. Esta situação pode ocorrer no protocolo de referência do BT e não
é tratada pelo mesmo. Na prática, muitos aplicativos são modificados para poder contornar esse problema, por exemplo, solicitando mais vizinhos ao tracker quando a taxa de
download vai à zero.
1
Fracao de termino - INTERNOS
Fracao de termino - EXTERNOS
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
90
120
160
0.1
0
0
1
3
5
7
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
90
120
160
0.1
0
10
0
1
3
5
7
10
Figura 4. Fração de peers que terminam o download com relação aos seus respectivos conjuntos (ponto k = 0 representa BT original).
Os gráficos ilustrados na Figura 4 apresentam as frações médias de término de
download para os dois conjuntos de peers (internos e externos). Primeiramente, é importante notar que a fração de término não é igual a um nem mesmo no BT original, ocorrendo um percentual significativo de peers que não termina o download (entram em deadlock). Entretanto, considerando os peers externos (Figura 4.(a)), as frações de término
obtidas mostraram-se todas aproximadamente 10% acima dos valores obtidos com o BT
original, independente do valor de k. Observamos ainda que quanto maior o tamanho
do swarm menor é a fração de término dos peers. Ou seja, o mecanismo de escolha
tendenciosa melhorou a fração de término dos peers externos.
O desempenho é bem diferente quando consideramos o conjunto dos internos (Figura 4.(b)). Neste caso, a fração de término é bem menor, chegando a apenas 20% para
k = 1. Para maiores swarms (160 peers), a fração de término dos internos é sempre pior
do que o BT original. Observamos ainda que quanto maior o swarm menor é a fração
de término, assim como no caso dos externos, mas de forma mais acentuada. Este certamente é um resultado indesejado para o para o mecanismo de escolha tendenciosa. Na
próxima seção veremos como este efeito pode ser mitigado, inclusive para o BT original.
7. Modificando o BitTorrent
Vimos na seção anterior que até mesmo o BT original possui um baixo desempenho com
relação à fração de peers que terminam o download por completo, problema que é exacerbado para peers internos quando utilizamos uma polı́tica tendenciosa para seleção de
peers. Parte do problema está em os peers saı́rem do swarm assim que terminam de baixar
o último pedaço, não dando chances deste pedaço ser servido pelo peer. Tendo em vista
esta causa, propomos uma simples modificação no protocolo que irá obrigar os peers a
permanecerem no swarm e servirem outros peers por um pequeno perı́odo de tempo antes
82
Anais
de deixarem o swarm. Nossa proposta consiste de dois simples critérios para determinar
este perı́odo:
• Timeout: Se após o tempo necessário para transmitir um pedaço completo, nenhum “novo” pedaço for solicitado ao peer, o mesmo pode sair do swarm. Um
“novo” pedaço é um pedaço que não tenha sido servido por esse peer enquanto
ele era um leecher (ou seja, antes dele completar o download do último pedaço).
Repare que este tempo é o tempo de transmissão de um pedaço.
• Após servir um novo pedaço: Caso algum novo pedaço tenha sido requisitado
ao peer antes do timeout, o mesmo poderá sair da rede assim que receber a
confirmação que este mesmo pedaço está disponı́vel em algum outro vizinho.
Neste momento, o peer pode sair do swarm. No pior caso, o peer transmite o
pedaço por inteiro.
A viabilidade técnica de implementar esta proposta está baseada em um sistema
de incentivo que o ISP pode oferecer aos seus clientes caso utilizem esta versão do protocolo, como por exemplo, incentivo econômico (redução de tarifas mensais) e incentivo
de banda, aumentando a capacidade de download e upload do peer. Dessa forma, além
de contribuir para o desempenho global do swarm, os peers poderão obter vantagens individuais, permanecendo conectados um tempo adicional muito pequeno em relação ao
tempo total de download.
Intuitivamente, o mecanismo acima dá oportunidade aos vizinhos do peer de solicitar e obter o último pedaço antes do mesmo sair do swarm, o que pode ter efeitos
drásticos. Ao adquirir um bloco que nenhum outro peer em sua vizinhança possui e permanecer no swarm por mais tempo, seus vizinhos terão tempo de demonstrar interesse
neste bloco. Os que estiverem na condição unchoke, e anteriormente não estavam recebendo blocos de outro pedaço, irão requisitar o último pedaço, por ser o mais raro. Dessa
forma, o peer irá repassar o pedaço a outros peers antes da sua saı́da, garantindo assim
ao menos mais uma réplica deste raro pedaço em sua vizinhança. Repare que estes outros
peers que adquirirem este pedaço irão contribuir para sua disseminação, passando pelo
mesmo procedimento, se este também for seu último pedaço.
Ao permitir que um peer saia do swarm assim que este adquirir um último pedaço,
seus vizinhos serão obrigados a aguardar que outro peer da vizinhança obtenha este
pedaço. Se este outro peer procede da mesma maneira, a situação se repete e o problema pode se agravar, dando origem ao deadlock descrito na Seção 6.3. Desta forma, um
fenômeno relacionado com este problema, também causado pela sincronização entre os
pedaços faltantes nos peers, foi identificado e avaliado teoricamente em um recente artigo
[Hajek and Zhu 2010].
7.1. Avaliação da proposta
Os gráficos da Figura 5 ilustram a fração de término de download dos peers quando os
mesmos implementam a modificação proposta para o protocolo. A avaliação a seguir
compara os resultados anteriores (apenas mudança do tracker) com a proposta acima, na
qual peers permanecem no swarm por um pequeno perı́odo de tempo após terminarem
o download. Podemos notar que em todos os casos, a fração de término de download
é maior, sendo a diferença notável (até 50% melhor) no caso do conjunto dos internos.
Repare que para k = 5, a fração de término de peers internos e externos já é maior do que
no próprio BT original (comparar com a Figura 4).
1.1
1.1
1
Fracao de termino - INTERNOS
1
Fracao de termino - EXTERNOS
83
0.9
0.8
0.7
0.6
0.5
0.4
0.3
90
120
160
0.2
0.1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
90
120
160
0.2
0.1
0
0
0
1
3
5
7
10
0
1
3
5
7
10
Figura 5. Fração de peers que terminam o download com o BT modificado,
no qual peers permanecem no swarm um pequeno tempo após completarem o
download (ponto k = 0 representa BT original).
O tempo médio de download dos peers internos e externos quando a proposta
acima é considerada se mostrou praticamente idêntico aos obtidos sem a proposta. Entretanto, este fato era esperado uma vez que a proposta acima obriga aos peers a permanecerem no swarm por apenas um pequeno perı́odo de tempo a mais, bem menos de 1% do
tempo médio de download. A redundância média também não foi afetada pela proposta
acima, uma vez que apenas mais uns poucos blocos serão trocados pelos peers. Por falta
de espaço, não apresentamos estes resultados.
8. Conclusão
Neste trabalho propomos um mecanismo simples para escolha tendenciosa de peers que
pode ser implementado no tracker e operado pelo ISP que deseja reduzir o tráfego P2P
em seus enlaces inter-ISPs. Nossa proposta é uma variação mais realista da proposta de
Bindal et. al, pois esta última requer a cooperação entre os ISPs para ser implementada
[Bindal et al. 2006]. O mecanismo proposto utiliza apenas a distinção entre peers internos
e externos ao ISP e não requer nenhuma outra informação. Intuitivamente, o mecanismo
proposto isola parcialmente os peers internos dos peers externos.
Fazemos uma avaliação teórica simplificada do mecanismo assim como uma
avaliação usando um simulador detalhado e fiel ao protocolo BitTorrent (todos os mecanismos e mensagens do protocolo BitTorrent de referência foram implementados). Resultados da simulação mostram que o mecanismo proposto reduz significativamente o
tráfego inter-ISP gerado pelo BitTorrent, chegando a 75%, em alguns casos. Por outro
lado, os peers internos ao ISP podem ter uma perda significativa de desempenho, tanto
com relação ao tempo de download quanto à fração de término de download. Em ambos
os casos os peers internos são prejudicados com relação aos peers externos ao ISP, resultado indesejado para o ISP e seus clientes. Para mitigar este problema, propomos uma
simples modificação do protocolo BitTorrent de forma que peers permaneçam no swarm
um pequeno intervalo de tempo após completarem o download. Resultados desta proposta mostram que o desempenho dos peers melhora significativamente, principalmente
a fração de término de download, exigindo apenas que os peers permaneçam o tempo
de transmissão de um pedaço, o que é mais 10 vezes menor que o tempo de médio de
download.
84
Anais
Por fim, este trabalho ilustra como polı́ticas para seleção de vizinhos podem ser
vantajosas tanto para os ISPs, com relação à gerência do tráfego na rede, quanto para os
seus clientes, que podem continuar a terem um bom desempenho de seus aplicativos. Esta
é uma questão central a atual discussão sobre aplicativos P2P e ISPs.
Referências
Aggarwal, V., Feldmann, A., and Scheideler, C. (2007). Can ISPs and P2P users cooperate
for improved performance? ACM SIGCOMM Computer Communication Review.
Bindal, R., Cao, P., Chan, W., Medved, J., Suwala, G., Bates, T., and Zhang, A. (2006).
Improving traffic locality in BitTorrent via biased neighbor selection. In IEEE International Conference on Distributed Computing Systems.
Choffnes, D. R. and Bustamante, F. E. (2008). Taming the torrent: A practical approach
to reducing cross-ISP traffic in P2P systems. In ACM SIGCOMM.
H. Schulze and K. Mochalski (2009). Internet Study 2008/2009. Technical report, Ipoque.
URL http://www.ipoque.com/resources/internet-studies/internet-study-2008 2009.
Hajek, B. and Zhu, J. (2010). The missing piece syndrome in peer-to-peer communication. CoRR, abs/1002.3493.
Le-Blond, S., Legout, A., and Dabbous, W. (2010). Pushing bittorrent locality to the limit.
CoRR, abs/1011.1892.
Lin, M., Lui, J. C. S., and Chiu, D.-M. (2010). An isp-friendly file distribution protocol:
Analysis, design, and implementation. IEEE Trans. on Par. and Dist. Sys.
Liogkas, N., Nelson, R., Kohler, E., and Zhang, L. (2006). Exploiting BitTorrent for Fun
(But Not Profit) IPTPS - International workshop on Peer-To-Peer Systems
Rocha, A., Jaime, G., Murai, F., Alves, B., Figueiredo, D., Leão, R. M. M., and de Souza e
Silva, E. A. (2009). Novas evoluções integradas à ferramenta Tangram-II v3.1. In Salão
de Ferramentas / XXVII Simpósio Brasileiro de Redes de Computadores.
Saleh, O. and Hefeeda, M. (2006). Modeling and caching of peer-to-peer traffic. In IEEE
International Conference on Network Protocols.
Sandvine Co. (2004). Meeting the challenge of today’s evasive P2P traffic. Technical
report, Waterloo, Canada. An Industry Whitepaper.
Shen, G., Wang, Y., Xiong, Y., Zhao, B. Y., and Zhang, Z.-L. (2007). HPTP: Relieving
the tension between ISPs and P2P. In Int. Workshop on Peer-To-Peer Systems (IPTPS).
Wang, H., Liu, J., Chen, B., Xu, K., and Ma, Z. (2010). On tracker selection for peer-topeer traffic locality. In Peer-to-Peer Computing’10
Xie, H., Yang, Y. R., Krishnamurthy, A., Liu, Y., and Silberschatz, A. (2008). P4P:
provider portal for applications. In ACM SIGCOMM.
Sistemas P2P
♦
Sessão Técnica 3
Redes Veiculares e
Direções de Pesquisa
87
Análise sobre o impacto da densidade, da carga e do padrão de
mobilidade sobre o desempenho de protocolos de roteamento
para Redes Veiculares
Bruno G. Mateus1 , Carina T. de Oliveira2 , Rossana M. C. Andrade1
1
Grupo de Redes Sistemas e Engenharia de Software (GREAT)
Universidade Federal do Ceará (UFC)
2
CNRS Laboratoire d’Informatique de Grenoble UMR 5217
Université Joseph Fourier (UJF)
Abstract. Advances in mobile computing and wireless communications have led
to the development of the Intelligent Transportation Systems, which include the
vehicular networks. In these networks, routing is a challenging task due to the
high mobility of nodes, the instability of wireless links and the diversity of scenarios. For this reason, several routing protocols have been designed with the
goal of solving one or more specific problems of each scenario. In this paper,
we analyze through simulations the impact of density, load and mobility pattern
in the performance of routing protocols in vehicular networks. The main contribution of this work is, thus, that our results can provide new directions for
designing efficient vehicular network routing protocols, able to adapt to different scenarios. To achieve this goal, four protocols are evaluated in urban and
highway scenarios.
Resumo. Os avanços alcançados na computação móvel e na comunicação sem
fio levaram ao desenvolvimento dos Sistemas Inteligentes de Transporte, onde
pode-se destacar as redes veiculares. Nestas redes, o roteamento é uma tarefa desafiadora devido à alta mobilidade dos nós, à instabilidade dos enlaces
sem-fio e a diversidade de cenários. Por essa razão, diversos protocolos de roteamento foram projetados com o objetivo de solucionar um ou mais problemas
especı́ficos de cada cenário. Neste artigo, analisamos através de simulações o
impacto da densidade, da carga e do padrão de mobilidade no desempenho do
roteamento em redes veiculares. A principal contribuição deste trabalho é que
os resultados alcançados forneçam diretrizes para os projetistas de redes veiculares desenvolverem protocolos de roteamento eficientes, capazes de se adaptar
aos mais diversos cenários. Para alcançar esse objetivo, quatro protocolos são
avaliados nos cenários urbano e de rodovia.
1. Introdução
É cada vez mais clara a importância da Tecnologia da Informação (TI) no desenvolvimento social, econômico e cultural de uma nação. Neste contexto, existe uma
demanda crescente do usuário de permanecer conectado onde quer que esteja e a qualquer momento, até mesmo quando está em movimento. As redes sem fio desempenham
um papel fundamental nessa tarefa, possibilitando que o usuário se conecte em sua casa,
no trabalho, no shopping e, até mesmo, no veı́culo. Este último cenário vem recebendo
88
Anais
bastante atenção dos pesquisadores e da indústria automobilı́stica, que estudam soluções
de redes capazes de integrar a nova geração de redes sem fio em veı́culos automotores. O
objetivo é desenvolver um Sistema de Transporte Inteligente (Intelligent Transportation
Systems - ITS) capaz de integrar diferentes veı́culos e possibilitar que aplicações com diferentes requisitos sejam atendidas satisfatoriamente. Para alcançar este objetivo foram
criadas as redes veiculares [Hartenstein and Laberteaux 2008].
Em um cenário de redes veiculares existem dois tipos de nós: veı́culo automotor
e infra-estrutura fixa [Bernsen and Manivannan 2008]. Os veı́culos automotores são nós
móveis como carros, caminhões e ônibus equipados com um dispositivo de comunicação
sem fio. A infra-estrutura fixa é fornecida pelos pontos de acesso posicionados nas margens de ruas e estradas. Os veı́culos automotores podem se comunicar entre si, veı́culoveı́culo (Vehicle-to-Vehicle - V2V), ou com pontos de acesso fixos, veı́culo-infra-estrutura
(Vehicle-to-Infrastructure - V2I). Neste trabalho, foca-se nos desafios das redes V2V.
Por ser uma tecnologia emergente, muitas aplicações já foram desenvolvidas para
ambientes de redes veiculares. Grande parte dessas aplicações sugere a existência de
uma comunicação de múltiplos saltos. Por isso, surge a necessidade de um protocolo
de roteamento eficiente capaz de lidar com a topologia altamente dinâmica da rede e as
frequentes desconexões. Além disso, outra caracterı́stica inerente das redes veiculares
que contribui para tornar ainda mais desafiador o desenvolvimento de um protocolo de
roteamento é a variedade de cenários, tais como: urbano, rodovia e rural.
Em redes veiculares, o cenário é uma caracterı́stica que influencia diretamente
a mobilidade dos nós. Logo, independentemente do cenário onde um dado veı́culo
esteja presente, é necessário que o protocolo de roteamento opere de forma satisfatória [Bernsen and Manivannan 2008], devendo ser inclusive tolerante às mudanças de
cenário. Devido à grande variedade de cenários, diversos protocolos de roteamento foram
projetados com objetivo de solucionar um ou mais problemas especı́ficos de cada cenário.
Por exemplo, Zhang et al. voltaram suas atenções para o cenário rural, caracterizado por
redes esparsas, com pouca densidade e muita mobilidade. Já em [Lochert et al. 2003]
e [Tian et al. 2003], o foco é o cenário urbano com cruzamentos e sinalizações. Em
cenários de rodovia, muitos trabalhos propõem mecanismos para utilizar de melhor maneira o curto tempo de contato entre os veı́culos [Cavalcanti et al. 2010].
Devido ao caráter especı́fico dos protocolos que hoje são encontrados na literatura, faz-se necessário novos protocolos de roteamento capazes de apresentar um desempenho satisfatório nos mais diversos tipos de cenários de redes veiculares, por essa razão,
vários esforços vêm sendo realizados para desenvolver um protocolo para todos esses
cenários [Jin et al. 2009]. Contudo, apesar de existirem várias soluções propostas para o
problema do roteamento em redes veiculares, ainda não está claro que caracterı́sticas
especı́ficas os protocolos devem levar em consideração na tomada de decisão, já que
nenhuma das soluções propostas alcançou um desempenho satisfatório em mais de um
cenário [Boban et al. 2008].
Como ponto inicial em direção à compreensão dos principais fatores que devem
ser considerados ao se projetar um protocolo de roteamento eficiente para redes veiculares, neste trabalho é proposta a identificação e análise através de simulações do impacto
da densidade veicular, da carga da rede e da mobilidade no desempenho de um protocolo
89
de roteamento. Neste trabalho nós focamos na análise dos cenários urbano e de rodovia já
que em escala global esses dois cenários concentram a maior parte do tráfego de veı́culos.
O restante do artigo está organizado da seguinte forma: a Seção 2 discute os trabalhos relacionados. Na Seção 3 apresentamos o ambiente utilizado nas simulações, bem
como a modelagem dos cenários utilizados. Os resultados são analisados na Seção 4. Por
fim, são apresentadas as conclusões e os trabalhos futuros na Seção 5.
O protocolo MURU (Multi-hop Routing Protocol for Urban Vanets) [Mo et al. 2006] utiliza a métrica EDD (Expected Disconnection Degree) para
a escolha das rotas com menor probabilidade de sofrer uma quebra de enlace em um
determinado perı́odo de tempo. O EDD é calculado através das informações sobre
velocidade e trajetória de cada veı́culo aliadas a uma função de predição de movimento.
Para isso, é assumida a existência de um serviço de localização (GPS), assim como
o conhecimento prévio da topologia da rede através de mapas digitais. De posse da
posição do destino, o protocolo calcula o menor caminho fı́sico até o destino baseado nas
informações obtidas dos mapas. A partir desse momento, inicia-se o envio de mensagens
de requisição de rotas (RREQ), que são limitadas por uma área retangular que varia
em função da posição dos nós de origem e destino e do comprimento do quarteirão.
Quando um nó recebe uma mensagem RREQ, ele determina o EDD entre ele e o nó que
enviou a mensagem. Em seguida, ele atualiza a métrica EDD no pacote. Enquanto ele
espera um tempo proporcional ao EDD (backoff time), ele escuta as mensagens RREQ
de outros vizinhos. Se o nó não descartar a mensagem RREQ durante esse tempo, ele
irá retransmitir dentro de uma área retangular menor do que a do nó anterior. Segundo o
protocolo, um nó descarta uma mensagem RREQ se ele receber uma nova RREQ com
valor menor no campo EDD. Depois que o destino recebe algumas mensagens RREQ de
diferentes rotas, ele escolhe a rota com o menor EDD acumulado e envia uma resposta
para a origem contendo o caminho escolhido. Os autores apresentam que o MURU é
livre de ciclos e que escolhe os caminhos com o menor EDD.
O ROMSGP (Receive On Most Stable Group-Path) [Sakhaee et al. 2007] é um
protocolo que agrupa os veı́culos utilizando informações de velocidade e direção do movimento. O protocolo procura garantir que os caminhos escolhidos sejam compostos por
veı́culos que estão se movendo juntos (direção e velocidade semelhantes). Logo, rotas
que envolvam veı́culos de um mesmo grupo são consideradas estáveis. Dado um conjunto de rotas possı́veis, o protocolo escolhe o caminho com o maior tempo de expiração
do enlace, representado pela métrica LET (Link Expiration Time). Para por em prática o
agrupamento de veı́culos, é assumido que cada veı́culo possui um GPS e que sua posição
é verificada a cada segundo. As informações sobre o grupo são incluı́das nas mensagens
de requisição de rotas. Dessa forma, quando um veı́culo recebe um RREQ, ele compara
o identificador do seu grupo com o identificador do veı́culo que originou a mensagem.
Se eles estiverem em grupos diferentes, o enlace entre eles é penalizado, sendo marcado
como instável, e a mensagem RREQ é descartada. Dessa forma, o mecanismo evita a
retransmissão de pacotes que podem tornar os enlaces instáveis. O ROMSGP diminui
a sobrecarga da rede evitando o envio de mensagens de controle, requisições de rotas e
mensagens de erros dos enlaces instáveis.
Outras propostas de roteamento podem ser encontradas na literatura.
Al-
90
Anais
gumas utilizam informações sobre o tráfego [Seet et al. 2004] e densidade da
via [Azarmi et al. 2008] para escolher o melhor caminho. Outros trabalhos optam por não utilizar serviço de localização e mapas para realizar o roteamento [Naumov and Gross 2007].
Em [Perkins et al. 2001], os autores comparam através de simulação dois protocolos importantes da redes móveis ad
hoc, o AODV [Perkins and Royer 1999] e o DSR [Johnson et al. 2001].
Já
em [Naumov et al. 2006] os autores comparam e analisam o desempenho dos protocolos AODV e GPSR [Karp and Kung 2000] no ambiente veicular. Ao final da análise, são
propostas algumas melhorias para ambos protocolos.
3. Ambiente de simulação
Para aproximar ao máximo a avaliação dos resultados em simuladores com
o mundo real, neste trabalho são utilizados mapas do formato OpenStreetMap
(OSM) [openstreetmap 2009]. O OSM é um formato de mapa livre e editável que possibilita o uso de dados geográficos de qualquer lugar do mundo de maneira colaborativa. Os
mapas do formato OSM aqui utilizados são baseados em mapas reais e estão disponı́veis
no site da OpenStreetMap, onde o usuário pode exportar um mapa real de qualquer cidade
do mundo, desde que seu mapa tenha sido descrito no formato OSM. Neste trabalho, dois
mapas são utilizados: um para representar o cenário urbano e outro para representar o
cenário de rodovia. Para o cenário urbano é utilizado o mapa do centro de Ottawa. Este
mapa engloba uma área de um quilômetro quadrado, contendo aproximadamente vinte
ruas, algumas de mão dupla outras de sentido único. O mapa contém cerca de oitenta
cruzamentos, dos quais cerca de cinquenta possuem semáforos. Para o cenário de rodovia
é utilizada uma rodovia de oito quilômetros de comprimento e oito faixas de veı́culos,
quatro para cada sentido.
Para tornar os dois cenários mais realı́sticos, representamos no simulador de
tráfego SUMO [SUMO 2009] alguns perfis de motoristas através das definição de tipos
de veı́culos, apresentados na Tabela 1. Como não se pode definir ao certo quantos perfis
de motoristas existem, optamos por utilizar três perfis: motoristas lentos, motoristas em
velocidade média e motoristas rápidos, os quais são distribuı́dos aleatoriamente em cada
rodada de simulação. Para isso, nos baseamos na velocidade máxima das vias urbanas de
trânsito rápido brasileiras que é 80 km/h. A partir desse valor definimos um perfil para
veı́culos que trafegam abaixo desse valor e um perfil que representa motoristas infratores,
que podem alcançar até 120 km/h.
Tipo
Velocidade máxima
Aceleração
Desaceleração
Tipo 1
Tipo 2
Tipo 3
120 km/h
80 km/h
60 km/h
9.7 km/h2
9 km/h2
7.7 km/h2
4.5 km/h2
4.5 km/h2
4.5 km/h2
Tabela 1. Tipos de veı́culos.
Neste trabalho, o simulador de rede escolhido foi o Network Simulator 2 (versão
2.33) [McCanne and Floyd ] por ser um simulador amplamente utilizado na literatura para
simulações de redes móveis ad hoc, por ser um programa de código aberto e, principalmente, pela compatibilidade com o SUMO. Os parâmetros utilizados no NS-2 estão listados na Tabela 2. Para nossos experimentos, consideramos as aplicações dos nós como
geradoras de dados CBR transmitidos em intervalos constantes de tempo. Os valores
apresentados nos gráficos da seção de resultados são valores médios de 30 amostras ob-
91
tidas por meio de repetições das simulações. Todos os gráficos são apresentados com
intervalo de confiança calculado com um nı́vel de confiança de 95%.
No simulador NS-2 foram implementados os protocolos MURU e ROMSGP. Apesar de utilizarem métricas diferentes, o MURU e o ROMSGP compartilham algumas caracterı́sticas comuns. Primeiramente, ambos os protocolos são reativos e baseados em
posição, utilizando informações sobre a mobilidade dos nós durante o roteamento. Outra
caracterı́stica comum é o uso de GPS, útil para calcular a posição atual dos veı́culos. Além
disso, para evitar o congestionamento da rede, o MURU e o ROMSGP implementam mecanismos que minimizam o número de pacotes de controle. Apesar das semelhanças, o
MURU e o ROMSGP também apresentam algumas diferenças. Enquanto o MURU necessita de mapas externos para calcular sua métrica principal, o ROMSGP agrupa os veı́culos
baseado na direção do movimento. O MURU e o ROMSGP também foram comparados
com dois protocolos legados de redes ad hoc, o AODV e o DSR, por seus resultados
significativos em cenários de mobilidade.
Parâmetro
Valor
Aplicação
Protocolos MAC/Fı́sico
Dimensão do cenário
Raio de transmissão
Modelo de propagação
Modelo de mobilidade
Tempo de simulação
Quantidade de nós
Quantidade de nós fontes
Intervalo entre envios
Tráfego CBR
IEEE 802.11
1 km x 1 km
400 m
TwoRayGround
Kraussβ car-following
200 s
100 - 500
10% - 60%
0.5 s
Tabela 2. Parâmetros de simulação no NS-2.
4. Resultados
Analisamos o impacto de três diferentes condições de rede sobre o desempenho
dos protocolos simulados: Densidade - variação da quantidade de veı́culos por unidade de
área; Carga - variação do número de veı́culos fonte (geradores de tráfego); e Mobilidade
- variação do tipo de cenário (urbano ou rodovia). Os resultados são apresentados nas
próximas seções em função dos Pacotes de Controle - número médio de pacotes de
controle utilizados para manter o funcionamento da rede; e da Taxa de Entrega - razão
média entre o número de dados entregues ao destino com relação ao número de dados que
são enviados pelo nó de origem.
4.1. Pacotes de Controle
Os pacotes de controle, apesar de indispensáveis para manter o correto funcionamento da rede, são os principais responsáveis pela sobrecarga da rede. À medida que a
quantidade de pacotes de controle enviados cresce, as chances da rede ficar congestionada
aumentam e, consequentemente, as perdas de pacotes passam a ser mais frequentes. Entretanto, a sobrecarga da rede pode ser amenizada se o protocolo de roteamento utilizar
um mecanismo para controlar o envio e/ou propagação desses pacotes.
A Figura 1 apresenta a quantidade de pacotes de controle enviados por cada protocolo de roteamento em função da densidade de veı́culos nos cenários urbano e rodovia.
Conforme pode ser visto nas Figuras 1(a) e 1(c), o DSR é o protocolo que mais envia
pacotes de controle no cenário urbano. Ao comparar o desempenho do DSR com o do
92
Anais
AODV, pode-se observar que o AODV envia menos pacotes de controle. Isso deve-se aos
diferentes mecanismos de roteamento utilizados por eles. Como o DSR realiza o roteamento baseado na origem, quando um enlace quebra, a não existência de um caminho
alternativo no cache faz com que um novo procedimento de descoberta de rota seja executado pelo nó de origem. Por outro lado, no AODV qualquer nó pode obter rotas novas
para o destino, logo, quando um enlace quebra, um nó intermediário pode iniciar o procedimento de rota, diminuindo assim o número de mensagens de controle para restabelecer
o caminho quebrado.
A variação da densidade veicular não influencia da mesma forma os diversos
cenários urbano e de rodovia. Em cenários urbanos, os cruzamentos com semáforos tendem a concentrar um maior número de veı́culos, enquanto regiões sem sinalização apresentam maior fluidez do tráfego. Já em cenários de rodovia, os veı́culos são distribuı́dos
quase que uniformemente ao longo das vias devido a ausência de regiões concentradoras
de veı́culos, permitindo maior fluidez do tráfego nas vias. Por essa razão, o aumento da
densidade de veı́culos afeta de maneira mais suave o envio de pacotes de controle, como
apresenta as Figuras 1(b) e 1(d). Pode-se observar no cenário de rodovia que quando a
rede é esparsa, o desempenho dos protocolos MURU e ROMSGP é semelhante. Além
disso, a diferença entre o número de pacotes enviados é bem menor se comparada com
uma rede nas mesmas condições no cenário urbano. Isso ocorre devido ao padrão de mobilidade do cenário de rodovia somado às caracterı́sticas dos mecanismos de controle de
sobrecarga utilizados pelos protocolos. No cenário de rodovia em uma rede esparsa, o
mecanismo utilizado pelo MURU (baseado na área de broadcast) se torna menos restritivo que o utilizado pelo ROMSGP, já que alguns caminhos formados por nós que estão
se movimentando no sentido contrário ao movimento do nó fonte serão propagados devido à proximidade das vias, enquanto no ROMSGP apenas caminhos compostos por nós
que se movimentam no mesmo sentido serão propagados. Entretanto, quando a densidade da rede aumenta, a área de broadcast passa a ser mais restritiva que o agrupamento
de veı́culos realizado pelo ROMGSP, já que devido ao aumento do número de veı́culos,
o número de caminhos de ambos os sentidos também aumenta. Assim, como a única
restrição imposta pelo ROMSGP para utilizar um caminho é que os nós que o compõe
estejam se movimentando na mesma direção, boa parte dos novos caminhos poderão ser
utilizados.
A Figura 2 apresenta a quantidade de pacotes de controle de acordo com o tipo de
pacote de controle (RERR, RREP e RREQ) em função do cenário e para cada protocolo
de roteamento. No cenário de rodovia, mais mensagens de reply são enviadas, logo mais
caminhos são estabelecidos. Contudo, devido ao elevado número de mensagens de erro,
pode-se concluir que grande parte desses caminhos quebram durante a transmissão das
mensagens de dados. Além disso, podemos verificar que em redes esparsas a mudança
de cenário é uma caracterı́stica determinante para o desempenho dos mecanismos de controle de sobrecarga do MURU e do ROMSGP. Enquanto no cenário urbano o MURU
envia menos pacotes de controle, no cenário de rodovia o ROMSGP é quem envia menos
pacotes de controle.
Em relação à sobrecarga da rede, os protocolos desenvolvidos para redes veiculares obtiveram melhor desempenho em ambos os cenários devido aos mecanismos de
controle de carga da rede implementados por eles, já que ao utilizar parâmetros de mobi-
(a) Cenário Urbano: 10% de nós fonte
(b) Cenário de Rodovia: 10% de nós fonte
(c) Cenário urbano: 30% de nós fonte
(d) Cenário de Rodovia: 30% de nós fonte
93
Figura 1. Quantidade de pacotes de controle enviados por cada protocolo de roteamento em função
da densidade de veı́culos nos cenários simulados.
Figura 2. Quantidade de pacotes de controle enviados em função do tipo de pacote de controle, do
cenário e do protocolo de roteamento. Rede composta por 100 veı́culos e 50% de nós fonte.
lidade eles conseguem evitar o envio desnecessário de mensagens de pacotes de controle,
principalmente quando a rede é muita densa. Para melhor entender o impacto da carga da
rede no desempenho dos protocolos foram realizadas simulações variando o número de
veı́culos fonte presente nos cenários. A quantidade de veı́culos fonte foi variada de 10%
a 60% do total de veı́culos. A Figura 3 demonstra o impacto do aumento do número de
94
Anais
nós fonte na quantidade de pacotes de controle necessária para manter a rede em funcionamento. Quando a carga da rede aumenta, o número de pacotes de controle enviados
aumenta. Isso ocorre devido ao maior número de pacotes de dados enviados. Como os
quatro protocolos simulados utilizam a estratégia reativa, é natural que a medida que o
número de fontes aumente, a quantidade de pacotes de controle enviados cresça também.
A Figura 3(a) mostra o desempenho dos protocolos em uma rede com 100
veı́culos. Como a rede representada nesse cenário é esparsa, os protocolos sofrem com a
escassez de caminhos para a realização do roteamento. Por essa razão, várias mensagens
de requisição de rotas são enviadas pelos protocolos, em especial o AODV, o que resulta
na maior quantidade de envio de pacotes de controle. O mesmo problema não ocorre
com o ROMSGP e o MURU devido ao mecanismo de controle de sobrecarga utilizado
por eles, que limita o encaminhamento de mensagens de requisição. Apesar do protocolo
DSR não ser eficiente em cenários com alta mobilidade, nesse cenário ele se sobressaiu
em relação ao AODV devido ao mecanismo de cache utilizado por ele. A Figura 3(c)
demonstra comportamentos similares dos protocolos simulados, ou seja, à medida que
o número de fontes aumenta, os protocolos sobrecarregam mais a rede. Conforme dito
anteriormente, os protocolos ROMSGP e MURU sofrem menos com o aumento da carga
da rede graças aos mecanismos de controle que utilizam. Nesse contexto, devido à dinamicidade da rede e ao maior número de caminhos existentes, o DSR foi o protocolo que
mais sobrecarregou a rede.
Em relação aos resultados obtidos na simulação dos cenários de rodovia (Figuras 3(b) e 3(d)), pode-se observar um comportamento distinto dos protocolos AODV e
DSR se compararmos aos resultados alcançados no cenário urbano. Em relação ao desempenho do DSR no cenário de rodovia, nós podemos observar que o aumento da carga
da rede não resulta em um crescimento acentuado do número de pacotes de controles enviados, mantendo-se praticamente constante. Isso ocorre porque no cenário de rodovia o
DSR consegue utilizar de maneira mais eficiente os caminhos alternativos armazenados
em cache. Por essa razão, quando a carga da rede é grande, o AODV é o protocolo que
mais envia pacotes de controle.
4.2. Taxa de Entrega
A Figura 4 demonstra o impacto da densidade da rede na taxa de entrega para
os cenários urbano e de rodovia. No cenário urbano, o aumento da densidade afeta a
taxa de entrega de duas formas distintas (Figuras 4(a) e 4(c)). Em redes esparsas, o
aumento da densidade determina uma maior quantidade de caminhos possı́veis de serem
utilizados no roteamento, o que consequentemente resulta em taxas de entrega melhores.
Contudo, quando a rede torna-se muito densa a taxa de entrega passa a ser prejudicada e,
a partir desse ponto, o aumento da densidade passa a afetar de forma negativa a taxa de
entrega. Destaca-se que o comportamento da taxa de entrega não é determinado apenas
pela densidade da rede, mas também pela quantidade de nós fontes. Nesse caso, quanto
maior a quantidade de nós fonte, maior o número de pacotes de controle necessário para
manter a rede funcionando. Contudo, à medida que a carga da rede aumenta, perdas de
pacotes passam a ser mais frequentes, degradando assim a taxa de entrega.
Nas Figuras 4(a) e 4(b) a carga da rede é pequena (10% de nós fonte). Por essa
razão, os protocolos AODV e DSR apresentam-se mais eficientes quando a densidade é
baixa, enquanto o MURU e ROMSGP sofrem para entregar os pacotes devido ao me-
(a) Cenário Urbano: 100 veı́culos
(b) Cenário de Rodovia: 100 veı́culos
(c) Cenário Urbano: 300 veı́culos
(d) Cenário de Rodovia: 300 veı́culos
95
Figura 3. Quantidade de pacotes de controle enviados por cada protocolo de roteamento em função
do número de fontes nos cenários simulados.
canismo implementado por eles para evitar a sobrecarga da rede, que é responsável por
filtrar os caminhos existentes elegendo os que podem ser utilizados. À medida que a
rede se torna mais densa, os protocolos passam a sofrer mais com a sobrecarga da rede.
Contudo, os protocolos MURU e ROMSGP conseguem lidar melhor com esse problema,
amenizando assim o impacto sobre a taxa de entrega. Já os protocolos DSR e AODV
têm seus desempenhos consideravelmente afetados pelo envio excessivo de pacotes de
controle, podendo ser observada uma queda acentuada da taxa de entrega. Comparando a
melhor taxa de entrega alcançada pelos protocolos com a taxa atingida com a rede mais
densa, pode-se perceber de maneira mais clara o quão eficientes são os protocolos de
roteamento para redes veiculares.
A Tabela 3 mostra que os protocolos MURU e ROMSGP lidam melhor com o
aumento da carga da rede obtendo a menor variação da taxa de entrega nas condições
extremas em ambos os cenários. No cenário urbano, a variação medida da taxa de entrega
dos protocolos MURU e ROMSGP foi de 10% e no cenário de rodovia foi de 5% para o
MURU e 15% para o ROMSGP. Além disso, no cenário urbano esses protocolos atingiram
uma maior taxa de entrega quando comparados com os resultados obtidos no cenário de
rodovia. Apesar do AODV e DSR sofrerem as maiores variações da taxa de entrega em
ambos os cenários, esses protocolos alcançaram a melhor taxa de entrega. No cenário
urbano, o DSR entregou 95% dos pacotes enquanto o AODV entregou 90%. No cenário
96
Anais
(a) Cenário urbano: 10% de nós fonte
(b) Cenário de rodovia: 10% de nós fonte
(c) Cenário urbano: 30% de nós fonte
(d) Cenário de rodovia: 30% de nós fonte
Figura 4. Taxa de entrega para cada protocolo de roteamento em função da densidade de veı́culos
nos cenários simulados.
de rodovia, o DSR entregou cerca de 90% dos pacotes, enquanto o AODV conseguiu
entregar cerca de 85%. No entanto, quando a densidade da rede é máxima, o ROMSGP
torna-se o protocolo mais eficiente, seguido respectivamente pelo AODV, MURU e DSR.
As Figuras 4(c) e 4(d) mostram o desempenho dos protocolos em uma rede com
30% de nós fonte. Uma maior quantidade de nós gerando mensagens só acelera o processo observado no cenário anterior: a degradação da taxa de entrega devido ao aumento
da densidade e da carga da rede. Como pode ser visto, quando a densidade da rede é
baixa, os protocolos AODV e DSR são mais eficientes pelas mesmas razões abordadas
anteriormente. Contudo, quando a densidade passa a ser de duzentos veı́culos, podemos
observar no cenário urbano um comportamento diferente em relação ao cenário anterior:
o protocolo que alcança a melhor taxa de entrega é o ROMSGP e não o AODV, devido
a sobrecarga da rede gerada pelo pacotes de controle enviados. Por sua vez, no cenário
de rodovia, o protocolo ROMSGP passar a ser o mais eficiente após a densidade veicular
ultrapassar trezentos veı́culos, já que no cenário de rodovia o aumento da densidade afeta
de maneira mais sutil o envio de pacotes de controle e, consequentemente, a sobrecarga
da rede.
A Tabela 3 mostra novamente que o DSR é o protocolo que mais sofre com o
aumento da densidade e carga da rede. Por outro lado, o MURU é novamente o protocolo
Porcentagem
de veı́culos
fontes
10%
30%
Protocolo
DSR
AODV
MURU
ROMSGP
DSR
AODV
MURU
ROMSGP
Melhor taxa de entrega
alcançada
Urbano
Rodovia
95%
90%
55%
70%
90%
95%
55%
70%
90%
85%
40%
60%
57%
77%
40%
55%
Taxa de entrega
alcançada com
densidade máxima da
rede
Urbano
Rodovia
20%
47%
45%
60%
10%
20%
35%
35%
15%
55%
35%
45%
5%
27%
30%
35%
97
Variação das taxas
alcançadas em
condições extremas
Urbano
Rodovia
75%
43%
10%
10%
80%
75%
20%
35%
75%
30%
5%
15%
52%
50%
10%
20%
Tabela 3. Comparação das taxas de entrega alcançadas em situações extremas da rede com 10% e
30% de nós fonte nos cenários simulados.
que apresentou a menor variação da taxa de entrega: 20% no cenário urbano e 10% no
cenário de rodovia. No cenário de rodovia, o AODV foi o protocolo que alcançou a maior
taxa de entrega, entregando 77% quando a rede possuı́a cem veı́culos. No cenário urbano,
o AODV também foi o protocolo que alcançou a melhor taxa de entrega, entretanto, com
o aumento da densidade ele teve seu desempenho rapidamente degradado. Comparando o
desempenho do ROMSGP nos cenários simulados, nós podemos perceber que no cenário
de rodovia o seu desempenho diminui suavemente com o aumento da densidade devido
ao menor impacto do aumento da densidade na quantidade de pacotes de controle enviados e, consequentemente, no aumento da sobrecarga da rede. Devido ao mecanismo de
controle de sobrecarga implementado pelo MURU, este foi o protocolo menos afetado
pelo aumento da densidade nos cenários simulados.
A Figura 5 apresenta o impacto do aumento da carga na taxa de entrega dos nós, no
cenário urbano e de rodovia. As Figuras 5(a) e 5(b) ilustram o desempenho dos protocolos
simulados quando aplicados em uma rede esparsa, mais especificamente com cem nós.
Como se trata de uma rede esparsa, ou seja, com poucos caminhos possı́veis de serem
utilizados no roteamento, os protocolos MURU e ROMSGP não superam os protocolos
tı́picos de MANETs, pois eles implementam mecanismos para evitar a sobrecarga da rede
que, por sua vez, acabam impedindo o roteamento através de caminhos que, apesar de não
serem estáveis, permitem a entrega dos pacotes de dados.
Perkins et al. [Perkins et al. 2001] demonstram através de simulações que o protocolo DSR é mais eficiente em redes que possuem baixa carga e/ou seus nós possuem baixa
mobilidade. Já o AODV é mais eficiente em redes com maior carga e maior mobilidade
dos nós. A Figura 5(a) comprova exatamente esse comportamento. A princı́pio, quando
a carga da rede é baixa, o protocolo DSR entrega mais pacotes que o AODV. Contudo, à
medida que a carga da rede aumenta, o desempenho do DSR diminui, chegando ao ponto
do AODV ultrapassar o DSR em relação a taxa de entrega. O mesmo comportamento
pode ser observado na Figura 5(b).
As Figuras 5(d) e 5(c), ilustram comportamentos semelhantes. Em todas elas,
à medida que a carga da rede aumenta, a taxa de entrega dos protocolos diminui. No
entanto, notam-se pequenas diferenças. Nas Figuras 5(d) e 5(c), quando a carga da rede é
mı́nima, o AODV é o protocolo com a melhor taxa de entrega. Com o aumento do número
de nós fonte, mais pacotes de dados são enviados, por isso mais pacotes de controle são
necessários para garantir a entrega dos dados, gerando, assim, uma sobrecarga da rede.
98
Anais
(a) Cenário urbano: 100 veı́culos
(b) Cenário de rodovia: 100 veı́culos
(c) Cenário urbano: 300 veı́culos
(d) Cenário de rodovia: 300 veı́culos
Figura 5. Taxa de entrega para cada protocolo de roteamento em função do número de fontes nos
cenários simulados.
Por essa razão, protocolos como o AODV e o DSR, que não implementam mecanismos
de controle de sobrecargas eficientes, têm seus desempenhos mais afetados. Por outro
lado, protocolos como o MURU e o ROMSGP, que implementam mecanismo de controle
de sobrecarga, têm seus desempenhos afetados suavemente. Por essa razão, quando a
carga da rede é máxima, os protocolos com melhores taxas de entrega são o MURU e o
ROMSGP.
A Tabela 4 mostra o resumo dos resultados obtidos em relação a taxa de entrega
nos cenários simulados. Pode-se perceber que os protocolos para redes móveis ad hoc
alcançam as melhores taxas de entrega, porém isso acontece apenas quando a rede é
esparsa. Quando a rede atinge sua densidade máxima, nós podemos perceber que os
protocolos para redes veiculares se sobressaem perante os protocolos desenvolvidos para
redes móveis ad hoc. Em condições nas quais a sobrecarga da rede é alta devido ao
aumento do número de veı́culos fonte, verifica-se que o protocolo MURU tem o melhor
desempenho dentre os protocolos simulados. Além disso, o protocolo MURU sempre
alcança a menor variação das taxas de entrega. Através da Tabela 4, pode-se constatar
que no cenário de rodovia os protocolos que alcançaram as melhores taxas de entregas
foram os protocolos para redes móveis ad hoc. Entretanto, diferentemente do observado
no cenário urbano, o protocolo AODV alcançou a melhor taxa de entrega mesmo quando
a densidade da rede era máxima, em redes com 10% de nós fonte. Contudo, os protocolos
99
de redes veiculares foram os que apresentaram a menor variação das taxas de entrega.
Condições
10% de fontes
Urbano
Rodovia
Melhor taxa de entrega
DSR
DSR
Melhor taxa de entrega com
densidade máxima
AODV
AODV
Menor variação das taxas de
entrega
MURU
e
ROMSGP
MURU
30% de fontes
Urbano
Rodovia
50% de fontes
Urbano
Rodovia
AODV
MURU
e
ROMSGP
AODV
MURU
AODV
ROMSGP
MURU
MURU
MURU
AODV
MURU
e
ROMSGP
MURU
Tabela 4. Resumo dos resultados obtidos em relação a taxa de entrega nos cenários simulados.
5. Conclusões e Trabalhos Futuros
Neste artigo, são apresentados os resultados obtidos por meio de simulações de
dois protocolos para redes veiculares, MURU e ROMSGP, em diferentes cenários e
condições de operação da rede. Foram realizadas comparações com protocolos tı́picos
das redes móveis ad hoc, AODV e DSR. Através dos resultados alcançados conclui-se
que os protocolos de roteamento ainda precisam evoluir para alcançar um desempenho
satisfatório. Contudo, alguns pontos relevantes relacionados à deficiência dos protocolos foram observados. Primeiramente, destacamos a necessidade do uso de métricas que
utilizem informações presentes nos mais variados cenários. Também destacamos a necessidade de um mecanismo de controle de sobrecarga capaz de adaptar seu comportamento
de acordo com a densidade da rede, já que, conforme os resultados apresentados, os mecanismos avaliados não alcançam um bom desempenho em redes pouco densas devido
ao alto número de pacotes descartados, enquanto em redes densas o desempenho é satisfatório.
Como trabalho futuro, propõe-se o desenvolvimento de um protocolo de roteamento adaptativo que leve em consideração as diretrizes apontadas por esse trabalho.
Portanto, espera-se desenvolver um protocolo que se adapte às condições da rede, tais
como a densidade, o padrão de mobilidade, o tipo de cenário (urbano, rodovia e rural), o
raio de transmissão, dentre outros.
Referências
Azarmi, M., Sabaei, M., and Pedram, H. (2008). Adaptive routing protocols for vehicular
ad hoc networks. In International Symposium on Telecommunications (IST).
Bernsen, J. and Manivannan, D. (2008). Routing protocols for vehicular ad hoc networks
that ensure quality of service. In International Conference on Wireless and Mobile
Communications (ICWMC).
Boban, M., Misek, G., and Tonguz, O. (2008). What is the best achievable qos for unicast
routing in vanets? In IEEE GLOBECOM Workshops.
Cavalcanti, S. R., Campista, M. E. M., Abdesslem, F. B., Costa, L. H. M. K., Amorim,
M. D., and Duarte, O. C. M. B. (2010). Veer: A trajectory-based peer selection algorithm for networks of vehicles. In IFIP Annual Mediterranean Ad Hoc Networking
Workshop (Med-Hoc-Net).
Hartenstein, H. and Laberteaux, K. (2008). A tutorial survey on vehicular ad hoc
networks. IEEE Communications Magazine, 46(6):164–175.
100
Anais
Jin, Z., Yan, N., and Bing, L. (2009). Reliable on-demand geographic routing protocol
resolving network disconnection for vanet. In International Conference on Wireless
Communications, Networking and Mobile Computing (WiCom).
Johnson, D. B., Maltz, D. A., and Broch, J. (2001). DSR: The dynamic source routing
protocol for multi-hop wireless ad hoc networks. In Ad Hoc Networking. AddisonWesley.
Karp, B. and Kung, H. T. (2000). GPSR: greedy perimeter stateless routing for wireless
networks. In International Conference on Mobile computing and networking, (MobiCom). ACM.
Lochert, C., Hartenstein, H., Tian, J., Fussler, H., Hermann, D., and Mauve, M. (2003). A
routing strategy for vehicular ad hoc networks in city environments. In IEEE Intelligent
Vehicles Symposium.
McCanne, S. and Floyd, S. Ns-2 network simulator. http://www.isi.edu/nsnam/ns/. Acessado em 23 de Abril de 2011.
Mo, Z., Zhu, H., Makki, K., and Pissinou, N. (2006). MURU: A multi-hop routing
protocol for urban vehicular ad hoc networks. In International Conference on Mobile
and Ubiquitous Systems - Workshops.
Naumov, V., Baumann, R., and Gross, T. (2006). An evaluation of inter-vehicle ad hoc
networks based on realistic vehicular traces. In ACM International Symposium on
Mobile Ad Hoc Networking and Computing (MobiHoc).
Naumov, V. and Gross, T. (2007). Connectivity-aware routing (CAR) in vehicular ad-hoc
networks. In IEEE International Conference on Computer Communications (INFOCOM).
openstreetmap (2009). Openstreetmap foundation. http://www.osmfoundation.org. Acessado em 06 de Janeiro de 2011.
Perkins, C. and Royer, E. (1999). Ad-hoc on-demand distance vector routing. In IEEE
Workshop on Mobile Computing Systems and Applications (WMCSA).
Perkins, C., Royer, E., Das, S., and Marina, M. (2001). Performance comparison of two
on-demand routing protocols for ad hoc networks. IEEE Personal Communications,
8(1):16–28.
Sakhaee, E., Taleb, T., Jamalipour, A., Kato, N., and Nemoto, Y. (2007). A novel scheme
to reduce control overhead and increase link duration in highly mobile ad hoc networks.
In IEEE Wireless Communications and Networking Conference (WCNC).
Seet, B., Liu, G., Lee, B., Foh, C., Wong, K., and Lee, K. (2004). A-star: A mobile ad
hoc routing strategy for metropolis vehicular communications. NETWORKING, pages
989–999.
SUMO (2009). Sumo. http://sumo.sourceforge.net/. Acessado em 03 de Janeiro de 2011.
Tian, J., Han, L., and Rothermel, K. (2003). Spatially aware packet routing for mobile
ad hoc inter-vehicle radio networks. In IEEE Intelligent Transportation Systems, volume 2, pages 1546–1551.
101
Sobre as Deficiências na Sinergia entre BitTorrent e MANETs
e Alternativas Viáveis
Sidney Doria, Marco Aurélio Spohn
1
Departamento de Sistemas e Computação
Universidade Federal de Campina Grande – UFCG
Campina Grande – PB
{sidney, maspohn}@dsc.ufcg.edu.br
Abstract. BitTorrent is well known as efficient in the Internet and has been the
default protocol in researchs on the synergy among P2P networks and MANETs.
This paper (i) analyzes the characteristics of BitTorrent and the adaptations
for MANETs, proposed by previous works, to incentive discussion about the
fact that BitTorrent might not be the optimal protocol to share contents among
peers in MANETs. Moreover, we present (ii) our efforts to improve P2MAN, our
proof-of-concept P2P sharing protocol, with a performance comparison with
BitHoc, using NS-2 network simulator, with results showing that P2MAN nodes
download contents faster than BitHoc nodes.
Resumo. BitTorrent é reconhecidamente eficiente na Internet e tem sido o protocolo referência em pesquisas sobre sinergia entre redes P2P e MANETs. Este
artigo (i) analisa as caracterı́sticas do BitTorrent e os trabalhos anteriores
que propõem sua adaptação para MANETs, com o intuito de fomentar a discussão sobre a adequação do BitTorrent para distribuição de conteúdos em
MANETs. Além disso, são apresentados (ii) os resultados dos nossos esforços
para avançar tecnicamente o P2MAN, nosso protocolo de compartilhamento
para prova de conceito e (iii) é apresentado um comparativo do P2MAN com o
BitHoc, no simulador NS-2, cujos resultados indicam que, nos cenários apresentados, os nós P2MAN realizam downloads em menos tempo que os nós BitHoc.
1. Introdução
As Redes Entre-Pares (Peer to Peer (P2P), em inglês) e as Redes Ad Hoc Móveis (Mobile
Ad Hoc Networks (MANETs), em inglês) apresentam um desafio em comum: manter
esforços colaborativos para prover comunicação de forma descentralizada em ambiente
dinâmico. Tal similaridade sugere uma potencial sinergia entre as duas redes, de modo a
produzir uma infra-estrutura de comunicação com a facilidade de instalação das MANETs
combinada à resiliência das redes P2P.
Particularmente, BitTorrent [Cohen 2003] tem sido o protocolo alvo de pesquisas recentes sobre sinergia entre redes P2P e MANETs [Rajagopalan et al. 2006,
Sbai et al. 2008, Souza and Nogueira 2008, Krifa et al. 2009a, Ko and Kim 2009,
Quental and Gonçalves 2010]. Note-se que, embora BitTorrent seja conhecido pela sua
eficiência e popularidade na Internet, há uma série de problemas de adaptação quando
sobreposto a MANETs. Defende-se uma linha de pensamento em que a solução enfatiza
os aspectos das MANETs sobre os aspectos P2P do problema.
102
Anais
Atualmente, estamos desenvolvendo o protocolo Peer-to-MANET (P2MAN) de
distribuição de conteúdo P2P para MANETs. P2MAN adota uma abordagem multicast
em malha de baixa sobrecarga, e um único grupo multicast para simplificar as operações
de controle e reduzir sobrecarga. Além disso, foi projetado em uma abordagem holı́stica,
que considera as restrições das MANETs, e que tenta se valer de suas peculiaridades
(e.g., escala e propósito restritos, roteamento multicast em malha). Os primeiros resultados [Doria and Spohn 2009] indicaram que P2MAN distribui conteúdos em MANETs
de forma escalável e eficiente. Entretanto, seu desempenho foi mensurado isoladamente,
sem comparativo um direto com as abordagens BitTorrent existentes na literatura.
Este trabalho traz três contribuições, a saber: (i) uma análise sobre os problemas de adaptação do BitTorrent sobre MANETs, com o intuito de apresentar uma discussão sobre a adequação do BitTorrent como protocolo de distribuição de conteúdos
para MANETs; (ii) os resultados dos nossos esforços para o avanço técnico do protocolo P2MAN [Doria and Spohn 2009], nosso protocolo para compartilhamento de
conteúdos em MANETs e (iii) um comparativo de desempenho entre o P2MAN e o
BitHoc [Sbai et al. 2008], então expoente do BitTorrent para MANETs.
O restante do trabalho está organizado como segue. A Seção 2 detalha os trabalhos relacionados à sinergia entre redes P2P e MANETs, distribuição de conteúdo P2P
e BitTorrent. A Seção 3 discute a viabilidade da sinergia entre BitTorrent e MANETs.
A Seção 4 versa sobre o P2MAN e seus avanços técnicos recentes e a Seção 5 traz os
resultados de um comparativo de desempenho entre o P2MAN e o BitHoc. Finalmente, a
Seção 6 conclui este trabalho.
A literatura já trata de sinergia entre redes P2P e MANETs há quase uma década. As
primeiras pesquisas tiveram por objetivo analisar o comportamento de protocolos relevantes de distribuição de conteúdo P2P, originalmente projetados para redes cabeadas tradicionais, sobre MANETs. Os resultados indicaram baixo desempenho das adaptações,
principalmente devido às caracterı́sticas mais dinâmicas das MANETs (e.g., mudanças de
topologia, falhas de enlace).
Em [Kortuem et al. 2001] os autores tratam sobre a colaboração entre redes P2P
e MANETs. [Klemm et al. 2003] e [Ding and Bhargava 2004] versam sobre protocolos
de distribuição P2P para MANETs. Os autores de [Gerla et al. 2005] discutem em profundidade o futuro da sinergia entre as duas redes e listam problemas em aberto. Em
[Oliveira et al. 2005] os autores argumentam que as duas redes são complementares, visto
que as MANETs são formadas tipicamente por nós de recursos computacionais limitados
e as redes P2P eliminam a necessidade de servidores com recursos abundantes no sistema.
Para contornar o problema de desempenho, novas pesquisas vêm tentando abordagens entre camadas, que estabelecem comunicação direta entre a camada de aplicação
e as camadas inferiores, ao custo de contrariar o propósito das modelagens por camadas.
Em [Y. Charlie Hu and Pucha 2003] os autores propõem um protocolo de roteamento que
se apóia em uma rede P2P auxiliar sobreposta, de modo que as descobertas de rotas ficam
limitadas a O(logN ). Os autores em [Conti et al. 2004] criaram uma camada adicional que se comunica com as demais camadas de rede, que consolida informações sobre
o status da rede. Além disso, conjecturam não ser possı́vel realizar certas operações
103
em MANETs com eficiência (e.g., economia de energia nas transmissões) com o paradigma de camadas independentes, mas não reuniram provas para embasar tal afirmação.
Em [Kozat et al. 2004] os autores também projetaram uma camada adicional que coleta
informações da rede.
Mais recentemente, outros trabalhos utilizaram abordagens entre camadas,
de redes P2P sobrepostas, para alcançar resultados otimizados para tarefas como
roteamento unicast e multicast e distribuição de conteúdos [Passarella et al. 2006,
Delmastro et al. 2008, Lee et al. 2006, Sbai and Barakat 2009].
2.1. Adaptações do BitTorrent
Particularmente, o protocolo BitTorrent tem sido alvo freqüente de pesquisas recentes
sobre sinergia entre redes P2P e MANETs. A literatura já abriga diversos trabalhos que
tentam modificar o BitTorrent para otimizá-lo sobre MANETs.
O BitTorrent for MANETs (BTM) [Rajagopalan et al. 2006] usa uma camada
especial que aglutina informações e operações de diversas camadas de rede, dando ciência
à camada de aplicação sobre a topologia da rede, o que pode ser vantajoso. Tal camada
de suporte é então co-responsável por rotear pacotes, solicitar arquivos e descobrir pares.
O Network-Aware P2P (NAP) [Ko and Kim 2009] modifica a estratégia de
seleção de pares e a estratégia de seleção de pedaços, considerando a topologia e as
condições de tráfego. Para obter tais informações, foi utilizada uma versão modificada
do OLSR, onde cada nó troca com seus vizinhos, até dois saltos, como foi o tráfego transmitido em um perı́odo de tempo. Assim, a banda disponı́vel é informada aos vizinhos
através dos pacotes HELLO. Em outra modificação, os nós podem calcular o custo de envio de pacotes, através da combinação de distância e tráfego entre nós. Essa informação
auxilia na seleção de nós para rotas menos congestionadas. Tal estratégia é então combinada à seleção de vizinhos com os pedaços mais raros.
O Social Network based P2P File Sharing System (SNP) baseia-se em estudos
que relacionam o comportamento social de indivı́duos e seus movimentos em redes P2P
móveis. O SNP agrupa nós em comunidades com interesses em comum, valendo-se de
palavras-chave que são trocadas pelos nós para esse fim. As comunidades são criadas
a partir de uma função que verifica a similaridade entre as palavras-chave. Através da
diferenciação entre os nós, são atribuı́das funções especiais a determinados nós, de modo
a facilitar a transferência de arquivos entre membros das comunidades.
O BitHoc [Sbai and Barakat 2009] é um expoente da literatura e já foi implementado tanto no simulador NS-2 [NS-2 2010] quanto em dispositivos pervasivos reais.
BitHoc não utiliza tecnologia entre camadas. Sua modificação está na escolha dos pares
aos quais os nós devem solicitar um arquivo. Sua estratégia geral é manter uma lista seletiva de pares, ordenada pela proximidade em saltos. Mantendo uma lista de nós próximos,
o BitHoc busca reduzir a sobrecarga de roteamento e minimizar os bem conhecidos problemas relacionados ao TCP nas MANETs [Holland and Vaidya 1999, Lee et al. 2001,
Wang and Zhang 2002, Wang and Zhang 2002]. Os autores do BitHoc também advogam
pela manutenção da redundância, através de mecanismos próprios de incentivo, para uma
distribuição de conteudos mais justa entre os pares.
104
Anais
3. Sobre a Viabilidade da Sinergia entre BitTorrent e MANETs
O propósito desta Seção é discutir a viabilidade do uso do BitTorrent como mecanismo
de distribuição de conteúdos entre pares em MANETs. O objetivo é fomentar a discussão
cientı́fica sobre o tema, de maneira que se produzam idéias e propostas alternativas para
o problema de distribuição eficiente de conteúdos em MANETs.
São muitos os argumentos e suposições utilizados na literatura para uso do
BitTorrent como referência para distribuição de conteúdos P2P em MANETs. Por exemplo:
• Eficiência comprovada na Internet
BitTorrent é eficiente em distribuir conteúdos na Internet, provendo uma entrega
rápida em uma escala impressionante. A suposição então é que tal eficiência possa
ser reproduzida em uma rede com escala tı́pica muito menor.
• Popularidade
É razoável supor que o uso de um protocolo popular como o BitTorrent em uma
MANET pode reduzir o tempo gasto com treinamento dos usuários, visto que
há uma boa chance de que alguns desses usuários já tenham experimentado o
protocolo na Internet.
• Arquitetura
A arquitetura do BitTorrent seria supostamente favorável às MANETs, já que
amortiza o custo de servir o arquivo pela rede móvel e é possı́vel reiniciar as transferências após desconexões de rede. Além disso, um nó pode servir pedaços de
um conteúdo, enquanto esse conteúdo ainda está sendo descarregado. Isso pode
ser vantajoso em uma MANET, cujo propósito tipicamente restrito sugere que os
nós têm interesses similares.
Note-se que o problema de fato a ser resolvido é como fazer distribuição eficiente
de conteúdos em MANETs, independentemente do protocolo a ser usado, e que alguns
desses argumentos não válidos exclusivamente para o BitTorrent. Com exceção da popularidade, outros protocolos de distribuição de conteúdo também podem ser valorizados
por tais argumentos. Essa observação leva a uma questão sobre o interesse assı́duo dos
pesquisadores em aplicar o BitTorrent nas MANETs:
Qual é o fator técnico preponderante, pelo qual o BitTorrent está sendo escolhido
de forma recorrente em pesquisas sobre sinergia com MANETs?
Tal questão se refere à hipótese de que os esforços para que o BitTorrent seja
usado de forma eficiente em MANETs sejam, sobremaneira, motivados pela sua popularidade. Essa hipótese se evidencia quando são estudados os problemas de adaptação
entre BitTorrent e MANETs, juntamente com as modificações propostas pela literatura ao
longo da última década.
3.1. Problemas de Adaptação entre BitTorrent e MANETs
Distribuir conteúdos de forma eficiente entre pares sobre MANETs é um problema difı́cil,
principalmente por conta das dissonâncias entre as duas redes. Por exemplo, as redes
populares de compartilhamento de conteúdo P2P foram originalmente projetadas para a
Internet (i.e., escala global, milhões de nós) e as MANETs tı́picas têm escala de dezenas
de nós. Tais protocolos P2P geralmente são de camada de aplicação, usam unicast para
105
disseminar os dados, valem-se de nós estáticos e adotam a suposição de que os vizinhos
estão a apenas um salto de distância. Em oposição, as MANETs utilizam broadcasts
fı́sicos não confiáveis em um meio compartilhado e seus nós são móveis, com enlaces
de comunicação estabelecidos dinamicamente em roteamento salto a salto. A literatura
comunica um conjunto de dificuldades de adaptação que podem ocorrer ao se tentar empregar BitTorrent em MANETs, tais como:
• Transmissões unicast
BitTorrent emprega transmissões unicast para enviar mensagens de controle e para
entregar os pedaços dos conteúdos, o que é custoso sobre MANETs, devido à sobrecarga provocada pelos handshakes em camadas mais baixas. O uso de unicast
portanto pode degradar o desempenho do sistema de distribuição de conteúdos.
• Mecanismo de Incentivo
Com o mecanismo de incentivo tit-for-tat do BitTorrent, múltiplos nós são incentivados a compartilhar e a transmitir pedaços de seus conteúdos, de forma a elevar
progressivamente a vazão do sistema, possivelmente ao limite da capacidade da
rede. De fato, manter os nós colaborando na transmissão é a razão fundamental
para os mecanismos de incentivo das redes P2P e um ponto fundamental de sua
otimização. Entretanto, em uma MANET, tal abordagem pode levar a colisões excessivas devido à disputa pela ocupação do meio compartilhado, possivelmente até
o colapso, produzindo um efeito oposto ao esperado [Grossglauser and Tse 2002].
Portanto, o incentivo a múltiplas transmissões unicast pode degradar o desempenho do sistema de distribuição de conteúdos.
• TCP
BitTorrent originalmente requer TCP como protocolo de transporte. Os problemas de desempenho do TCP em MANETs já foram demonstrados exaustivamente na literatura [Holland and Vaidya 1999]. O uso do TCP nas transmissões
pode portanto degradar o desempenho do sistema de distribuição de conteúdos.
Em atenção a esse problema, Anastasi et al. desenvolveram recentemente o
TPA [Anastasi et al. 2009], um protocolo de transporte confiável mais eficiente
do que o TCP em MANETs, que adota uma abordagem entre camadas. Mesmo
considerando tais avanços recentes com protocolos de transporte para MANETs,
ainda haveria a necessidade de adaptar o BitTorrent ou uma variante do protocolo
para o TPA.
• Tracker
A arquitetura do BitTorrent prevê os Trackers, que são nós fixos na rede que
endereçam os conteúdos. MANETs são totalmente dinâmicas, o que requer uma
adaptação do modelo com Trackers para um modelo totalmente distribuı́do. Há
também a hipótese de eliminação do Tracker no BitTorrent e a utilização de outras
formas de localização de conteúdo na rede, como a difusão.
• Distância entre Vizinhos
O BitTorrent considera vazão de transmissão como métrica para reputação e
seleção de pares. Na arquitetura original do BitTorrent assume-se que os vizinhos
são nós estáticos que estão a um salto de distância. Portanto, não são consideradas
as caracterı́sticas de mobilidade e de roteamento salto a salto das MANETs. O
desconhecimento da distância entre os pares pode levar o BitTorrent a provocar
excesso de colisões numa MANET, mesmo com poucas transmissões ativas, visto
106
Anais
que elas podem ocorrer entre nós diametralmente opostos na rede, o que recrutaria vários nós intermediários a repassar os dados, ocupando o meio compartilhado.
Portanto, tal suposição do BitTorrent pode degradar o desempenho de distribuição
de conteúdos.
• Segurança
Na Internet, o protocolo BitTorrent tipicamente realiza comunicação entre pares
em enlaces independentes. Entretanto, em MANETs, o uso de meio fı́sico compartilhado para as transmissões pode aumentar os riscos de segurança na entrega
dos arquivos.
Para relativizar a viabilidade do uso de BitTorrent em MANETs, ponderam-se os
problemas de adaptação citados e o fato de que a literatura demonstra não haver ainda uma
adaptação do BitTorrent completamente otimizada para MANETs. Ademais, trabalhos
anteriores utilizam cenários com restrições, visando permitir as análises de desempenho
em ambiente controlado. Entretanto, tais cenários podem ser considerados pouco realistas
por se afastarem em demasia da tipificação de uma MANET. Por exemplo, o cenário utilizado em [Krifa et al. 2009a, Souza and Nogueira 2008, Quental and Gonçalves 2010]
considera apenas 40 nós, dispostos em formato de malha equidistante, sem mobilidade
(i.e., nós estáticos), com alcance de rádio reduzido para 50m e transmitindo um único
arquivo de tamanho reduzido, inicialmente a partir de uma única origem. É possı́vel
ainda visualizar que, considerando o conhecimento cientı́fico atual, se fossem aplicadas as adaptações mais bem sucedidas da literatura no protocolo BitTorrent, de forma
a adequá-lo ao máximo para MANETs, haveria uma considerável descaracterização do
protocolo.
Diante do exposto, pondera-se que o BitTorrent pode não ser a melhor escolha
para distribuir conteúdos em MANETs. Defende-se que uma relação sinérgica otimizada
entre redes P2P e MANETs pode requerer esforços que vão além da adaptação direta de
uma arquitetura P2P de sucesso das redes cabeadas de larga escala (i.e., Internet), mesmo
com as modernas adaptações entre camadas já propostas na literatura.
Para contribuir com novas formas de se obter vantagem dos conceitos P2P em
MANETs, estamos desenvolvendo um protocolo nativo de distribuição de conteúdo para
MANETs, denominado Peer-to-MANET (P2MAN). O objetivo é dar mais prioridade aos
aspectos MANET em vez dos aspectos P2P do problema. A Seção 4.2 explica de forma
sucinta o funcionamento do P2MAN.
4. P2MAN: Uma Alternativa para Distribuição de Conteúdos em MANETs
Peer-to-MANET (P2MAN) [Doria and Spohn 2009] é um protocolo de distribuição de
conteúdos entre pares para MANETs, que implementa conceitos bem sucedidos das redes
P2P populares, mas com uma abordagem que considera plenamente as restrições e as
dificuldades inerentes às MANETs.
4.1. Considerações Prévias
Neste trabalho considera-se o caso geral em que uma MANET não é formada para um
propósito geral, mas para a comunicação de um grupo de indivı́duos inter-relacionados
de alguma forma (e.g., campo de batalha, solução de desastres, operações de resgate,
laboratórios provisórios). Sendo assim, é razoável assumir que a informação fluirá em
107
algum momento de um indivı́duo para um grupo de indivı́duos correlatos, especialmente
fluxos de informações.
No escopo deste trabalho, a comunicação de dados significa compartilhamento
de arquivos digitais, como os que são compartilhados na Internet através das redes P2P
mais populares. Apesar dos bons resultados iniciais do P2MAN em grupos maiores de
nós (e.g., 100 nós), e em mobilidades mais altas (e.g., 30 m/s), assume-se que os nós
não se movem rápido e continuamente a tal ponto de que a única comunicação possı́vel
seria a inundação de pacotes. Assume-se que há ausência total de nós isolados, visto
que o objetivo é verificar quão bem P2MAN pode distribuir conteúdos a todos os nós
destinatários conectados.
Assume-se que não há nós erráticos na rede. Em particular, cada nó da rede deve
cooperar repassando os pacotes que lhe foram solicitados. Neste trabalho não foram exploradas questões de segurança em quaisquer camadas. Entretanto, há um trabalho em
andamento sobre segurança no P2MAN. Empregamos uma versão modificada da Rede
de Favores como solução para reduzir o problema de drenagem maliciosa de recursos,
provocada por nós maliciosos. Tais resultados serão objeto de outro trabalho.
4.2. Arquitetura do P2MAN
O objetivo desta Seção é explicar de forma sucinta o funcionamento do P2MAN. Uma
explicação detalhada consta em [Doria and Spohn 2009].
P2MAN é um protocolo multicast, que emprega grupos multicast distintos para
entregar conteúdos e um grupo multicast especial, denominado Canal Público, para todas as operações de controle. Quando um nó P2MAN inicia, junta-se ao Canal Público
(CP) para poder trocar mensagens de controle. Todos os nós que desejam compartilhar conteúdo devem ser membros do CP. Não há nós servidores com informações para
localização de conteúdos nem tais informações são copiadas (i.e., mantidas em cache)
pelos nós na rede. Em vez disso, para localizar um conteúdo, um nó consulta o Canal
Público sem a necessidade de inundar a rede com mensagens de controle. Caso algum nó
ativo tenha o conteúdo, este será alcançado em algum momento através do CP e a resposta
retorna também via CP. A resposta traz consigo metadados gerados pelo nó proprietário
do conteúdo, com informações detalhadas sobre o conteúdo.
Como em muitas redes P2P, P2MAN fraciona o conteúdo para a entrega. O nó
proprietário decide como o objeto será dividido em pedaços e faz uma representação do
conteúdo através de um mapa de bits (em que cada bit representa um pedaço do conteúdo).
O proprietário também decide que grupo multicast será usado para transmitir o conteúdo.
Os metadados são criados pelo nó proprietário, contendo as informações necessárias para
guiar os nós solicitantes. Após receber a resposta, o nó solicitante junta-se ao grupo
multicast anunciado pela fonte e envia uma mensagem de autorização ao Canal Público.
Ao receber uma mensagem de autorização, o proprietário do conteúdo pode iniciar a
transmissão.
Note-se que a maioria das redes P2P de distribuição de conteúdo emprega algum tipo de mecanismo de incentivo. Entretanto, múltiplas transmissões unicast podem
produzir colisões em excesso devido à disputa pelo meio compartilhado. A abordagem
multicast do P2MAN contorna esse problema, visto que apenas um nó transmissor é necessário para distribuir um conteúdo a todos os nós solicitantes. Por isso, outra finalidade
108
Anais
do processo de autorização é assegurar que apenas um nó seja o transmissor multicast do
conteúdo para os membros do grupo multicast. Por outro lado, a diversidade necessária é
obtida durante a seleção dos nós transmissores.
Assumindo-se a adoção de um protocolo de roteamento multicast sem entrega
confiável (e sem um protocolo de transporte multicast, a garantia de entrega é realizada
na camada de aplicação, através de um mecanismo de retransmissão denominado Modo
de Reparação. No modo de reparação, um nó pode solicitar os pedaços que ainda não recebeu. O proprietário então retransmite os pedaços que faltam. Enquanto houver pedaços
faltando, novos pedidos e retransmissões ocorrerão, até que o nó solicitante receba todos
os pedaços.
4.3. Avanços Recentes do P2MAN
Ao final do desenvolvimento da primeira versão do P2MAN, foram realizadas
avaliações de desempenho no simulador NS-2 e os resultados constam na literatura [Doria and Spohn 2009]. Desde então o P2MAN passou por algumas refatorações,
correções e recentemente alguns aspectos do seu design foram modificados para efeito de
otimização. O objetivo desta Seção é comunicar as alterações mais relevantes do P2MAN
desde a sua publicação original.
4.3.1. Proteção contra Tempestade de Requisições
Na versão mais recente do P2MAN, após transmitir um conteúdo, o nó proprietário inicia um temporizador denominado Proteção contra Tempestade de Requisições. O valor
deste temporizador pode ser definido pelo usuário. O objetivo deste temporizador é evitar um efeito fase que pode ocorrer logo após o envio de muitos pedaços. Devido à
intensa retransmissão de pacotes salto a salto até os nós solicitantes, alguns nós podem
requisitar mais de uma vez pedaços que já foram enviados, pois ficam temporariamente
impedidos de ouvir as respostas de suas requisições. A Proteção contra Tempestade de
Requisições possibilita que os nós requisitantes ouçam as respostas do nó proprietário no
canal público, sem que uma nova inundação de pacotes ocorra imediatamente.
4.3.2. Multiplas Entregas Simultâneas
No P2MAN original ainda não era possı́vel entregar múltiplos arquivos simultaneamente. Tal funcionalidade foi adicionada e foram realizadas novas simulações para
medir o impacto das várias transmissões no tempo de entrega, no cenário de rede proposto no trabalho original. A figura 1 mostra os resultados da avaliação do P2MAN
em processo de múltiplas entregas simultâneas de arquivos. As configurações utilizadas,
definições de cenário, número de nós e demais parâmetros de simulação estão detalhados
em [Doria and Spohn 2009]:
109
Figura 1. Tempo Total de Entrega x Entregas Concorrentes.
4.3.3. Novo Modo de Reparação
No P2MAN, se um nó aguardar a chegada de um pedaço por mais tempo do que reza um
temporizador programado, ele entrará em Modo de Reparação. De forma simplificada,
quando um nó entra em modo de reparação o download é reiniciado, mas dessa vez o
nó informa aos proprietários os pedaços que já possui, através de um mapa de bits. Ao
receber respostas de nós proprietários, um nó requisitante envia uma autorização de envio
de pedaços ao nó proprietário escolhido.
No P2MAN original, uma vez iniciado o processo de reparação ele não pára,
mesmo que durante este processo ocorra a chegada de um pedaço da transmissão anterior. Uma situação assim nem sempre ocorre quando a transmissão é interrompida.
Podem ocorrer dificuldades transientes na transmissão (e.g., colisões, interferências, congestionamento). Nesse caso, há um trade off entre aumentar o valor do temporizador
de espera ou procurar um novo nó proprietário (i.e., seeder) imediatamente. Valores de
temporização maiores são mais adequados a eventos transientes e novas escolhas de proprietários são melhores em ambientes mais dinâmicos, considerando que novas seleções
sempre retornem os melhores nós proprietários para o nó solicitante.
Para resolver este problema na nova versão do P2MAN, optou-se por adicionar
a possibilidade de abortar o processo de Reparação se um novo pedaço chegar antes do
envio da autorização ao remetente. Assim, atualmente um nó pode entrar no Modo de
Reparação e abortá-lo em tempo, caso perceba a chegada de um novo pedaço da transmissão original. O momento limı́trofe para a interrupção do Modo de Reparação é antes
do envio da autorização ao remetente. Considerando-se que a requisição de reparação
pode solicitar a retransmissão de muitos pedaços, optou-se por uma rede que gera menos
tráfego, o que assegura um bom desempenho do protocolo em ambientes com tráfego
mais intenso.
110
Anais
5. Um Comparativo de Desempenho entre P2MAN e BitHoc
BitHoc é de facto um expoente da literatura sobre a sinergia entre BitTorrent e MANETs.
Seus autores já produziram diversas publicações relacionadas, sendo a mais recente sobre
sua implementação em dispositivos pervasivos reais [Krifa et al. 2009b]. Uma dificuldade
encontrada para comparar P2MAN com o estado da arte foi obter os códigos dos protocolos de trabalhos relacionados. Ao limite dos nossos esforços, tentamos sem sucesso obter
o código do BitHoc para reproduzir os experimentos dos autores no NS-2. Entretanto,
foi possı́vel realizar um comparativo do P2MAN com o BitHoc através do detalhamento
do cenário disposto no artigo original do BitHoc [Krifa et al. 2009a], comparando tais
resultados do BitHoc com os resultados do P2MAN no mesmo cenário.
5.1. Cenário de Simulação
O cenário proposto pelos autores do BitHoc é composto de 40 nós estáticos dispostos em
forma de grande em um plano, como na figura 2. A distância entre dois nós foi definida
em 40m para um alcance de transmissão de 50m. Os autores justificam tal cenário como
sendo ideal para garantir conectividade e reduzir interferências.
Figura 2. Topologia da Simulação [Krifa et al. 2009a].
O nó 0, no canto superior esquerdo, é o nó proprietário do conteúdo a ser distribuı́do e os demais nós são receptores. O tamanho do arquivo foi ajustado para
10M bytes. Todos os nós iniciam o download simultaneamente no tempo t = 1500s.
A simulação encerra quando todos os nós recebem o arquivo. Quando um nó recebe um
arquivo, imediatamente o disponibiliza para compartilhamento. Todos os nós utilizam o
protocolo MAC 802.11 com o mecanismo RTS/CTSData/ACK e enlace de 1 M bps. O
protocolo de rede é o DSDV e o de transporte é o TCP. Os parâmetros usados no BitHoc
constam na tabela 0(a) e os parâmetros do P2MAN constam na tabela 0(b).
(a) BitHoc
Parâmetro
Protocolo de Transporte
Protocolo de Roteamento unicast
block size
max upload num
choking period
choking best neighbors num
received bytes reset interval
(b) P2MAN
Descrição
TCP
DSDV
1 KB
4
40 s
3
80 s
Parâmetro
Protocolo de Transporte
Protocolo de Roteamento Multicast
Tamanho do Pedaço
Temporizador de Reparação
Tabela 1. Parâmetros de Simulação.
Descrição
UDP
PUMA
1 KB
600 ms
111
A métrica geral adotada para a comparação entre os protocolos foi o Tempo
Médio de Entrega. Os resultados representam uma média de 20 execuções e intervalo
de confiança de 95%.
A Figura 3 mostra os tempos médios de entrega dos nós BitHoc (b) e P2MAN (c),
como função do número de saltos para o nó 0. Note-se que neste cenário a maior distância
para o nó 0 é de 12 saltos. Na Figura (b), o quantum q é um parâmetro do BitHoc que
define a razão entre o número de fatias de tempo em que um nó servirá aos vizinhos
próximos, e tempo em que servirá a vizinhos mais distantes.
(a) BitTorrent Padrão: Tempo Médio de Entrega
(b) BitHoc: Tempo Médio de Entrega
(c) P2MAN: Tempo Médio de Entrega
Figura 3. Tempo Médio de Entrega.
Como esperado, o tempo de entrega aumenta a medida que se observa nós mais
afastados da origem dos dados. É possı́vel perceber que os nós P2MAN têm um tempo
de término mais curto cerca de 14% (a um salto) a 60% (a 4 saltos), com melhor êxito
em toda a extensão do gráfico, quando comparado ao BitHoc utilizando o quantum mais
eficiente para este cenário. Comparando-se o desempenho dos P2MAN ao BitTorrent
padrão, com o TTL sem modificações (i.e., valor máximo), os nós P2MAN chegam a
realizar o download em um tempo até 140% (a 12 saltos) mais curto.
112
Anais
6. Conclusão
Este trabalho apresentou uma análise das caracterı́sticas do BitTorrent e de algumas
adaptações do BitTorrent para MANETs, constantes na literatura, com o intuito de relativizar e fomentar a discussão sobre a viabilidade sinérgica entre o BitTorrent e as
MANETs. Através da análise das caracterı́sticas do BitTorrent e das dissonâncias entre BitTorrent e as MANETs, manifestadas através de problemas de adaptação destacados
na literatura, ponderou-se que o BitTorrent pode não ser a opção mais eficiente de compartilhamento entre pares para MANETs.
Também foram apresentados os resultados dos nossos esforços para avançar tecnicamente o P2MAN, nosso protocolo de distribuição de conteúdo entre pares. Foram apresentados o temporizador de Proteção contra Tempestade de Requisições, a implementação
de Multiplas Entregas Simultâneas, cujo desempenho foi apresentado em gráfico, estendendo o artigo original do P2MAN [Doria and Spohn 2009], e o Novo Modo de
Reparação que permite que nós P2MAN possam abortar o processo de autorização de envio na hipótese de chegada de pacotes com atraso superior ao temporizador de reparação.
Por fim, foi apresentado um comparativo do P2MAN com o BitHoc, no simulador NS-2. Os resultados indicaram que os nós P2MAN obtiveram desempenho superior aos nós BitHoc de 14% e 60%, e de até 140% quando o P2MAN é comparado ao
BitTorrent padrão. Como trabalhos futuros, duas novas idéias estão em andamento: (i)
estão sendo testadas versões do P2MAN que transmitem conteúdos em grupos associados
a canais de rádio especı́ficos, por conteúdo, de forma a priorizar transmissões ortogonais
dos conteúdos para reduzir congestionamentos e incentivar o paralelismo. E, (ii) PUMA
e P2MAN estão sendo implementados em dispositivos reais, com versões para Linux, de
modo a ser possı́vel testar seus desempenhos em uma bancada para testes reais.
Referências
Anastasi, G., Ancillotti, E., Conti, M., and Passarella, A. (2009). Design and performance
evaluation of a transport protocol for ad hoc networks. The Computer Journal Advance,
52:186–209.
Cohen, B. (2003). Incentives build robustness in bittorrent. In Workshop on Economics
of Peer-to-Peer Systems, Berkeley, CA, EUA.
Conti, M., Gregori, E., and Turi, G. (2004). Towards scalable p2p computing for mobile
ad hoc networks. In Proceedings of the Second IEEE Annual Conference on Pervasive
Computing and Communications Workshops, page 109.
Delmastro, F., Passarella, A., and Conti, M. (2008). P2p multicast for pervasive ad hoc
networks. Pervasive and Mobile Computing, 4(1):62 – 91.
Ding, G. and Bhargava, B. (2004). Peer-to-peer file-sharing over mobile ad hoc networks.
In Proceedings of the Second IEEE Annual Conference on Pervasive Computing and
Communications Workshops, page 104.
Doria, S. and Spohn, M. A. (2009). A multicast approach for peer-to-peer content distribution in mobile ad hoc networks. In IEEE Wireless Communications and Networking
Conference (WCNC), pages 1–6.
113
Gerla, M., Lindemann, C., and Rowstron, A. (2005). P2P manet’s - new research issues.
In Perspectives Workshop: Peer-to-Peer Mobile Ad Hoc Networks - New Research
Issues, number 05152 in Dagstuhl Seminar Proceedings, Dagstuhl, Germany.
Grossglauser, M. and Tse, D. N. C. (2002). Mobility increases the capacity of ad hoc
wireless networks. IEEE/ACM Trans. Netw., 10:477–486.
Holland, G. and Vaidya, N. (1999). Analysis of tcp performance over mobile ad hoc
networks. In Proceedings of the 5th Annual ACM/IEEE International Conference on
Mobile Computing and Networking, pages 219–230.
Klemm, A., Lindemann, C., and Waldhorst, O. (2003). A special-purpose peer-to-peer
file sharing system for mobile ad hoc networks. IEEE 58th Vehicular Technology Conference, 4:2758–2763.
Ko, S. K. and Kim, Y. H. (2009). Network-aware p2p content sharing over manet. In
Tenth International Conference on Mobile Data Management: Systems, Services and
Middleware (MDM), pages 661–65.
Kortuem, G., Schneider, J., Preuitt, D., Thompson, T., Fickas, S., and Segall, Z. (2001).
When peer-to-peer comes face-to-face: Collaborative peer-to-peer computing in mobile ad hoc networks. In Proceedings of the First International Conference on Peer-toPeer Computing, page 75.
Kozat, U., Koutsopoulos, I., and Tassiulas, L. (2004). A framework for cross-layer design of energy-efficient communication with qos provisioning in multi-hop wireless
networks. In Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, volume 2, pages 1446–1456.
Krifa, A., Sbai, M. K., Barakat, C., and Turletti, T. (2009a). Bithoc: A content sharing
application for wireless ad hoc networks. Pervasive Computing and Communications,
IEEE International Conference on, 0:1–3.
Krifa, A., Sbai, M. K., Barakat, C., and Turletti, T. (2009b). A standalone content sharing application for spontaneous communities of mobile handhelds. In MobiHeld ’09:
Proceedings of the 1st ACM workshop on Networking, systems, and applications for
mobile handhelds, pages 77–78, New York, NY, USA. ACM.
Lee, S.-B., Ahn, G.-S., and Campbell, A. (2001). Improving udp and tcp performance in
mobile ad hoc networks with insignia. IEEE Communication Magazine.
Lee, U., Park, J.-S., Yeh, J., Pau, G., and Gerla, M. (2006). Code torrent: content distribution using network coding in vanet. In MobiShare ’06: Proceedings of the 1st
international workshop on Decentralized resource sharing in mobile computing and
networking, pages 1–5, New York, NY, USA. ACM.
NS-2 (2010). The network simulator. http://www.isi.edu/nsnam/ns.
Oliveira, L., Siqueira, I., and Loureiro, A. (2005). On the performance of ad hoc routing protocols under a peer-to-peer application. Journal on Parallel and Distributed
Computing, 65(11):1337–1347.
Passarella, A., Delmastro, F., and Conti, M. (2006). Xscribe: a stateless, cross-layer
approach to p2p multicast in multi-hop ad hoc networks. In MobiShare ’06: Procee-
114
Anais
dings of the 1st international workshop on Decentralized resource sharing in mobile
computing and networking, pages 6–11, New York, NY, USA. ACM.
Quental, N. C. and Gonçalves, P. A. (2010). Cds-bittorrent: Um sistema de disseminação
de conteúdo para a melhoria do desempenho de aplicações bittorrent sobre manets. In
VI Workshop de Redes Dinâmicas e Sistemas Peer-to-Peer (WP2P).
Rajagopalan, Sundaram, Shen, and Chien-Chung (2006). A cross-layer decentralized
bittorrent for mobile ad hoc networks. In Third Annual International Conference on
Mobile and Ubiquitous Systems: Networking & Services, pages 1–10.
Sbai, M. K. and Barakat, C. (2009). Revisiting p2p content sharing in wireless ad hoc
networks. Lecture Notes in Computer Science, 5918:13–25.
Sbai, M. K., Barakat, C., Choi, J., Hamra, A. A., and Turletti, T. (2008). Adapting
BitTorrent to Wireless Ad Hoc Networks, volume 5198, pages 189–203. Springer Berlin
/ Heidelberg.
Souza, C. and Nogueira, J. M. (2008). Um estudo do bittorrent em redes ad hoc sem
fio crı́ticas com localidade espaço-temporal. In XXV Simpósio Brasileiro de Redes de
Computadores e Sistemas Distribuı́dos, pages 329–342.
Wang, F. and Zhang, Y. (2002). Improving tcp performance over mobile ad hoc networks
ith out-of-order detection and response. In Proceedings of the 3rd ACM International
Symposium on Mobile Ad Hoc Networking & Computing, pages 217–225.
Y. Charlie Hu, S. D. and Pucha, H. (2003). Exploiting the synergy between peer-to-peer
and mobile ad hoc networks. In 9th Workshop on Hot Topics in Operating Systems,
pages 37–42, Lihue, HI, USA.
115
Redes Centradas na Informação: Uma Comparação de
Abordagens
Bruno Magalhães Martins & Antônio Marcos Alberti
Instituto Nacional de Telecomunicações - Inatel
Santa Rita do Sapucaí - MG - Brazil
brunom@mtel.inatel.br, alberti@inatel.br
Abstract. The current Internet was designed using the host-centric principle,
which put host connectivity on the center of its original design. As a result, the
network evolved to provide hosts communication through IP routing. Complex
functions were moved from network core to end hosts. Recent surveys suggest that
a significant portion of the current Internet traffic is related to content exchange,
instead of original Internet applications. New communication models, such as
peer-to-peer, appeared to improve content distribution and sharing on the
Internet. However, in recent years the host-centric model began to be questioned
and a new paradigm emerged: the information-centric. Since the Internet today is
basically a content exchanging network, why not to focus on this aspect of its
evolution? In this paper, we discuss NetInf, CCN e PSIRP information-centric
approaches, presenting their characteristics and providing a comparing of them.
The aim is to critically review some of the existing proposals and determine
opportunities and challenges for future research.
Resumo. A Internet atual foi projetada utilizando o paradigma host-centric, que
colocou os terminais da rede no centro do projeto original. Como resultado, a
rede evoluiu para conectar hosts através do roteamento IP. Funções complexas
foram retiradas do núcleo da rede e movidas para os terminais. Levantamentos
recentes sugerem que parte significativa do tráfego atual da Internet é voltada à
transferência de conteúdos, e não mais para as aplicações originais da rede.
Novos modelos de comunicação, dentre eles o peer-to-peer, surgiram para
melhorar a distribuição e a troca de conteúdos na Internet. Entretanto, nos
últimos anos o modelo host-centric começou a ser questionado e um novo
paradigma apareceu: o information-centric (ou redes centradas na informação).
Já que a Internet hoje basicamente é uma rede de transferência de conteúdos e
informações, porque não centrar sua evolução neste aspecto, ao invés da
conectividade de terminais? Neste artigo, discutiremos as propostas de redes
centradas na informação NetInf, CCN e PSIRP, apresentado suas características
e comparado-as. O objetivo é analisar criticamente algumas das propostas
existentes e determinar oportunidades e desafios para pesquisa futura.
1. Introdução
Diante da disseminação do uso da Internet e o aumento da acessibilidade aos
dispositivos de criação e modificação de mídia e informação, hoje as redes de
comunicação passam por uma fase em que grande parte dos usuários conectados está
deixando de ser um mero consumidor de conteúdos, para se tornar produtor. A maioria
destes conteúdos (fotos, vídeos, posts, etc.) é disponibilizada na rede e o grande
problema é que na arquitetura atual, toda a preocupação é centrada nos hosts, não nos
conteúdos gerados e armazenados por estes hosts. Em outras palavras, os usuários se
116
Anais
importam com o conteúdo que a rede possui, enquanto a Internet atual é focada na
localização do armazenamento deste conteúdo. Há uma série de problemas oriundos
desta incompatibilidade de modelos, tais como disponibilidade de conteúdo, segurança
e dependência de localização. Para Van Jacobson1 [Jacobson et al. 2009], a forma direta
e unificada de resolver estes problemas é substituir o “onde” pelo “o que” em relação ao
conteúdo.
Nas redes atuais, o endereço IP é sobrecarregado ao se responsabilizar pela
dupla funcionalidade de identificação e localização dos hosts. Ou seja, a mobilidade na
rede muitas vezes leva a troca do endereço IP, o que pode levar indiretamente a troca de
identificação na rede. É como se você trocasse de identificação ao se mover. Por isto é
tão difícil identificar o originador de um ataque em uma rede IP. O desacoplamento da
identificação e localização existente no endereço IP permite a melhoria do suporte a
segurança, mobilidade, multihoming2. Além disto, a amarração das informações na web
ao URL (Uniform Resource Locator) e ao endereço do domínio e do host onde elas se
encontram, exige o conhecimento prévio da localização da informação para que o
acesso a mesma possa ser feito.
Nas redes orientadas/centradas em informação/conteúdo o fluxo de mensagens é
dirigido para os nós que manifestam o seu interesse através de identificadores de nomes
da informação, em vez de nomes de interfaces de hosts [Rothenberg et al. 2008]. Elas
possuem como funcionalidade principal a interconexão dos produtores de conteúdo aos
consumidores, independente das localizações dos hosts envolvidos na comunicação.
Desta forma, consegue-se um aumento da eficiência na disponibilidade e disseminação
da informação, já que a recuperação dos conteúdos pode ser beneficiada ao utilizar
cópias ao longo da rede. Assim, do ponto de vista do usuário, toda informação terá um
identificador único e esta informação poderá ser recuperada de forma mais eficiente já
que a informação pode ser encontrada em um local mais próximo ou até mesmo no seu
ambiente local, além do aumento do desempenho e facilidade no acesso a estas
informações. Ou seja, o grande desafio destas redes é, portanto, estabelecer um padrão
para nomeação da informação de forma consistente e eficiente, além de fornecer
soluções para roteamento das informações baseadas em informações nomeadas.
O restante deste artigo é dividido da seguinte forma. Na Seção 2 serão
apresentadas três importantes abordagens de redes centradas na informação: NetInf
[Niebert et al. 2008], CCN (Content-Centric Network) [Palo Alto Research Center
2010] e PSIRP (Publish/Subscribe Internetworking Routing Paradigm) [Ain et al.
2008]. Na Seção 3, estas abordagens são comparadas. Isto também é feito por [Ahlgren
et al. 2010]. Finalmente, na Seção 4 são apresentadas as conclusões do artigo.
2. Abordagens de Redes Centradas na Informação
Nas seções seguintes apresentaremos uma visão geral das abordagens NetInf, CCN e
PSIRP, bem como algumas comparações de características mais relevantes destas
abordagens. É importante salientar que apesar das particularidades, os três projetos a
1
Van Jacobson é o autor do cabeçalho TCP/IP e trabalha atualmente como pesquisador do PARC (Palo Alto Research Center Incorporated)
no programa de investigação de redes centrados em conteúdo. Seu ponto de vista é preservar as decisões de design do TCP/IP: simplicidade,
robustez e escalabilidade [Jacobson et al. 2009][Palo Alto Research Center 2010].
2
O termo multihoming significa que existem múltiplas possibilidades de conexões para o acesso à Internet através de uma rede ou de uma
estação. Ou seja, significa ter múltiplas interfaces com múltiplos localizadores para um mesmo host, ao mesmo tempo.
117
serem citados adotam o modelo de comunicação publica/assina (publish/subscribe), na
qual o interessado em uma determinada informação deve solicitá-la a rede.
Publicar significa disponibilizar qualquer conjunto de dados na rede, enquanto a
assinatura de um conteúdo corresponde a uma porção de dados solicitada por algum
interessado na informação. O modelo de
comunicação
publica/assina
(publish/subscribe) visa trazer ao receptor o controle do fluxo de comunicação, saindo,
portanto do modelo atual “receptor aceita tudo”. Os termos “centrado no conteúdo” e
“orientado à informação” são aplicados essencialmente da mesma forma para indicar
redes nas quais os objetos de informação são em si o foco principal do projeto. A seguir,
portanto, os termos informação e conteúdo serão utilizados de forma equivalente.
2.1. 4WARD NetInf
O 4WARD (Architecture and Design for the Future Internet) é um projeto de nova
Internet que tem o apoio do FP7 (EU Framework Programme 7) e visa criar uma nova
arquitetura de rede baseada na abordagem clean slate. O projeto 4WARD é dividido em
seis grupos de trabalho incluindo o NetInf [Niebert et al. 2008]. A ideia principal do
NetInf [Dannewitz 2008][Ahlgren et al. 2010][Dannewitz et al. 2008][Ahlgren et al.
2008] é obter um sistema para recuperação de informação baseado em um identificador
único desta informação. Para tal, é necessário um mecanismo de resolução de nomes
que faça o mapeamento de um identificador para um localizador desta informação. A
proposta considera que este mecanismo deve ser persistente e independente de cópia ou
localização. Em outras palavras, a identificação da informação não pode mudar ao se
relacionar com uma cópia ou com uma localização diferente da informação.
Além disso, o mecanismo de resolução de nomes para identificadores de
informação do NetInf é concebido de forma plana, ou seja, não hierárquico. Assim, este
mecanismo plano é incompatível com a concepção hierárquica do DNS (Domain Name
System) atual. Apesar do mecanismo plano não ser legível a humanos, este mecanismo
suporta melhores mecanismos de segurança e privacidade e não exige entidades
centralizadas de gerenciamento de nomes. Para [Dannewitz 2008], o NetInf estende o
conceito de desacoplamento da identificação e localização com outro nível de indireção,
visando desacoplar os objetos de informação de seus locais de armazenamento, ou seja,
criar acesso à informação independente do local de armazenamento e se beneficiar de
cópias distribuídas ao longo da rede.
O modelo de informação do NetInf é baseado em dois objetos: o objeto de
informação (IO – Information Object) e o objeto de dados (DO – Data Object). Os IOs
são objetos que representam a informação propriamente dita. Eles podem representar
uma imagem, um arquivo de som, um conteúdo de vídeo, páginas Web e assim por
diante. Já os DOs são um tipo especial de IO que representam um objeto no seu nível de
bit. Um DO aponta, por exemplo, para um arquivo, uma seqüência binária resultante da
codificação de mídia, tal como um arquivo com codificação MP3, ou para um texto. A
partir deste modelo de informação do NetInf, a pesquisa e recuperação da informação
pode se desenvolver de forma mais eficiente. Uma pesquisa baseada em um IO, por
exemplo, pode referir-se uma música específica sem especificar a codificação desta música
ou a orquestra que a executa, dado que muitas vezes estas informações não são relevantes
ao usuário. Os IOs, portanto, possibilitam que os usuários localizem o conteúdo interessado
independentemente de sua representação específica ou outras características, que a
princípio, não são interessantes a este usuário.
118
Anais
Segundo [Dannewitz 2008], a pesquisa de objetos de informação do NetInf é
feita através de um mecanismo de busca integrado na arquitetura NetInf, ou
alternativamente, através de um mecanismos de busca externa. Ambos, porém, devem
incluir novos tipos de funcionalidades baseadas em atributos do mundo real de
entidades físicas, tais como posição GPS (Global Positioning System) ou etiquetas de
RFID (Radio Frequency Identification).
O paradigma publica/assina (publish/subscribe) do NetInf é implementado a
partir da publicação de um objeto de informação. Esta publicação é feita ao registrar o
nome de determinado objeto de informação em um sistema de resolução de nomes, e a
assinatura por sua vez, é feita quando algum interessado solicita ao sistema de resolução
de nomes algum objeto publicado. A localização e assinatura de um objeto de
informação no NetInf só é possível, portanto, depois que este for publicado.
Para que se tenha segurança e confiança no conteúdo a ser disseminado na rede,
o NetInf propõe que a informação seja auto-certificável, ou seja, a confiança deve ser
nativa do conteúdo, ao contrário das redes de hoje em que a confiança na informação é
baseada no host que enviou esta informação. A integridade do conteúdo é garantida
através de uma ligação criptográfica entre o objeto de informação e o nome deste objeto
e a autenticidade é garantida a partir da aplicação de uma função hash de chave pública
como parte do nome auto-certificável. A verificação da autenticidade, portanto,
necessita de uma relação com uma entidade externa.
Os nomes da arquitetura NetInf são constituídos de três campos: um campo Tipo
responsável por definir o formato do nome, que especifica por exemplo, o algoritmo
hash utilizado no processo de auto-certificação; o campo Autenticador, responsável por
fazer a ligação entre o identificador do IO à chave pública; e finalmente, o campo
Rótulo, responsável por fazer a identificação do objeto individual. A combinação do
Autenticador com o Rótulo necessita ser único globalmente.
A arquitetura NetInf faz o uso de DHTs (Distributed Hash Tables) para o
roteamento dos conteúdos. Segundo [Cirani e Veltri 2007], as DHTs são uma classe de
sistemas distribuídos descentralizados que prestam um serviço de pesquisa semelhante a
uma tabela hash. Pares <chave, valor> são armazenados na DHT, e qualquer nó pode
participar recuperando o valor associado a uma dada chave. A responsabilidade por
manter o mapeamento entre as chaves e valores é distribuída entre os nós participantes
da topologia virtual DHT. Isso permite as DHTs escalarem um número extremamente
grande de nós e lidar com as chegadas e partidas contínuas de nós. As DHT formam
uma infra-estrutura que pode ser usada para criar serviços mais complexos, tais como
sistemas de arquivos distribuídos, compartilhamento de arquivos peer-to-peer e sistemas
de distribuição de conteúdo, web caching cooperativo, multicast, anycast, serviços de nome
de domínio e mensagens instantâneas.
A recuperação e entrega do conteúdo em NetInf se resume na combinação de
dois processos: o de resolução de nomes, que se responsabiliza por prover a localização
para um determinado identificador de objeto através de consulta em uma DHT; e o
processo de roteamento, que se responsabiliza por encaminhar a requisição para a
localização do armazenamento e retornar o conteúdo associado.
No NetInf existem duas abordagens para lidar com estes dois processos citados:
a primeira alternativa separa a fase de resolução de nomes da fase de roteamento, como
usado tradicionalmente nos esquemas de roteamento baseado em topologia, tais como o
119
OSPF (Open Shortest Path First) e o BGP (Border Gateway Protocol); a segunda
alternativa seria um esquema integrado de roteamento baseado em nomes de conteúdos
(LLC – Late Locator Construction), que combina o caminho de resolução e o caminho
de recuperação em um processo único. Segundo [Ahlgren et al. 2010], este último
esquema executa o roteamento através do mapeamento direto entre o identificador do
objeto de dados e a rota, o que diminui a latência e resulta, provavelmente, em melhor
desempenho. Ou seja, no roteamento LLC o localizador de um objeto é construído
dinamicamente baseado no caminho seguido pelos primeiros pacotes de sinalização
enviados. O assinante consulta o localizador do nó publicador no sistema de resolução
de nomes e envia pacotes de controle para o publicador, a fim de levantar informações
atualizadas da topologia da rede. A localização do objeto é construída no último
momento antes de enviar os pacotes de dados, daí a origem do termo Late Locator
Construction.
2.2. CCN – Content-Centric Network
CCN é um projeto do PARC (Palo Alto Research Center) que visa transformar a forma
como as redes de comunicação de dados atuais operam, através de uma mudança na
arquitetura de rede que faça a recuperação do conteúdo pelo seu nome, e não pela sua
localização. Neste contexto, a principal motivação das CCNs é melhorar a eficiência da
utilização da Internet atual, direcionando o foco da rede para a distribuição de conteúdo.
Desta forma, as CCNs propõem um novo mecanismo de distribuição de
conteúdo com os mesmos princípios de engenharia do IP, porém, utiliza a nomeação de
conteúdo, em vez de identificadores de hosts como foco principal. Segundo Van
Jacobson em [Palo Alto Research Center 2010], a visão das CCNs é reutilizar os
elementos bem sucedidos do TCP/IP, e construir uma nova rede, substituindo o modelo
IP centrado em hosts por um modelo orientado a conteúdo, para ser utilizado como o
protocolo central de interconexão de redes.
Conforme [Jacobson et al. 2009], nas CCNs existem dois tipos de pacotes: o de
interesse e o de dados. Um consumidor envia por broadcast a requisição do conteúdo
interessado através de um pacote de interesse. Esta informação fica armazenada em uma
tabela de interesses pendentes - PIT (Pending Interest Table). Uma base de informação
de encaminhamento - FIB (Forwarding Information Base) é utilizada para encaminhar
pacotes de interesse da tabela PIT, em busca de uma potencial fonte (nó publicador ou
cache) para a informação desejada. Qualquer nó que tenha o conteúdo de mesmo nome
do pacote de interesse enviado pelo consumidor pode responder com um pacote de
dados. Para que uma potencial fonte consiga identificar e localizar o assinante do conteúdo,
os pacotes de interesse deixam, figurativamente falando, “migalhas de pão” ao longo do
caminho, para que os pacotes de informação retornem pelo sentido reverso do caminho.
Desta forma, é possível maximizar o compartilhamento de informações na rede, já que cada
pacote enviado pode ser recuperado por vários consumidores interessados. Esta
característica reduz os custos de operação, pois uma única cópia pode ser compartilhada por
vários assinantes [Jacobson et al. 2009].
O controle de fluxo nas CCNs é baseado numa regra simples na qual um pacote
de interesse pode recuperar no máximo um pacote de dados. Em outras palavras,
pacotes de dados e de interesse utilizam uma razão de um para um, o que mantém o
controle de fluxo balanceado. Um controle de fluxo semelhante é utilizado no TCP,
entre o pacote de dados e o pacote de reconhecimento (Ack - Acknowledge). Os pacotes
120
Anais
de interesse têm o mesmo papel do anúncio da janela deslizante do TCP, ou seja, o
tamanho da janela do transmissor pode variar a partir da quantidade de pacotes de
interesse enviados [Jacobson et al. 2009]. Esta regra básica garante que o controle de
fluxo seja mantido e permite a comunicação de forma eficiente entre várias máquinas
sobre diversas redes heterogêneas.
A segurança nas CCNs é nativa do conteúdo, ou seja, a proteção e a confiança
“viajam” com o próprio conteúdo, evitando assim, várias das vulnerabilidades das redes
IP atuais. Ao contrário do NetInf, nas CCNs os nomes são tipicamente hierárquicos. No
contexto das redes centradas na informação, os mecanismos para resolução de nomes de
forma hierárquica podem criar nomes legíveis a humanos, além de fornecerem “dicas”
para a resolução de localizadores.
Ainda segundo Jacobson [Jacobson et al., 2009], nas CCNs, a relação de
confiança com o publicador é feita através do prefixo do nome do conteúdo, já que cada
pacote enviado contém a assinatura do publicador explícita no seu nome. A assinatura é
feita em cada pacote através do seu respectivo nome e estas assinaturas são padrões de
chaves públicas fornecidas por uma PKI (Public Key Infrastructure). A verificação do
nome com o conteúdo é feita através da respectiva chave privada, pertencente ao
requisitante do conteúdo. A confiança na chave de assinatura e a integridade dos dados
devem ser fornecidas através de mecanismos adicionais. Por exemplo, através de um
certificado baseado em alguma PKI. O paradigma publica/assina (publish/subscribe)
nas CCNs se dá quando um nó anuncia o nome de determinado conteúdo ao roteador. É
assim que a informação é publicada. A assinatura é feita quando um nó interessado no
conteúdo envia um pacote de interesse em busca de um potencial publicador. Os
pacotes de interesse são enviados por broadcast e a escolha de um dado publicador é
feita a partir da análise do maior prefixo correspondente ao nome especificado no
pacote de interesse. Os pacotes de dados seguem o caminho reverso até alcançar o
emitente do pacote de interesse (nó assinante).
2.3. PSIRP – Publish/Subscribe Internetworking Routing Paradigm
O PSIRP [Ain et al. 2008] é um projeto Europeu financiado pelo FP7 que começou em
janeiro de 2008 e tem previsão de término em 2010. O paradigma de roteamento
publica/assina (publish/subscribe) visa a troca do atual modelo de comunicação da
Internet “receptor aceita tudo que lhe for enviado” por um paradigma de comunicação
consensual ou autorizada e controlada totalmente pelo receptor (ou assinante). O PSIRP
propõe o projeto e análise de protocolos criptográficos focados apenas em publicar e
assinar o conteúdo, em vez do paradigma enviar e receber da Internet atual. Publicar
significa tornar um conjunto de dados disponível na rede, enquanto a assinatura de um
conteúdo corresponde a uma porção de dados solicitada por algum interessado na
informação publicada.
Para [Wong et al. 2008], o paradigma de roteamento publica/assina
(publish/subscribe) é um mecanismo atraente para a localização e recuperação de
conteúdo, uma vez que tal mecanismo trata de forma independente os publicadores e os
assinantes de conteúdo. No PSIRP, as mensagens não são dirigidas a qualquer nome de
receptor, já que não existem nomes de receptor ou transmissor fornecidos por redes.
Desta forma, o roteamento da requisição e do próprio conteúdo no PSIRP é dividido em
dois processos: um para o encontro do solicitante (assinante) com uma potencial fonte
121
(publicadora) do conteúdo, e outro destinado à entrega dos pacotes de conteúdo ao
assinante.
Quando um nó publica algum dado, a transferência da informação propriamente
dita não ocorre. O que ocorre é a publicação da disponibilidade desta informação em um
sistema chamado de rendezvous ou ponto de encontro. O rendezvous é responsável pelo
encontro entre o publicador e o assinante de determinada informação. Em outras
palavras, quando um nó se inscreve para determinada informação, a rede encontra a
publicação de interesse e cria o caminho de entrega entre o publicador e o assinante
desta informação.
A arquitetura RTFM (Rendezvous, Topology, Forwarding and Mediation) do
PSIRP é composta por quatro funções [Rothenberg et al. 2008][Zahemzky et al. 2010]:
ponto de encontro (rendezvous), gerenciamento de topologia, encaminhamento e
mediação. O rendezvous é responsável por fazer a ligação de um interessado em um
conteúdo com uma ou mais potenciais fontes para este conteúdo. O gerenciamento de
topologia constrói e mantém caminhos entre diferentes redes de transmissão baseadas
no paradigma publica/assina. O encaminhamento realiza a entrega de pacotes baseada
em técnicas de comutação por rótulos. E finalmente, a mediação refere-se à transmissão
física de dados entre dois nós.
Conforme [Ain et al. 2008], a arquitetura do PSIRP possui ainda um mecanismo
de escopo, utilizado para limitar o alcance de uma informação publicada. Com base em
políticas de governança, um usuário pode construir uma relação de confiança e
privacidade entre as entidades participantes na comunicação (publicadores, assinantes e
a própria informação). Uma determinada publicação pode estar disponível em diversos
escopos e pode ser inserida em um escopo a partir do interesse de um publicador ou de
um assinante.
Ainda segundo [Ain et al. 2008], os identificadores de aplicação (AIds –
Application Identifiers) são utilizados por publicadores e assinantes para classificar,
distinguir e rastrear entidades como dispositivos, produtos, pessoas, títulos de conteúdos
(músicas, endereços de páginas web), serviços (endereço de serviços web ou de email,
número de telefone), etc. Estes identificadores, diferente dos outros identificadores a
serem apresentados, são definidos usando a semântica da aplicação e contextos
específicos.
Os identificadores de Rendezvous (RIds – Rendezvous Identifiers) são utilizados
para ligar os identificadores de nível superior (identificadores de aplicações) com os
identificadores das camadas inferiores (identificadores de encaminhamento). Os RIds
podem ainda incluir operações como autenticação de rede, controle de acesso de
publicadores e de assinantes interessados em participar de um determinado encontro,
além de permitir o encaminhamento de solicitações de conteúdo para um determinado
publicador [Zahemzky et al. 2010].
Os identificadores de encontro podem ser criados por um emissor ou um
receptor de dados a fim de estabelecer uma conexão. Em outras palavras, o publicador
pode adquirir um identificador e enviar para o assinante, ou um assinante pode
selecionar um identificador para o encontro e informar a um potencial publicador.
Existe ainda uma terceira opção para a escolha de identificadores, onde uma aplicação
ou um serviço necessita de um identificador de encontro para estabelecer a
comunicação.
122
Anais
Os identificadores de escopo (SIds – Scope Identifiers) são utilizados para
delimitar a acessibilidade do conteúdo publicado. Os SIds são implementados pelos
RIds para limitar a distribuição de conteúdo a regiões específicas e definir a rota para a
entrega dos pacotes de dados, ao definir o FId (Forwarding Identifiers). Um dos
desafios do PSIRP é gerenciar a escalabilidade relacionada às estruturas de escopos, já
que para estabelecer um determinado ponto de encontro, precisa-se dimensionar
corretamente o escopo relacionado.
Ainda segundo [Ain et al. 2008], um par (RId, SId) é usado pelo sistema de
encontro para determinar o conjunto apropriado de identificadores de encaminhamento
para a entrega dos dados para um conjunto de assinantes. Um único RId pode ser
associado a um conjunto de SIds. Em outras palavras, uma publicação de dados pode
ser associada a um ponto de encontro estabelecido pelo publicador, e ao mesmo tempo,
estar ligada a diferentes escopos de acessibilidade. Resumidamente, existe pelo menos
um ponto de encontro por escopo. O publicador de uma informação deve publicá-la
dentro de um escopo específico, identificando-o durante a operação de publicação.
Os identificadores de encaminhamento (Fids) são utilizados para o transporte
das publicações através das redes. Cada par ativo (RId, SId) possui um mapeamento de
pelo menos um identificador de encaminhamento. As árvores de transmissão
identificadas por um FId podem ser compartilhadas para finalidades de escalabilidade
[Ain et al. 2008].
Para questões de segurança, é esperado que os identificadores sejam concebidos
de maneira semelhante à utilizada pelo HIP, ou seja, utilizando o identificador baseado
em uma chave pública cuja a correspondente chave privada é de posse do publicador.
Isso permite que o host publicador escolha um identificador que possa ser usado por
assinantes para autenticar os dados e verificar se eles foram enviados de fato pelo
publicador que possui a associada chave privada.
Em PSIRP, as propriedades de segurança para mensagens de controle mais
importantes são a proteção da integridade e a autenticação. A proteção da integridade
pode verificar, por exemplo, se o pacote foi modificado, e a autenticação garante que o
publicador possui a permissão do escopo para publicar uma informação com um
determinado par (RId, SId) [Zahemzky et al. 2010].
Conforme [Zahemzky et al. 2010], o PSIRP possui ainda uma autenticação a
nível de pacote (PLA - Packet Level Authentication). A PLA é uma função para prover
segurança aos hosts finais através de uma assinatura criptográfica feita individualmente
em cada pacote. Ela permite ainda, que os nós ao longo do caminho de entrega
verifiquem os pacotes sem que existam associações de confiança pré-estabelecidas com
o publicador. Em PSIRP, a PLA é utilizada geralmente para segurança de mensagens de
controle (mensagens publica/assina), podendo ser ampliada para a sua utilização em
todo o tráfego.
O PSIRP possui ainda um mecanismo anexado aos pacotes para melhorar o
desempenho do encaminhamento de dados, denominado de filtros de Bloom [Ahlgren et
al. 2010]. Os filtros de Bloom são uma simples estrutura de dados aleatória com o
propósito de consultar e selecionar elementos de forma eficiente em um dado conjunto
de participantes, como por exemplo, a escolha de uma rota em um conjunto de rotas. A
desvantagem dos filtros de Bloom é que estes permitem falsos positivos, em
contrapartida, a economia de espaço muitas vezes compensa essa desvantagem quando
123
a probabilidade de um erro é controlada ou é suportada por alguma aplicação [Ahlgren
et al. 2010].
3. Comparações entre NetInf, CCN e PSIRP
Nesta seção são comparadas e discutidas características e opções de projeto mais
relevantes entre as arquiteturas apresentadas.
3.1. Nomeação da Informação
Em qualquer projeto de redes centradas na informação, deve ser possível se referir à
própria informação, independentemente das redes em que ela se encontra. Um esquema
de nomeação para objetos de informação é, portanto, talvez a parte mais importante do
projeto [Ahlgren et al. 2010].
A princípio, os nomes NetInf e PSIRP são semelhantes por usarem um esquema
de nomeação plano, e divergem pelo fato do NetInf utilizar um único namespace,
enquanto o PSIRP utiliza dois namespaces, um para o encontro e outro para o
encaminhamento. O namespace especificado pelo NetInf é semelhante ao do PSIRP
destinado ao encontro. Por outro lado, o NetInf não possui o namespace destinado ao
encaminhamento, pois este namespace é parte do protocolo particular da camada de
rede. Já o esquema de nomeação da CCN utiliza a concepção hierárquica. A estrutura de
nomes para a informação é concebida em forma de árvore, sendo que a raiz da estrutura
representa o prefixo do nome da informação. Isto torna este prefixo único e exclusivo a
um determinado publicador.
Os esquemas de nomeação hierárquicos têm a vantagem de estabelecer nomes
legíveis a humanos e aptos à interação através de um browser. Outra vantagem dos
sistemas hierárquicos é que estes permitem a agregação de estado de roteamento –
routing state – além do fato que, o conteúdo CCN pode ser criado dinamicamente em
resposta a uma solicitação. Esta peculiaridade das CCNs só é possível devido à sua
estrutura de nomes hierárquicos concebidos de forma significativa. Em contrapartida, os
nomes planos possuem melhores propriedades de segurança, já que não dependem de
entidades centralizadas de resolução de nomes para desenvolver esta atividade,
permitindo a auto-identificação das informações. Esta última peculiaridade é bastante
atraente às aplicações que necessitam gerar informações com identificadores de forma
autônoma. A questão mais importante, portanto, seria como fazer a ligação entre o
esquema de nomeação de forma plana e um sistema de resolução de nomes para
endereços como o DNS atual, já que este último é baseado em identificadores
hierárquicos e, portanto, inapropriado para identificadores planos. Ou ainda, no caso de
soluções clean-slate, como relacionar os nomes planos a localização e posterior
encaminhamento.
Existem outras propostas de encaminhamento de conteúdo e consulta a sistemas
de cache baseado em nomes planos na literatura como o SPSwitch baseado em filtros de
Bloom [Rothenberg et al. 2008]; consulta para roteamento de conteúdo baseado em
DHTs [Ahlgren et al. 2010][Liu et al. 2008]; além do roteamento baseado em rótulos
planos (ROFL – Routing on Flat Labels) [Campista 2010].
124
Anais
3.2. Questões de Segurança
O fato de que nas redes centradas em conteúdos, as mensagens enviadas contêm
controles relacionados apenas ao conteúdo cria um isolamento natural entre informação
e os hosts da rede, tornando estes menos vulneráveis, já que usuários mal-intencionados
terão mais dificuldade em acessar estes hosts usando apenas informação fraudulenta. As
abordagens baseadas em nomes planos estão fortemente ligadas às relações de
confiança, já que os nomes possuem ligações com o conteúdo através de criptografia de
chave pública.
A integridade dos objetos de dados do NetInf é feita através do campo
autenticador, que faz a ligação direta com o publicador dos dados. “Se o campo de
rótulo contiver um valor de hash criptográfico calculado sobre o objeto de dados, o
nome também conterá uma ligação direta com o conteúdo, que fornece, assim, a autocertificação da integridade do objeto de dados” [Ahlgren et al. 2010]. Nas CCNs, a
relação com o publicador é feita através do seu prefixo único explícito em cada pacote
de dados enviado. A assinatura é feita em cada pacote através do respectivo nome e
estas assinaturas são padrões de chave pública. A verificação do nome com o conteúdo
é feita através da respectiva chave privada. A confiança na chave de assinatura e a
integridade dos dados devem ser fornecidas através de mecanismos adicionais. Por
exemplo, um certificado baseado em PKI. Para o PSIRP a segurança é garantida através
dos identificadores de encontro e escopo construídos a partir do hash do conteúdo, além
de possuir um mecanismo de segurança indireto através do hash de chave pública
adicionado ao rótulo. Mais ainda, o PSIRP dispõe da autenticação em nível de pacote
(PLA – Packet-Level Authentication) adicionada para o encaminhamento de pacotes, a
fim de combater ataques DoS [Ahlgren et al. 2010].
3.3. Roteamento
Nas CCNs o pacote de interesse é roteado por broadcast para uma potencial fonte que
contenha os dados desejados. O publicador escolhido será o que possuir o maior prefixo
correspondente ao nome especificado no pacote de interesse, daí mais uma
peculiaridade dos nomes hierárquicos nesta abordagem. Os pacotes de dados seguem o
caminho inverso até alcançar o solicitante. Além disso, segundo [Jacobson et al. 2009],
as CCNs podem utilizar os protocolos de roteamento convencionais, já que elas são
compatíveis com as redes IP. Já no NetInf e no PSIRP o roteamento é dividido em dois
processos: um para o encontro do solicitante com uma potencial fonte, e outro destinado
à entrega dos pacotes propriamente dita. O PSIRP possui ainda um mecanismo de
encaminhamento de dados baseados em filtros de Bloom anexado aos pacotes. Já o
NetInf possui o mecanismo de roteamento baseado em nomes (LLC), que integra os
caminhos de resolução e recuperação, e que segundo [Ahlgren et al. 2008] pode resultar
em melhor desempenho.
3.4. Aspectos de Caching
Um dos princípios das redes centradas na informação é que os usuários podem se beneficiar
de cópias de conteúdos espalhados ao longo da rede, permitindo otimizar a disseminação
global da informação. O cache de objetos de informação, portanto, é parte crucial de todas
as três abordagens de redes centrada em informações. Na
arquitetura
NetInf,
o
conteúdo em cache também pode ser encontrado através de busca local ou ser encontrado
através do sistema de resolução de nomes se, neste caso, existir uma cópia em cache neste
125
local. Há também a possibilidade do transporte NetInf encontrar cópias em cache no
caminho para a localização de uma cópia do objeto. Já no PSIRP, o cache de conteúdo se
limita ao escopo e ao ponto de encontro. Nas CCNs, o conteúdo em cache pode ser
localizado através de um mecanismo de pesquisa local ou ao longo do caminho do pacote
de interesse até a potencial fonte. Questões de caching são indispensáveis até quando se fala
nos seus aspectos legais e contratuais. Por exemplo, quem se responsabiliza pelos conteúdos
em cache ao longo da rede, os desenvolvedores do conteúdo ou os proprietários do cache?
Quais são os direitos e obrigações dos usuários que fornecem o cache para operadoras de
serviços?
3.5. Relação entre o Publicador e o Assinante
Como citado anteriormente, nas CCNs, apenas quando um nó anuncia um prefixo de
determinado conteúdo ao roteador a informação é publicada. A assinatura é feita quando um
nó interessado no conteúdo envia um pacote de interesse em busca de um potencial
publicador. Já no NetInf, a publicação é feita ao registrar o nome de determinado objeto de
informação em um sistema de resolução de nomes e a assinatura é feita a partir da
solicitação do objeto publicado ao sistema de resolução de nomes. No PSIRP, o contato
entre o publicador e o assinante é feito através do processo de rendezvous.
3.6. Encontro entre o Emissor e o Receptor
No NetInf e no PSIRP, o ponto de encontro entre o emissor e o receptor é estabelecido
apenas depois que os identificadores são registrados em um sistema de resolução de
nomes. Já nas CCNs, o publicador pode criar o conteúdo dinamicamente a partir de uma
solicitação. Em outras palavras, um interessado pode construir um nome para
determinado conteúdo que ainda não exista, e o remetente cria dados em resposta,
completando o encontro.
3.7. Escalabilidade
Um novo projeto de arquitetura de rede que aspira tornar-se uma verdadeira rede
mundial deve ser escalável ao extremo, permitindo que trilhões de nós e terminais sejam
conectados a rede. Além disso, os projetos devem ser capazes de transportar os exabytes
de informação mensal Internet atual e futura, e ainda ser economicamente viável
[MINTS 2010]. Os roteadores das CCNs têm dois desafios ao lidarem com a escala: o
gerenciamento do número de prefixos de nomes e o armazenamento de informações de
estado por pacote (Per-Packet State). As informações de estado são necessárias ao
longo do caminho fim a fim, o que representa uma desvantagem do ponto de vista da
escalabilidade. Já para o PSIRP, o desafio é gerenciar a escalabilidade relacionada às
estruturas de escopos, já que para estabelecer um determinado ponto de encontro,
precisa-se dimensionar corretamente o escopo relacionado. Outro desafio é o
gerenciamento do encaminhamento baseado no filtro de Bloom, que se torna um
problema quando usado com grandes grupos de destinatários. O desafio de
escalabilidade enfrentado pela arquitetura NetInf é que cada objeto de informação deve
ser representado por uma entrada no sistema de resolução de nomes global.
3.8. Outros Aspectos
As abordagens de redes centradas no conteúdo devem suportar a mobilidade tanto dos
objetos de informação, quanto de hosts e redes [Martins e Alberti 2011]. Para o NetInf e
o PSIRP, a mobilidade da informação é garantida pela persistência de nomes e pelo
126
Anais
desacoplamento entre a identificação e a localização da informação. Enquanto a
mobilidade de entidades físicas (nós e redes) é suportada por mecanismos adicionais de
desacoplamento da identificação e localização de hosts, semelhantes ao Mobile IP
[Perkins 2002] (acrescentando o care-of-address) e ao HIP [Moskowitz e Nikander
2006] (conceito de rendezvous), para o NetInf e PSIRP, respectivamente. Dado que
a localização do objeto de informação influência semanticamente nos nomes
CCNs, estas redes não desacoplam a identificação e a localização da informação em um
dado domínio. O desacoplamento não acontece também para entidades físicas, como
hosts e redes. Segundo [Jacobson et al. 2009], as CCNs endereçam conteúdo e não
hosts, não existindo a necessidade de mapear um endereço a partir de um identificador.
Neste caso, quando uma conexão é interrompida devido a um evento de mobilidade,
esta conexão pode ser restabelecida logo que exista uma conectividade disponível. A
Tabela 1 é uma versão modificada e ampliada da tabela contida em [Ahlgren et al.
2010] e resume as comparações feitas entre as abordagens de redes centradas no
conteúdo.
Tabela 1. Resumo das comparações em Redes Centradas na Informação
NetInf
CCN
PSIRP
Esquema de Nomeação
Um namespace plano.
Hierárquico.
Nomes
Nomes persistentes, opacos e não
agregáveis.
Ligação direta do nome com a chave
pública.
Nomes persistentes, legíveis e
agregáveis.
Ligação com o publicador através do
prefixo do nome.
Dois namespaces planos. Um para o
rendezvous e outro para o transporte.
Nomes persistentes, opacos e não
agregáveis.
Hash de conteúdo + hash chave
pública + autenticação a nível de
pacote.
Dois roteamentos: Um para
encontro, outro para transporte +
filtro de Bloom.
Limitado ao escopo do ponto de
encontro.
Segurança
Roteamento
Dois roteamentos: um para encontro, Broadcast do pacote de interesse para
outro para transporte + LLC.
fonte, dados caminho reverso.
Caching
Localizado pelo mecanismo de
resolução de nomes; pesquisa local ou
transp.
Pub: Objeto de Informação
As: Consulta NRS. Encontro necessita
do registro prévio do nome junto ao
NRS.
Uma entrada no NRS por objeto;
agregação de publicação.
Semelhante ao Mobile
IP – Home Address e
Care-of Address.
Desacopla –
Persistência de nomes.
Relação entre o
Publicador e o Assinante
Escalabilidade
Desacoplamento ID/Loc
Hosts
Desacoplamento
ID/LOC
Informação
Localizado por pesquisa local ou no
caminho para o publicador.
Pub: Prefixo de nome
As: Envia o interesse. O encontro pode
ser criado dinamicamente em resposta a
um interesse.
Nº de prefixos; estado de encam. por
pacote.
Mapeamento ID/LOC
considerado
desnecessário.
Não desacopla
Localização influencia
semanticamente no nome.
Pub: Estabelece o ponto de encontro
As: Estabelece contato.
Encontro desenvolvido no
rendezvous.
Confusa – depende das estruturas de
escopos.
Semelhante ao HIP Rendezvous.
Desacopla –
Persistência de nomes.
4. Conclusões
As abordagens de redes centradas na informação propõem o desenvolvimento de uma
rede com o foco na informação propriamente dita em vez de hosts, se preocupando,
sobretudo com a segurança, escalabilidade, eficiência, qualidade e suporte a
comunicação em tempo real. Tais abordagens podem ser classificadas como clean slate,
uma vez que redesenham do zero a forma como trocamos informação na Internet. Estas
redes têm como principal função a interligação em grande escala dos desenvolvedores e
consumidores de conteúdo aumentando a eficiência no acesso e na disseminação da
informação.
O grande desafio das redes centradas na informação é estabelecer um padrão
para nomeação da informação de forma consistente e eficiente, além de soluções para
localização e roteamento das informações baseadas nas informações nomeadas. Assim
sendo, a principal diferença entre as três abordagens é o sistema de resolução de nomes,
127
já que os demais desafios como roteamento, segurança e escalabilidade estão fortemente
ligados ao esquema de nomeação escolhido. A arquitetura NetInf e o PSIRP utilizam o
esquema de resolução de nomes na forma plana e a CCN utilizam o esquema de
nomeação de forma hierárquica. Ainda, os sistemas com nomeação plana sofrem com a
incompatibilidade com o DNS atual e, portanto, necessitam de um mecanismo que
interopere com o DNS ou a concepção de um sistema de resolução de nomes para
nomes planos que seja escalável. Em contrapartida, estes sistemas planos possuem uma
ligação mais próxima com os requisitos de segurança.
Outro desafio para a utilização de nomes planos é que estes nomes são opacos e
livres de semântica. Em outras palavras, um nome plano é representado por uma
seqüência de bits, a qual não traz informações legíveis e interpretáveis a usuários. A
arquitetura NetInf faz o uso de DHTs. Para nomes planos, sistemas baseados em DHTs
são uma abordagem promissora [Ahlgren et al. 2010]. Entretanto, ao contrário das
CCNs, estes sistemas requerem que o conteúdo seja publicado explicitamente para
informar à DHT a sua localização antes que a informação possa ser recuperada.
Referências
Jacobson, V., Smetters, D. K., Thornton, J. D., Plass, M., Briggs, N., Braynard, R.,
Networking Named Content, ACM CoNEXT 2009, Italy.
Palo Alto Research Center Incorporated. Focus Area. Disponível em 24/06/2010 no
endereço http://www.parc.com/work/focus-area/networking/.
Rothenberg, C., Verdi, L., Magalhães, F., Towards a New Generation of InformationOriented Internetworking Architectures, ACM CoNEXT 2008, EUA.
Niebert, N., Lundgren, L e Abramowicz, H., 4WARD Deliverable 0.1, Dissemination
and Exploitation Plan, 2008.
Dannewitz, C., NetInf: An Information-Centric Design for the Future Internet, 2008.
Ahlgren, B., D’ambrosio, M, Dannewitz, C., et al., Second NetInf Architecture
Description. Deliverable 6.2. 2010. Último acesso em 20/04/2010 no endereço
http://tools.ietf.org/html/draft-ietf-lisp-06/.
Dannewitz, C., Pentikousis, K., Rembarz, R., Renault, É., Strandberg, O., Ubillos, J.,
Scenarios and Research Issues for a Network of Information, MobiMedia 2008,
Finland.
Ahlgren, B., D’ambrosio, M, Marsh, I., Marchisio, M., Strandberg, O., Design
Considerations for a Network of Information, ACM CoNEXT 2008, EUA.
Cirani, S., Veltri, L., Implementation of a Framework for a DHT-based Distributed
Location Service, SoftCOM 2008, Itália.
Zahemzky, A., Borislava, G., Rothenberg., C.E., Experimentally Driven Research in
Publish/Subscribe Information Centric Internetworking, Tridentcom 2010,
Alemanha.
Nikander, P., Marias, G., Towards Understanding Pure Publish/Subscribe
Cryptographic Protocols, Cambridge Security Protocols Workshop (SPW 2008),
2008.
128
Anais
Liu, S., Bi, J., Wang, Y., A DHTs-Based Mapping System for Identifier and Locator
Separation Network, First International Conference on Advances in Future Internet,
2009, EUA.
Campista, M. E., et al., Interconexão de Redes na Internet do Futuro: Desafios e
Soluções.
2010.
Disponível
em
15
set.
2010
no
endereço
http://www.gta.ufrj.br/ftp/gta/TechReports/CFM10.pdf.
Minnesota Internet Traffic Studies (MINTS), The Exabyte Era, Acessado em 20 de
setembro de 2010 no endereço http://www.dtc.umn.edu/mints/references.html.
Perkins, C., IP Mobility Support for IPv4, RFC3344, 2002.
Moskowitz, R., Nikander, P., Host Identity Protocol (HIP) Architecture, RFC4423,
2006.
Ain, M., et al., PSIRP Publish-Subscribe Internet Routing Paradigm Deliverable 2.2:
Conceptual Architecture of PSIRP Including Subcomponent Descriptions, 2008.
Wong, W., Verdi, F., Magalhães, M. F., A Security Plane for Pub-Sub Based Content
Oriented Networks, ACM CoNEXT Conference, 2008.
Martins, B. M., Alberti, A. M., Host Identification and Location Decoupling: A
Comparison of Approaches, International Workshop on Telecommunications (IWT
2011), 2011, Brasil.
Sistemas P2P
♦
Sessão Técnica 4
Segurança e Desempenho
131
Distribuição de Conteúdo Multimı́dia em Tempo Real com
Transporte de Fluxos Controlados e Não Confiáveis entre
Pares
Leandro M. de Sales1 , Hyggo O. de Almeida2 , Angelo Perkusich2 , Rafael A. Silva1
1
Instituto de Computação
Universidade Federal de Alagoas (UFAL)
57.072-970 – Maceió – AL – Brasil
2
Centro de Engenharia Elétrica e Informática
Universidade Federal de Campina Grande (UFCG)
58.429-140 – Campina Grande – PB – Brasil
{leandro,rafaelsilva}@ic.ufal.br, hyggo@dsc.ufcg.edu.br, perkusic@dee.ufcg.edu.br
Resumo. A transmissão de conteúdo multimı́dia em tempo real através da Internet é de fundamental importância para as diversas aplicações atuais como voz
sobre IP, videoconferência, jogos e TV pela Web. Os protocolos de transporte
mais conhecidos - TCP e UDP - não são efetivos quando se deseja transmitir
dados destas aplicações. Neste sentido, a IETF tem trabalhado em novos protocolos de transporte que aumentem a qualidade destas aplicações multimı́dia.
Dentre estes novos protocolos, o DCCP (RFC 4340) é efetivo em transmissões
de conteúdo multimı́dia através da Internet. Todavia, o DCCP não é efetivo em
cenários onde existam muitos nós receptores e apenas um nó transmissor. Portanto, este artigo propõe o MU-DCCP, uma extensão do protocolo DCCP capaz
de permitir transmissões de dados multimı́dia de 1 para muitos nós e controle
de congestionamento de tráfego não confiável. O MU-DCCP utiliza multicast
quando disponı́vel ou um fluxo unicast por cada rede de destino e compartilhamento de dados entre os nós receptores. Com o uso do MU-DCCP, constata-se
uma redução considerável de congestionamento na rede.
1. Introdução
A transmissão de conteúdos multimı́dia em tempo real através da Internet tornou-se uma
necessidade em aplicações como Voz sobre IP (VoIP), Videoconferência, Jogos e WebTV.
Aplicações deste tipo implementam mecanismos sofisticados para melhorar a qualidade
dos fluxos de dados e utilizar de forma eficiente os recursos disponı́veis da rede. Na
prática, tais mecanismos são implementados em forma de protocolos de rede com o intuito de: (i) reduzir altos nı́veis de congestionamento na rede; (ii) manter a eqüidade entre
diferentes fluxos transmitidos por diferentes sistemas finais conectados à rede; e (iii) garantir nı́veis mı́nimos de qualidade do conteúdo multimı́dia sendo transmitido.
Aplicações como as supracitadas estão ganhando cada vez mais espaço no que
diz respeito a adeptos em suas utilizações, principalmente na Internet. Para se ter uma
idéia deste crescimento, recentemente a empresa Cisco publicou um artigo [Leavitt 2010]
onde apresentou uma previsão de que em 2014 o tráfego de video será maior do que o
tráfego P2P em 2009, o que correspondeu a 39 % do tráfego naquele ano. A empresa
prevê também que em 2014, o tráfego de VoIP, vı́deo e jogos na Internet alcançará a
marca de 40 Exabytes/mês, quase 50 % do tráfego de dados total na Internet previsto para
2014. Embora já se saiba o potencial do modelo de serviço P2P, esta previsão demonstra o nı́vel de aceitação dos usuários em compartilhar seus arquivos e obter mais dados
disponibilizados por outros usuários. Recentemente, a Paramount Pictures publicou uma
nota [Freak 2011] informando que passará a transmitir filmes através de grandes redes
P2P, tais como o BitTorrent. A própria empresa BitTorrent anunciou que está trabalhando
em uma aplicação P2P para transmissão de conteúdos multimı́dia em tempo real. Por
132
Anais
último, no final de março/2011, a Amazon anúnciou [Amazon 2011] que também entrará
na disputa por uma fatia deste tipo de serviço. A empresa disponibilizará um reprodutor
de conteúdo multimı́dia completamente online, onde as pessoas poderão comprar músicas
e vı́deos online e em seguida reproduzi-los em tempo real, com os dados armazenados na
infra-estrutura de computação nas nuvens da empresa.
Diante deste cenário, desenvolver protocolos de rede para dar suporte a estas novas formas de fornecer serviços multimı́dia através da Internet tem se tornado uma tarefa
ainda mais complexa, pois exige-se uma harmonia entre os requisitos mencionados anteriormente em meio às mudanças no consumo e disponibilidade de recursos da rede.
Os protocolos para a Internet precisam ser projetados para inferir o estado da rede e ao
mesmo tempo tomar decisões de acordo com as mudanças detectadas de forma rápida.
Do ponto de vista da camada de transporte da pilha TCP/IP, protocolos tradicionais de
transporte como o UDP e o TCP não foram projetados para tal, sendo deixado a cargo dos
desenvolvedores das aplicações implementarem seus próprios mecanismos para controle
de congestionamento e de fluxos de dados sem garantia de entrega, particularmente no
caso do uso do UDP, adotado na maior parte das aplicações multimı́dia. Nos casos em
que se tentam utilizar TCP em aplicações multimı́dia em tempo real, o mesmo não apresenta um desempenho satisfatório porque se implementa controle de congestionamento e
garantia de entrega de uma forma não adequada para aplicações multimı́dia com transmissão de dados em tempo real.
Visando melhorar este cenário, novos protocolos de transporte de dados para a Internet foram padronizados pela IETF, onde os principais foram o protocolo DCCP (Datagram Congestion Control Protocol) [Kohler et al. 2006b] [Kohler et al. 2006c] e o SCTP
(Stream Control Transmission Protocol) [Jungmaier 2003]. No contexto deste trabalho, o
foco da pesquisa está no protocolo DCCP e, por este motivo, discussões acerca de outros
novos protocolos de transporte, como o SCTP, serão omitidas.
1.1. Cenário de aplicação e escopo do trabalho
Neste trabalho, o cenário de aplicação analisado envolve a transmissão de dados multimı́dia em tempo real e o uso de algoritmos de controle de congestionamento durante a
transmissão de dados visando compartilhar o canal de transmissão de forma equilibrada
entre todos os nós presentes na rede. Este cenário geralmente envolve diversos desafios,
tais como: (i) permitir que fluxos multimı́dia convivam com fluxos de dados de aplicações
elásticas sem que estes últimos sejam degradados pelos primeiros – vasta utilização do
protocolo TCP; e (ii) evitar perdas excessivas de dados por parte das aplicações multimı́dia em questão, pois, neste caso, não faz sentido retransmitir dados quando estes são
perdidos.
Existem diversos exemplos de aplicações que podem ser aplicados no cenário investigado, principalmente quando se utiliza o modelo de serviço P2P, tais como:
• Aplicações para transmissão de conteúdo multimı́dia em tempo real de um nó
da rede para um outro, ou para um conjunto de outros nós. Por exemplo, sites
durante a transmissão de dados, online como o livestream.tv e streamtheworld.com
permitem que um usuário transmita conteúdos multimı́dia do seu computador para
milhares de outros usuários conectados à Internet;
• Aplicações de telefonia IP, tais como o Skype, principalmente considerando o
modo de conversa em grupo;
• TV Online, por exemplo, transmissões através da Internet de jogos da copa do
mundo ou do campeonato brasileiro de futebol; e
• Jogos, videoconferência 1-para-muitos e rádios online. Para estes exemplos, existem muitos usuários interessados por um mesmo conteúdo, porém poucos dados
individualizados. Ou seja, nada muda em termos dos dados que cada nó receptor
receberá do nó transmissor.
133
Uma caracterı́stica fundamental compartilhada por todos os exemplos supracitados é que na transmissão de dados sempre existe um nó gerador do conteúdo e milhares
de nós receptores (1 → N). Quando se projeta um protocolo de rede para este fim, deve-se
levar em consideração esta caracterı́stica da aplicação para que se possa obter resultados
significativos na qualidade do fluxo de dados multimı́dia sendo transmitido e na efetiva
utilização dos recursos da rede.
Neste contexto, as duas grandes questões que surgem são: (i) como fazer isto de
forma padronizada e assim evitar que cada desenvolvedor de aplicação tenha que implementar este tipo de mecanismo na sua própria aplicação, o que aumentaria a sua complexidade e o seu gerenciamento do ciclo de vida; e (ii) o que pode ser aproveitado do que
está disponı́vel para atingir o objetivo da primeira pergunta.
A seguir, será abordada uma discussão geral acerca da utilização dos protocolos de
transportes da pilha TCP/IP quanto utilizados para transmissão de fluxos multimı́dia em
tempo real, assim como detalhes e problemas do protocolo DCCP em transmissões multimı́dia em tempo real. Na Seção 3, será apresentada discussões sobre o problema tratado
neste trabalho. Na Seção 4, será apresentado o MU-DCCP, uma versão multi(uni)cast do
protocolo DCCP para distribuição de conteúdos multimı́dia em tempo real e com suporte
a controle de congestionamento e compartilhamento de fluxos multimı́dia entre pares. Na
Seção 5 será apresentada a metodologia utilizada nesta pesquisa e os resultados obtidos
com discussões relacionadas. Por fim, na Seção 6 serão apresentadas as conclusões desta
pesquisa.
2. Visão geral do TCP, UDP e DCCP em cenários de aplicações multimı́dia
em tempo real
O protocolo UDP tem sido largamente utilizado em aplicações multimı́dia em tempo real
por ser um protocolo leve, fazendo uso apenas do serviço de melhor esforço do IP para
transmitir dados na Internet. Com o passar dos anos e antes do DCCP, o UDP se tornou
a primeira e única opção para transmissão de dados multimı́dia em tempo real, porém
gerando diversos efeitos colaterais nas grandes redes, os quais são vastamente discutidos
na literatura[Floyd et al. 2006, de Sales et al. 2008b, de Sales et al. 2008a].
Para se ter uma idéia dos efeitos colaterais gerados na rede com o uso do UDP,
observa-se o gráfico vazão × tempo ilustrado na Figura 1. Este gráfico corresponde a
um experimento realizado com a transmissão de 1 fluxo TCP competindo com 3 fluxos
de áudio UDP em uma rede Ethernet de 100 Mbps. Observe que o UDP sempre ocupa
o máximo da largura de banda disponı́vel na rede ao passo que não oferece chances para
outros fluxos utilizarem o canal, como é o caso do TCP. Por este motivo, o UDP sempre se
apresenta com altas taxas de perda de pacotes, sobretudo quando há congestionamento na
rede. No caso deste experimento, nos primeiros 50 s, quando não disputava com nenhum
outro fluxo, o fluxo TCP utilizou a rede de forma satisfatória, alcançando uma vazão em
torno de 20 Mbps. Entretanto, após esta fase, quando os três fluxos UDP foram transmitidos na rede, a vazão do fluxo TCP reduziu praticamente para 0, permanecendo assim até
o final do experimento.
O protocolo TCP, por sua vez, atende de forma satisfatória as aplicações que toleram atrasos na entrega de dados e que exigem que estes sejam todos entregues corretamente e em ordem (aplicações elásticas). Porém, em se tratando de transporte de dados
multimı́dia em tempo real, o TCP se torna o protocolo menos apropriado para este fim,
pelo menos comparando-o com o UDP e o DCCP. Nas aplicações de fluxo multimı́dia
em tempo real, é preferı́vel manter o fluxo de dados e reproduzir o conteúdo que chega
a esperar do que a informação perdida ser retransmitida, mesmo diante do fato de que
parte dos dados da aplicação terem sido perdidos. Ao utilizar o TCP, isto não é possı́vel.
O principal motivo é que o TCP implementa uma entrega confiável de dados adotando a
abordagem de retransmitir qualquer pacote perdido quando: (i) nenhuma confirmação de
recepção (ACK) de pacote for recebida dentro do intervalo de tempo de um temporiza-
134
Anais
25
TCP
UDP−1
UDP−2
UDP−3
Vazão (Mbits/s)
20
15
10
5
0
0
50
100
150
200 250
Tempo (s)
300
350
400
Figura 1. TCP × UDP. Após 50 s do inı́cio do experimento, o fluxo UDP ocupa
toda a largura de banda disponı́vel na rede.
dor de retransmissão (RTO); e (ii) pela recepção de três pacotes contendo a confirmação
de recepção do último pacote recebido corretamente. Esta estratégia acarreta em atrasos
indesejáveis quando se trata de transmissão de dados multimı́dia em tempo real.
Em condições de congestionamento na rede, o atraso fim a fim aumenta e conseqüentemente degrada a qualidade do conteúdo multimı́dia sendo transmitido. Esta
situação é agravada com a retransmissão de pacotes perdidos e que podem não fazer mais
sentido à aplicação receptora devido ao comportamento transiente dos fluxos multimı́dias.
Neste caso, se os pacotes de dados retransmitidos não alcançarem o receptor até um determinado instante, estes serão descartados. A conseqüência disso é o desperdı́cio no uso
dos recursos da rede, pois buffers dos roteadores são alocados para processar e repassar
pacotes que, nestes casos, terminam sendo inúteis às aplicações.
O comportamento do TCP para situações como a mencionada anteriormente pode
ser observado no gráfico ilustrado na Figura 2. No experimento realizado, transmitiu-se
um áudio com duração de 100 s, armazenado no destino e em seguida comparado com
o original. Neste caso, constatou-se que apenas 30 % do áudio alcançou o destino, fato
ocorrido devido ao excesso de retransmissões de pacotes que foram perdidos na rede
quando considerado fluxos TCP disputando com fluxos UDP.
2.1. O Protocolo DCCP
Com apenas essas duas opções para transporte de dados na Internet e objetivando promover melhorias nos serviços oferecidos pelas aplicações multimı́dia, a IETF aprovou
a especificação do protocolo DCCP para transporte de dados multimı́dia para Internet.
Trata-se de um protocolo de rede localizado na camada de transporte da pilha TCP/IP, tal
como o TCP e o UDP. É um protocolo orientado à conexão, não garante entrega e nem
ordenação dos dados transmitidos. Todavia implementa controle de congestionamento
para transmissão não-confiável de fluxo de dados [de Sales et al. 2008b].
Sendo assim, o DCCP herda do TCP as caracterı́sticas de ser orientado à conexão e
fornecer controle de congestionamento. Do UDP, o DCCP herda as caracterı́sticas de não
garantir entrega e nem ordenação dos dados transmitidos. Além destas caracterı́sticas, o
DCCP também adiciona dois conceitos novos: a escolha tardia de dados e um arcabouço
para gerenciamento dos algoritmos de controle de congestionamento de forma modular.
A escolha tardia de dados permite a mudança de dados de um pacote mesmo depois
que o mesmo já tenha sido enviado para a camada de transporte e ainda não tenha sido
135
TCP−Reno x UDP
Original
Audio TCP
−8
RMS (dB)
−10
−12
−14
−16
−18
−20
0
20
40
60
80
100
Tempo (s)
Figura 2. TCP Reno × UDP, sendo o TCP enviando um arquivo de áudio.
enviado através da rede. Já o arcabouço de gerenciamento de algoritmos de controle de
congestionamento permite adicionar novos algoritmos de controle de congestionamento
à aplicação e utilizá-los mesmo que uma conexão DCCP já tenha sido estabelecida.
Para entender as melhorias providas pelo protocolo DCCP, considere o gráfico
vazão × tempo apresentado na Figura 3. Neste gráfico, ilustra-se os comportamentos
dos protocolos TCP e DCCP quando utilizados para transmissão de um arquivo e de um
conteúdo multimı́dia, respectivamente. A partir do gráfico, é possı́vel constatar que os
protocolos TCP e DCCP compartilham entre si a largura de banda disponı́vel, onde cada
fluxo consegue transmitir dados na rede. Note que o comportamento do protocolo TCP
para os 50 s iniciais foi similar ao confronto TCP × UDP (Figura 1). Porém, diferentemente do que ocorreu naquele caso, após os primeiros 50 s dos confrontos TCP × DCCP,
a vazão do protocolo TCP continuou sendo satisfatória.
2.1.1. Arcabouço Modularizado de Algoritmos de Controle de Congestionamento
O DCCP oferece três algoritmos de controle de congestionamento, chamados CCIDs
(Congestion Control IDentifiers). Os CCIDs são os componentes responsáveis por oferecer o controle de congestionamento em conexões DCCP. No Linux, os CCIDs são
módulos do kernel que funcionam sobre o núcleo da implementação do DCCP. Como tal,
podem ser carregados e descarregados a qualquer momento, e as aplicações podem selecionar um CCID adequado para um determinado padrão de fluxo multimı́dia. Por exemplo, aplicações VoIP são caracterizadas pela transmissão de rajadas de pequenos pacotes
seguidas de perı́odos de silêncio, enquanto aplicações de vı́deo sob demanda geralmente
transmitem conteúdo multimı́dia a taxas constantes. Nesse caso, para uma aplicação VoIP
é melhor usar uma técnica de controle de congestionamento criada para VoIP. Esta idéia
não se aplica em protocolos como o TCP e o UDP.
Os CCIDs padronizados são:
CCID-2 [Kohler et al. 2006a], CCID3 [Kohler and Handley 2006] e o CCID-4 [Kohler et al. 2007]. O CCID-2 (RFC
136
Anais
25
TCP
DCCP−1
DCCP−2
DCCP−3
Vazão (Mbits/s)
20
15
10
5
0
0
50
100
150
200 250
Tempo (s)
300
350
400
Figura 3. TCP × DCCP. Ambos os protocolos conseguem transmitir dados na
rede.
4341) é melhor para aplicações que usam toda a banda de rede disponı́vel e se adaptam a
alterações súbitas de banda. Assemelha-se ao controle de congestionamento do TCP, que
se baseia no conceito de janela de congestionamento. O tamanho dessa janela determina
quantos pacotes o remetente tem permissão para enviar pela rede. Isso significa que
quanto maior for a janela de congestionamento, mais pacotes o DCCP está autorizado a
enviar dados pela rede.
Quando o CCID-2 detecta que um pacote foi perdido, ele diminui pela metade a
janela de congestionamento. Tal ação caracteriza uma mudança abrupta na taxa de transmissão, principalmente para aplicações multimı́dia. No estado inicial de transmissão, a
janela de congestionamento aumenta de forma exponencial conforme os pacotes enviados são confirmados, até alcançar a fase de contenção do congestionamento. Na fase de
contenção, a taxa de transmissão aumenta linearmente até que aconteça o primeiro evento
de perda de pacote.
O CCID-3 (RFC 4342) implementa um algoritmo de controle de congestionamento baseado no receptor, que controla a taxa do remetente. Periodicamente, o receptor
envia ao remetente pacotes de informação relatando eventos de perda e outras estatı́sticas
de conexão que são inseridas na equação do TFRC (TCP-Friendly Rate Control) (RFC
3448). O resultado desta equação corresponde à taxa de transmissão que o DCCP deverá
utilizar para os próximos envios de pacotes.
Por último, a IETF recentemente publicou a RFC do CCID-4 (RFC 5622), própria
para aplicações que enviam rajadas de pacotes pequenos intercalados por intervalos de
silêncio. A escrita da especificação do CCID-4 também foi uma contribuição no contexto
deste projeto, sendo as principais: melhoria do texto e implementação da especificação
no kernel do Linux.
Para transmissões de dados multimı́dia em redes de computadores, onde satisfazer
os requisitos de tempo pode definir o nı́vel de qualidade da transmissão multimı́dia, o
DCCP pode melhorar a qualidade do fluxo multimı́dia e ainda resolver diversos problemas
de congestionamento da rede, como os causados por retransmissões desnecessárias de
pacotes feitas pelo protocolo TCP ou por problemas de excessiva perda de pacotes quando
se utiliza o protocolo UDP.
Sendo assim, a motivação do DCCP está relacionada com as caracterı́sticas
intrı́nsecas das aplicações com restrição de tempo de resposta e no fato de que grande parte
137
desse tipo de aplicação utiliza o UDP. Considerando os problemas e limitações dos protocolos TCP e UDP discutidos até aqui, o DCCP surgiu como uma das possı́veis soluções
para o seguinte problema-chave: de um lado apresenta-se o protocolo UDP, adotado por
diversas aplicações com restrição de tempo e que não realizam controle de congestionamento. Por outro lado apresenta-se o protocolo TCP, cujas aplicações podem se tornar
inutilizáveis devido ao congestionamento causado pelo UDP, além de realizarem retransmissões para garantir a entrega de dados.
Neste trabalho, apresenta-se o protocolo DCCP como uma opção efetiva a ser
adotada para transmissão de dados multimı́dia, principalmente por ter um comportamento similar ao protocolo TCP e por ser um protocolo padronizado. Acredita-se que
sua utilização trará diversas vantagens, pois melhora o uso dos recursos da rede, como é
apontado nos gráficos apresentados. Todavia, ainda possui falhas crı́ticas e que precisam
ser corrigidas quando utilizados em larga escala.
3. O Problema do DCCP em Transmissões de Dados Multimı́dia em Tempo
Real
Como foi possı́vel observar, com o DCCP, obtém-se resultados animadores no ponto de
vista de transmissão de dados multimı́dia e melhor utilização dos recursos de rede, resolvendo a maior parte dos problemas aparentes do TCP e do UDP nesse contexto. O problema se apresenta quando o protocolo DCCP é utilizado para distribuição de conteúdo
multimı́dia sendo transmitido a partir de um nó da rede para vários nós localizados em
redes distintas (1 → N).
Não é possı́vel utilizar facilmente o protocolo DCCP para realizar esse tipo de
transmissão, pois o DCCP é um protocolo orientado à conexão e portanto para cada novo
usuário interessado em receber um fluxo multimı́dia transmitido com DCCP, uma nova
conexão se faz necessária. As conseqüências desta limitação do DCCP são desastrosas,
tornando-o um protocolo paradoxal para o que ele se propõe: resolver os problemas de
congestionamento de rede gerados pelo protocolo UDP em cenários de aplicações multimı́dia. Entretanto, quando o protocolo é utilizado em larga escala, simplesmente não é
efetivo. Este fato pode ser explicado pelos seguintes motivos:
1. Excessivo consumo de recurso computacional: para cada nova conexão, o nó
transmissor deve alocar recursos computacionais (memória e processamento) para
poder tratar cada nova conexão. Em cenários como os considerados nesta pesquisa, se muitos nós estão conectados em um único servidor, então isto elevará
sobremaneira o consumo de recurso computacional do nó transmissor proporcionalmente a quantidade de nós receptores interessados pelo fluxo multimı́dia transmitido por um único nó na rede. Além disso, embora o conteúdo transmitido por
um nó seja de interesse de muitos outros nós, os fluxos são enviados independentemente uns dos outros, o que gera duplicações desnecessárias e conseqüentemente
desperdı́cio de recursos de rede;
2. A taxa de transmissão individualmente tenderá a 0: O protocolo DCCP realiza
controle de congestionamento utilizando uma equação matemática para definir a
taxa de transmissão de uma conexão. À medida que mais nós se conectam a um nó
transmissor, menor será a taxa de transmissão do nó transmissor para cada um dos
nós receptores conectados a ele. Para a rede, esta estratégia é justa e evita que a
mesma entre em colapso de congestionamento, mas para cada fluxo de dados isto é
ruim. Este fenômeno é vastamente descrito na literatura e denominado de tragédia
dos comuns [Hardin 1968]. A tragédia dos comuns ocorre neste caso porque se
a taxa de transmissão de um determinado fluxo for muito pequena, pode ser que
ela não seja suficiente para a recepção de um conteúdo multimı́dia em tempo real,
que geralmente exige uma taxa de transmissão mı́nima para que a transmissão
ocorra efetivamente. Estatisticamente, a taxa de transmissão de cada fluxo DCCP
convergirá para um ponto de equilı́brio. Todavia, este ponto será mı́nimo, não
138
Anais
suficiente em aplicações consideradas neste trabalho, muito embora todos terão
direitos iguais sobre o uso do canal. Este problema pode ser descrito matematicamente utilizando como base a Equação 1, que define cada taxa de transmissão
Xi calculada pelo DCCP CCID-3. Nesta equação, Xi é a taxa de transmissão em
bytes/segundo, s é o tamanho do pacote em bytes, R é o RTT em segundos, p é
a taxa de ocorrência de perdas, entre 0 e 1, RTO é o valor do timeout de retransmissão do TCP em segundos e b é igual a 1 e representa o número máximo de
pacotes confirmados por um único ACK. Considere-se o problema descrito anteriormente e que oP
uso total do canal para uma quantidade N de fluxos DCCP é
definido por B = N
i=1 Xi . Em condições severas de congestionamentos na rede,
o valor de B é equivalente à largura de banda do canal de transmissão. Quando
isto ocorre, tem-se que N atingiu um valor maior do que a rede suporta, fazendo
com que os valores de p e R na Equação 1 também aumentem, e portanto tem-se
B
= 0.
que lim
N →∞ N
s
q
q
Xi =
(1)
p
R × 2 × b × 3 + (RT O × 3 3 × b × p8 × p × (1 + 32 × p2 )
Neste contexto, foram realizadas pesquisas em busca de evidências mais contundentes de que este fato ocorre na prática. Por limitações de recursos computacionais
para a realização de experimentos acerca do problema descrito, realizou-se simulações
utilizando o NS-2 a fim de explorar os cenários estudados aqui. Foram executados 10
cenários de simulações de rede cuja topologia foi definida como uma árvore binária, onde
cada ramo da árvore representava um roteador e cada roteador tinha 10 nós DCCP conectados a ele. Cada um dos 10 cenários foram repetidos n vezes até ser alcançado uma
média com nı́vel de confiança de 95%. Em cada cenário, aumentava-se o nı́vel da árvore
binária que definia a topologia da rede em 1. Por exemplo, o primeiro cenário tinha 10 nós
receptores e 1 roteador, no cenário seguinte 30 nós e três roteadores, no seguinte 70 nós
e 7 roteadores e assim por diante. O resultado das simulações estão resumidos no gráfico
ilustrado na Figura 4. O eixo X do gráfico representa o número de nós receptores à medida
que as simulações eram executadas, ao passo que o eixo Y é a taxa de transmissão média
conseguida por cada conexão DCCP. A transmissão ocorreu da seguinte forma: um nó
localizado na raiz árvore transmitiu o mesmo conteúdo multimı́dia para todos os outros
nós conectados à rede, simulando uma tı́pica transmissão multimı́dia 1 → N e um tráfego
de comportamento equivalente a VoIP.
É possı́vel observar no gráfico da Figura 4 que a vazão média de cada fluxo DCCP
transmitido aos receptores tende a zero à medida que o número de receptores aumenta,
sendo possı́vel concluir que o protocolo DCCP não escala quando utilizado para transmissão de dados multimı́dia em cenários de aplicações com um transmissor transmitindo
para vários receptores (1 → N).
Uma questão intrigante neste aspecto é que o protocolo DCCP funciona perfeitamente em cenários simplórios, mas sofre claramente de um problema de escalabilidade,
o que é crı́tico para aplicações consideradas neste trabalho. Isto torna o protocolo DCCP
inútil para cenários de distribuição de conteúdo multimı́dia, fazendo com que os desenvolvedores continuem sem motivações para efetivamente utilizar o protocolo DCCP em
suas aplicações.
Sendo assim, o protocolo DCCP apresenta-se como uma alternativa ao UDP em
cenários simplórios de transmissão multimı́dia, mas em situações de cenários reais de
aplicações multimı́dia como costuma-se encontrar na Internet, o protocolo DCCP, pelo
menos da forma que atualmente é empregado, não apresenta qualquer possibilidade de ser
utilizado em cenários de aplicações multimı́dia mais complexos. Obviamente, é possı́vel
observar através do gráfico apresentado que quanto mais nós receptores forem adicionados na rede, mais acentuada será a perda de dados, causando a diminuição da vazão
139
Number of Nodes vs. Throughput
25
25
DCCP
Tree level 1 (< 1% of loss per flow)
Throughput (Mbps)
20
20
15
15
Tree level 2 (~ 15% of loss per flow)
10
10
5
5
Tree level 5..10 (> 87% of loss per flow)
0
10
30
70
150
310
630
1270
2550
5110
0
10230
Number of Nodes
Figura 4. Gráfico de uma transmissão DCCP com um transmissor enviando dados de áudio VoIP utilizando o protocolo DCCP para X receptores. A vazão média
de cada fluxo tende a zero à medida que o número de receptores aumenta.
média alcançada por cada fluxo DCCP. Note que apenas fluxos DCCP foram transmitidos
nesta simulação, os quais já foram necessários para causar o problema apresentado. Em
situações mais realistas, o problema se torna ainda mais grave, pois o protocolo DCCP
disputará o canal não apenas com outros fluxos DCCP, mas também com fluxos TCP e
ainda com fluxos UDP.
Sendo assim, para cenários como este, os desenvolvedores de aplicações multimı́dia não tem outra opção a não ser continuar utilizando o protocolo UDP, porém ao
custo do que já foi discutido na seção anterior; além disso, TCP não é aplicável neste
cenário por diversas questões também já discutidas. Quanto aos desenvolvedores de
aplicações multimı́dia em tempo real que decidem utilizar UDP e que desejam implementar um mecanismo de controle de congestionamento, estes atualmente se deparam
com dois problemas:
1. Desenvolvimento de pelo menos um algoritmo de controle de congestionamento
na camada de aplicação, o que aumenta na complexidade da aplicação;
2. Falta de padronização, cada desenvolvedor implementará seu algoritmo da forma
que desejar.
Diante deste problema, utilizar UDP não parece ser a solução apropriada, porém é
a que se utiliza atualmente. Uma abordagem neste sentido e vastamente considerada pelos pesquisadores para atender aos requisitos das aplicações consideradas neste trabalho
é utilizar um modo de transmissão multicast. Nestes casos, todos os usuários passam a
receber o mesmo conteúdo do fluxo de dados sendo transmitido ao custo de ser necessário
apenas uma única transmissão de dados por parte do nó transmissor. Porém, a complexidade aumenta, no ponto de vista do desenvolvimento da aplicação, quando se implementa
mecanismos de controle de congestionamento na camada de aplicação, além de quebrar a
filosofia dos protocolos em camadas considerada pelo modelo de serviços TCP/IP. Neste
caso, cada camada deve oferecer serviços para sua camada superior e, conseqüentemente,
140
Anais
usufruir de serviços da camada inferior. Sendo assim, o serviço de controle de congestionamento deve ser implementado na camada de transporte e não na camada de aplicação.
Portanto, embora o DCCP seja um protocolo promissor para transporte de fluxos multimı́dia, os desenvolvedores não têm motivos para passarem a utilizá-lo devido a
falta de qualquer função deste protocolo que permita o desenvolvimento de uma solução
sub-ótima para distribuição de conteúdos multimı́dia em tempo real não proporcional a
transmissão de um novo fluxo para cada novo nó interessado em recebê-lo.
4. O Multi(Uni)cast DCCP
O Multi(Uni)cast Datagram Congestion Control Protocol (MU-DCCP) é uma extensão
do protocolo DCCP para transmissão de fluxos de dados multimı́dia em cenários de um
nó transmissor com muitos nós receptores. O MU-DCCP permite a transmissão de pacotes de dados com suporte ao controle de congestionamento de fluxos não confiáveis. O
MU-DCCP pode operar em dois modos de transmissão: (i) multicast; e (ii) multi-unicast.
Para cada um dos modos de transmissão providos pelo MU-DCCP, a aplicação primeiramente seleciona o modo desejado e um algoritmo especı́fico é utilizado para realizar
o estabelecimento de conexão e transmissão de dados entre os receptores envolvidos. O
modo multicast é utilizado geralmente em redes locais, e o modo unicast é utilizado para
que um nó, localizado na rede local, estabeleça uma conexão com um nó transmissor e
distribua o conteúdo na sua rede local.
4.1. Visão Geral do MU-DCCP
Quando uma aplicação inicia um socket DCCP correspondente a conexão desejada, a
mesma envia um pacote do tipo DCCP-MREQUEST com o campo TTL da camada de
rede igual a 1. Este pacote é enviado em modo multicast para o endereço 239.255.255.251
e a porta 1900 (este socket é chamado de canal de controle do MU-DCCP). No cabeçalho
do pacote DCCP-MREQUEST existem dois campos, um para especificar o endereço IP
(32bits) do nó transmissor e o outro para especificar a porta (16bits) do nó transmissor,
do qual o nó receptor deseja receber o conteúdo multimı́dia. Como o pacote é transmitido
na rede local com TTL=1, isto significa que o pacote não será roteado para a rede externa
e apenas o nós da sua rede local o receberá. Para facilitar a explicação, considere-se o
endereço 200.200.211.5 e porta 8900 como sendo o socket do nó transmissor o qual o nó
receptor tem interesse de se conectar. Neste caso, o nó receptor envia uma mensagem
multicast do pacote DCCP-MREQUEST para o endereço multicast especificado anteriormente e com os campos IP e porta do pacote DCCP-MREQUEST preenchidos com os
dados do socket do nó transmissor.
Por outro lado, todos os outros nós DCCP existentes na rede local devem,
ao implementarem a extensão MU-DCCP, iniciar um socket multicast no endereço
IP 239.255.255.251 e na porta 1900. Isto permitirá a recepção de pacotes DCCPMREQUEST transmitidos por qualquer nó na rede. Sendo assim, caso um nó na rede
local já esteja recebendo um fluxo multimı́dia DCCP vindo de 200.200.211.5 na porta
8900, quando receber um DCCP-MREQUEST responderá para o nó interessado um pacote do tipo DCCP-MRESPONSE, o que deve ocorrer em modo unicast. Ao responder
com o DCCP-MRESPONSE, o nó receptor do fluxo original, passa a funcionar como um
nó relay (DCCP Relay), retransmitindo na rede local os pacotes que estão recebendo do
nó transmissor. No cabeçalho do DCCP-MRESPONSE, o nó especificará em qual modo
ele repassará os pacotes para a rede local, se no modo multicast ou no modo unicast.
Note que, caso não exista nenhum nó do tipo DCCP Relay na rede local, o nó interessado em receber o fluxo pode enviar um pacote do tipo DCCP-MREQUEST, porém
com TTL=2. Caso o roteador da rede local esteja roteando pacotes multicast no endereço
IP e porta do canal de controle do MU-DCCP, é possı́vel que um DCCP Relay responda
com um pacote do tipo DCCP-MRESPONSE da forma que foi explicado anteriormente.
141
Caso o nó que enviar o DCCP-MREQUEST não receba nenhum pacote do tipo DCCPMRESPONSE, o mesmo poderá tomar duas decisões, configurável via parâmetro de
configuração da aplicação (setado via setsockopt(), por exemplo): (1) Enviar outro pacote
do tipo DCCP-MREQUEST com o valor de TTL incrementado em 1; ou (2) iniciar uma
conexão unicast com o nó transmissor. Caso ocorra a segunda opção, o nó MU-DCCP
que iniciar uma conexão unicast com um nó transmissor qualquer deve se auto eleger para
ser um DCCP Relay em pedidos de conexão através do pacote DCCP-MREQUEST que
este venha a receber via o canal de controle do MU-DCCP.
4.2. Modos de Transmissão do MU-DCCP
A mensagem de resposta de conexão enviada por um nó MU-DCCP, contém três campos:
(i) o campo multicast (1 bit), se ativado o nó transmitirá os dados em modo multicast; (ii)
o campo endereço IP, que especificará qual endereço IP (32 bits) o DCCP Relay passará a
transmitir os dados; e (iii) o campo porta (16 bits), que especificará a porta que o DCCP
Relay passará a transmitir os dados.
Note que um DCCP Relay pode decidir alterar o modo de sua transmissão a qualquer momento, bastando para isso enviar um pacote do tipo DCCP-MSYNC, via multicast, para o canal de controle do MU-DCCP, contendo a modificação desejada. Ao
receber um DCCP-MSYNC, os nós envolvidos na recepção dos dados devem realizar as
devidas modificações em seu modo de recepção. O formato do DCCP-MSYNC é igual
ao formato do pacote DCCP-MRESPONSE.
4.3. Controle de congestionamento com DCCP em modo multicast
O MU-DCCP suporta transmissão de dados tanto unicast quanto em modo multicast. Algoritmos de controle de congestionamento em modo multicast são mais complexos porque geralmente estes utilizam o feedback dos receptores para tomar decisões na definição
da sua taxa de transmissão. Neste caso, nenhum CCID existente para DCCP foi projetado
para funcionar neste modo, sendo necessário trabalhar em um novo CCID capaz de tratar
todas as caracterı́sticas de transmissão de dados de fluxo não confiável em modo multicast. No contexto deste trabalho, definiu-se o CCID-5, um algoritmo para controle de
congestionamento de fluxos de dados não confiável em transmissões multicast utilizando
o protocolo DCCP.
O foco principalmente de funcionamento do CCID-5 é fazê-lo capaz de ser executado em um DCCP Relay que esteja transmitindo em modo multicast. O CCID-5 determina uma nova taxa de transmissão baseado em relatórios enviados pelos nós receptores
da sua rede local. Note que, como estão sendo tratados fluxos de dados não confiáveis,
a solução para o CCID-5 pode fazer uso deste tipo de transmissão para reduzir a necessidade de confirmação de todos os pacotes recebidos pelos nós receptores. Como estão
sendo considerados cenários onde existem apenas um nó transmissor dos dados e diversos nós receptores, receber confirmação de recepção de todos os nós receptores poderia
inundar o nó transmissor de pacotes de controle, com confirmação de recepção de pacotes
de dados por parte dos receptores.
Assim, foi possı́vel desenvolver o CCID-5 como um algoritmo de controle de congestionamento que não precisa necessariamente receber um relatório de recepção de todos
os nós receptores, mas sim de um sub-grupo de nós receptores, reduzindo de tal forma a
quantidade de dados de controle transmitidos na rede em direção ao nó transmissor dos
dados. É importante salientar que nem sempre o nó transmissor dos dados será aquele
que gera o conteúdo, mas sim um nó transmissor que poderá executar o CCID-5 pode
ser um nó do tipo DCCP Relay. Dado isto, desenvolveu-se um algoritmo para permitir
a eleição de nós DCCP Relays e nós DCCP Reporters, responsáveis por relatar a um nó
transmissor qualquer sua taxa de recepção de dados via multicast. Ao receber relatórios
enviados pelos DCCP Reporters, os nós DCCP Relays ajustarão sua taxa de transmissão
de acordo com estes relatórios, o que pode ser feito utilizando uma equação de cálculo de
taxa de transmissão, como por exemplo a própria Equação 1.
142
Anais
4.4. Eleição de Nós DCCP Relays e de DCCP Reporters
Os nós DCCP Relays são selecionados de duas formas: (i) serão DCCP Relays aqueles
que iniciarem a primeira conexão unicast com um nó DCCP gerador dos dados, ou seja,
o nó transmissor original; (ii) serão DCCP Relays aqueles que negociarem com algum
outro nó DCCP Relay sua promoção para nó DCCP Relay. Note-se que este caso o nó
que conceder a promoção de um nó DCCP Relay para outro deverá se rebaixar para um nó
MU-DCCP normal. Além disso, quando um DCCP Relay conceder este status, o mesmo
poderá se desconectar do nó DCCP gerador dos dados enviando um DCCP-MRESET,
que conterá o endereço do novo nó DCCP Relay. É possı́vel também que um nó DCCP
Relay eleja outros nós DCCP Relays secundários, localizados na sua própria rede local.
Esta funcionalidade é importante porque caso o atual DCCP Relay perca sua conexão
ou desconecte do nó transmissor gerador dos dados, qualquer DCCP Relay secundário
poderá assumir o papel de DCCP Relay primário. Neste caso, o nó que passar a assumir
este papel deverá enviar um pacote do tipo DCCP-MELECT informando que assumirá a
transmissão de dados outrora provida pelo nó DCCP Relay antigo.
Com relação aos nós DCCP Reporters, o processo de eleição funciona de forma
similar, porém qualquer nó pode se tornar um DCCP Reporter. O processo funciona da seguinte forma: à medida que um DCCP Relay receber pacotes do tipo DCCP-MREQUEST,
no pacote DCCP-MRESPONSE o nó DCCP Relay pode ativar a flag desse pacote informando que aquele nó deverá enviar relatórios de confirmação de pacotes. Desta forma, o
DCCP Relay poderá limitar a quantidade de DCCP Reporters e assim receber relatórios
apenas de um sub-conjunto de nós da rede. Como a transmissão é multicast e local, é
possı́vel ter poucos nós DCCP Reporters e continuar sendo efetivo no ponto de vista de
determinar a melhor taxa de transmissão. No contexto deste trabalho, não realizou-se muitos experimentos na tentativa de se é possı́vel determinar qual é a quantidade necessária
de DCCP Reporters para se obter taxas de transmissões justas.
4.5. Adaptação de Fluxo Multimı́dia
Uma funcionalidade peculiar do MU-DCCP é a capacidade que ele tem de fazer adaptação
de fluxos multimı́dia de forma distribuı́da. A maioria das soluções para transmissão de dados multimı́dia, além de realizarem controle de congestionamento no nı́vel de aplicação,
realizam adaptação de fluxo multimı́dia na fonte geradora dos dados. Uma solução para
adaptação de fluxo multimı́dia é transmitir os dados em diferentes canais, sendo que em
cada canal transmite-se fluxos multimı́dia com uma determinada qualidade. Dependendo
da qualidade desejada pelo nó receptor, ele solicita a transmissão em um determinado canal. O problema dessa abordagem é que o nó transmissor, necessariamente deve transmitir
os dados em múltiplos canais, o que aumenta a complexidade da aplicação e a quantidade
de fluxos de dados sendo transmitidos a partir do servidor. No MU-DCCP, é possı́vel realizar a adaptação de fluxo de dados de forma distribuı́da, na prática, em cada DCCP Relay.
Suponhe-se que existem duas redes adjacentes, rede 1 e rede 2. Considere que existe um
nó DCCP Relay na rede 1 e entre esta e o nó transmissor a largura de banda disponı́vel é
de 100 Mbps. Caso a largura de banda disponı́vel na rede 2 seja de no máximo 10 Mbps,
um nó receptor na rede 2 teria que solicitar um fluxo multimı́dia em um canal diferente,
considerando a solução supracitada. No caso do MU-DCCP é possı́vel que um nó na
rede 2 obtenha o fluxo multimı́dia através do DCCP Relay presente na rede 1, bastante,
neste caso, que o DCCP Relay presente na rede 1 adapte o fluxo para o nó que esteja na
rede 2. Desta forma, pode-se diminuir o tráfego na rede do nó transmissor e ainda sim
permitir que nós em redes com baixa largura de banda consigam obter o fluxo multimı́dia
adaptado.
5. Resultados e Discussões
Nesta seção são apresentados os resultados e discussões sobre um conjunto de simulações
realizadas no contexto desta pesquisa utilizando o MU-DCCP. Nas simulações realizadas,
143
utilizou-se uma topologia de rede ilustrada na Figura 5 e a metodologia de execução das
simulações igual a que foi descrita na Seção 3. A topologia da rede simulada segue a
estrutura de uma árvore binária, onde as folhas de cada nó pai representam outras redes e
assim sucessivamente. Os parâmetros de configuração de toda a rede foram definidos da
seguinte forma:
Legend:
Sender
100M
Receivers
bps
Tree Level 1
1ms
25
m
s
Routers
30
0M
bp
s
Tree Level 2
Tree Level 3
...
...
...
...
...
...
...
...
Tree Level n
Figura 5. Topologia da rede definida para as simulações realizadas. Cada rede é
representada por um roteador e com 10 nós em cada rede.
•
•
•
•
•
•
•
Número de computadores receptores por rede: 10
Largura de banda da rede local: 100Mbps
Latência da rede local: 1ms
Largura de banda do backbone: 300Mbps
Latência do backbone: 25ms
Tamanho da fila dos roteadores do backbone: 3000 pacotes
Duração da simulação: 900s
5.1. Discussões sobre os resultados
No gráfico ilustrado na Figura 6, apresenta-se o resultado das transmissões simuladas
utilizando o NS-2 e o protocolo DCCP com a extensão MU-DCCP habilitada. Transmitiuse o mesmo padrão de tráfego VoIP utilizado na Seção 3. É possı́vel observar claramente
que, quando se compara o gráfico da Figura 4 com o gráfico da Figura 6, o uso do MUDCCP melhorou sobremaneira a taxa efetiva de recepção de dados por parte dos nós
receptores.
Como está sendo considerada a taxa efetiva de recepção, constatou-se uma
redução de mais de 90 % da taxa média de perda de pacotes por cada nó receptor, além de
permitir uma distribuição adequada de fluxos de dados multimı́dia. É possı́vel observar
também que, mesmo aumentando a quantidade de usuários receptores, por exemplo, entre
N=150 e N=2550, a taxa média de recepção continuou sendo satisfatória, sendo crescente
à medida que o valor de N aumentou. Isso pode ser justificado pelo fato de que quanto
mais nós DCCP na rede, aumentam-se as chances de se tornarem nós DCCP Relays, o
que conseqüentemente aumentam as chances de existirem mais nós receptores recebendo
fluxos de dados via multicast e não somente via unicast.
6. Considerações Finais e Trabalhos Futuros
Neste artigo, apresentou-se os resultados da pesquisa sobre o MU-DCCP, uma versão
modificada do protocolo DCCP com suporte a transmissão de dados multimı́dia em modo
144
Anais
Throughput (Mbps)
Number of Nodes vs. Throughput
25
25
20
20
DCCP
MU-DCCP
15
15
10
10
5
5
0
10
30
70
150
310
630
1270
2550
5110
0
10230
Number of Nodes
Figura 6. Gráfico de uma transmissão DCCP com um transmissor enviando dados de áudio VoIP utilizando o protocolo DCCP e a extensão MU-DCCP para X
receptores.
multicast quando possı́vel ou multi-unicast quando multicast não for possı́vel. Após os
estudos realizados durante o desenvolvimento deste trabalho, algumas conclusões puderam ser obtidas acerca do uso do protocolo DCCP em transmissão de dados em cenários
1 → N: (i) o protocolo DCCP não se apresenta de forma satisfatória quando utilizado
em cenários de aplicações em larga escala, por exemplo, em aplicações de distribuição
de conteúdo multimı́dia partindo de um nó transmissor para diversos nós receptores; (ii)
Fez-se necessárias soluções a fim de resolver este problema do protocolo DCCP e o MUDCCP foi a resposta para isto. Após a definição e implementação do MU-DCCP, diversas simulações foram realizadas com o MU-DCCP, sendo os principais resultados e
discussões apresentados neste artigo. No contexto do MU-DCCP também foi desenvolvido o CCID-5, um algoritmo de controle de congestionamento para transmissão de dados
multimı́dia com suporte a multicast. De acordo com os resultados obtidos, observou-se
uma melhoria significativa do uso do MU-DCCP em cenários de aplicações multimı́dia
em tempo real.
Com estes resultados obtidos, o atual trabalho está sendo a escrita de um Internet
Draft para posterior submissão como RFC promovida pela IETF. Como os resultados tem
sido bastante animadores, espera-se que o MU-DCCP venha a ser adotado pelas principais aplicações multimı́dia no futuro. A proposta do MU-DCCP é importante porque ela
abstrai toda a complexidade de transmissão de dados multimı́dia com suporte a controle
de congestionamento e com suporte ao modo multicast, caracterı́stica ausente na versão
original do protocolo DCCP.
Como trabalhos futuros, pretende-se evoluir o MU-DCCP no sentido de melhorar o algoritmo de eleição de DCCP Relays e de DCCP Reporters. A melhoria desses
algoritmos esta vinculada a execução de mais simulações em cenários diferentes do que
o estudado e apresentado neste trabalho. Além disso, pretende-se executar simulações do
MU-DCCP em transmissões de dados com outros padrões de tráfego, tais como vı́deo e
jogos e realizar um estudo mais aprofundado a respeito do atraso gerado à medida que os
145
nós receptores estão mais distantes do nó transmissor. Pretende-se ainda implementar o
MU-DCCP no kernel do Linux e executar experimentos a fim de estudar o comportamento
do MU-DCCP em cenários reais de rede.
Referências
Amazon (2011). Introducing Amazon Cloud Player for Web & Android. Online
publication in Amazon.com. http://www.amazon.com/b?ie=UTF8&node=
2658409011.
de Sales, L. M., Almeida, H. O., Perkusich, A., and Jr., M. S. (2008a). An Experimental
Evaluation of DCCP Transport Protocol: A Focus on the Fairness and Hand-off over
802.11g Networks. In In Proceedings of the 5th IEEE Consumer Communications and
Networking Conference, pages 1149–1153.
de Sales, L. M., Almeida, H. O., Perkusich, A., and Jr., M. S. (2008b). On the Performance
of TCP, UDP and DCCP over 802.11g Networks. In In Proceedings of the SAC 2008
23rd ACM Symposium on Applied Computing Fortaleza, CE, pages 2074–2080.
Floyd, S., Handley, M., and Kohler, E. (2006). Problem Statement for the datagram
congestion control protocol (DCCP). http://www.ietf.org/rfc/rfc4336.
txt. Ultimo acesso: 12/04/2011.
Freak, T. (2011). Paramount Pictures to Release Film on Bittorrent. Online publication in the Torrent Freak Website.
http://torrentfreak.com/
paramount-pictures-partner-with-bittorrent-release-movie-110317/.
Hardin, G. (1968). The Tragedy of the Commons. Science, 162(3859):1243 – 1248.
Jungmaier, A. (2003). SCTP for Beginners. Computer Network Tecnology Group, 1
edition.
Kohler, E. and Handley, M. (2006). Profile for Datagram Congestion Control Protocol
(DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC). http://
www.ietf.org/rfc/rfc4342.txt. Ultimo acesso: 12/04/2011.
Kohler, E., Handley, M., and Floyd (2006a). Profile for Datagram Congestion Control
Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control. In IETF
Online RFC. http://www.ietf.org/rfc/rfc4341.txt. Ultimo acesso:
12/04/2011.
Kohler, E., Handley, M., and Floyd, S. (2006b). Datagram Congestion Control Protocol (DCCP). http://www.ietf.org/rfc/rfc4340.txt. Ultimo acesso:
12/04/2011.
Kohler, E., Handley, M., and Floyd, S. (2006c). Designing DCCP: Congestion Control
Without Reliability. In SIGCOMM ’06: Proceedings of the 2006 conference on Applications, technologies, architectures, and protocols for computer communications,
pages 27–38, New York, NY, USA. ACM Press.
Kohler, E., Handley, M., and Floyd, S. (2007). Profile for Datagram Congestion Control
Protocol (DCCP) Congestion Control ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP). http://www.ietf.org/rfc/rfc5622.txt. Ultimo acesso:
6 de maio de 2011.
Leavitt, N. (2010). Network-Usage Changes Push Internet Traffic to the Edge. Computer,
43(10):13 –15.
146
Anais
147
Aumentando a Segurança de Um Protocolo de Distribuição de
Conteúdo P2P para MANETs
Sidney Doria, Marco Aurélio Spohn
1
Departamento de Sistemas e Computação
Universidade Federal de Campina Grande – UFCG
Campina Grande – PB
{sidney, maspohn}@dsc.ufcg.edu.br
Abstract. Rogue peers are a concern because they decrease the utility of the
resource-sharing systems, potentially towards to the system collapse. We are
currently deploying Peer-to-MANET, a multicast peer-to-peer approach to distribute contents on mobile ad hoc networks. This work presents our efforts to
improve trust, avoiding rogue and selfish peers in Peer-to-MANET. We employ a
modified version of the Network of Favors as a decentralized reputation system
to punish rogue peers activities. Through simulations in NS-2, we show that our
solution minimizes download success rate by rogue peers, avoiding that maliciously peers cause resource depletion of other peers.
Resumo. Nós desonestos são indesejáveis pois eles diminuem a utilidade dos
sistemas de compartilhamento P2P, possivelmente até seu colapso. Atualmente estamos desenvolvendo o Peer-to-MANET (P2MAN), um protocolo de
distribuição de conteúdo para MANETs. Este trabalho apresenta nossos
esforços para aumentar a segurança do P2MAN, evitando nós desonestos e nós
caroneiros. Empregou-se uma versão modificada da Rede de Favores, como
sistema de reputação descentralizado, para punir atividades desonestas de nós.
Através de simulações no NS-2, demonstramos que a solução proposta reduz a
taxa de sucesso de download dos nós desonestos e evita que pares maliciosos
tentem o esgotamento de recursos de outros pares.
1. Introdução
A Internet é definida como um grupo global de redes de dispositivos computacionais interconectadas (e.g., redes domésticas, redes corporativas). Recentemente os usuários têm
se valido de avanços nas tecnologias computacionais móveis e no aumento dos serviços
móveis, de tal forma que o padrão de uso tem mudado e é possı́vel vislumbrar um futuro
onde a Internet será ubı́qua, através da interconexão de muitos dispositivos computacionais pervasivos. Nessa trilha, os serviços celulares e as redes móveis são consideradas o
futuro das infra-estruturas de rede [Stuckmann and Zimmermann 2009].
Uma rede móvel ad hoc (MANET) consiste em um conjunto de pares que desejam
se conectar sem fio, mas sem se valer de nenhuma estrutura fixa de comunicação. A natureza móvel dos nós implica que eles podem agir como roteadores para outros nós, quando
dois nós comunicantes estiverem a mais de um salto de distância. Defende-se na literatura que aplicativos que estejam sendo executados em uma MANET são essencialmente
entre pares (P2P) por natureza. Provavelmente o problema das redes P2P mais discutido
148
Anais
é a distribuição de conteúdos entre os pares. Trabalhos recentes mostram os esforços
para adaptar protocolos P2P populares, especialmente o BitTorrent [Cohen 2003], para
o compartilhamento de dados em MANETs. Embora o BitTorrent e outros protocolos
sejam conhecidos por eficiência na Internet, ele têm problemas de adaptação conhecidos quando funcionando sobre MANETs. Os protocolos P2P geralmente funcionam na
camada de aplicação, empregando transmissões unicast, sem ciência da mobilidade dos
nós. Por outro lado, MANETs geralmente fazem uso de transmissões por difusão não
confiável, sobre um canal de rádio compartilhado, onde os nós são livres para se movimentar. Tais contrastes têm desafiado as pesquisas para otimização das redes P2P sobre
as MANETs.
Atualmente, estamos desenvolvendo o protocolo Peer-to-MANET (P2MAN) de
distribuição de conteúdo P2P para MANETs. P2MAN é um protocolo nativo, cuja
inovação central está na abordagem multicast em malha de baixa sobrecarga, e por adotar um único grupo multicast para simplificar as operações de controle e reduzir sobrecarga. Além disso, foi projetado em uma abordagem holı́stica, considerando as restrições
tı́picas das MANETs, ao mesmo tempo que tenta se valer das suas peculiaridades (e.g.,
escala e propósito restritos, roteamento multicast em malha). Os primeiros resultados [Doria and Spohn 2009] do P2MAN são animadores, pois indicaram que P2MAN
distribui conteúdos em MANETs de forma escalável e eficiente
Apesar dos potenciais benfı́cios do uso de redes P2P como o P2MAN, os nós
desonestos são uma procupação, visto que eles podem degradar o desempenho do sistema, potencialmente até o colapso. Este trabalho visa aumentar a segurança do P2MAN,
desencorajando as atividades de nós desonestos que tentam reduzir o desempenho do sistema de distribuição de conteúdo da seguinte maneira: (a) enviando pedaços de conteúdos
falsos para outros nós, (b) com comportamento egoı́sta, sendo caroneiros. Propõe-se uma
modificação da Rede de Favores [Andrade et al. 2004] (NoF), que originalmente foi projetada para redes P2P de compartilhamento de CPU em grades computacionais, como
um mecanismo de reputação descentralizado para o P2MAN. Através de simulações no
NS-2 [NS-2 2010], demonstra-se que a solução proposta minimiza as atividades dos nós
maliciosos citados.
O restante deste artigo está organizado como segue. Na Seção 2 confronta-se o
estado da arte com esta abordagem. Na Seção 3 a solução é detalhada. Na Seção 4 é
detalhado o estudo baseado em simulações e os resultados são apresentads. Por fim, a
Seção 5 conclui este trabalho e apresenta trabalhos futuros.
2.1. Distribuição de Conteúdo P2P sobre MANETs
Distribuir conteúdos com eficiência em MANETs é um problema difı́cil. Já foram
empregados diversos protocolos P2P para realizar a distribuição de conteúdos. Trabalhos
anteriores adaptaram algoritmos P2P populares em MANETs [Kortuem et al. 2001,
Klemm et al. 2003, Androutsellis-Theotokis and Spinellis 2004].
Particularmente,
destacam-se os esforços para adaptar o BitTorrent sobre MANETs [Krifa et al. 2009a,
Krifa et al. 2009b, Sbai et al. 2008, Rajagopalan et al. 2006, Sbai and Barakat 2009,
Souza and Nogueira 2008, Quental and Gonçalves 2010]. Um protocolo popular na
Internet como o BitTorrent pode ter uma melhor aceitação dos usuário de MANETs, visto
149
que seu tempo de treinamento seria menor, considerando que há uma maior probabilidade
de que alguns usuários já tenham experiência prévia com o protocolo. Entretanto, muitos
protocolos de distribuição de conteúdo P2P apresentam problemas técnicos de adaptação
quando executando sobre MANETs, como explicado a seguir.
Por exemplo, as redes populares de compartilhamento de conteúdo P2P foram originalmente projetadas para a Internet (i.e., escala global, milhões de nós) e as
MANETs tı́picas têm escala de dezenas de nós. Em atenção à escala, alguns trabalhos [Ding and Bhargava 2004, Y. Charlie Hu and Pucha 2003] adaptaram a Distributed
Hash Table (DHT) e outras tecnologias de localização das redes P2P para as MANETs.
Também, as MANETs têm problemas intrı́secos de infra-estrutura que os sistemas P2P
não têm como preocupação. Por exemplo, o BitTorrent emprega unicast, o que é custoso
para uma MANET devido à sobrecarga gerada por handshakes em camadas inferiores.
Ademais, protocolos P2P como o BitTorrent adotam o TCP como protocolo de
transporte. Os problemas de desempenho do TCP em MANETs já foram demonstrados
exaustivamente na literatura [Holland and Vaidya 1999] (e.g., o TCP interpreta as perdas
de pacotes no enlace sem fio como contenção e reduz a velocidade da transmissão). O uso
do TCP nas transmissões pode portanto degradar o desempenho do sistema de distribuição
de conteúdos. Em atenção a esse problema, Anastasi et al. desenvolveram recentemente o
TPA [Anastasi et al. 2009], um protocolo de transporte confiável mais eficiente do que o
TCP em MANETs, que adota uma abordagem entre camadas. Mesmo considerando tais
avanços recentes com protocolos de transporte para MANETs, ainda haveria a necessidade de adaptar o BitTorrent ou uma variante do protocolo para o TPA.
De fato, para contornar problemas de desempenho, novas pesquisas vêm tentando abordagens entre camadas, que estabelecem comunicação direta entre a camada
de aplicação e as camadas inferiores, ao custo de contrariar o propósito das modelagens
por camadas. Por exemplo, em [Y. Charlie Hu and Pucha 2003] os autores propõem um
protocolo de roteamento que se apóia em uma rede P2P auxiliar sobreposta, de modo que
as descobertas de rotas ficam limitadas a O(logN ). Os autores em [Conti et al. 2004]
criaram uma camada adicional que se comunica com as demais camadas de rede, que
consolida informações sobre o status da rede. Além disso, conjecturam não ser possı́vel
realizar certas operações em MANETs com eficiência (e.g., economia de energia nas
transmissões) com o paradigma de camadas independentes, mas não reuniram provas
para embasar tal afirmação. Em [Kozat et al. 2004] os autores também projetaram uma
camada adicional que coleta informações da rede.
Mais recentemente, outros trabalhos utilizaram abordagens entre camadas,
de redes P2P sobrepostas, para alcançar resultados otimizados para tarefas como
roteamento unicast e multicast e distribuição de conteúdos [Passarella et al. 2006,
Delmastro et al. 2008, Lee et al. 2006, Sbai and Barakat 2009]. Para preservar o modelo
de camadas, optou-se por não utilizar uma abordagem entre camadas no desenvolvimento
do P2MAN.
150
Anais
2.1.1. Peer-to-MANET
Peer-to-MANET (P2MAN) é um protocolo baseado em multicast para distribuição de
conteúdo entre-pares em redes ad hoc móveis. Foi projetado para mitigar as limitações das
MANETs e obter vantagem dos conceitos das redes P2P. P2MAN usa grupos multicast
para entregar conteúdos e um grupo multicast especial, denominado Canal Público, para
todas as operações de controle.
Quando um nó P2MAN inicia, junta-se ao Canal Público (CP) para poder trocar
mensagens de controle. Todos os nós que desejam compartilhar conteúdo devem ser
membros do CP. Não há servidor com informações para localização de conteúdos nem tais
informações são copiadas (i.e., mantidas em cache) pelos nós na rede. Em vez disso, para
localizar um conteúdo, um nó consulta o Canal Público sem a necessidade de inundar
a rede com mensagens de controle. Caso algum nó ativo tenha o conteúdo, este será
alcançado através do CP e uma resposta será retornada também via CP. A resposta também
traz metadados gerados pelo nó proprietário do conteúdo, com informações detalhadas
sobre o conteúdo.
Como em muitas redes P2P, P2MAN fraciona o conteúdo para a entrega. O nó
proprietário decide como o objeto será dividido em pedaços e faz uma representação do
conteúdo através de um mapa de bits (em que cada bit representa um pedaço do conteúdo).
O proprietário também decide que grupo multicast será usado para transmitir o conteúdo.
Os metadados são criados pelo nó proprietário, contendo as informações necessárias para
guiar os nós solicitantes. Após receber a resposta, o nó solicitante junta-se ao grupo
multicast anunciado pela fonte e envia uma mensagem de autorização ao Canal Público.
Ao receber uma mensagem de autorização, o proprietário do conteúdo pode iniciar a
transmissão.
Assumindo-se a adoção de um protocolo de roteamento multicast sem entrega
confiável (e sem um protocolo de transporte multicast), a garantia de entrega é realizada
na camada de aplicação, através de um mecanismo de retransmissão denominado Modo
de Reparação. No modo de reparação, um nó pode solicitar os pedaços que ainda não recebeu. O proprietário então retransmite os pedaços que faltam. Enquanto houver pedaços
faltando, novos pedidos e retransmissões ocorrerão, até que o nó solicitante receba todos
os pedaços. A Tabela 1 resume as escolhas de projeto do P2MAN, confrontando-as com
as abordagens comuns da literatura e mostrando as vantages esperadas.
2.1.2. Protocol for Unified Multicasting through Announcements (PUMA): uma
breve descrição
Há uma preocupação da comunidade cientı́fica a respeito da sobrecarga gerada para se
manter uma malha multicast em uma MANET, especialmente na presença de particionamentos de rede ou alta mobilidade. Esta procupação é a razão principal da escolha do protocolo multicast Protocol for Unified Multicasting through Announcements
(PUMA) [Vaishampayan and Garcia-Luna-Aceves 2004] para este trabalho. PUMA foi
escolhido como protocolo de roteamento para o P2MAN porque demonstrou-se que o
PUMA tem baixa sobrecarga e manutenção rápida da malha, além de superar o desempenho dos protocolos multicast mais representativos.
151
Tabela 1. P2MAN: Escolhas de Projeto.
Literatura
DHT adaptada
ou inundação
Unicast
com
mecanismo de
incentivo
TCP
TCP
P2MAN
Canal Público
Multicast
UDP
Modo de Reparação
Vantagens
Nativo, pouca sobrecarga, bem adaptado à
escala
Nativo, simples, sem necessidade de mecanismo de incentivo, menor sobrecarga de
handshakes
Menos sobrecarga, desempenho máximo
do transporte (menor degradação)
Menos sobrecarga, confiabilidade por
reparação oportunı́stica
PUMA é um protocolo de roteamento multicast baseado em malha, com a montagem da malha orientada aos receptores. Por padrão, o primeiro receptor de um grupo
multicast se torna o lı́der do grupo (i.e., core). Caso múltiplos nós se juntem simultaneamente a um mesmo grupo, o nó com o maior endereço IP será eleito o lı́der do grupo.
O que faz o PUMA simples e muito eficiente é sua baixa sobrecarga de pacotes de controle. Um único pacote de controle, denominado anúncio multicast, é usado para manter
a malha. Além disso, na ocorrência de múltiplos grupos e múltiplas malhas, os pacotes
de controle podem ser agrupados em um único anúncio. PUMA não requer quaisquer
protocolos unicast para funcionar. Todas as transmissões são feitas por difusão. Apesar
de usar difusões não confiáveis, a malha formada pelo PUMA introduz uma redundância
aceitável. No PUMA, a malha inclui apenas membros do grupo multicast e os nós que
interconectam os seus membros. Assim, as difusões ficam limitadas ao escopo da malha.
À medida que anúncios se propagam pela malha, os nós aprendem o caminho mais
curto até o lı́der. Desta forma, pacotes de dados podem ser roteados rapidamente para o
lı́der. No caminho para o lı́der, duas coisas podem acontecer a um pacote de dados: (a)
o pacote percorre a rede até que alcance finalmente o lı́der, ou (b) pode alcançar um nó
membro da malha antes do lı́der. De qualquer forma, quando um pacote chega até um
membro da malha, será difundido apenas dentro da malha. O lı́der não é um ponto único
de falha porque, em caso de falha, ocorre uma rápida eleição através de um algoritmo
distribuı́do muito eficiente.
2.2. Mecanismos de Reputação Entre Pares
Um mecanismo de reputação para sistemas entre pares é uma técnica para guardar o comportamento prévio de pares para ser usado como guia para outros pares da rede. Um
desafio que tais mecanismos têm de enfrentar é reaver as informações coletadas sobre
os nós de forma confiável, visto que nós maliciosos podem adulterar as informações que
armazenam. Em [Aberer and Despotovic 2001], de forma antecipada, os autores apresentam um mecanismo de reputação especificamente projetado para redes P2P. O algoritmo
Eigen [Kamvar et al. 2003] mantém uma pontuação global para cada par i, computada
através da pontuação de i dada por todos os outros pares, aplicado o peso das próprias
pontuações globais de tais pares. Alguns pares especiais computam, armazenam e replicam os valores globais de reputação para um par. Os pares especiais encontram os pares
152
Anais
para os quais devem manter a pontuação, e são encontrados por pares que necessitam
dessa informação, através de uma tabela hash distribuı́da.
Entretanto, essas abordagens são sucetı́veis aos ataques em conluio que podem acontecer. Nós desonestos podem conspirar para reduzir a reputação de nós honestos da rede. Chun et al. propuseram uma arquitetura [Chun et al. 2003] para aumentar a segurança de trocas entre nós baseada em troca de tickets. Esta arquitetura, porém, assume uma infra-estrutura de chaves criptográficas e o estabelecimento
de relações de confiança entre os pares para que seja possı́vel o acesso aos recursos.
Em P2PRep [Cornelli et al. 2002], cada par armazena informação sobre suas próprias
interações com outros pares. Para assegurar a confiabilidade dessa informação, P2PRep
lança mão de votação para obtenção de opiniões sobre a reputação de um par. Também,
P2PRep usa heurı́sticas para encontrar blocos de potenciais pares maliciosos e uma infraestrutura de chaves criptográficas para verificar as identidades de pares envolvidos numa
transação.
2.2.1. A Rede de Favores
A idéia central da Rede de Favores (NoF) é que os usuários que são os maiores colaboradores de recursos da rede devem receber maior prioridade de acesso aos recursos
disponı́veis na rede. Esse princı́pio segue como um guia para a distribuição balanceada dos recursos disponı́veis entre os usuários e, portanto, como um incentivo para a
colaboração. A NoF contorna a necessidade de prover confiabilidade dos dados coletados, visto que não agrega valores globais de reputação a um par. Em vez disso, pares
somente usam as informações de reputação envolvendo suas próprias interações entre pares. Essa informação é armazenada localmente no nó. Estratégias maliciosas baseadas em
mentiras sobre o comportamento de nós terceiros (e.g., ataques em conluio) não podem
ser aplicadas.
Na NoF, alocar um recurso a um par que o requisita é prestar um favor, e o valor do
favor é o valor do trabalho realizado para compartilhar o recurso ao par solicitante. Cada
par mantém um registro local do total de favores prestados a e recebidos de cada par com
quem tenha realizado transações no passado. Cada vez que um par presta um favor ou
recebe um favor, ele atualiza o número apropriado. Um par calcula a reputação local de
outro par baseando-se nesses números, de forma que um par que tem lhe prestado muitos
favores e recebido poucos terá uma reputação maior. Um par usa a reputação atual para
decidir para que outros pares ele prestará favores, quando tiver de arbitrar entre mais de
um solicitante de recurso. Portanto, sempre que houver contenção de recursos, os pares
com maior reputação terão prioridade.
Seja v(A, B) o valor total de recursos doados do nó A para o nó B no passado do
sistema, o nó A calcula rA (B), a reputação do nó B, usando a Equação 1:
rA (B) = max{0, v(B, A) − v(A, B) + log(v(B, A))}
(1)
Usando 1, o nó A calcula a reputação do nó B com o número de favores que A
recebeu de B, menos o número de favores que B recebeu de A. Usando uma função
de reputação não-negativa é possı́vel evitar a priorização de nós que maliciosamente tro-
153
cam de identidade para se beneficiar daqueles nós que consumiram mais recursos do que
contribuiram. O termo sub linear log(v(B, A)) foi introduzido na equação para que se
possa distinguir entre nós que trocam de identidade maliciosamente e que nunca doaram
quaisquer recursos de um nó B que colaborou para A no passado, mas recebeu o mesmo
montante de favores que doou para A. Também, é possı́vel identificar um colaborador
mesmo se o colaborador tenha consumido mais recursos do que tenha doado, visto que
ele já doou recursos no passado.
3. Aumentando a Segurança no P2MAN
Para aumentar a segurança do P2MAN, adotou-se uma versão modificada da Rede de
Favores para computar a pontuação de reputação dos nós, baseada na interação entre esses
nós, para identificar e desencorajar as atividades de nós desonestos. Foram combinados o
mecanismo de pontuação da NoF, um mecanismo de Lista Negra e o mecanismo de envio
de conteúdos do P2MAN para aumentar a robustez do sistema, sistematicamente evitando
que nós maliciosos recebam pedaços de conteúdo dos seus vizinhos.
Como em trabalhos anteriores, assumindo-se que se o sistema possui algum mecanismo pelo qual seja possı́vel ao nó identificar nós colaboradores com precisão suficiente,
e que os colaboradores reconhecidos recebam prioridade nos recursos, então o nós pagarão para serem colaboradores. Como uma conseqüência esperada, os nós modificarão
suas estratégias de colaboração e o sistema evoluirá para um estado em que não haverá
nós desonestos. A abordagem usada neste trabalho é detalhada a seguir.
3.1. Adaptando a Rede de Favores ao P2MAN
De forma similar à NoF, um nó P2MAN atribui uma pontuação para cada nó vizinho com
o qual ele interage, e armazena essa informação localmente, de acordo com os favores
que o nó recebe ou doa. No P2MAN, transmitir um pedaço de um conteúdo requisitado é prestar um favor. Entretanto, um nó proprietário P2MAN deve decidir se vai ou
não responder a requisições de conteúdo. Essa decisão é baseada num fator denominado
Saúde. A Saúde é uma metáfora que representa a noção intuitiva de disponibilidade de
uma coleção de recursos do nó. Por exemplo, como os nós móveis possuem recursos de
energia limitados, deve-se poupar a energia disponı́vel. Sendo assim, as transmissões são
consideradas custosas. Para um nó que tenha a sua fonte de energia a plena carga é mais
conveniente transmitir conteúdos do que para um nó com uma fonte de energia próxima
da exaustão.
Seja ρ ∈ < : 0 ≤ ρ ≤ 1 a probabilidade de que um nó proprietário A compartilhará seus conteúdos quando requisitado, θA seja o limiar de saúde do nó A e rA (max) a
máxima reputação de nós armazenada no nó A, define-se ρ na Equação 2, como a seguir.
ρ = min(1, (θA + θA .
rA (B)
)) : 0 ≤ θ ≤ 1
rA (max)
(2)
Assumindo que os nós P2MAN sabem medir seu estado interno, de forma a poder
computar sua saúde, quando um nó P2MAN A estiver plenamente saudável, θA será 1.
Da mesma forma, quando A tiver exaurido seus recursos, θA será 0. O segundo termo na
Equação foi introduzido para comparar a reputação de um nó solicitante com a melhor
154
Anais
reputação armazenada no nó A. O objetivo deste segundo termo é aumentar a probabilidade de que um bom colaborador receba pedaços de conteúdo. Assim, quando um nó
iniciante (i.e., com reputação nula) requisita um conteúdo ao nó A, a probabilidade de
o nó A atender à requisição depende somente do seu limiar de saúde (i.e., θA ). Se em
algum momento o nó A estiver plenamente saudável, ele atenderá às requisições de compartilhamento de conteúdo, mesmo a nós iniciantes na rede. Entretanto, quando o melhor
colaborador (i.e., rA(max)) requisitar um conteúdo ao nó A, a probabilidade de o nó A
atender a sua requisição será duas vezes maior do que a probabilidade de A atender um
nó iniciante (i.e., max(1, 2θA ). Essa abordagem captura a idéia de esforço de um nó para
garantir a reciprocidade de favores aos seus colaboradores.
A NoF original não resolve o problema de ataques maliciosos por nós desonestos
que desejam reduzir o desempenho do sistema através do envio de pedaços falsos de
conteúdo para os vizinhos que solicitam. Destaca-se que o impacto da transmissão de
pedaços falsos para pares de uma rede P2P de distribuição de conteúdo pode ser ordens
de magnitude pior se a rede P2P estiver sobre uma MANET. Isso se deve ao fato de que
as MANETs utilizam roteamento salto a salto em ambiente dinâmico. A medida que
um pedaço falso atravessa uma MANET, muitos nós podem ser requisitados a repassar
os pacotes que compõem o pedaço, desde o nó proprietário até o destino. No caso de
um ataque em conluio, uns poucos nós desonestos podem saturar uma MANET inteira,
enviando pedaços falsos para nós diametralmente opostos na rede.
Para contornar esse problema, foi feita uma modificação na NoF, adicionando um
mecanismo de Lista Negra. O objetivo da lista negra é punir imediatamente quaisquer
nós P2MAN que enviem pedaços falsos para os nós solicitantes. Dessa forma, assim
que um pedaço falso é recebido por um nó solicitante, ele incorpora o nó em sua lista
negra, evitando responder às requisições futuras de tal nó (e.g., resposta a requisições de
conteúdo, envio de pedaços) por um perı́odo programado. O perı́odo programado pode
ser ajustado convenientemente pelo usuário do sistema. Para calcular rA (B), assume-se
que um nó P2MAN tem informações confiáveis sobre v(B, A) e v(A, B).
Particularmente, assume-se que um nó P2MAN genérico é capaz de: (i) medir o
número de favores providos por outro nó P2MAN, e (ii) verificar se o favor prestado é
válido ou não (i.e., que os dados enviados são válidos).
3.2. Coibindo Atividades de Nós Desonestos
Por se tratar de um protocolo P2P multicast para MANETs, uma estratégia do P2MAN
é evitar as múltiplas transmissões de conteúdo um para um, o que reduz a saturação da
transmissão. Em vez disso, P2MAN reforça a seleção de únicos nós transmissores para
cada conteúdo, por um processo de seleção de nós proprietários. Note-se que, como parte
da implementação do P2MAN, uma requisição de conteúdo deve ser realizada através de
uma mensagem para o Canal Público (i.e., grupo multicast especial).
Ao receber uma mensagem de solicitação, um nó proprietário pode responder ao
Canal Público, se desejar, informando que possui o conteúdo e enviando os metadados
com detalhes do conteúdo (e.g., fracionamento, grupo multicast). Todos os nós proprietários podem responder às solicitações no Canal Público. Após analisar as múltiplas
opções, o nó solicitante autoriza um único nó proprietário a enviar pedaços, através de
uma mensagem especı́fica. Particularmente, o processo de seleção e envio de pedaços é
155
relevante para evitar atividades maliciosas no P2MAN, como explicado a seguir.
Supondo que um nó desonesto deseja enviar pedaços falsos para obter vantagem
desonesta na rede, ou para reduzir o desempenho do sistema, ele pode responder positivamente a quaisquer requisições de conteúdo na rede. Para completar o ataque, o nó
malicioso deve aguardar por uma autorização, visto que pedaços enviados por nós não
autorizados são ignorados pelo solicitante, que nem estará associado ao grupo multicast
correto. Quando receber uma autorização, o nó poderá enviar os pedaços falsos ao grupo
multicast alvo. Quando o primeiro pedaço falso for recebido pelos nós solicitantes do
grupo, o remetente será incluı́do nas listas negras dos participantes, que se desconectarão
imediatamente do grupo multicast indicado pelo nó malicioso.
Por um perı́odo programado, os nós atacados vão ignorar as comunicações seguintes do nó atacante incluı́do na lista negra. Defende-se que esta abordagem é suficiente
para minimizar as atividades maliciosas de nós desonestos, evitando que haja transmissão
de pedaços para esses nós desonestos. A atividade dos nós caroneiros (free riders) será
minimizada também, visto que tais nós terão baixa reputação na rede, como explicado a
seguir.
Supondo agora que um nó desonesto deseja ser um caroneiro, não respondendo a
quaisquer solicitações. A partir daı́, sua reputação não aumentará com o tempo. Mesmo
no caso de um ataque de mudança de identidades, o nó desonesto permanecerá com a
reputação nula, exatamente como um nó iniciante.
4. Avaliação
Nesta Seção o desempenho da solução proposta é medido, apresentando-se os resultados de simulações que mostram que as modificações aplicadas à Rede de Favores são
suficientes para evitar que nós maliciosos tenham êxito e levem um sistema P2MAN ao
colapso.
4.1. Cenário de Simulação
Foram realizadas simulações em um cenário tı́pico de MANETs, no simulador Network
Simulator 2.34. Foi modelada uma rede com 100 nó móveis homogêneos. No modelo
proposto, é possı́vel ajustar o perı́odo programado de penalidade, o número de pares que
enviam pedaços falsos, e o número de pares caroneiros. Os resultados são representados
por uma média de 20 rodadas de simulação, com um intervalo de confiança de 95%.
Os nós estão espalhados aleatoriamente sobre o terreno e movem-se de acordo
com o modelo de mobilidade Random Waypoint (excluindo-se a velocidade mı́nima
zero). Os conteúdos compartilhados são fracionados em pedaços de 1000 Bytes, de
acordo com as recomendações de tamanho de pacote UDP de Lee et al. [Lee et al. 2002].
O tamanho do conteúdo é de 100 KBytes. Foram considerados 70 nós solicitantes. Desses, 25 nós são caroneiros, 25 nós são desonestos e enviarão pedaços falsos, e 20 nós são
honestos. A Tabela 2 mostra os parâmetros de configuração do P2MAN.
Quando a simulação inicia, todos os nós têm zero favores e, em algum momento,
os nós solicitantes iniciam a descoberta de conteúdos na rede. Quando o primeiro nó
honesto inicia solicitações, os respectivos nós proprietários respondem, se estiverem com
saúde suficiente. Então, nós proprietários saudáveis e autorizados enviam pedaços para
156
Anais
Tabela 2. Parâmetros de Simulação do P2MAN.
Parâmetro
Simulador
Número de Rodadas
Tamanho do Terreno
Modelo de Mobilidade
Tempo de Pausa
Alcance de Rádio
Largura de Banda
Protocolo de Enlace
Velocidade Máxima
Tamanho do Pedaço
Tamanho do Conteúdo
Perı́odo de Penalidade
Limiar de Saúde (θ)
Número de Nós
Número de Nós Proprietários
Número de Nós Solicitantes
Número de Caroneiros (i.e., não colaboram)
Número de Nós Desonestos (i.e., enviam pedaços falsos)
Número de Nós Honestos (i.e., colaboradores)
Descrição
2.34
20
1000x1000
Random Waypoint
0s
250 m
2 M bps
802.11DCF M ode
5 m/s
1000 Bytes
100 KBytes
300 s
0.8
100
30
70
25
25
20
os solicitantes. Ao receber e validar os pedaços, os solicitantes então incrementam suas
tabelas de reputação. De forma similar, quando o primeiro nó solicita conteúdos, nós
proprietários saudáveis também respondem, visto ser impossı́vel determinar quais nós
são caroneiros ou maliciosos antes das interações. Portanto, o resultado esperado é que
ambos nós honestos e maliciosos recebam pedaços nas primeiras interações e, após um
perı́odo de tempo, os colaboradores serão pontuados e conseqüentemente privilegiados.
Nós maliciosos permanecerão com reputação nula. Quando nós maliciosos iniciarem as
respostas com conteúdos falsos, todos os solicitantes envolvidos devem incluı́-lo em suas
listas negras. Dessa forma, o resultado esperado é que, em um perı́odo curto de tempo,
os nós desonestos sejam incapazes de enviar pedaços falsos com êxito e suas reputações
permaneçam nulas para todo o sistema, visto que eles não colaboram.
A duração das simulações é de 5000s. Um nó solicitante pede um conteúdo por
vez e quando recebe integralmente um conteúdo, uma nova requisição é feita imediatamente, de forma que o sistema está em constante atividade. A Figura 1 mostra os resultados das simulações, com a taxa de sucesso de download dos nós honestos, nós desonestos
e nós caroneiros, coletados a cada 500s de simulação. Assume-se que os nós não mudam
de estratégia, de forma que um nó honesto permanece honesto durante toda a simulação.
Note-se que, mesmo entre nós honestos, a taxa de sucesso de download não é máxima,
visto que o download de alguns pedaços pode falhar.
A Figura 1 mostra uma redução substancial na taxa de sucesso dos nós desonestos. Também, os nós caroneiros têm suas atividades minimizadas após um perı́odo. Nas
simulações foram usados conteúdos pequenos para download. Ressalte-se que, quando o
download de um conteúdo é concluı́do, um novo download inicia. Portanto, para novos
157
Figura 1. Taxa de Sucesso de Download de Nós Honestos, Nós Desonestos, e
Nós Caroneiros.
conteúdos, potencialmente novos proprietários são requisitados e os nós caroneiros podem se beneficiar recebendo alguns pedaços desses novos nós proprietários, o que explica
a inclinação mais suave no decaimento do gráfico, até serem finalmente detectados por
uma quantidade suficiente de nós para serem coibidos.
5. Conclusão
Este trabalho tratou do problema de aumentar a segurança do P2MAN, que é um protocolo de distribuição de conteúdo P2P para MANETs, minimizando as atividades de nós
caroneiros e nós desonestos. A abordagem utilizada foi uma adaptação da Rede de Favores como mecanismo de reputação distribuı́do. Na versão modificada foi incorporada
uma funcionalidade de lista negra para auxiliar a NoF a combater os nós desonestos no
P2MAN. Também, foi definido o conceito de saúde do nó, em um esforço para modelar as
restrições de recursos dos nós móveis sem fio no contexto de distribuição das MANETs.
Com essa modelagem foi possı́vel evitar o problema de drenagem maliciosa de recursos
por nós desonestos.
Através do simulador NS-2, foi demonstrado que a abordagem proposta é suficiente para minimizar as atividades de nós maliciosos, reduzindo a taxa de sucesso de
download dos nós desonestos a quase zero.
Pretende-se estender este trabalho, incluindo a informação de energia e outras
restrições de recursos nas simulações e realizando análises mais completas para medir o
impacto da saúde do nó na habilidade do P2MAN de distribuir conteúdos em MANETs.
158
Anais
Referências
Aberer, K. and Despotovic, Z. (2001). Managing trust in a peer-2-peer information system. In Proceedings of the tenth international conference on Information and knowledge management, pages 310–317, New York, NY, USA. ACM.
Anastasi, G., Ancillotti, E., Conti, M., and Passarella, A. (2009). Design and performance
evaluation of a transport protocol for ad hoc networks. The Computer Journal Advance,
52:186–209.
Andrade, N., Brasileiro, F., Cirne, W., and Mowbray, M. (2004). Discouraging free riding in a peer-to-peer cpu-sharing grid. High-Performance Distributed Computing,
International Symposium on, 0:129–137.
Androutsellis-Theotokis, S. and Spinellis, D. (2004). A survey of peer-to-peer content
distribution technologies. ACM Computer Surveys, 36(4):335–371.
Chun, B., Fu, Y., and Vahdat, A. (2003). Bootstrapping a distributed computational economy with peer-topeer bartering. In 1st Workshop on Economics of Peer-to-Peer
Systems.
Cohen, B. (2003). Incentives build robustness in bittorrent. In Workshop on Economics
of Peer-to-Peer Systems, Berkeley, CA, EUA.
Conti, M., Gregori, E., and Turi, G. (2004). Towards scalable p2p computing for mobile
ad hoc networks. In Proceedings of the Second IEEE Annual Conference on Pervasive
Computing and Communications Workshops, page 109.
Cornelli, F., Damiani, E., di Vimercati, S. D. C., Paraboschi, S., and Samarati, P. (2002).
Choosing reputable servents in a p2p network. In Proceedings of the 11th international
conference on World Wide Web, pages 376–386, New York, NY, USA. ACM.
Delmastro, F., Passarella, A., and Conti, M. (2008). P2p multicast for pervasive ad hoc
networks. Pervasive and Mobile Computing, 4(1):62 – 91.
Ding, G. and Bhargava, B. (2004). Peer-to-peer file-sharing over mobile ad hoc networks.
In Proceedings of the Second IEEE Annual Conference on Pervasive Computing and
Communications Workshops, page 104.
Doria, S. and Spohn, M. A. (2009). A multicast approach for peer-to-peer content distribution in mobile ad hoc networks. In IEEE Wireless Communications and Networking
Conference (WCNC), pages 1–6.
Holland, G. and Vaidya, N. (1999). Analysis of tcp performance over mobile ad hoc
networks. In Proceedings of the 5th Annual ACM/IEEE International Conference on
Mobile Computing and Networking, pages 219–230.
Kamvar, S. D., Schlosser, M. T., and Garcia-Molina, H. (2003). The eigentrust algorithm
for reputation management in p2p networks. In Proceedings of the 12th international
conference on World Wide Web, pages 640–651, New York, NY, USA. ACM.
Klemm, A., Lindemann, C., and Waldhorst, O. (2003). A special-purpose peer-to-peer
file sharing system for mobile ad hoc networks. IEEE 58th Vehicular Technology Conference, 4:2758–2763.
159
Kortuem, G., Schneider, J., Preuitt, D., Thompson, T., Fickas, S., and Segall, Z. (2001).
When peer-to-peer comes face-to-face: Collaborative peer-to-peer computing in mobile ad hoc networks. In Proceedings of the First International Conference on Peer-toPeer Computing, page 75.
Kozat, U., Koutsopoulos, I., and Tassiulas, L. (2004). A framework for cross-layer design of energy-efficient communication with qos provisioning in multi-hop wireless
networks. In Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, volume 2, pages 1446–1456.
Krifa, A., Sbai, M. K., Barakat, C., and Turletti, T. (2009a). Bithoc: A content sharing
application for wireless ad hoc networks. Pervasive Computing and Communications,
IEEE International Conference on, 0:1–3.
Krifa, A., Sbai, M. K., Barakat, C., and Turletti, T. (2009b). A standalone content sharing application for spontaneous communities of mobile handhelds. In MobiHeld ’09:
Proceedings of the 1st ACM workshop on Networking, systems, and applications for
mobile handhelds, pages 77–78, New York, NY, USA. ACM.
Lee, J., Kim, G., and Park, S. (2002). Optimum udp packet sizes in ad hoc networks.
In Workshop on High Performance Switching and Routing. Merging Optical and IP
Technologies, pages 214–218, Seoul, South Korea.
Lee, U., Park, J.-S., Yeh, J., Pau, G., and Gerla, M. (2006). Code torrent: content distribution using network coding in vanet. In MobiShare ’06: Proceedings of the 1st
international workshop on Decentralized resource sharing in mobile computing and
networking, pages 1–5, New York, NY, USA. ACM.
NS-2 (2010). The network simulator. http://www.isi.edu/nsnam/ns.
Passarella, A., Delmastro, F., and Conti, M. (2006). Xscribe: a stateless, cross-layer
approach to p2p multicast in multi-hop ad hoc networks. In MobiShare ’06: Proceedings of the 1st international workshop on Decentralized resource sharing in mobile
computing and networking, pages 6–11, New York, NY, USA. ACM.
Quental, N. C. and Gonçalves, P. A. (2010). Cds-bittorrent: Um sistema de disseminação
de conteúdo para a melhoria do desempenho de aplicações bittorrent sobre manets. In
VI Workshop de Redes Dinâmicas e Sistemas Peer-to-Peer (WP2P).
Rajagopalan, Sundaram, Shen, and Chien-Chung (2006). A cross-layer decentralized
bittorrent for mobile ad hoc networks. In Third Annual International Conference on
Mobile and Ubiquitous Systems: Networking & Services, pages 1–10.
Sbai, M. K. and Barakat, C. (2009). Revisiting p2p content sharing in wireless ad hoc
networks. Lecture Notes in Computer Science, 5918:13–25.
Sbai, M. K., Barakat, C., Choi, J., Hamra, A. A., and Turletti, T. (2008). Adapting
BitTorrent to Wireless Ad Hoc Networks, volume 5198, pages 189–203. Springer Berlin
/ Heidelberg.
Souza, C. and Nogueira, J. M. (2008). Um estudo do bittorrent em redes ad hoc sem
fio crı́ticas com localidade espaço-temporal. In XXV Simpósio Brasileiro de Redes de
Computadores e Sistemas Distribuı́dos, pages 329–342.
160
Anais
Stuckmann, P. and Zimmermann, R. (2009). European research on future internet design.
IEEE Wireless Communications, 16:14–22.
Vaishampayan, R. and Garcia-Luna-Aceves, J. J. (2004). Efficient and robust multicast
routing in mobile ad hoc networks. IEEE International Conference on Mobile Ad-hoc
and Sensor Systems, pages 304–313.
Y. Charlie Hu, S. D. and Pucha, H. (2003). Exploiting the synergy between peer-to-peer
and mobile ad hoc networks. In 9th Workshop on Hot Topics in Operating Systems,
pages 37–42, Lihue, HI, USA.
161
Agregação de Pacotes em Ambientes com Enlaces de Baixa
Capacidade de Transmissão
P. H. Azevêdo Filho1 , M. F. Caetano2 , J. L. Bordim1
1
Departamento de Ciência da Computação – Universidade de Brasília (UnB)
Caixa postal 4466 – 70910-900 – Brasília – DF – Brasil
2
Departamento de Engenharia Elétrica – Universidade de Brasília (UnB)
Caixa postal 4386 – 70910-900 – Brasília – DF – Brasil
bordim@unb.br, caetano@cic.unb.br, paulo.a.filho@aiesec.net
Abstract. This work presents a new technique for improving the capacity of saturated wireless networks of hosting real time voice conversations, without degrading the quality provided to users. To reach this goal, a packet aggregation
protocol was tailored to work in the IP layer of the networking stack, in order to reduce the number of wireless transmissions and decrease the volume of
headers sent. This technique, called MAPAS, was compared to a state-of-the-art
packet aggregation policy and to a non-aggregating network, and a significant
improvement in supporting the traffic was noticed in the network that used MAPAS.
Resumo. A principal contribuição deste trabalho é propor um mecanismo de
agregação de pacotes voltado para ambientes de rede sem fio onde a capacidade dos enlaces não é homogénea. O mecanismo proposto, caracteriza-se
pela utilização de estimativas de tempo para realizar a entrega dos dados permitindo a agregação dos pacotes e mantendo o atraso máximo dentro dos limites da aplicação. O mecanismo proposto, denominado MAPAS (Mecanismo
de Agregação de Pacotes em Ambientes Saturados), foi implementado e comparação com outras políticas de agregação de pacotes. Os resultados mostram
que mecanismo proposto permite uma maior agregação de dados mantendo os
requisitos de temporização e atrasos de aplicações sensíveis como o de tráfego
de voz.
1. Introdução
A popularização da Internet acelerou a corrida por novas tecnologias e impulsionou o processo de convergência de serviços com base no protocolo IP. Esta convergência fomentou
o surgimento de novas tendências e serviços. Um exemplo desta tendência é a tecnologia
de tráfego de Voz sobre IP (Voice over IP - VoIP). Ao longo dos últimos anos, o VoIP
tem ganhado adeptos tanto no setor privado como no setor público. O Governo Federal,
por exemplo, há algum tempo vem buscando formas de reduzir custos com telefonia nos
órgãos públicos. Esta iniciativa ganhou força com o projeto VoIP4All que vem sendo
executado junto à RNP [Oliveira 2007]. Dentre os principais fatores de sucesso do VoIP
estão a possibilidade de integração ao sistema de telefonia pública e redução dos custos
em chamadas telefônicas [Correio Popular Online 2005].
162
Anais
Em um contexto diferente, mas ao mesmo tempo, a utilização de tecnologias de
comunicação sem fio foi impulsionada pelo avanço dos componentes eletrônicos e das
comunicações pessoais sem fio. De forma a permitir a sua padronização, o IEEE (The
Institute of Electrical and Electronics Engineers ) iniciou estudos para a elaboração de
um padrão para redes sem fio locais e metropolitanas. Deste trabalho surgiu o padrão
IEEE 802.11 (ou WiFi), cujo objetivo era permitir a conectividade sem fio entre equipamentos em uma área local [IEEE 2007]. Devido a sua simplicidade de instalação, configuração, baixo consumo de energia e custos atrativos, criou-se um cenário favorável para
a utilização do WiFi nos mais diversos ambientes. O padrão IEEE802.11 permite dois
modos de operação, com e sem infra-estrutura. No primeiro modo, a comunicação entre
os dispositivos se dá através um elemento central, ou ponto de acesso. No segundo modo,
também chamado modo ad hoc, a comunicação entre os dispositivos é viável mesmo sem
a presença de uma infra-estrutura pré-existente. Atualmente, as redes ad hoc encontram
aplicações em inúmeros cenários, desde em operações de busca e resgate até a simples
troca de arquivos entre dois dispositivos adjacentes.
O baixo custo e sua ampla utilização fazem do padrão IEEE 802.11 uma alternativa natural para se agregar mobilidade às aplicações de VoIP. No entanto, as redes sem
fios não oferecem o mesmo desempenho das redes cabeadas, por serem mais suscetíveis
a interferências e colisões. Além disso, o tráfego de voz exige que a rede tenha uma boa
capacidade de enviar pacotes de maneira contínua e com pequena variação do atraso para
que se possa garantir a qualidade do serviço (Quality of Service - QoS).
O uso de longos cabeçalhos na camada física e os mecanismos de contenção
de acesso ao meio fazem com que as redes sem fio tenham maior dificuldade para suportar aplicações VoIP. Para minimizar estes problemas, a comunidade científica vem
buscando alternativas de forma a atender os requisitos destas aplicações. Entre as técnicas exploradas, a agregação de pacotes tem apresentado resultados interessantes, em
especial para o tráfego de voz [Petrović et al. 2003, Katti et al. 2006, Castro et al. 2007,
Raghavendra et al. 2006]. A Figura 1 mostra um exemplo onde há o envio de diversos
pacotes de voz unidos em um único pacote. Esta técnica permite que os pacotes de vários emissores sejam agregados em um ponto comum, o que permite uma diluição no
overhead imposto pelos protocolos de comunicação sem fio utilizados. Estas e outras
questões serão abordadas com maior nível de detalhe nas próximas sub-seções. Para prover tal comportamento, mecanismos de multiplexação e demultiplexação dos pacotes de
voz precisam ser bem definidos para que esta técnica produza os benefícios desejados.
1.1. Trabalhos Relacionados
Em [Petrović et al. 2003] é apresentada uma proposta de um algoritmo de roteamento,
compressão e agregação de pacotes para redes de sensores. Os resultados mostram ganhos significativos em termos de redução de custo de roteamento. No entanto, esta abordagem não atende aos requisitos de QoS para tráfego de voz. Em [Katti et al. 2006], os
autores propõem uma combinação linear entre os dados estão sendo transmitidos, considerando para isso, que os dispositivos da rede possuem vários pacotes armazenados.
Este método exige mudanças profundas na pilha TCP/IP. A proposta denominada IPAC
[Raghavendra et al. 2006] define mecanismos para reter os dados na origem de forma a
agregá-los em um pacote maior e então transmiti-los. Os resultados mostram que em
certos cenários é possível obter ganhos significativos. No entanto, o uso dessa técnica
163
Figura 1. Representação de vários pacotes sendo agregados em um só, com a
adição de cabeçalhos extras para controlar o início dos pacotes.
pode desperdiçar oportunidades de agregação em outros pontos da rede. Outro problema
é a dificuldade de estimar o volume de dados que podem ser retidos na origem sem degradar o serviço. Uma evolução desta proposta é apresentada em [Castro et al. 2007],
onde os autores propõem que pacotes sejam agregados ao longo do caminho. No entanto,
as estimativas de tempo de agregação são determinadas de forma fixa, o que pode gerar
atrasos excessivos e descarte de pacotes, especialmente, em ambientes onde os enlaces
possuem diferenças de capacidade, ou desperdiçar oportunidades de agregação, quando
as condições do canal forem boas.
Este trabalho apresenta um mecanismo de agregação de pacotes para suporte a
aplicações VoIP sobre redes sem fio. O mecanismo proposto permite a redução do número
transmissões bem como do overhead dos cabeçalhos envolvidos no processo de agregação. Diferente dos demais trabalhos, nossa proposta realiza a avaliação local e dinâmica
do comportamento do fluxo de dados o que permite a aplicação da solução mesmo para
redes com enlaces heterogêneos. Os requisitos de tempo impostos pela aplicação são respeitados e o trabalho de agregação é realizado de forma adaptativa. Os resultados obtidos
através de simulações demonstram que o mecanismo proposto permite ganhos significativos quando comparados com os de outras técnicas semelhantes propostas. Em média, foi
possível reduzir em 50% o número de transmissões e manter o mesmo volume de dados
transmitidos.
O restante deste documento está organizado da seguinte forma: A Seção 2 introduz conceitos relacionados com o processo de agregação de pacotes. A Seção 3 uma nova
proposta de agregação de pacotes será apresentada. Na Seção 4 os experimentos realizados serão descritos e seus resultados apresentados e discutidos. Por fim, na Seção 5 serão
apresentadas as conclusões e trabalhos futuros.
2. Agregação de Pacotes
O foco da agregação de pacotes em redes sem fio é minimizar o overhead introduzido
pelos temporizadores e pacotes de controle que fazem parte dos protocolos de comunicação sem fio. No caso do WiFi, estes temporizadores fixos independem da carga útil do
164
Anais
pacote sendo transmitido [IEEE 2007]. Dentre os temporizadores fixos podemos citar o
SIFS (Short Interframe Space), DIFS (DCF Interframe Space) e preâmbulo. Os pacotes
RTS (Request To Send) e CTS (Clear To Send) podem ser considerados como fixos, tendo
em vista que os mesmos são transmitidos a uma taxa de transmissão fixa, independente
da qualidade e capacidade do canal. Por outro lado, o tempo de contenção depende de
vários fatores, entre eles o número transmissores. Neste contexto, a agregação de pacotes
tenta minimizar os efeitos de overhead descritos através da união da carga útil dos pacotes
a serem transmitidos. Um melhor detalhamento sobre os diversos temporizadores, bem
como, a relação entre o overhead e a carga útil dos pacotes, em uma rede sem fio, pode
ser verificado em [Bordim et al. 2010].
Os trabalhos relacionados, apresentados na seção anterior, consideram um ambiente em que as conexões entre os nós adjacentes possuem as mesmas características em
termos de capacidade de transmissão e temporização. No entanto, dada a dinâmica das
redes móveis e as características do meio aéreo, as condições do canal em um nó ni podem ser bastante diferentes daquelas observadas pelo nó nj , mesmo no caso em que ni e
nj sejam adjacentes (para 0 < i < j < N , e N representa o número de nós da rede em
questão). Em outras palavras, as condições do enlace entre dois nós adjacentes, ni e nj ,
em uma rede sem fio, pode variar ao longo do tempo e estão sujeitas a interferências, colisões e contenção. Esta, por exemplo, está diretamente associada ao número de vizinhos e
suas respectivas ações, tais como volume de pacotes enviados, recebidos ou mesmo roteados através destes nós. Portanto, um mecanismo de agregação de pacotes deve levar em
conta estas questões, de forma a prover um nível de QoS aceitável para esses ambientes.
É importante ressaltar que a temporização é um fator crítico que interfere diretamente na
qualidade do serviço percebido pelo usuário.
Para melhor ilustrar como a agregação de pacotes pode ser utilizada em uma rede
ad hoc, considere o cenário ilustrado na Figura 2. Na figura, quatro nós estão representados. Suponha que os nós na e nb possuam dados a serem encaminhados para o nó nd .
Assuma que ambos os nós na e nb estejam transmitido seus pacotes a uma taxa constante. Considerando o codec iLBC, teremos 38 bytes a cada 20 ms sendo gerados, na
Camada de Aplicação, pelos nós na e nb [Página do Codec iLBC 2010]. Estes pacotes
serão entregues ao nó nc , que irá repassá-los ao destinatário. Como é possível perceber,
existe a oportunidade para o nó nc em combinar os pacotes recebidos de na e nb antes de
repassar para o destino nd . A agregação de pacotes permite ao nó nc reduzir o número de
transmissões para o nó nd . No entanto, para que este processo seja viável, o tempo gasto
neste processo deve estar dentro dos limites aceitáveis pela aplicação. Isto é, o nó nc deve
possuir mecanismos para poder estimar o tempo gasto para o encaminhamento do pacote
da origem até o nó nc e o tempo necessário para encaminha-lo do nó nc até o destino final
que, em nosso exemplo, é o nó nd . Vale ressaltar que para comunicação VoIP, o tempo
total para transmitir uma mensagem da origem ao destino não pode superar 150ms, de
forma a ser possível garantir um nível aceitável de QoS [ITU-T 1996].
Até o momento, as técnicas de agregação de pacotes consideram o tempo para
transpor cada enlace como sendo constante, o que facilita esta estimativa. Por outro lado,
esta restrição não é realista. Seguindo o exemplo da Figura 2, o enlace entre os nós nc e nd
pode ter uma capacidade inferior à dos outros dois enlaces da rede. Isso faz com que uma
estimativa global de tempo possa acarretar em desperdício de oportunidade de agregação
165
Figura 2. Topologia de rede contendo enlaces com capacidades diferenciadas.
ou, ainda, no descarte de pacotes. Na próxima seção serão apresentados os detalhes do
mecanismo de agregação proposto neste trabalho. O referido mecanismo visa atender aos
requisitos descritos, de forma a realizar a agregação de pacotes mesmo em cenários em
que os enlaces apresentam características distintas.
3. MAPAS
Esse mecanismo tem seu foco no tráfego de dados com taxas constantes de transmissão,
como o VoIP, por exemplo. O mecanismo proposto é denominado Mecanismo de Agregação de Pacotes em Ambientes Saturados - MAPAS. O ponto central desta proposta consiste
em estimar o tempo máximo (tpk ) que um dado pacote pk pode ser retido em determinado
em nó na rota até o seu destino, onde k (0 ≤ k ≤ R), representa o identificador do pacote
e R o total de pacotes da rede.
3.1. Estimando o Tempo de Retenção
O princípio básico que rege o MAPAS, diferente dos demais trabalhos, em vez de esperar
um valor fixo para que cheguem mais pacotes agregáveis, é o de esperar o maior tempo
possível sem que haja prejuízos para a aplicação. Para tanto, é preciso que cada nó da
rede possua de antemão uma estimativa do tempo necessário para o pacote chegar ao
seu destino. Este tipo de informação pode ser obtida a partir da análise das informações
contidas nos protocolos de comunicação atualmente disponíveis para redes ad hoc.
Os protocolos de roteamento para redes ad hoc em geral requererem que os nós
guardem informações sobre o caminho para um nó específico com o qual haja comunicação. Essa informação pode ser o próximo nó pelo qual o pacote deve passar (next hop),
como no caso dos protocolos DSDV (Destination-Sequenced Distance-Vector Routing) e
AODV (Ad hoc On Demand Distance Vector), ou mesmo a rota inteira, como no protocolo DSR (Destination Source Routing), que pode chegar a gravar várias rotas completas
para um mesmo destino [Johnson et al. 2007].
Durante a fase de descoberta da rota, por exemplo no DSR, é possível estimar o
tempo necessário para chegar ao destino. Definimos Tr,d como a estimativa de tempo para
chegar ao nó de destino d, a partir do nó r, onde r representa um nó no caminho entre
a origem e o destino do pacote em questão. Esta estimativa pode ser realizada para cada
salto ao longo da rota. Para ilustrar o funcionamento, considere a Figura 2. Suponha que o
nó na envie um pacote de descoberta de rota para o nó nd . Este pacote irá chegar ao nó nc
e será encaminhado ao nó nd o qual irá responder como um pacote de confirmação de rota.
Note que neste caso, os nós na e nc podem estimar o tempo Ta,d e Tc,d , respectivamente,
durante o envio da solicitação de rota e o seu respectivo retorno. Esse valor de tempo
servirá de base na definição de quanto tempo um pacote pode aguardar a cada salto.
166
Anais
Ressalta-se que outros autores utilizam mecanismos semelhantes em outros contextos para estimar o tempo de travessia de uma rota [Bordim et al. 2004]. As variações
nos enlaces podem ser capturadas através do envio constante pacotes de manutenção da
rota. Esta técnica é de fato é utilizada por vários protocolos de roteamento. Uma vez
que a estimativa de tempo de retenção dos pacotes esteja disponível, a próxima tarefa é
permitir a agregação dos pacotes. Esta tarefa será detalhada na seção subsequente.
3.2. Cabeçalho de Agregação
Para melhor controlar os dados transmitidos com agregação, mas sem aumentar significativamente o tamanho dos cabeçalhos, foi desenvolvido um formato de cabeçalho de
agregação para a camada de rede. O cabeçalho é detalhado na Tabela 1. Como o funcionaTabela 1. Composição do cabeçalho do pacote de agregação proposto.
Tamanho (bytes)
1
2
4
4
Nome
eT ime
size
source
dest
Conteúdo
Tempo de vida do pacote, em milissegundos
Tamanho, em bytes, daquela parte agregada
Endereço IP da origem do pacote
Endereço IP do destino final do pacote
mento ocorre na camada IP, para separar o conteúdo dos pacotes agregados, basta remover
os cabeçalhos MAC (feito na camada inferior) e IP (feito na própria camada IP). O valor
do campo protocol do cabeçalho IP indicará se este pacote é um pacote de agregação ou
não, da mesma maneira que em [Castro et al. 2007]. Em caso afirmativo, os primeiros 11
bytes após o cabeçalho IP serão de um cabeçalho de agregação. O campo eT ime indica o
tempo decorrido desde a geração do pacote. Note que cada nó é responsável por atualizar
este campo antes de encaminhar o pacote para o próximo nó no caminho até o destino. O
campo size indicará o volume (em bytes que pertencem ao pacote agregado em questão.
Após esse número de bytes, poderá haver outro cabeçalho de agregação, e assim sucessivamente, até o limite de total length do cabeçalho IP, indicando que não há mais pacotes
agregados.
3.3. Funcionamento do MAPAS
Uma vez que o tempo necessário para um pacote percorrer o caminho da origem até o
destino está disponível, é possível verificar se um dado pacote pode ou não aguardar por
uma oportunidade de agregação com outros pacotes. Esta estimativa é obtida através dos
valores contidos em eT ime e Tr,d . A título de exemplo, considere o cenário da Figura
2, onde o nó nc está no caminho entre os nós na e nd . Quanto um pacote pi , oriundo de
na , é recebido por nc , o campo eT ime conterá o tempo gasto pelo pacote pi para chegar
ao nó nc . O tempo Tc,d contém a estimativa de tempo para pi chegar até o nó nd . Com
base nestes valores, o nó nc poderá estimar o tempo de retenção para o pacote pi . Neste
caso, o nó nc utiliza Equação 1 para estimar o tempo de retenção tpk para o pacote pk . Na
Equação 1, Amax representa o atraso máximo permitido pela aplicação. No caso do VoIP,
Amax = 150ms.
tpk = Amax − (eT ime + Tr,d ).
(1)
Quando maior o valor de tpk , maior será o tempo de retenção permitido para este pacote e,
consequentemente, maior serão as oportunidades de agregação. O protocolo de agregação
167
proposto neste trabalho utiliza os mecanismos descritos acima para estimar o tempo em
que um pacote poderá ser retido e agregado durante o seu percurso até o nó de destino. Os
detalhes do MAPAS são apresentados no Protocolo 1. No Protocolo MAPAS, P denota
Algoritmo 1 Protocolo MAPAS
Entrada Pacote P
1: Ptransp ← desencapsula(P )
2: P ← P − Ptransp
3: se Ptransp 6= ∅ então
4:
envia_camada_transporte(Ptransp )
5: fim se
6: S ← separa(P )
7: enf ilera(S)
8: para toda fila Q 6= ∅ faça
9:
se lim_tempo(Q) || lim_tamanho(Q) então
10:
envia_camada_enlace(f rente(Q))
11:
fim se
12: fim para
um pacote agregador e |P | representa o número total de pacotes agregados em P . Um
pacote agregador P pode conter dois ou mais pacotes agregados, isto é |P | ≥ 2; S representa subconjunto de pacotes de P (isto é, S ⊂ P ) e Q é uma lista de pacotes ordenada,
de forma crescente, por tpk . Desta forma, a cabeça da fila Q possui o pacote com menor
tempo de retenção. Este critério é utilizado para definir a prioridade de transmissão de
cada pacote.
Suponha que o ni (0 < i < N ) receba um pacote P . Ao executar as linhas 1 a 5
do MAPAS, ni irá desencapsular os dados em P e verificar quais pacotes pk , 0 < k < R,
contidos em P são destinados a ele. As linhas 6 e 7 permitem a ni agregar os pacotes
em S que deverão ser encaminhados para seus respectivos destinos. Em outras palavras,
os pacotes são agregados de acordo com o seu próximo salto (next hop), de forma que
os pacotes com o mesmo destino são colocados na mesma fila Q. As linhas 8 a 12 são
responsáveis por verificar quais filas possuem pacotes cujo tempo de retenção esgotou ou
cujo tamanho da fila esteja acima de um certo limite. Em ambos os casos, estes pacotes
serão encaminhados para o respectivo (next hop).
A próxima seção apresenta os cenários e os resultados da simulações da proposta
de agregação apresentada.
4. Simulações e Resultados
Esta seção tem como objetivo avaliar o desempenho do mecanismo de agregação proposto. Para este fim, um simulador em C++ foi desenvolvido de forma a incorporar as
características do MAPAS e de uma rede sem fio utilizando o padrão IEEE802.11. Além
do MAPAS, o mecanismo proposto [Castro et al. 2007] também foi implementado e será
utilizado como base para comparação. Três cenários foram escolhidos para a simulação,
um contendo um enlace com baixa capacidade de transmissão, um segundo cenário contendo um gargalo de comunicação, e um terceiro cenário onde os nós estão dispostos em
168
Anais
uma estrutura hierárquica. Os detalhes da simulação e seus parâmetros serão detalhados
juntamente com o cenário em questão nas subseções abaixo.
4.1. Primeiro cenário: Enlace de Baixa Capacidade
O objetivo deste primeiro cenário é permitir uma avaliação do mecanismo de temporização do MAPAS em um cenário onde os enlaces não possuem a mesma capacidade de
transmissão. A topologia utilizada é semelhante a apresentada na Figura 2. Na simulação,
os nós A e B estão ligados ao nó C por dois enlaces de 100kBps cada. O enlace entre os
nós C e D terá uma variação de capacidade e assumirá valores entre 10 a 100kBps. Os
nós A e B geram um tráfego de dez mil pacotes de voz cada um, com intervalos de 20ms
entre os pacotes (semelhante ao iLBC). Estes pacotes são repassados ao nó C e então
encaminhados ao nó de destino (nó D).
Total de Transmissoes
Cabecalhos transportados
50000
4e+06
MAPAS
Castro et al.
Sem agregar
MAPAS
Castro et al.
Sem agregar
3.5e+06
40000
Cabecalhos (bytes)
Numero de Transmissoes
3e+06
30000
20000
2.5e+06
2e+06
1.5e+06
1e+06
10000
500000
0
0
20
40
60
Capacidade do enlace (em Kbps)
80
100
20
40
60
80
100
Figura 3. Indicadores de uso eficiente da rede: (i) Número de transmissões necessárias para transportar os dados gerados; e, (ii) Quantidade total de cabeçalhos transmitidos na rede
A Figura 3 apresenta o número de transmissões necessárias para transportar os
dados e a quantidade total de cabeçalhos transmitidos. Como pode ser visto na figura, o
MAPAS permite reduzir significativamente o número de transmissões quando comparados com o método proposto em [Castro et al. 2007]. De fato, o MAPAS consegue agregar
de duas a quatro vezes mais pacotes em comparação com os métodos avaliados. Por sua
vez, a redução no volume de pacotes trafegados permite ao MAPAS uma economia significativa em termos do volume de bytes de cabeçalhos necessários para realizar o transporte
dos dados. Nota-se que mesmo com um cabeçalho de agregação e informações de temporização, o MAPAS ainda permite uma redução significativa no volume total de bytes
de controle trafegados. Esta economia representa uma redução superior a 55% quando
comparado com o mecanismo proposto em [Castro et al. 2007].
A Figura 4 apresenta os resultados em termos de número de pacotes descartados pela aplicação e atraso máximo. Como pode observado, quando a capacidade
do último enlace é de 10kBps, apenas o MAPAS permite a entrega total dos pacotes.
Neste caso, mais de 40% dos pacotes são descartados quando se utiliza a proposta de
[Castro et al. 2007]. A ausência de mecanismos de estimativa de tempo de retenção inviabiliza a agregação dos pacotes e eventualmente acarreta no descarte devido a atrasos
excessivos quando há uma variação mais significativa na capacidade do enlace. Essa situação torna-se clara quando o enlace é limitado a 10kBps. O mecanismo de estimativa
Pacotes Descartados
169
Atraso Maximo
60
MAPAS
Castro et al.
Sem agregar
MAPAS
Castro et al.
Sem agregar
50
Atraso Maximo (ms)
Pacotes Descartados (%)
150
40
30
20
100
50
10
0
0
20
40
60
80
100
20
40
60
80
100
Figura 4. Indicadores de QoS: (i) Pacotes descartados; e (ii) Atraso máximo.
Figura 5. Topologia de rede contendo um gateway comum para um conjunto de
nós.
retenção do MAPAS possibilita uma melhor gerência do tempo de retenção dos pacotes,
permitindo que estes cheguem ao destino dentro dos limites estabelecidos pela aplicação.
4.2. Segundo Cenário: Rede Multiplexada
A característica deste cenário mostra um conjunto de nós que possui um gateway comum
(o nó 9 na Figura 5). O intuito deste teste é verificar até que ponto o MAPAS consegue
garantir a temporização dado as característica de um enlace compartilhado entre vários
nós que desejam rotear seus dados através de um mesmo nó intermediário. Neste cenário,
cada um dos oito nós estão conectados a um único nó através de enlaces com capacidade
100kBps. Cada um deste nós enviará dez mil pacotes ao nó 10 em intervalos de 20ms,
totalizando 80 mil pacotes. Novamente, variamos a capacidade do último enlace, isto é,
entre os nós 9 e 10. A Tabela 2 apresenta os resultados da simulação para o caso em que
a capacidade do último enlace é fixa em 50kBps.
Como pode ser visto na Tabela 2, qualitativamente os resultados são similares
aos obtidos no primeiro cenário. Nota-se que o MAPAS permite a entrega dos dados
dentro dos limites estabelecidos pela aplicação, não gerando atrasos e evitando descarte.
Por este motivo, a vazão obtida pelo MAPAS é maior do que das outras propostas. O
mecanismo de agregação do MAPAS permite reduzir o volume de pacotes enviados, e
consequentemente, o volume de cabeçalhos e dados de controle trafegados. A redução
obtida pelo MAPAS em termos de volume de cabeçalhos corresponde a uma redução de
mais de 55% se comparado com um mecanismo convencional. O atraso ( delay) máximo
introduzido pelo MAPAS é menor que das outras propostas e está dentro dos limites de
170
Anais
Tabela 2. Resultados obtidos para o segundo cenário simulado.
Número de transmissões
Cabeçalhos enviados (bytes)
Throughput (kBps)
Overhead induzido (%)
Perda de pacotes (%)
Delay máximo (ms)
Jitter (ms)
Máximo de pacotes agregados
Média de pacotes agregados
Sem agregar
160.000
12.160.000
51,45
66,67
40,94
150
60
1
1
Castro et al.
100.000
10.400.000
57,34
63,11
40,96
150
48
4
1,33
MAPAS
31.669
6.733.454
64,04
52,55
0
145
19
16
4,44
Figura 6. Topologia hierárquica composta de 15 nós.
uma aplicação VoIP. Além disso, o MAPAS apresenta a menor variação de atraso ( jitter
) entre as propostas apresentadas.
4.3. Terceiro Cenário: Rede Hierárquica
O último cenário estudado é apresentado na Figura 6, onde a topologia tem o formato de
árvore invertida. Neste cenário, todos os enlaces possuem a mesma capacidade. O intuito
é verificar o desempenho do MAPAS em um cenário em que ele não se beneficiasse da
diferença de velocidade dos enlaces.
Nesse cenário, há 15 nós ligados de maneira hierárquica, com cada um dos nós da
base (folhas) enviando dez mil pacotes ao nó do topo (raiz). Novamente, cada pacote é
gerado a um intervalo constante de 20ms, totalizando 80 mil pacotes.
Tabela 3. Resultados obtidos para o terceiro cenário de rede simulado.
Número de transmissões
Cabeçalhos enviados (bytes)
Throughput (kBps)
Overhead induzido (%)
Perda de pacotes (%)
Delay máximo (ms)
Jitter (ms)
Máximo de pacotes agregados
Média de pacotes agregados
Sem agregar
240.000
18.240.000
99,5
66,67
15,37
150
32
1
1
Castro et al.
147.768
16.163.916
126,4
63,93
0
134
20
2,88
1,55
MAPAS
108.572
12.639.984
108,7
58,09
0
145
19
14
3,57
171
É possível perceber que em um cenário mais homogêneo com relação aos enlaces,
tanto o MAPAS quanto o método proposto [Castro et al. 2007] são eficazes. Conforme
mostra a Tabela 3, ambas as propostas entregam todos os pacotes nos tempos corretos
(atraso máximo e frequência de chegada, representada pelo jitter). Quando avaliamos os
métodos propostos em função do número de transmissões necessárias para transmitir os
dados gerados, nota-se que o MAPAS é mais eficiente, obtendo redução de aproximadamente 36%. Isso se dá pelo fato do MAPAS possuir um mecanismo mais elaborado para
reter os pacotes, permitindo assim melhores condição para a agregação. A redução no
volume de dados de controle trafegados também são menores no MAPAS.
4.4. Resultados consolidados
Figura 7. Comparativo gráfico do número de transmissões realizado em cada
cenário usando as três abordagens implementadas.
A Figura 7 apresenta os dados consolidados dos cenários apresentados anteriormente. Neste gráfico é possível comparar o número de transmissões ocorrido em cada
cenário. Nota-se que o MAPAS apresenta o menor custo de transmissão em relação as outras abordagens. Em geral, o MAPAS consegue entregar o mesmo volume de dados com
uma redução de aproximadamente 50% no volume de transmissões nos cenários avaliados. A Figura 8 apresenta o volume total dos dados trafegados (payload) e o respectivo
volume de dados de cabeçalhos (overhead) gerado para mover os dados da origem ao destino em cada cenário simulado. Lembramos que o volume de payload é igual para cada
cenário, independente da abordagem utilizada. Nota-se que o MAPAS transfere o mesmo
volume de dados das outras abordagens possibilitando realizar as transmissões com um
custo menor em termos de número de pacotes gerados.
5. Conclusões e Trabalhos Futuros
A principal contribuição deste trabalho foi propor um mecanismo de agregação de pacotes
voltado para ambientes de redes sem fio. O mecanismo proposto, denominado MAPAS,
172
Anais
Figura 8. Comparativo gráfico do volume em bytes transmitido em cada cenário
usando as três abordagens implementadas.
caracteriza-se pela utilização de estimativas de tempo para realizar a entrega dos dados
de forma a permitir a agregação dos pacotes e manter o atraso máximo dentro dos limites
da aplicação. O mecanismo de agregação proposto foi avaliado através de simulações e
os resultados comparados com mais duas propostas: o método convencional onde não há
agregação e outro método que utiliza agregação. Os resultados mostram que o MAPAS
permite uma maior agregação de dados quando comparado com outros mecanismos, em
especial em ambientes onde os enlaces não possuem as mesmas capacidades. Vale ressaltar que em ambientes reais, a capacidade do enlace sem fio pode variar por diversos
fatores, a distância entre os nós sendo uma delas.
O mecanismo proposto pelo MAPAS permite manter a variação do atraso e atraso
total dentro dos limites aceitáveis pela aplicação. Para os cenários apontados, foi possível
validar o desempenho obtido. Como os resultados foram bastante positivos, é possível ver
essa nova técnica como uma alternativa na otimização do uso de redes sem fios, em especial daquelas em que o tráfego predominante é o de aplicações de tempo real, como VoIP.
Como trabalhos futuros, pretende-se realizar uma avaliação do desempenho do MAPAS
sob a óptica da camada de enlace, tendo em vista a redução do volume de dados trafegados, o que implica diretamente no custo de bateria e contenção pelo meio. Estes dados
devem apontar para uma melhoria ainda mais significativa do MAPAS em relação a outros
mecanismos.
Referências
[Bordim et al. 2010] Bordim, J. L., Caetano, M. F., Barreto, P. S., and Barbosa, A. V. (2010).
Theoretical maximum throughput of IEEE 802.11g networks.
[Bordim et al. 2004] Bordim, J. L., Kosuga, M., Tanaka, S., Haq, M., and Matsumoto, M.
(2004). Admission control and simple class based QoS provisioning for mobile ad
173
hoc networks. In Proceedings of the IEEE 60th Vehicular Technology Conference,
volume 2, pages 1533–1548.
[Castro et al. 2007] Castro, M. C., Dely, P., Karlsson, J., and Kassler, A. (2007). Capacity
increase for voice over IP traffic through packet aggregation in wireless multihop mesh
networks. International workshop on Wireless Ad Hoc, Mesh and Sensor Networks.
[Correio Popular Online 2005] Correio Popular Online (2005). Tecnologia voip revoluciona
a comunicação nas empresas. Caderno Economia.
[IEEE 2007] IEEE (2007). Part 11: Wireless lan medium access control (mac) and physical
layer (phy) specifications. Technical report, IEEE Std 802.11.
[ITU-T 1996] ITU-T (1996). General characteristics of international telephone connections
and international telephone circuits one-way transmission time.
[Johnson et al. 2007] Johnson, D. et al. (2007). The Dynamic Source Routing Protocol
(DSR) for Mobile Ad Hoc Networks for IPv4. RFC 4728.
[Katti et al. 2006] Katti, S., Rahul, H., Hu, W., Katabi, D., Medard, M., and Crowcroft, J.
(2006). XORs in the air: Practical wireless network coding. In ACM SIGCOMM,
volume 36, pages 243–254.
[Oliveira 2007] Oliveira, C. X. (2007). Implantação de um laboratório de voz sobre ip na
unb. Monografia de Graduação em Ciência da Computação na Universidade de Brasília.
[Página do Codec iLBC 2010] Página do Codec iLBC (2010). www.ilbcfreeware.
org.
[Petrović et al. 2003] Petrović, D., Shah, R. C., Ramchandran, K., and Rabaey, J. (2003).
Data funneling: Routing with aggregation and compression for wireless sensor
networks. In ICC 2003 International Conference on Communications, pages 156–162.
[Raghavendra et al. 2006] Raghavendra, R., Jardosh, A. P., Belding-Royer, E. M., and
Zheng, H. (2006). IPAC: IP-based adaptive packet concatenation for multihop wireless networks. In 40th Asilomar conference on signals, systems and computers, pages
2147–2153.
174
Anais
175
Índice por Autor
A
Alberti, A. M. ...................................115
Andrade, N. ........................................47
Andrade, R. M. C. ..............................87
B
Bordim, J. L. .....................................161
C
Caetano, M. F. ..................................161
Castro, G. de G. C. .............................57
D
de Almeida, H. O. .............................131
de Bona, L. C. E. ................................31
de Lima, F. M. ....................................17
de Oliveira, C. T. ................................87
de Sales, L. M. ..................................131
Doria, S. ....................................101, 147
F
Figueiredo, D. R. ................................71
Filho, P. H. A. ...................................161
G
Gomes, R. L. .........................................3
J
Junior, E. P. D. ................................... 31
K
Klachquin, A. ..................................... 71
M
Manola, R. ........................................... 3
Marcondes, C. ...................................... 3
Marques-Neto, H. T. .......................... 57
Martinello, M. ...................................... 3
Martins, B. M. .................................. 115
Mateus, B. G. ..................................... 87
P
Perkusich, A. .................................... 131
R
Ruoso, V. K. ...................................... 31
S
Santana, J. .......................................... 47
Silva, R. A........................................ 131
Spohn, M. A. ............................ 101, 147
Sztajnberg, A. .................................... 17
ISSN 2177-496X
9 772177 496009
Patrocínios:

VII Workshop de Redes Dinâmicas e Sistemas - SBRC 2011

Transcription

Similar documents

A computação a serviço da cidadania: o Hotline

Estudo das Vulnerabilidades da Arquitetura BitTorrent, Ataques e

Curvas e superfıcies implıcitas: noç ˜oes de geometrias diferencial e

Ediç˜ao tridimensional de fotografias arquitetônicas

manual do lingo

Reticulados, Projeç˜oes e Aplicaç˜oes

Manual Caixa Mágica 14

Introdução aos Sistemas Dinâmicos

Manual de utilizador

Cálculo e estimaç ˜ao de invariantes geométricos