tvoip: tv sobre ip arquiteturas para transmissão em …celio/papers/minicurso-sbrc06.pdf · célio...

50
Capítulo 3 TVoIP: TV sobre IP Arquiteturas para Transmissão em Larga Escala Célio Albuquerque, Tiago Proença e Etienne Oliveira Instituto de Computação – Universidade Federal Fluminense (IC-UFF) Niterói – RJ 24.210-240 – Brasil {celio,tproenca,eoliveira}@ic.uff.br Abstract Services for video content distribution over the Internet, live and on-demand, are increasing in popularity with the dissemination of broadband access networks. This work identifies two ortho- gonal approaches to the great challenge of delivering television content over IP networks in a scalable manner. Commercial initiatives towards supporting television content over IP networks are currently under deployment, motivated mainly by emerging convergent multimedia networks. Commercial IPTV is typically based on a private IP network and makes use of multicast trans- mission techniques with the goal of delivering a service with quality equivalent to conventional broadcast TV. However, the commercial IPTV has limited coverage, in conformity with the extent of its private IP network. On the other hand, other initiatives have been proposed aiming to de- ploy a service with global coverage and using the infrastructure of the Internet. The basic idea is to take advantage of the user’s idle resources, in order to form a cooperative environment for TV distribution. The great challenge of the cooperative IPTV is to guarantee the quality of the service and to provide incentive mechanisms for cooperation. This work presents architectures for video distribution in large scale over the Internet. It will be discussed the state-of-art of current approaches and it will be presented new distribution proposals capable of providing sustainability for a TV over IP service on the Internet, including solutions based on application level multicast such as content distribution networks, multi-paths, pseudo-servers and peer-to-peer. Resumo Os serviços de distribuição de conteúdo televisivo na Internet tanto ao vivo como sob demanda estão ganhando cada vez mais popularidade com a disseminação das redes de acesso em banda larga. Este minicurso identifica duas vertentes ortogonais para o grande desafio de realizar a entrega de um serviço escalável de distribuição de TV sobre redes IP. Iniciativas comerciais de

Upload: vannguyet

Post on 13-Sep-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

Capítulo

3TVoIP: TV sobre IPArquiteturas para Transmissão em Larga Escala

Célio Albuquerque, Tiago Proença e Etienne OliveiraInstituto de Computação – Universidade Federal Fluminense (IC-UFF)Niterói – RJ 24.210-240 – Brasil

{celio,tproenca,eoliveira}@ic.uff.br

Abstract

Services for video content distribution over the Internet, live and on-demand, are increasing inpopularity with the dissemination of broadband access networks. This work identifies two ortho-gonal approaches to the great challenge of delivering television content over IP networks in ascalable manner. Commercial initiatives towards supporting television content over IP networksare currently under deployment, motivated mainly by emerging convergent multimedia networks.Commercial IPTV is typically based on a private IP network and makes use of multicast trans-mission techniques with the goal of delivering a service with quality equivalent to conventionalbroadcast TV. However, the commercial IPTV has limited coverage, in conformity with the extentof its private IP network. On the other hand, other initiatives have been proposed aiming to de-ploy a service with global coverage and using the infrastructure of the Internet. The basic ideais to take advantage of the user’s idle resources, in order to form a cooperative environment forTV distribution. The great challenge of the cooperative IPTV is to guarantee the quality of theservice and to provide incentive mechanisms for cooperation. This work presents architectures forvideo distribution in large scale over the Internet. It will be discussed the state-of-art of currentapproaches and it will be presented new distribution proposals capable of providing sustainabilityfor a TV over IP service on the Internet, including solutions based on application level multicastsuch as content distribution networks, multi-paths, pseudo-servers and peer-to-peer.

Resumo

Os serviços de distribuição de conteúdo televisivo na Internet tanto ao vivo como sob demandaestão ganhando cada vez mais popularidade com a disseminação das redes de acesso em bandalarga. Este minicurso identifica duas vertentes ortogonais para o grande desafio de realizar aentrega de um serviço escalável de distribuição de TV sobre redes IP. Iniciativas comerciais de

transmissão de conteúdo televisivo sobre redes IP têm surgido, impulsionadas principalmente pelosurgimento das redes convergentes. O IPTV comercial é baseado em uma arquitetura IP privada,faz uso de técnicas de transmissão em multicast e objetiva fornecer um serviço com qualidadeequivalente ao prestado pela TV convencional. No entanto, o IPTV comercial possui abrangêncialimitada, de acordo com o alcance da rede privada. Em contrapartida, outras iniciativas vêmsendo propostas visando fornecer um serviço de alcance global e utilizando a infra-estrutura daInternet. A idéia básica é utilizar os recursos ociosos dos usuários, de modo a formar um ambientecooperativo para distribuição de TV. O grande desafio do IPTV cooperativo é garantir a qualidadedo serviço e prover mecanismos de incentivo a cooperação. Este minicurso apresenta algumasarquiteturas para distribuição de vídeo em larga escala na Internet. É abordado o estado daarte das tecnologias atuais e são apresentadas novas propostas de distribuição capazes de proversustentabilidade para um serviço de TV sobre IP na Internet, descrevendo soluções baseadas emmulticast em nível de aplicação como redes de distribuição de conteúdo, multi-caminhos, pseudo-servidores e peer-to-peer.

3.1. IntroduçãoA intensa evolução das tecnologias de comunicação possibilitou o acesso em banda larga à últimamilha, criando um leque de oportunidades para provedores e distribuidores de conteúdo. Entreestas ofertas, podemos citar serviços como acesso à Internet, transmissão de voz, transmissão desinais de TV, entre outras.

O serviço de acesso à Internet em banda larga possibilitou a realização de jogos em 3Dem tempo real, acesso a bibliotecas virtuais e a outros serviços que demandam recursos de co-municação mais exigentes. Empresas de telecomunicações em todo o mundo estão investindo eminfraestrutura, substituindo os cabos metálicos por cabos de fibra ótica, de forma a possibilitara oferta de acessos em banda larga com velocidade bem superior a atual, conforme poderá serobservado na Tabela 3.1 da Seção 3.2.4.

O serviço de transmissão de voz sobre rede de dados banda larga, denominado Voice overIP (VoIP), vem sendo explorado por inúmeras empresas e ofertado tanto para usuários residenciaisquanto para usuários corporativos. Como a qualidade do serviço de VoIP assemelha-se bastanteao serviço prestado pelas operadoras de telefonia fixa tradicionais, a expectativa do mercado é defranca expansão. Entre as empresas autorizadas pela Anatel para prestar o serviço de VoIP pode-mos citar a Brasil Telecom, Primeira Escolha, Transit Telecom e a GVT, que oferecem serviçosdenominados respectivamente como VoipFone, VoiceLine, ViaVoIP e SkypeIn, Vono.

Já o serviço de transmissão de sinais de TV sobre redes de dados banda larga denominadoneste trabalho de forma genérica e abrangente como Television over IP (TVoIP), ainda não éofertado com a mesma qualidade e abrangência que o serviço prestado pela TV convencional.Desta forma, novas arquiteturas que sejam capazes de prover qualidade de serviço vêm sendopropostas, objetivando a garantia de requisitos de comunicação, a comunicação multidestinatáriae uma maior abrangência. Algumas destas novas propostas serão detalhadas na Seção 3.3.

O conjunto de serviços de acesso à Internet em banda larga, telefonia via redes IP e vídeointerativo através de um único canal de comunicação e por um único provedor é denominado tripleplay. As principais operadoras de serviços tais como operadoras de TV a cabo, distribuidoras deenergia elétrica, operadoras de telefonia fixa e operadoras espelho de telefonia fixa estão atentas aessa nova oportunidade que surge no mercado e espera-se que, em breve, possam estar ofertandoo serviço triple play aos assinantes.

A oferta de triple play é mais uma oportunidade de negócios para as operadoras, possi-

bilitando a fidelização de clientes residenciais através de pacotes com multiplicidade de serviços.As operadoras que tiverem capacidade de oferecer serviços triple play terão, provavelmente, umafatia maior deste cobiçado mercado.

A chegada do serviço de transmissão de voz sobre redes de dados (VoIP) criou uma re-viravolta no modelo de negócios existente. O impacto foi tão grande que algumas empresas detelefonia fixa, que também atuam como fornecedoras de acesso em banda larga, chegaram a blo-quear, em seu backbone, o tráfego proveniente de protocolos utilizados para transmissão de vozsobre rede de dados. Embora esta atitude tenha sido tomada, empresas provedoras de serviçosde VoIP, tais como Skype, prosperaram e hoje compõem uma fatia considerável do mercado. Re-centemente a Skype anunciou uma parceria com a operadora brasileira de telefonia fixa TransitTelecom, que opera no STFC (Sistema de Telefonia Fixa Comutada),e juntas passaram a oferecer,através do software SkypeIn, o serviço de recebimento de ligações por um telefone convencionalcom fornecimento de uma numeração exclusiva.

Da mesma forma que o VoIP provocou uma mudança no modelo de negócios de tele-fonia, espera-se que este processo se repita sob a ótica do sistema televisivo, impulsionado peloamadurecimento do IPTV.

Atualmente, o fornecimento deste tipo de serviço comercialmente conta com algumaslimitações. Uma delas, é que a maioria dos serviços de TV sobre IP são oferecidos sobre um back-bone proprietário. Este fato deve-se a capacidade parcial ou, dependendo da região, a incapacidadetotal da Internet atual de prover qualidade de serviço e de lidar com tráfego multicast de formaescalável. No entanto, através de redes privadas e de porte menor para distribuição comercial deconteúdo de TV, é possível garantir qualidade de serviço e ter suporte a tráfego multicast de formaeficiente.

Novas abordagens vêm sendo propostas para resolver o problema de escalabilidade da ar-quitetura IPTV comercial, procurando fornecer um serviço de alcance global e utilizando a infra-estrutura da Internet, ao invés de redes privadas. A idéia básica é utilizar os recursos ociosos nosnós clientes, de modo a formar um ambiente totalmente cooperativo. No entanto, estas aborda-gens baseadas em IPTV cooperativo possuem várias limitações, sendo uma delas a dificuldade defornecer qualidade de serviço ao mecanismo e de se ter um modelo de cobrança pelo serviço.

O objetivo principal deste minicurso é explorar arquiteturas de distribuição de vídeo emlarga escala na Internet. Será abordado o estado da arte das tecnologias atuais e serão apresentadasnovas propostas de distribuição capazes de prover sustentabilidade para um serviço de TV sobreIP na Internet, descrevendo em detalhes soluções baseadas em multicast em nível de aplicaçãocomo redes de distribuição de conteúdo, multi-caminhos, pseudo-servidores e peer-to-peer. Apartir do modelo de distribuição de vídeo utilizado nas tecnologias atuais, serão destacados osproblemas específicos existentes e a discussão de alguns novos modelos para solucioná-los. Porfim, propostas para otimização desses modelos serão expostas.

O perfil desejado para o público deste minicurso são alunos de graduação, mestrado e dou-torado que estejam pesquisando ou tenham intenção de iniciar pesquisas nas áreas de distribuiçãode TV Digital e de conteúdo multimídia via Internet.

Este trabalho está organizado como segue. A Seção 3.2 apresenta o estado da arte dastecnologias atuais e apresenta algumas soluções IPTV comerciais. A Seção 3.3 apresenta algumasalternativas para distribuição de TV via Internet. A Seção 3.4 apresenta algumas técnicas paraotimização das propostas. Por fim, a Seção 3.5 tece as considerações finais e apresenta futurasdireções que podem ser tomadas pelo serviço de distribuição de TV em redes IP.

3.1.1. Modelo de Negócios

O modelo de negócios instalado atualmente para as empresas de TV aberta associa os processosde produção e distribuição de conteúdo. Já para algumas empresas de TV por assinatura, deve-seagregar a necessidade de construção de redes cabeadas para distribuição do conteúdo.

Em um novo modelo de negócios, a responsabilidade pelas etapas de produção de con-teúdo, distribuição de conteúdo e infraestrutura seria distribuída entre empresas parceiras, per-mitindo a dedicação exclusiva à atividade fim. A possibilidade de distribuição de canais de TVatravés de redes IP ratifica a necessidade do surgimento de um novo modelo de negócios.

Uma empresa dedicada a prover infraestrutura para distribuição de conteúdo poderia ofer-tar seus serviços a mais de uma produtora de conteúdo, permitindo o compartilhamento dos recur-sos e, provavelmente, reduzindo custos e aumentando a capilaridade. A partir da implementaçãodeste modelo, com o processo de veiculação simplificado e com custo reduzido, novas e antigasprodutoras de conteúdo poderiam investir em produtos nacionais e, com isso, ofertá-los a umaparcela da população que hoje não compreende e, conseqüentemente, não se interessa pelos pro-gramas importados oferecidos pela maioria dos canais das empresas de TV por assinatura. Estamudança de paradigma seria suficiente para a criação de um novo nicho de mercado, permitindo aregionalização de programas ofertados.

Especificamente em relação a IPTV, o cliente pode estar em qualquer continente e aindareceber uma programação personalizada, além de outras funções ainda indisponíveis na TV tradi-cional, como canais interativos, programação sob demanda, gravação de programas, publicidadeindividualizada, entre outras.

3.1.2. Abrangência Global

O modelo de distribuição de sinais das emissoras de TV aberta determina uma banda passante fixa,um tipo de receptor e limita a área de abrangência do sinal transmitido. A maior restrição impostaé justamente a limitação do espectro de freqüência destinado a cada emissora para transmissãoanalógica, o que impede a oferta simultânea de vários programas de uma mesma emissora. Aárea de abrangência fica limitada à área coberta pelas retransmissoras e afiliadas da emissora,tipicamente restrita a alguns municípios. A abrangência nacional é atingida com a utilização desatélites, que requerem receptores específicos e de custo superior aos receptores utilizados porsistemas de radiodifusão.

Para as emissoras de TV por assinatura o espectro de freqüência não pode ser consideradocomo uma limitação, em função, principalmente, da digitalização dos programas transmitidos,possibilitando a recepção de vários canais simultaneamente. Com o emprego de codificação nosinal distribuído, torna-se necessária a utilização de receptores fornecidos pela própria emissorade TV por assinatura.

Já no caso de distribuição de sinais de vídeo através da tecnologia de TVoIP não existe li-mitação em relação à abrangência. Por ter os sinais distribuídos através da Internet, a digitalizaçãotorna-se obrigatória e o alcance global, possibilitando o recebimento de programação de qualqueremissora e de qualquer nação.

3.1.3. Escalabilidade

O modelo de radiodifusão utilizado por emissoras de TV aberta é capaz de alcançar praticamentetodos os domicílios na sua área de alcance, embora seja fundamental a existência de repetidoras,de forma a ampliar a área de abrangência.

As emissoras de TV por assinatura que optarem por disseminar o sinal através de satélitenão devem ter problema de escalabilidade. Já as que optaram por construir uma rede cabeada,certamente vêm enfrentando este problema, devido à dificuldade de levar até o assinante a infra-estrutura mínima necessária ao recebimento do sinal.

O modelo de distribuição de sinais proposto para a TVoIP deve tratar da questão da esca-labilidade com muita cautela. Como o meio de comunicação (Internet) entre a difusora do sinale o assinante é compartilhado por inúmeras outras aplicações, deve haver, necessariamente, ummodelo que mantenha a estabilidade da rede, principalmente em função da grande quantidade detráfego gerado pela transmissão de programas televisivos que requerem características especiais.A manutenção da qualidade do sinal também pode ser afetada caso haja comprometimento da redeem função de dimensionamento incorreto.

3.1.4. Interatividade

A capacidade de um dispositivo interagir ou permitir interação com o seu respectivo usuário é de-nominada Interatividade. A existência de interatividade está estritamente relacionada à existênciade um meio eletrônico, intermediando a interação. De acordo com [38], é possível classificar oconceito de interatividade em três níveis de abrangência:

• Interatividade com o conjunto televisivo: Nesse nível a interatividade está restrita ao uso docontrole remoto, permitindo a troca de canais e o avanço, o retrocesso e a pausa de imagensno vídeo-cassete. O telespectador, neste nível, não pode alterar o conteúdo, apenas a formacomo o mesmo é visto.

• Interatividade com o conteúdo do programa da televisão: Nesse nível a interatividade éplena e representa o maior desafio para os produtores. Nesta visão, o telespectador podecontrolar o conteúdo do programa que está assistindo, assim como é capaz de controlar aprogramação que gostaria de assistir.

• Interatividade com o conteúdo que encontra-se na televisão: Também chamado de coativo,este nível contém as mesmas características que o nível anterior e, ainda, funcionalidadesque mudarão radicalmente a forma como assistimos televisão pelas próximas décadas. Ob-ter informações a qualquer momento sobre as condições climáticas, esportes, programação,notícias das emissoras, etc, assim como obter informações detalhadas a cerca dos produtosanunciados e poder comprá-los.

Lemos, em [24] classifica a interatividade em relação à televisão em cinco níveis distintos,conforme pode ser observado a seguir:

• Nível 0: este é o nível mais baixo de interatividade, sendo possível ao telespectador atroca de canal, a regulagem de volume, o ajuste de contraste e brilho ou ligar ou desligaro aparelho de televisão. A transmissão ainda ocorre em preto e branco, com apenas um oudois canais.

• Nível 1: Surge então a televisão colorida e outras emissoras. O controle remoto vem suprira demanda de conforto requerida pela possibilidade de navegar entre os inúmeros canaisdisponíveis, assim como efetuar ajustes na forma como a programação é assistida. Essanavegação, também chamada de zapping, é considerada a precursora da navegação da web(World Wild Web).

• Nível 2: O aparelho de televisão passa a poder ser utilizado para outros fins, não apenas paraassistir os programas transmitidos pelas emissoras de televisão. Jogos eletrônicos, vídeos-cassete e câmeras portáteis permitem que o usuário se aproprie da televisão para jogar ousimplesmente assistir a filmagens previamente gravadas. O vídeo-cassete ainda permite queo usuário possa se apropriar dos programas transmitidos pelas emissoras, podendo gravá-lose assistí-los quando bem desejar.

• Nível 3: Os primeiros sinais de interatividade digital surgem neste nível, onde o telespecta-dor pode interferir no conteúdo da programação através de fax, telefone ou mensagens decorreio eletrônico (e-mail). Programas como BigBrother, Intercine e Você Decide da RedeGlobo, Casa dos Artistas do SBT e outros similares encontram-se classificados neste nível.

• Nível 4: Neste nível surge a TV interativa, possibilitando que o telespectador possa utilizaro controle remoto e interferir na programação, selecionando cenas ou ângulos de câme-ras que lhe convém. O canal SportTV Premiere oferece este recurso, conforme pode serobservado na Figura 3.1 .

Figura 3.1. Seleção de cenas e ângulos (Fonte: [5])

Existem, ainda, mais três níveis complementares propostos em [6] que possibilitam ao te-lespectador interferir plenamente na programação e não apenas reagir aos programas transmitidospelas emissoras.

• Nível 5: Neste nível o próprio telespectador pode participar da programação, enviandovídeos de baixa qualidade, produzidos através de web cam ou filmadoras analógicas. Surge,neste nível, a necessidade de um canal de retorno ou canal de interação que seja capaz deprover recursos para a transmissão do vídeo do telespectador para a emissora.

• Nível 6: O nível 6 oferece os mesmos recursos que o nível 5, entretanto permite a trans-missão de vídeos de alta qualidade. O canal de retorno ou canal de interatividade deve,obrigatoriamente, dispor de banda superior à oferecida no nível 5.

• Nível 7: Neste nível o telespectador alcança a interatividade plena, gerando conteúdo damesma forma que a emissora. Neste modelo, o telespectador rompe o monopólio de produ-ção e veiculação das redes de televisão e passa a atuar como se fosse um internauta na web,com capacidade e recursos necessários à publicação de sites com o conteúdo que desejar.

No caso de emissoras que façam uso de radiodifusão torna-se necessário o uso de umatecnologia alternativa para implementação de um canal de retorno, também conhecido por canalde interatividade, de forma que o telespectador possa se comunicar com a emissora.

As emissoras que mantêm uma infraestrutura para distribuição do sinal através de redecabeada têm a possibilidade de utilizar este meio de comunicação para prover o canal de interati-vidade, ainda que seja necessário adicionar algum equipamento no domicílio do assinante.

O modelo de distribuição de sinais de vídeo através de TVoIP fornece, automaticamente,a infraestrutura necessária ao canal de interatividade através do acesso em banda larga.

3.2. Estado da ArteA distribuição de canais de TV na Internet é um fenômeno relativamente recente. No entanto,diversos usuários já experimentaram algum tipo de conteúdo televisivo na Internet, principalmenteatravés de fluxos de vídeos disponibilizados em páginas web de notícias, de jornais e de canais deTV tradicionais. Devido a facilidade de distribuição de vídeo via Internet, recentemente um grandenúmero de emissoras de TV de pequeno porte vêm disponibilizando conteúdo na rede. Portaiscomo http://broadband-television.com, http://wwitv.com e http://broadcast-live.com permitem oacesso ao conteúdo de centenas de emissoras de TV espalhadas por todo o mundo, sendo quealgumas delas oferecem conteúdo ao vivo em unicast e apenas uma minoria oferece distribuiçãopara grupos via IP multicast.

Esta seção tem por objetivo apresentar o estado da arte das tecnologias atuais e levantaralgumas das limitações existentes nestas tecnologias. Serão apresentados as arquiteturas paradistribuição de vídeo Download-and-play, Streaming e IP Multicast e alguns sistemas comerciaisde IPTV em funcionamento nos EUA, Itália e França.

3.2.1. Cliente-servidor: Download-and-play

Arquiteturas Download-and-play possibilitam o envio de arquivos multimídia sob demanda, nor-malmente através dos protocolos http e ftp ou através de redes Peer-to-peer (P2P). O envio dearquivos de áudio e vídeo é tratado com a mesma simplicidade que se envia, por exemplo, ar-quivos de texto ou imagens, ou seja, essas aplicações não requerem características especiais emrelação ao atraso na rede e à variação dos atrasos (jitter). Fica, então, a cargo do protocolo contro-lar apenas as perdas ocasionais e efetuar as solicitações de retransmissão.

O processo de download de um arquivo multimídia deve ser concluído antes que o mesmopossa ser visualizado, logo o atraso inserido neste processo varia de acordo com o tamanho doarquivo solicitado.

No momento da reprodução do arquivo, o usuário passar a ter controle completo, podendoparar ou pausar a reprodução e retroceder ou avançar até uma determinada parte. A Figura 3.2apresenta a arquitetura Cliente-Servidor: Download-and-play.

3.2.2. Cliente-servidor: Streaming

Diferentemente da arquitetura Download-and-play, a arquitetura Streaming possibilita a apresen-tação do arquivo solicitado à medida que o mesmo é recebido, evitando a necessidade de efetuar

Figura 3.2. Arquitetura Cliente-Servidor: Download-and-play

o download completo do arquivo antes de iniciar a reprodução do mesmo. Para que isso seja pos-sível, o servidor web deve enviar um meta-arquivo ao navegador (browser) do cliente, contendoinformações a cerca dos recursos necessários à reprodução do objeto solicitado. O navegador,após analisar o conteúdo do meta-arquivo, identifica a aplicação reprodutora associada e repassaas informações recebidas. Cabe, então, à aplicação reprodutora exibir o conteúdo solicitado.

A arquitetura Streaming permite, através de redes IP, que qualquer cliente possa receberuma programação de áudio e/ou vídeo, da mesma forma como é possível recepcionar os sinaistransmitidos por emissoras de rádio ou de TV nos respectivos receptores. Deve-se, entretanto, res-saltar que, na arquitetura Streaming, em função da mídia solicitada ser decodificada e reproduzidaà medida que a mesma é recebida, as aplicações são altamente sensíveis ao atraso e à variação dosatrasos, ao ponto que um atraso na ordem de algumas centenas de milissegundos pode ser sufici-ente para que uma determinada aplicação descarte a mensagem. Contudo, aplicações multimídiasão tolerantes a perdas ocasionais, que podem causar apenas ruídos, muitas vezes imperceptíveisno processo de reprodução.

No momento da reprodução do arquivo, o usuário não tem o controle completo, e con-seqüentemente, não pode pular partes ou avançar até uma determinada parte. Contudo, em algu-mas aplicações, as funções de pausa e retrocesso podem estar habilitadas. Deve-se destacar que,embora a utilização de técnicas de multicasting seja apropriada para este tipo de tráfego, atual-mente a maioria das transmissões ocorre através de vários fluxos unicast. A Figura 3.3 apresentaa arquitetura Cliente-Servidor: Streaming.

Figura 3.3. Arquitetura Cliente-Servidor: Streaming

3.2.3. IP Multicast

Há muitos anos que inúmeros cientistas e pesquisadores vêm buscando alternativas viáveis comintuito de resolver definitivamente o problema de escalabilidade de um serviço de transmissãode mídia na Internet. O IP Multicast foi proposto para melhorar a eficiência na comunicação deum-para-muitos e muitos-para-muitos na Internet. No IP Multicast os dados só passam por umenlace de comunicação uma única vez e são replicados nos roteadores para os clientes que desejamreceber o conteúdo. Esta arquitetura fornece a robustez necessária para prover a escalabilidade queos usuários de serviços multimídia requerem atualmente na Internet.

Em 1992, foi criada a Mbone (Internet Multicast Backbone), uma rede experimental, com-posta de inúmeras sub-redes, com capacidade de transmitir tráfego IP Multicast sobre uma redeIP de melhor-esforço. O Mbone não é geralmente conectado aos ISPs mas é freqüentementeconectado a universidades e instituições de pesquisa. Seu principal uso é para aplicações de vi-deoconferência e de trabalho cooperativo. No entanto, outros projetos recentes como o da redeInternet2’s Abilene Network [31] e o IPv6 fizeram com que o MBone se tornasse obsoleto.

Os principais algoritmos de roteamento da arquitetura IP Multicast baseiam-se na constru-ção de árvores de roteamento, que podem ser compartilhadas pelo grupo ou baseadas no servidorde mídia de origem. Como exemplo podemos citar os protocolos DVMRP [47] (Distance VectorMulticast Routing Protocol), PIM [14] (Protocol Independent Multicast), MOSPF [29] (Multi-cast Open Shortest Path First Protocol), IGMP [8] (Internet Group Management Protocol), entreoutros.

3.2.4. Sistemas Comerciais

A emergente demanda por serviços multimídia vem impulsionando a oferta de redes convergentes,também conhecidas por redes triple-play, que são na verdade redes capazes de suportar voz, dadose vídeo.

Esta nova geração de redes permite também o surgimento de novas aplicações, aumen-tando o leque de ofertas por parte de provedores de serviço e de conteúdo, e também possibilitandomais conforto e opções aos assinantes.

O serviço de TV por assinatura através de redes IP (IPTV), admite novas funcionalidadescomo Personal Video Recorder (PVR), Video over Demand (VoD), Video Podcasting, interati-vidade, comércio televisivo (t-commerce), governo televisivo (t-government), ensino televisivo(t-learning), acesso ao sistema bancário (t-banking), entre outras. Através de um dispositivo de-nominado set-top box, a gravação de programas (PVR) ou a aquisição de vídeos sob demanda(VoD) deixa de ser ficção e torna-se realidade.

O serviço de voz sobre redes IP (VoIP) possibilita a redução de custo nas ligações te-lefônicas e ainda oferece vantagens adicionais como conferência, email de voz, mobilidade, entreoutras. Além dos serviços descritos, a realização de jogos ao vivo e a integração com o sistema detelefonia celular são também algumas das funcionalidades deste novo ambiente.

O ADSL (Asymmetric Digital Subscriber Line) vem se destacando entre as tecnologiasatualmente disponíveis para redes de acesso banda larga, embora existam investimentos e expec-tativas que as tecnologias baseadas em cable modem, WLAN (Wireless Local Area Network),PLC (Power Line Communication), WiMax e FTTH (Fiber To The Home) possam se tornar umaalternativa viável. A Tabela 3.1 apresenta as várias alternativas disponíveis baseadas no padrãoxDSL.

Tabela 3.1. Tecnologia DSL (Fonte: [15])

Padrão ITU Ratificada Taxa de Upload Taxa de DownloadADSL G.992.1 1999 800 Kbps 7 Mbps

ADSL2 G.992.3 e G.992.4 2002 1 Mbps 8 MbpsADSL2+ G.992.5 2003 1 Mbps 24 Mbps

ADSL2-RE G.992.3 2003 1 Mbps 8 MbpsSHDSL G.991.3 2003 5,6 Mbps 5,6 MbpsVDSL G.993.1 2004 15 Mbps 55 Mbps

VDSL2 - 12 Mhz G.993.2 2005 30 Mbps 55 MbpsVDSL2 - 12 Mhz G.993.2 2005 100 Mbps 100 Mbps

As subseções seguintes apresentam soluções propostas para uma rede metropolitana deacesso, a solução Microsoft para IPTV, além de uma breve descrição de empresas que ofertam esteserviço.

3.2.4.1. Rede de Acesso

Um dos principais desafios para as operadoras é definir uma topologia para rede de acesso quepossibilite a oferta de serviços triple play e garanta os requisitos necessários para cada aplicação.Entre as principais alternativas, surgem topologias baseadas em ATM (Asynchronous TransferMode) e Ethernet.

Figura 3.4. Rede de Acesso baseada em Metro Ethernet

A Figura 3.4 exemplifica uma alternativa, baseada na tecnologia Metro Ethernet. Nestaalternativa, alguns dispositivos têm funções específicas, tais como:

• DSLAM: O dispositivo Digital Subscriber Line Access Multiplexer recebe sinais transmi-tidos pelas múltiplas conexões dos assinantes do serviço DSL (Digital Subscriber Line) eos encaminha através de uma rede de alta velocidade utilizando técnicas de multiplexação.Embora atue na camada de enlace, alguns DSLAMs além de possibilitar a classificação detráfego em VLANs (Virtual Local Area Network), suportam requisitos de QoS (Quality ofService), como diffserv e filas de prioridade, e ainda possuem habilidade para filtrar pacotes.

Dependendo do fabricante do produto, o DSLAM pode se conectar a um backbone atravésde redes ATM, Frame Relay ou Gigabit Ethernet.

• Splitter: Este dispositivo possibilita a separação entre a freqüência destinada à voz, atra-vés de um aparelho telefônico convencional conectado a uma PSTN (Public Switched Te-lephone Network), e a freqüência destinada aos dados, que podem incluir voz e vídeo.A tarefa do splitter é relativamente simples, pois as operadoras de telefonia fixa utilizamfreqüências baixas e bem definidas, tipicamente entre 300 Hz e 4000 Hz, facilitando o tra-balho de separação. A Figura 3.5 apresenta um exemplo de distribuição de freqüência.

• BRAS: O dispositivo Broadband Remote Access Server encaminha o tráfego provenientee destinado ao dispositivo DSLAM à rede IP da operadora. A gerência das políticas deutilização, assim como dos parâmetros referentes à qualidade de serviço, são algumas dasfunções inerentes ao dispositivo BRAS. Além disso, cabe ao BRAS prover as sessões PPPdos assinantes sobre redes IP ou ATM.

Figura 3.5. Linha Telefônica

O DSLAM tem uma função primordial na topologia apresentada, pois como este equipa-mento encontra-se posicionado no ponto de troca de dados entre a operadora e a rede de últimamilha, ele pode ser utilizado como concentrador de tráfego. Desta forma, caso o DSLAM estejaassociado à tecnologia de IP Multicast no backbone da operadora, ele será capaz de reduzir sig-nificativamente o tráfego no backbone, possibilitando o envio de um único fluxo de dados paracada canal veiculado. A quantidade de canais que podem ser veiculados passa a depender exclu-sivamente da capacidade do backbone. Do DSLAM para o assinante, a transmissão ocorre emunicast.

3.2.4.2. Microsoft TV IPTV Edition

Conforme [27], a Microsoft desenvolveu uma solução integrada, denominada Microsoft TV IPTVEdition, capaz de prover todas as funcionalidades necessárias ao transporte de sinais de canaisdigitalizados para uso por provedoras de conteúdo de TV. Entre as inúmeras funcionalidades,podemos citar algumas, tais como:

• O Guia de Programação Multimídia (Multime-dia Program Guide), comumente denominado deEPG (Electronic Program Guide), provê informa-ções sobre a programação das emissoras, sobredisponibilidade de conteúdos sob demanda, fun-ções de pesquisa, PIP (Picture in Picture), etc;

• A tecnologia proprietária Fast Channel Surfing,desenvolvida pela Microsoft, promete eliminarcom o atraso indesejável que é inserido no pro-cesso de troca de canais em transmissões digitais.Além disso, funções como a distribuição de vídeosob demanda (VoD), incluindo vídeos em HDTV(High Definition Television) e gravação de vídeos(PVR) encontram-se disponíveis nesta solução;

• A tecnologia de compressão de dados utilizadapelo Microsoft Windows Media R© 9 Series possi-bilita a transmissão de sinais de vídeo no padrãoSDTV (Standard Definition Television) com taxavariando de 1,5 Mbps a 1,8 Mbps e no padrãoHDTV com taxa variando entre 7 Mbps e 9 Mbps.De acordo com o fabricante, estas taxas ocupammenos da metade da banda necessária à transmis-são de sinais de vídeo com compressão MPEG-2;

• A proteção contra cópia ou pirataria é garantida através do Microsoft Digital RightsManagement 9 Series, que possibilita a distribuição de vídeos através de uma pla-taforma segura e, ainda, oferece uma oportunidade para que os assinantes possamadquirir conteúdo diferenciado;

• A comunicação entre a operadora e o assinante éfacilitada com a implementação de novas funcio-nalidades, como a identificação do assinante atra-vés do caller id, o envio de mensagens instantâ-neas, e-mail, SMS na televisão e outras. A ope-radora pode, desta forma, informar ao assinante,instantaneamente, qualquer mudança que ocorrana grade de programação.

• A solução Microsoft TV IPTV Edition possibilita, a integração de sistemas de trans-missão de vídeo com serviços de voz e dados, através de uma única arquitetura derede, simplificando e reduzindo os custos para as provedoras de serviço.

Figura 3.6. Solução Microsoft para IPTV (Fonte: [23])

A Figura 3.6 destaca, de forma simplificada, a topologia proposta pela Microsoft, como Microsoft Windows Media 9 Series efetuando a codificação do sinal, o Microsoft IPTV ServerFamily (SQL Server, Biztalk R© Server, Operations Support Services, Business Support Services,etc) integrando as funcionalidades e distribuindo os vídeos para o backbone da operadora e, porfim, o set-top box com Microsoft IPTV Client e o sistema operacional Microsoft Windows CE.

3.2.4.3. FastWeb e RAI Click (Itália)

Como na Itália praticamente não existe operadora de TV a cabo, a Fastweb [16], operada pelae.Biscom, encontrou um mercado sem competidores para distribuição de vídeos através de IPTV,acesso a Internet e VoIP, sendo a primeira operadora a ofertar o serviço triple play.

Em Milan, a maior cidade italiana, a tecnologia FTTH está disponível em praticamente100% das residências, o que favorece a oferta de inúmeros serviços, incluindo a oferta de tripleplay. No caso da operadora Fastweb, a ligação telefônica entre clientes é gratuita e, para as resi-dências atendidas por FTTH, a conexão a Internet é disponibilizada através de acesso de 10 Mbps.A transmissão de sinais das operadoras de TV consome 4 Mbps e encontram-se disponíveis opera-doras locais (RAI, Mediaset, MTV, La7, etc), operadoras internacionais (Bloomberg, BBC World,Disney, CNN, Carton Network, etc) e ainda existem opções de canais por assinatura (Cinema Sky,Sport Sky, etc).

Figura 3.7. Malha de Rede - Operadora Fastweb (Fonte: [16])

O serviço de IPTV na Itália surgiu com a operadora RAI Click, resultado de uma parceriaentre a operadora estatal RAI e a Fastweb. Nesta parceria, coube à RAI Click a responsabilidadepela gerência, produção e empacotamento do conteúdo televisivo, restando para a Fastweb a in-cumbência de distribuir o conteúdo produzido através de ADSL ou FTTH. Além disso, a RAIClick tornou-se um ambiente de teste para programas interativos: em 2002 iniciou-se a veiculaçãode propagandas interativas e em 2003 foi veiculado um programa de entrevistas com os assinantesparticipando através de uma câmera.

3.2.4.4. Free e MaLigne (França)

Em operação desde dezembro de 2003, a Free atua apenas em Paris e Lion e oferece o serviço detriple play com VoIP, conexão a Internet de 2 Mbps e IPTV baseado em MPEG-2 e taxa de 3,5Mbps.

Já a operadora MaLigne, uma subsidiária da France Telecom, oferece IPTV baseado emMPEG-2 e MPEG-2 TS (Transport Stream) e deve estar ofertando, em breve, codificação comH.264 (AVC) para solicitações de VoD. Uma das vantagens do protocolo H.264 sobre o protocoloMPEG-2 é a maior capacidade de compressão, atingindo uma taxa de 2:1 em vídeos com a mesmaqualidade. Além disso, a implementação do protocolo H.264 possibilitará a transmissão de vídeos

em HDTV.

3.2.4.5. Bluewin (Suíça)

A operadora Swisscom, com intuito de lançar comercialmente o serviço de IPTV, tem efetuadoinúmeras experiências através do serviço Bluewin em várias cidades na Suíça. A topologia abaixoapresenta o modelo de distribuição adotado para o Bluewin, que oferta vários canais ao vivo,incluindo emissoras de televisão abertas e por assinatura.

Figura 3.8. Topologia de teste da Bluewin (Fonte: [23])

3.2.5. Limitações

Embora a arquitetura Cliente-Servidor: Download-and-play não exija requisitos especiais da redepara permitir a reprodução de arquivos multimídia, esta possui uma limitação preponderante: a in-capacidade de lidar com transmissões ao vivo. Esta característica reduz, imensamente, o universode atuação da arquitetura Cliente-Servidor: Download-and-play.

Por ser capaz de lidar com fluxos de arquivos multimídia, a arquitetura Cliente-Servidor:Streaming vem sendo amplamente difundida e utilizada. Contudo, necessita de característicasespeciais que possam garantir um atraso máximo, jitter, assim como outros requisitos de qualidadede serviço. É importante notar que as arquiteturas cliente-servidor possuem número de clienteslimitado devido a carga concentrada no servidor.

A proposta da arquitetura IP Multicast visa ser escalável e reduzir significativamente abanda necessária ao tráfego multimídia e atualmente esta arquitetura é utilizada principalmenteem redes privadas. Para que a Internet possa tirar proveito dos recursos propostos pela arquiteturaIP Multicast será necessário atualizar a imensa maioria dos roteadores, incorporando protocolosde roteamento específicos (para redes IP Multicast) e, possivelmente, incrementando o hardwarede alguns roteadores.

Além disso, há necessidade de investimento tecnológico e de infra-estrutura na rede deúltima milha. Para que seja possível apresentar uma programação com uma qualidade aceitável,a taxa de transmissão deve estar entre 2 Mbps e 4 Mbps, caso a codificação fique a cargo do pro-tocolo MPEG-2. Esta taxa se aplica a recepção de um único canal, desconsiderando a hipótesede haver mais de um aparelho de TV, onde possa haver o interesse em assistir uma outra emis-sora. Para que o serviço triple play seja ofertado, deve-se ainda garantir banda com os requisitos

exigidos pelo serviço de VoIP e para o acesso a Internet.

A solução para redução da banda necessária à codificação de um programa televisivo podeestar nos protocolos H.264 (AVC) e VC-1, que em princípio são capazes de reduzir a banda pelametade, mantendo-se a mesma qualidade. Com estes novos protocolos, a possibilidade de trans-missão de programas em HDTV passa a ser uma realidade. Além disso, as dificuldades iniciaisdas redes de última milha para prover acessos de alta velocidade vêm sendo, paulatinamente, ven-cidas. A tecnologia DSL vem evoluindo (ver Tabela 3.1) e a oferta de FTTH, com rede Ethernet(10 Mbps), alcançando um número crescente de residências.

3.3. Novas Propostas de DistribuiçãoAté o momento não foi apresentado nenhum mecanismo que permita ao modelo de IP Multicastser aplicado a uma escala de milhões de nós como seria de fato necessário para que as aplicaçõesmulticast em geral se difundam na Internet comercial. Embora exista expectativa para distribuiçãocomercial de canais de TV através da Internet e baseada na tecnologia IP Multicast, devido aosproblemas existentes de escalabilidade do IP Multicast nos roteadores, a utilização desta propostaé ainda muito limitada.

Formas alternartivas de comunicação em grupo têm surgido com o intuito de solucionaralgumas das limitações sofridas pela arquitetura comercial. Principalmente tentam resolver oproblema de escalabilidade, tentando fornecer um serviço de alcance global e utilizando a infra-estrutura da Internet, ao invés de redes privadas.

O multicast na camada de aplicação é cada vez mais considerado como alternativa aoIP multicast. Visando não depender da infra-estrutura multicast da rede, a técnica de multicastem nível de aplicação fornece a funcionalidade de roteador a qualquer um dos nós. Assim osnós participantes associam seus recursos para rotear e distribuir as mensagens multicast usandosomente serviços de rede unicast.

Assim, nesta seção serão abordadas as propostas emergentes para distribuição de vídeoem ambiente cooperativo, visando explorar as tecnologias em multicast em nível de aplicaçãocomo redes de distribuição de conteúdo, multi-caminhos, pseudo-servidores e peer-to-peer. Serãodestacadas as vantagens e limitações de cada uma das propostas.

3.3.1. Redes de Distribuição de Conteúdo Multimídia

Quando desejamos transmitir algum tipo de conteúdo multimídia, a idéia mais comum que surgeé utilizar um único servidor. O conteúdo é simplesmente enviado do servidor para o cliente,de acordo com o número de requisições. No entanto, existem três limitações com o uso destasolução. Primeiro, como um cliente pode estar muito longe do servidor, os pacotes do servidorpara o cliente podem trafegar por vários ISPs, aumentando significativamente a probabilidade deperdas e de atraso. Segundo, se o vídeo é muito popular, possivelmente o vídeo será enviado váriasvezes através dos mesmos ISPs e por conseguinte através dos mesmos enlaces de comunicação,consumindo de forma significativa a largura de banda. Terceiro, quando o servidor atinge suacapacidade máxima, este não consegue servir mais clientes, o que torna esta solução não escalável.

A idéia básica para resolver essas limitações é mover o conteúdo do servidor de origempara os servidores de borda da Internet aproximando-os dos clientes. Servir o conteúdo a partirde um servidor local tipicamente apresenta melhor desempenho (menor latência de acesso, maiortaxa de transferência) do que utilizando o servidor de origem. Uma rede de distribuição de con-teúdo (Content Distribution Network - CDN) utiliza justamente esta idéia, pois tenta distribuirgeograficamente vários servidores com réplicas dos objetos, possibilitando ao cliente receber do

melhor servidor o conteúdo com um menor atraso.

O uso deste tipo de arquitetura já é bem utilizado para distribuição de objetos de dados,mas ainda pouco explorado para transmissão de fluxos de vídeo. Empresas como Akamai [20] eMirror-Image [28] oferecem o serviço, mais ainda limitado a vídeos de qualidade razoável e semmuitas opções de serviços interativos. Esta seção irá apresentar uma arquitetura baseada em CDNpara transmissão de vídeo que supera estas limitações, oferencendo serviços mais próximos dosencontrados nos sistemas de distribuição de TV convencionais. Questões tais como onde colocaros servidores de réplica, como distribuir cópias do conteúdo para estes servidores e como rotear asrequisições do cliente para o servidor de réplica apropriado são os desafios principais no projetode uma CDN e também serão discutidos nesta seção.

3.3.1.1. Visão Geral

Uma empresa de CDN objetiva fornecer aos provedores de conteúdo um serviço de entrega efici-ente até os clientes requisitantes, de modo que tenha os menores atrasos possíveis. Estes prove-dores de conteúdo podem ser produtoras de música, jornais e outros que queiram ter seu conteúdodisponibilizado na web de forma rápida e fácil. Após um contrato entre o provedor de conteúdoe a CDN, o provedor de conteúdo entrega a CDN os dados que deseja disponibilizar para que aCDN realize posterior distribuição para os servidores de réplicas.

A empresa de CDN conta com um grande número de provedores de serviço Internet (In-ternet Service Provider - ISP) como parceiros. Cada ISP possui servidores da CDN que sãogerenciados remotamente. São nestes servidores o local onde residem os dados dos provedores deconteúdo. Do ponto de vista do ISP, ter servidores de uma empresa de CDN é algo muito vanta-joso, pois provê aos seus consumidores um excelente tempo de resposta para acessar o conteúdoda CDN, o que pode ser uma vantagem competitiva sobre outros ISPs. Com isto, grandes empre-sas de CDNs como a Akamai [1, 20] conseguem ter mais de 19.000 servidores distribuídos portodo o mundo.

Tipicamente uma empresa de CDN fornece seu serviço de distribuição de conteúdo está-tico da seguinte maneira:

1. A empresa de CDN espalha centenas a milhares de seus servidores por toda a Internet. Emgeral os servidores da CDN são instalados em um data center, que normalmente é um edi-fício que hospeda servidores de propriedade de terceiros. Esses data centers muitas vezesestão em ISPs de nível mais baixo, próximos às redes de acesso aos ISPs e aos clientes.

2. A CDN duplica o conteúdo de seu cliente nos seus servidores de réplicas. Sempre que seucliente atualiza o conteúdo, a CDN redistribui o novo conteúdo novamente aos servidores.

3. A empresa CDN fornece um mecanismo que entrega a um cliente que tenha requisitado,o conteúdo pelo servidor CDN que melhor possa atendê-lo. Esse servidor pode ser o queestiver mais próximo do cliente (talvez no mesmo ISP) ou pode ser um servidor CDN cujocaminho até o cliente está livre de congestionamento.

Para tentar ilustrar melhor a idéia, a Figura 3.9 mostra a interação entre o provedor deconteúdo e a empresa CDN. O provedor de conteúdo primeiro determina qual de seus objetos (porexemplo, vídeos) ele quer que a CDN distribua. O provedor de conteúdo rotula o conteúdo e entãoo envia para um nó CDN de distribuição, que por sua vez, duplica esse conteúdo e o retransmitepara todos os servidores de réplica. Sempre que o provedor de conteúdo modifica um objeto queé distribuído pela CDN, ele envia a versão atualizada ao nó CDN de distribuição, que mais uma

vez, duplica e distribui o objeto aos servidores de réplica da CDN. É importante ter em menteque os servidores de réplica da empresa CDN não são exclusivos para cada um dos provedoresde conteúdo, isto é, cada servidor da CDN normalmente contém objetos de muitos provedores deconteúdo.

Figura 3.9. Esquema de distribuição do conteúdo pela CDN

Uma questão importante refere-se a como o navegador de um usuário, a partir de umaURL (Universal Resource Locator) específica, consegue determinar se deve extrair um objetodo servidor de origem (provedor de conteúdo) ou de um dos servidores de réplicas da CDN.Normalmente as CDNs utilizam redirecionamento DNS (Domain Name System) para guiar osnavegadores até o servidor correto. Esta e outras técnicas existentes serão abordadas mais adiante,na Seção 3.3.1.2.

Ainda resta explicar como uma empresa CDN determina o melhor servidor de réplica parao usuário requisitante. Embora cada empresa CDN tenha seu modo proprietário exclusivo parafazer isso, não é difícil ter uma idéia aproximada do que elas fazem. A empresa CDN monitoraseus servidores de réplica para cada acesso ISP na Internet que contenha clientes requisitantespotenciais. Então a CDN determina o melhor servidor de réplica com base em seu conhecimentodas tabelas de roteamento da Internet (especificamente, as tabelas BGP), em estimativas de roundtrip time e em outros dados de medição que possui, de seus vários servidores a várias redes deacesso. Dessa maneira, a CDN estima qual servidor de réplica fornece o melhor serviço de melhoresforço para o ISP. A CDN faz isso para um grande número de acessos ISPs na Internet e utilizaessa informação para configurar o servidor DNS com autoridade.

3.3.1.2. Arquitetura de uma CDN

De modo geral, uma arquitetura para uma CDN tipicamente possui sete componentes: cliente,servidores de réplica, servidor de origem, organização de faturamento, sistema de roteamentode requisições, sistema de distribuição e um sistema de contabilização. A Figura 3.10 ilustra a

arquitetura, bem como os relacionamentos entre os componentes.

Figura 3.10. Componentes da arquitetura de um sistema CDN (Fonte: [36])

1. O servidor de origem delega seu espaço de nomes URI (Universal Resource Identifier) paraos objetos a serem distribuídos pela CDN ao sistema de roteamento de requisições.

2. O servidor de origem publica o conteúdo a ser distribuído e entregue pela CDN para osistema de distribuição.

3. O sistema de distribuição move o conteúdo para os servidores de réplica. Além disso,este sistema interage com o sistema de roteamento de requisições através de feedback paraauxiliar no processo de seleção do servidor de réplica para as requisições dos clientes.

4. O cliente requisita documentos para o que ele percebe como origem. Porém, devido adelegação do espaço de nomes URI, a requisição é direcionada para o sistema de roteamentode requisições.

5. O sistema de roteamento de requisições roteia a requisição para um servidor de réplicaadequado na CDN.

6. O servidor de réplica selecionado entrega o conteúdo requisitado ao cliente. Além disso,o servidor de réplica envia informações de contabilização do conteúdo entregue para osistema de contabilização.

7. O sistema de contabilização agrega e separa a informação de contabilização em registros eestatísticas para uso pelo servidor de origem e pela organização de faturamento. As estatís-ticas também são usadas como feedback para o sistema de roteamento de requisições.

8. A organização de faturamento utiliza registros oriundos do processo de distribuição do con-teúdo para determinar cada uma das partes envolvidas e realizar a cobrança adequada.

Como podemos perceber, duas etapas fundamentais envolvidas no processo de servir umarequisição de um cliente em uma CDN envolvem a localização de um servidor adequado que pos-sua uma réplica do objeto requisitado e o redirecionamento da requisição para este servidor. Estasetapas são conhecidas respectivamente como seleção do servidor e roteamento de requisição e são

realizadas pelo sistema de roteamento de requisições. Estas etapas serão descritas brevemente aseguir:

Seleção do servidor: O problema de como escolher um servidor de réplica adequado emuma CDN para servir uma dada requisição envolve as seguintes questões:

• Determinar a distância entre o cliente e o servidor: Os números de saltos (hop counts) e otempo de ida e volta (round trip time) são duas métricas normalmente usadas para medirdistância em redes de computadores. Duas ferramentas bem populares para obter esses doisparâmetros são ping e traceroute. No entanto, nenhuma dessas duas métricas é suficiente eprecisa para indicar a proximidade entre clientes e servidores de réplica porque a primeiranão leva em conta situações de tráfego na rede e a segunda é altamente variável [36].

• Determinar a carga de um servidor de réplica: Duas técnicas amplamente utilizadas paradeterminar a carga de um servidor são server push e client probe. Na primeira técnica, osservidores de réplica propagam a informação de carga para alguns agentes. Na segundaabordagem, os agentes sondam o status dos servidores de interesse periodicamente. Existeum compromisso entre as freqüências das sondagens para uma medida precisa e o tráfegoimposto pela sondagem [36].

Roteamento de requisição: Muitas técnicas têm sido usadas para levar clientes a usaremum servidor em particular dentre um conjunto de servidores de réplica. Em geral, elas podem serclassificadas em cinco categorias:

• Multiplexação de clientes: Nesse esquema, o cliente ou um servidor proxy próximo aocliente recebe o endereço de um conjunto de servidores de réplica candidatos e escolhe umpara enviar a requisição. Geralmente esse esquema impõe um overhead adicional por enviarum conjunto de servidores de réplica candidatos para o cliente quando é feita a requisiçãode algum conteúdo. Também, devido à falta de informação em geral, o cliente pode escolherum servidor com grande carga, o que poderia resultar em servidores sobrecarregados e aindaem uma maior latência de acesso.

• Redirecionamento HTTP: Este é o mais simples e provavelmente o menos eficiente meiode redirecionar requisições. Neste esquema, as requisições de conteúdo seguem todas parao servidor de origem, onde o servidor redireciona o navegador para uma nova URL no níveldo protocolo HTTP. Como o servidor de origem ou cluster de servidores é o único pontoresponsável for redirecionar requisições, isto pode torná-los um gargalo e ainda torna oesquema propício a erros.

• DNS Indirection: Esse esquema utiliza modificações no DNS para retornar o endereço IPde um servidor de réplica dentre um conjunto de servidores de réplica quando o servidorDNS é consultado pelo cliente. Esta técnica é transparente para o cliente. A qualidade daseleção do servidor pode ser melhorada levando-se em conta o desempenho do servidor.Alguns CDNs comerciais, como Akamai [20], estão adotando esta abordagem.

• Anycasting: Essencialmente, o roteamento de requisições em uma CDN pode ser vistocomo uma aplicação de localizar cópias próximas em servidores replicados. Técnicas comoanycasting, desenvolvidas para localização de servidores, podem ser usadas para rotea-mento de requisições em CDNs. Neste esquema, um nome anycast de domínio/endereço,que pode ser um endereço IP anycast ou uma URL de conteúdo, é usado para definir um

grupo de servidores que oferecem o mesmo serviço. Um cliente que deseje comunicar-se com somente um dos servidores envia pacotes com o endereço anycast no campo deendereço de destino. Os pacotes são então roteados através de roteadores anycast-awarepara ao menos um dos servidores identificados pelo endereço anycast. Este roteamentoanycast-aware pode ser integrado na infra-estrutura de roteamento da Internet, oferecendodesta forma serviço de roteamento para todas as CDNs. Além disso, esse esquema tem opotencial de ser bem escalável com o crescimento da Internet.

• Roteamento Peer-to-Peer: Sistemas P2P estão se tornando amplamente empregados na In-ternet para disseminação de conteúdo. Os nós participantes em um sistema P2P geralmentepertencem a diferentes afiliações e juntos constituem uma rede ad-hoc. Como neste tipo derede a topologia está constantemente se modificando, nenhum nó possui uma informaçãoglobal completa sobre a rede. O problema de rotear requisições eficientemente de uma ma-neira distribuída sem impor um alto overhead de propagação da informação de roteamentoé uma grande área de pesquisa.

3.3.1.3. Distribuição de conteúdo televisivo com uma CDN

As empresas de CDNs tradicionais fornecem suporte a conteúdo de dados razoavelmente bem. Noentanto, quando se trata de transmissão de fluxos de vídeo, o suporte é muitas vezes limitado adistribuição de fluxos ao vivo e sob demanda de baixa e média qualidade. Para que um serviço deTV seja popular na Internet, espera-se no mínimo que apresente boa qualidade de vídeo e ofereçaalgum tipo de serviço que possibilite assistir uma programação que já tenha sido transmitida.Para isto, primeiramente as CDNs devem melhorar drasticamente a qualidade dos fluxos de vídeooferecidos a seus consumidores. Segundo, devem fornecer serviços com funções semelhantes àsencontradas no sistema de TV convencional de forma a acomodar novos modelos de negócio.

Uma arquitetura em pesquisa que atende a todos estes requisitos é conhecida como Prism(Portal Infrastructure Streaming Media) [13, 4]. Esta arquitetura, é uma CDN voltada para dis-tribuição, armazenamento e entrega de fluxos de vídeo de alta qualidade em redes IP. Esta arqui-tetura se diferencia das tradicionais pelo fato de oferecer algumas funcionalidades aos clientesmuito semelhantes às encontradas no sistema de TV convencional. Uma destas funcionalidadesé a possibilidade de armazenamento do conteúdo para posterior acesso sob demanda, um serviçoconhecido como stored-TV (STV). Este serviço permite que os usuários visualizem o conteúdobaseado em seu nome ou pelo horário em que foi transmitido. Por exemplo, usuários podem aces-sar programas que foram ao ar na CNN às 1:00 PM do dia 2 de Janeiro de 2006. Uma outravantagem da arquitetura é que o conteúdo armazenado dentro da rede é acessível através de todainfra-estrutura Prism. Isto possibilita, por exemplo, que um usuário localizado no Brasil consigaacessar eventos esportivos europeus, ou mesmo outro tipo de conteúdo de TV, seja ao vivo ou sobdemanda.

A arquitetura Prism também fornece um serviço que lembra um VCR (Video Cassette Re-corder), pois permite que os usuários especifiquem a programação que desejam armazenar. Alémdisso, através do serviço de STV, um provedor de serviço poderia armazenar determinados pacotesde conteúdo de forma periódica. Imagine a possibilidade de realizar o armazenamento das últimastrês horas de conteúdo de um grande número de canais ou mesmo do conteúdo semanal de progra-mas que vão em exibição em horários de pico. É fácil perceber que este tipo de serviço oferecidopela arquitetura Prism disponibiliza muito mais conteúdo quando comparado ao emergente PVR.

A arquitetura Prism tem como objetivo fornecer uma qualidade comparável a transmissãode TV existente. No entanto, surge uma questão com relação a infra-estrutura de rede necessáriapara que isto seja possível. Tecnicamente, as tecnologias de acesso a Internet em banda larga tais

como cabo e o xDSL oferecem largura de banda suficiente para os serviços oferecidos pelo Prism.Obviamente, oferecer este tipo de serviço também dependeria das considerações de negócios tantoem termos de acesso a banda larga a um custo acessível, quanto de modelos de negócio atrativospara os provedores de conteúdo.

Nesta seção serão apresentados os componentes da arquitetura Prism e descritos resumida-mente cada um deles. Após iremos dar uma visão mais detalhada sobre os principais componentesda arquitetura e sobre o esquema de nomeação do conteúdo. Iniciaremos com a descrição dos trêscomponentes básicos da arquitetura:

• Fonte ao vivo (Live source): recebe o conteúdo do provedor de conteúdo e realiza as etapasnecessárias para codificação e posterior transmissão deste conteúdo para dentro da infra-estrutura Prism.

• Portal: recebe o conteúdo das fontes ao vivo e de outros portais e o transmite para os clientesPrism. Os portais podem armazenar e arquivar conteúdo ao vivo, de forma a possibilitarque o conteúdo possa ser visto sob demanda. Além disso, os portais também fornecemfuncionalidades que lembram um VCR, tais como fast-forward (FF) e rewind (RW) paraseus clientes. Dentro da arquitetura estão posicionados entre os clientes e os servidores,normalmente nas descontinuidades de banda como um cable head end.

• Cliente: recebe o conteúdo de um portal e o exibe para os usuários finais. São consideradosclientes dispositivos como set-top boxes ou PCs conectados ao backbone através de acessovia banda larga.

Um cliente normalmente interage com um portal próximo a si na rede. Este portal naarquitetura Prism é conhecido como portal local. O portal local pode agir como um proxy emsituações em que recebe uma requisição por um conteúdo que não possui armazenado localmente.Isto permite que o portal local forneça controles VCR para o cliente mesmo quando o conteúdoque está sendo visto venha de um portal remoto e também permite que o portal local efetue cachedo conteúdo recentemente visualizado, no caso dos usuários desejarem revê-los depois.

Figura 3.11. Plano de dados da arquitetura Prism (Fonte: [13])

Os três tipos de componentes básicos descritos anteriormente se comunicam na rede comcomponentes do plano de dados (data plane) ou do plano de controle (control plane). Como

o plano de dados (Figura 3.11) é comum a qualquer CDN que realize transmissão de fluxos devídeo, o mesmo será considerado apenas brevemente:

• Distribuição de conteúdo (Content distribution): Os mecanismos de distribuição de con-teúdo transferem conteúdo de uma fonte ao vivo para um ou mais portais e até mesmo entreportais.

• Entrega de conteúdo (Content delivery): Os mecanismos de entrega de conteúdo realizama transmissão do conteúdo de um portal para um ou mais clientes. Os portais devem estartopologicamente próximos aos clientes de forma a fornecer um desempenho aceitável paraas operações sensíveis a latência como as funções de controle VCR.

Um aspecto único do Prism é que ele possibilita o armazenamento de conteúdo ao vivodentro da rede para subseqüente acesso sob demanda. Isto difere do acesso sob demanda das CDNsconvencionais pelo fato de não existir um servidor de origem bem conhecido onde se espera queo conteúdo resida. O plano de controle é quem controla como o conteúdo vai ser localizado nainfra-estrutura. A Figura 3.12 ilustra os três componentes principais do plano de controle:

Figura 3.12. Plano de controle da arquitetura Prism (Fonte: [13])

• Gerenciamento de conteúdo (Content Management): coorderna e gerencia o armazena-mento de conteúdo nos portais. A entrada para o processo de gerenciamento de conteúdoinclui informação sobre o tipo de serviço, acordos de nível de serviço (Service Level Agree-ments - SLAs) com os provedores de conteúdo, capacidade do portal e a carga causada porum acesso de usuário.

• Descoberta de conteúdo (Content Discovery): determina a existência e a localização doconteúdo dentro da infra-estrutura. Quando os usuários fazem a requisição por um conteúdoespecífico, o Prism usa o mecanismo de descoberta de conteúdo para determinar de qual

portal ou fonte ao vivo o conteúdo pode ser obtido. Enquanto a descoberta de conteúdoé acionada pela requisição de um usuário, o processo de descoberta real, como mostradona Figura 3.12, ocorre entre as entidades Prism e não é visível para outro usuário excetoatravés do processo de redirecionamento descrito a seguir.

• Redirecionamento ciente de conteúdo (Content-Aware Redirection): redireciona as requisi-ções dos usuários para o portal que melhor os satisfaça. A localização do conteúdo requi-sitado junto com outros parâmetros podem ser usados para determinar o portal apropriadopelo qual o conteúdo deveria ser servido ao cliente. Todos os servidores de borda, incluindoos portais, tem capacidades básicas de redirecionamento. Entretanto, servidores separadosde redirecionamento, ou redirecionadores, geralmente realizam esta função especializadado plano de controle do Prism.

Nomeação do Conteúdo

No Prism, o conteúdo é referênciado pelo nome e não pela localização, através de umesquema de nomes conhecido como URN (Uniform Resource Name) em contraste a uma URL.Isto permite maior flexibilidade no acesso ao conteúdo, permitindo que os usuários acessem oconteúdo de várias maneiras sem revelar ou conhecer a estrutura interna da arquitetura.

Este esquema de nomeação é bastante interessante, pois permite que o conteúdo possa seridentificado de acordo com os nomes de canais existentes, distribuidora da rede de TV e locali-zação regional. Além disso, como o conteúdo é armazenado e acumulado na arquitetura durantetodo o tempo, é fácil referênciar um programa pela data e horário em que foi ao ar.

A sintaxe do esquema de nomes é apresentada na Figura 3.13 e é possível observar que asURNs consistem em duas partes: uma formada pelo nome do canal e outra formada pela especifi-cação do programa. O nome do canal é formado por quatro elementos, descritos a seguir:

Figura 3.13. Sintaxe do esquema de nomes (Fonte: [13])

• Emissora: é o nome do canal que os usuários geralmente conhecem. Pode ser um simplesidentificador como “ABC” ou o nome completo.

• Canal: o número do canal associado com o conteúdo. Em alguns casos este campo podeser nulo.

• Distribuidor: indica a entidade responsável por distribuir o conteúdo como a estação detransmissão proprietária, uma empresa de cabo ou satélite, ou um sistema de distribuiçãode conteúdo baseado em Internet.

• Localização: é a fonte da versão específica do conteúdo. Pode ser usado para indicar umatorre de transmissão ou cable head end.

A especificação do programa é utilizada para referenciar o programa de interesse do cli-ente. É composto por:

• Horário de ínicio e término: indicam respectivamente o horário de início e término doprograma expresso na forma UTC (ex. utc:20060106T2200).

• Programa: identifica o conteúdo associado a um canal particular.

• offset: um atraso opcional relativo ao horário de início do programa, expresso em segundos.

A adoção deste esquema de nomeação ainda está sendo discutida no IETF (Internet En-gineering Task Force). Na ausência deste suporte na Internet atual, os autores sugerem codificaruma URN em URL do seguinte modo:

stv:<abc;wabc;;>rtsp://server/prismurn/abc/wabc/*/*/

Gerenciamento do Conteúdo

A principal função do gerenciamento de conteúdo é coordenar a distribuição e o armaze-namento do conteúdo dentro da infra-estrutura. Isto é feito de maneira que equilibre os recursosrequeridos com aqueles disponíveis de forma a realizar a entrega adequada do conteúdo requisi-tado pelos usuários.

Ao contrário das soluções de vídeo sobre demanda convencionais onde o conteúdo é razo-avelmente estático, o serviço de STV permite que novos conteúdos possam ser adicionados con-tinuamente. Para isto, a infra-estrutura necessita ser informada pelo gerenciamento de conteúdosobre quais fluxos de TV são de interesse e sobre quais partes dos mesmos devem ser armazenadase por quanto tempo.

A Figura 3.14 ilustra dois tipos principais de mensagens envolvidas no gerenciamento deconteúdo.

• Mensagens de atualização (Update messages): Um gerenciador de conteúdo envia men-sagens de atualização para instruir um portal a respeito das políticas, uso de recursos emanipulação do conteúdo. O gerenciador de conteúdo diz aos portais qual conteúdo obter,quando e quais políticas de armazenamento e desapropriação devem ser associadas ao con-teúdo. As mensagens de atualização permitem que o gerenciador de conteúdo diga ao portalquais de seus recursos devem ser particionados e qual entidade é responsável por gerenciara respectiva partição. O recurso de principal preocupação é o espaço de armazenamento doportal, mas outros recursos também poderiam ser gerenciados desta mesma maneira.

• Mensagens de relatório (Report messages): Um portal usas estas mensagens para informaro gerenciador de conteúdo sobre sua disponibilidade de recursos. Mensagens de relatóriotambém transportam estatísticas de uso do conteúdo e carga do portal. O gerenciador deconteúdo usa esta informação nas decisões dinâmicas de gerenciamento de conteúdo. Por

Figura 3.14. Gerenciamento do conteúdo na arquitetura Prism (Fonte: [13])

exemplo, se um conjunto de portais que tenha um filme em particular comece a se tornarcarregado com o volume de requisições, o gerenciador de conteúdo poderia instruir outrosportais para receber e armazenar o filme em questão.

Como ilustrado na Figura 3.14, vários gerenciadores de conteúdo podem gerenciar osmesmos portais. Isto é útil se os gerenciadores de conteúdo são especializados em diferentesserviços ou tipos de conteúdo. Por exemplo, um gerente de conteúdo poderia exclusivamentelidar com um serviço de filme sob demanda, enquanto outro poderia realizar STV. Observe que aFigura 3.14 também ilustra a interação entre gerenciadores de conteúdo em diferentes domíniosadministrativos, o que facilita o gerenciamento de conteúdo entre CDNs.

Descoberta de Conteúdo (Content Discovery)

Quando um cliente requisita um conteúdo do Prism, o redirecionador primeiro usa o des-cobrimento de conteúdo para determinar a localização do conteúdo. Normalmente o redireciona-dor redireciona o cliente para um portal que tenha o conteúdo requisitado. Quando portais quetenham o conteúdo estão largamente utilizados, o redirecionador pode dinamicamente aumentar onúmero de portais servindo este conteúdo. Neste caso o cliente pode ser redirecionado para umportal que ainda não tenha uma cópia do conteúdo. Caso isso ocorra, a localização real do con-teúdo pode ser codificada na forma de uma URL de redirecionamento, ou o próprio portal poderealizar uma query pelo conteúdo através do serviço de descoberta de conteúdo.

A arquitetura do descobrimento de conteúdo é construída sobre um serviço de mapea-mento que mantém uma associação entre o conteúdo, identificado por uma URN, e um conjuntode URLs que fornecem a exata localização do conteúdo na infra-estrutura.

A Figura 3.15 ilustra uma infra-estrutura de portal na qual os portais são organizados emvizinhanças, o que na prática pode ser implementado em data centers localizados geograficamentedistantes. O serviço de mapeamento consiste de um servidor de mapeamento local em cada umadas vizinhanças e um servidor de mapeamento global. Os portais locais enviam atualizaçõessobre seu conteúdo armazenado para os servidores de mapeamento locais, que por sua vez enviam

Figura 3.15. Hierarquia do serviço de mapeamento (Fonte: [13])

mensagens de atualização para o servidor de mapeamento global. Os servidores de mapeamentolocal resolvem todas as queries para o conteúdo local, enquanto que o servidor de mapeamentoglobal resolve as queries que não podem ser resolvidas localmente.

A confiabilidade e escalabilidade do sistema pode ser melhorada através da replicação dosservidores de mapeamento. Se a carga do serviço de mapeamento é em maior parte de queries aoinvés de atualizações, (o que é provável, uma vez que as queries são disparadas pelas requisiçõesdos clientes enquanto o conteúdo é atualizado infrequentemente) uma solução atrativa é simples-mente replicar os servidores e distribuir as queries entre eles, contanto que o tamanho da basede dados seja razoável. Desde que os metadados sejam de ordens de magnitude menores que osobjetos de vídeo, esta proposta é viável mesmo em uma CDN de grande porte.

Redirecionamento ciente de conteúdo (Content-Aware Redirection)

A política principal do mecanismo de redirecionamento é ter o cliente redirecionado paraseu portal local para que seja possível realizar as funções VCR de forma rápida nos fluxos devídeo, mesmo em momentos em que este conteúdo não está armazenado no portal. No entanto,existem situações em que é ineficiente realizar a transmissão do conteúdo através do portal local.Isto é especialmente verdade quando o portal local está sobrecarregado. Nestas situações, o re-direcionador pode encaminhar o cliente para outros portais para que consiga acesso ao conteúdo.Vale salientar que estes aspectos de redirecionamento do Prism não são únicos nesta arquitetura,e também são encontrados nos sistemas de redirecionamento das CDNs atuais. No entanto o sis-tema de redirecionamento do Prism estende a funcionalidade básica para também levar em contaa localização do conteúdo durante o redirecionamento. O processo de redirecionamento pode serdividido em sete passos. Assim, temos:

• Usando um guia de programação web ou algum outro serviço semelhante, o navegador dousuário obtém a URN do conteúdo a ser visualizado.

• O navegador envia pra o player de mídia a URN, codificada como uma URL que apontapara o redirecionador, como por exemplo, rtsp://redirector/prismurn/cnn/*/*/*. Este playerde mídia pode ser específico da arquitetura ou um player comum que suporte RTSP, só queneste caso o player comum não estará ciente que está se comunicando com a infra-estruturaPrism.

• O cliente se conecta ao redirecionador especificado na URL e usa o protocolo RTSP pararequisitar o conteúdo.

• O redirecionador envia uma query para o serviço de mapeamento para ver a disponibilidadee a localização do conteúdo requisitado.

• O redirecionador leva em conta os resultados da query do serviço de mapeamento, a cargaatual e a proximidade do cliente e o redireciona para o portal que melhor seja capaz deservir a requisição. Isto é tipicamente realizado com redirecionamento RTSP, mas técnicasalternativas podem ser usadas.

• Recebendo a resposta, o cliente envia as requisições RTSP para o portal especificado peloredirecionador para dar início ao processo de transmissão.

• Caso o portal que esteja servindo o cliente redirecionado não tenha o conteúdo requisi-tado, este portal deve obtê-lo de um portal remoto antes de que possa começar a realizar atransmissão do conteúdo.

A arquitetura Prism mostra-se como uma alternativa viável para distribuição de conteúdotelevisivo na Internet. Além de fornecer serviços com funções semelhantes às encontradas nosistema de TV convencional, possibilita especificar o conteúdo desejado de forma intuitiva atravésde seu esquema de nomeação de conteúdo. Além disso, fornece meios para acomodação de novosmodelos de negócio para este emergente segmento de mercado.

A próxima seção irá descrever um tipo diferente de abordagem, na qual a transmissão devídeo é realizada a partir de várias fontes para o cliente, de forma que o conteúdo seja recebidoatravés de múltiplos caminhos.

3.3.2. Distribuição de TV sobre IP através de múltiplos caminhos

A Internet nos últimos anos teve um crescimento substancial em tráfego e popularidade [17].Como resultado, sites com conteúdo popular tiveram que lidar com um grande volume de requi-sições de clientes, e por conseguinte grandes volumes de carga nos servidores. Por outro lado, aexpectativa dos usuários só tem crescido: eles desejam realizar download do conteúdo no menortempo possível.

Duas soluções principais foram propostas para lidar com este aumento de carga e alcançarum menor tempo de download. A primeira solução utiliza servidores proxy para realizar cache doconteúdo de maneira que fique próximo aos clientes [48]. A outra utiliza servidores mirrors e oredirecionamento de clientes a algum dos servidores. O cliente pode ser redirecionado de formaautomática (Seção 3.3.1) ou manualmente escolhendo um servidor de uma lista de servidoresmirrors.

Quando a cópia do mesmo conteúdo existe em vários servidores, escolher o servidor queforneça o melhor tempo de resposta não é uma tarefa trivial e uma escolha errada pode gerar

um serviço de baixa qualidade para o usuário. Mesmo quando o melhor servidor é selecionado,o desempenho pode flutuar durante a sessão de download, gerando muitas vezes um tempo deresposta ruim ao término do download do conteúdo.

Na presença de vários servidores mirrors que podem servir o mesmo conteúdo, uma alter-nativa interessante para aumentar o desempenho é conectar a vários servidores em paralelo [41].Dessa forma, ao invés de fazer o download de todo o conteúdo de um único servidor, o usuáriopode realizar download em paralelo de diferentes partes do documento de cada um dos servidoresmirror disponíveis. Assim, o usuário pode obter um desempenho melhor e mais uniforme. Umavez que todas as partes do documento são recebidas, o usuário reconstrói o documento originaljuntando todas as partes. Um exemplo de aplicação que usa idéia similar é o software BitTorrent[7].

Uma grande vantagem de utilizar o acesso paralelo é que esta técnica é mais resiliente acongestionamento e falhas de rede e nos servidores do que quando se utiliza um único servidor.Além disso, o processo de seleção do servidor é eliminado, uma vez que o cliente está conectadoa vários servidores que tenham uma cópia do conteúdo. Outra vantagem é que a vazão do clienteaumenta, uma vez que é aproximadamente a soma de todas as larguras de banda existentes docliente para cada um dos servidores.

3.3.2.1. Algoritmos para download em paralelo

De acordo com a literatura [17, 40], existem três técnicas principais para realizar download emparalelo:

• Static-Equal: Nesta técnica o cliente realiza download de partes iguais do documento decada um dos servidores disponíveis. Esta técnica é estática, visto que a decisão de qualparte do arquivo a ser recebido por cada um dos servidores é feita a priori e não pode sermodificada após o início do download.

• Static-Unequal: Nesta técnica, a quantidade de dados do documento que o cliente recebede cada um dos servidores é proporcional a vazão do respectivo servidor. Antes do inícioda transferência do documento, o cliente estima a vazão para cada um dos servidores. Coma estimativa da vazão em mãos, o cliente requisita para cada servidor uma parte do docu-mento. Embora o cliente nesta técnica realize download de partes de tamanho diferentesdo documento, esta decisão é feita a priori e não pode ser modificada após o início dodownload.

• Dynamic: Nesta técnica, a proporção do documento recebido pelo cliente de cada um dosservidores é ajustada dinamicamente durante o processo de download. A idéia básica con-siste em particionar o documento em vários blocos de mesmo tamanho. Assim, o clienterequisita um bloco diferente de cada um dos servidores. Quando um servidor termina detransmitir um bloco, o cliente efetua uma nova requisição para um bloco que não tenha sidorequisitada a nenhum outro servidor. O mesmo processo é repetido para cada bloco até quetodos os blocos sejam recebidos.

Em geral podemos dizer que a técnica Static-UnEqual realiza download de documentosem um tempo bem menor que a técnica Static-Equal. Isto se deve ao fato desta técnica conseguirrealizar o download da parte do documento relativa ao servidor de forma proporcional a sua taxade serviço, ou seja, um servidor lento irá enviar uma parte menor do documento enquanto que umservidor rápido irá entregar uma parte maior. Para calcular a quantidade que cada servidor deve

enviar, a técnica utiliza uma média ponderada dos valores de vazão medidos no respectivo servidor.Esta técnica pode aumentar a velocidade do processo de download quando as condições da redeou do servidor são estáveis ou facilmente previsíveis. Como o cenário mais comum é encontramosas condições da rede e dos servidores mudando constantemente, as predições sobre vazão não sãotão precisas e isto acaba fazendo com que esta técnica não execute da melhor maneira possível[40].

A técnica Dynamic oferece algumas vantagens em relação as outras duas. Os servidorescontactados pelo cliente compartilham a carga de maneira proporcional aos recursos disponíveisem cada servidor, o que acaba ocasionando um balanceamento de carga automático no sistema.Assim, os servidores mais rápidos irão entregar partes maiores do documento enquanto que osservidores mais lentos irão entregar partes menores. O interessante é que este balanceamentoautomático de carga é realizado sem nenhum conhecimento a priori sobre a vazão dos servidores.Além disso, a carga é automaticamente movida de partes com congestionamento na Internet paraoutras partes que possuam recursos mais abundantes.

3.3.2.2. Recebendo vídeo de vários servidores

As técnicas anteriormente descritas nos fornecem motivação suficiente para explorarmos os bene-fícios do uso de vários caminhos na distribuição de conteúdo televisivo. No contexto da transmis-são de vídeo, necessitamos de técnicas de codificação de sinais que dêem suporte apropriado paraque este conceito seja possível.

Uma das formas de codificação que possibilita a transmissão através de múltiplos cami-nhos é a codificação em múltiplos descritores (Multiple Description Coding - MDC). A codifica-ção em múltiplos descritores é um método de codificação de sinais de áudio e/ou vídeo cujo sinal écodificado em dois ou mais fluxos distintos, onde cada fluxo é chamado de descritor. Cada subcon-junto destes descritores pode ser recebido e decodificado em um sinal com distorção em relação aosinal original. O nível de distorção depende diretamente do número de descritores recebidos, istoé, quanto mais descritores recebidos, menor é a distorção do sinal e melhor é a qualidade. Assim,podemos dizer que o método apresenta as seguintes propriedades [26]:

• Cada descritor pode ser decodificado independentemente dos demais, gerando uma aproxi-mação usável do sinal original;

• Os descritores contém informações complementares, de forma que a qualidade do sinaldecodificado melhora com o aumento do número de descritores utilizados na decodificação.

Com relação a conhecida técnica de codificação em camadas (Layering coding), podemosdizer que nesta somente os dados relativos as camadas de melhoramento podem ser perdidos oudescartados, como mostra a Figura 3.16. Isto se deve ao fato da codificação em camadas priorizaras informações que se localizam na camada base, de modo que se os dados desta camada foremperdidos, os dados das camadas de melhoramento se tornam inúteis. A codificação em múltiplosdescritores visa superar esta limitação, garantindo a reprodução do fluxo mediante a decodificaçãode qualquer subconjunto de descritores e com qualidade proporcional ao número de descritoresdecodificados [35]. Para alcançar esta flexibilidade, a codificação em múltiplos descritores incorreem uma modesta perda de desempenho se comparada à codificação em camadas [26, 35].

Figura 3.16. (a) Codificação em múltiplos descritores. (b) Codificação em cama-das (Fonte: [35])

Um esquema simples de codificação em múltiplos descritores pode ser descrito da se-guinte forma [26, 35]: A seqüência de imagens de um vídeo é demultiplexada em M subseqüên-cias, colocando-se cada K-ésima imagem, m + iK, i = 0,1,2, ..., na m-ésima subseqüência, m =1, ..,M. As subseqüências são independentemente codificadas para formar os M descritores. Qual-quer subconjunto destes M descritores pode ser decodificado e as imagens podem ser remultiple-xadas para reconstruir uma seqüência de vídeo cuja taxa de quadros (frame rate) é proporcionalao número de descritores recebidos.

Quando conciliada a diversidade de caminhos, a codificação em múltiplos descritoresoferece melhor flexibilidade com relação a tolerância a falhas de rede. A idéia é que cada caminhotransporte um descritor diferente do mesmo fluxo e, dado que o uso de múltiplos caminhos reduz aprobabilidade de se ter perdas simultâneas, pode-se melhorar as chances de recepção de um fluxode boa qualidade na maior parte do tempo [26, 3].

Diversos algoritmos para a codificação em múltiplos descritores têm sido propostos re-centemente, fornecendo diferentes níveis de compressão ou tolerância a erros. Algumas das ca-racterísticas buscadas por esses codificadores são [26, 3]:

• Eficácia na compressão, buscando as propriedades da codificação em múltiplos descritorescom um mínimo de acréscimo na largura de banda que os codificadores tradicionais emcamadas forneceriam;

• Habilidade de usar corretamente alguns descritores para o reparo de outros que estejamcorrompidos. Com isso, uma qualidade usável do fluxo pode ser mantida mesmo quandoexistirem perdas em todos os descritores, desde que as mesmas não ocorram exatamentenos mesmos instantes de tempo;

• Habilidade de operar corretamente em caminhos de rede que possuam larguras de bandadiferentes ou desbalanceadas;

• Compatibilidade com padrões existentes, como MPEG-4 e H.263, de forma que uma apli-cação de reprodução convencional possa reproduzir separadamente cada descritor, como seele fosse um único fluxo codificado pelos métodos tradicionais em camadas.

Um esquema alternativo para a codificação utilizando múltiplos descritores é utilizar gru-pos de quadros (Groups of Frames - GOF). O sinal de áudio ou vídeo ou ambos é particionado emGOFs, tendo cada grupo uma duração aproximada de 1 segundo. Cada GOF é então independen-temente codificado, protegido contra erros e particionado em M pacotes, como ilustrado na Figura3.17. Se quaisquer m≤M desses pacotes forem recebidos, então os Rm primeiros bits do GOF ori-ginal podem ser recuperados, ocasionando uma distorção D(Rm), onde 0 = R0 ≤ R1 ≤ ...≤ RM e

Figura 3.17. Codificação de um GOF (Fonte: [35])

conseqüentemente D(R0)≥D(R1)≥ ...≥D(RM). Com isso, todos os pacotes são igualmente im-portantes, sendo apenas o número de pacotes que forem decodificados determinante na qualidadedo GOF reconstruído. A distorção esperada do fluxo transmitido é dada por ∑

Mm=0 p(m)D(Rm),

onde p(m) é a probabilidade que m dos M pacotes sejam recebidos. Enviando-se o m-ésimo pa-cote de cada GOF no m-ésimo descritor, tem-se o sinal inteiro representado por M descritores,onde cada descritor é uma seqüência de pacotes transmitidos na taxa de 1 pacote por GOF [35],como ilustrado na Figura 3.18.

Figura 3.18. Construção dos fluxos MDC a partir de pacotes dos GOFs (Fonte: [35])

O esquema de codificação em múltiplos descritores é uma técnica de codificação de sinaisque fornece o suporte apropriado para codificação dos fluxos de vídeo para transmissão através demúltiplos caminhos.

Iremos verificar na próxima seção que o uso desta técnica em ambientes cooperativosformados através de redes P2P possibilita recebimento contínuo do vídeo, mesmo em situações

onde existem disrupção na árvore de transmissão multicast. Serão apresentados dois sistemas dedistribuição de conteúdo que utilizam esta técnica como forma de codificação de vídeo.

3.3.3. Distribuição de TV utilizando ambientes cooperativos

Recentemente, as redes peer-to-peer têm sido utilizadas para compartilhamento de arquivos, men-sagens instantâneas, multicast em nível de aplicação entre outros tipos de aplicações. Esta tec-nologia muda o paradigma cliente-servidor atual, de forma que não depende de uma organizaçãocentral ou hierárquica, e ainda fornece aos seus integrantes as mesmas capacidades e responsabili-dades. Assim, um integrante pode acessar diretamente os recursos de qualquer outro, sem nenhumcontrole centralizado.

Redes peer-to-peer são redes overlay que funcionam na Internet com o objetivo de com-partilhar recursos entre os usuários, sendo que por princípio não há diferenciação entre os partici-pantes. Existem diversas outras definições na literatura, porém em geral é aceito pela comunidadeque sistemas P2P devem suportar os seguintes requisitos [39]:

• A rede deve ser escalável;

• Os nós podem estar localizados nas bordas da rede;

• A rede deve possuir nós com conectividade variável ou temporária e endereços tambémvariáveis;

• Os nós devem possuir a capacidade de se comunicarem diretamente uns com os outros.

• A rede deve possuir a capacidade de lidar com diferentes taxas de transmissão entre nós;

• A rede deve possuir nós com autonomia parcial ou total em relação a um servidor centrali-zado;

• A rede deve assegurar que os nós possuam capacidades iguais de fornecer e consumir re-cursos de outros nós;

Uma grande vantagem do uso de redes P2P é a possibilidade de agregar e utilizar a capaci-dade de processamento e armazenamento que fica subutilizada em máquinas ociosas. Por possuirnatureza descentralizada e distribuída, os sistemas P2P são inerentemente robustos a certos tiposde falhas muito comuns em sistemas centralizados. Além disso, apresentam o benefício de escala-bilidade, uma vez que tratam do crescimento incontrolável no número de usuários e equipamentosconectados. Finalmente, a tecnologia P2P estimula as pessoas no momento em que elas perce-bem que podem participar e fazer a diferença. Isto explica o sucesso de algumas aplicações comoKaZaa [43], Napster [30] e Gnutella [18].

No caso específico de distribuição de vídeo, os próprios usuários da rede, auxiliam os ser-vidores nas tarefas de distribuição do conteúdo. Uma abordagem bastante comum neste cenárioé a formação de árvores de distribuição, onde os servidores se encontram nas raízes e os clientesnos nós intermediários e folhas, para a distribuição sincronizada de conteúdo, implementado dessaforma um multicast no nível de aplicação. A idéia de se utilizar redes P2P para realizar multicastna camada de aplicação é tornar possível o uso de multicast na rede, visto a ausência de um IP mul-ticast efetivo. A idéia é organizar os clientes em uma rede overlay, onde o multicast é alcançadoatravés da retransmissão dos pacotes via unicast pelos membros da rede. Embora aparentementeisto só eleve a funcionalidade de multicast à camada de aplicação, esta proposta atualmente re-voluciona a forma como as aplicações de rede podem ser construídas. No IP multicast, exceto

pelos nós de borda, a rede é composta por roteadores que não fazem nada mais que encaminharpacotes. Em contrapartida, cada nó na rede overlay é um dispositivo inteligente que contribui comvários tipos de recursos como ciclos de processador, armazenamento entre outros. Esta flexibili-dade pode ser utilizada no desenvolvimento de aplicações que permitem um roteamento flexível,como transmissão de vídeo utilizando redes P2P. Esta seção irá descrever algumas arquiteturas dedistribuição, bem como as vantagens de escalabilidade das propostas.

3.3.3.1. Pseudoserving

A proposta de Pseudoserving [22], foi uma das primeiras técnicas a utilizar redes P2P para auxiliaro servidor na tarefa de distribuição do conteúdo. Ela fornece uma solução para o problema de altorequisito de banda nos servidores, combinando elementos de caching e mecanismos de incentivo.Pseudoserving parte da observação que usuários em posse de conteúdo popular de um servidorcongestionado estão em posse de um recurso muito valioso. Se houver incentivos para compar-tilhar este recurso, o congestionamento próximo ao servidor pode ser evitado e a capacidade dosistema aumentada, o que contribui para um serviço escalável e de melhor qualidade para todos osusuários.

A proposta de Pseudoserving consegue incentivar os usuários a contribuírem com a dis-seminação do conteúdo através de um contrato com uma entidade chamada super-servidor. Nestecontrato, o super-servidor garante ao usuário a localização de uma cópia do arquivo de mídia re-quisitado e, em troca, o usuário em questão deve servir outros usuários com o arquivo recebidopor um período de tempo específico.

A arquitetura do sistema é formada por dois componentes: o super-servidor e um conjuntode pseudo-servidores. O super-servidor fornece acesso ao conteúdo em troca de alguma quantiade recursos de rede e armazenamento especificados através de um contrato. Em condições debaixa demanda esta quantia é zero, situação em que o super-servidor funciona como um servidortradicional e os pseudo-servidores como clientes. Sob condições de alta-demanda, quando oslimites de concorrência do servidor tenham se excedido, o super-servidor necessita de recursose a forma de obtê-los é conceder acesso imediato a um pseudo-servidor. Nestas circunstâncias,o super-servidor fornece ao pseudo-servidor uma referência para o local onde o conteúdo podeser obtido, e após receber o conteúdo, o pseudo-servidor serve as requisições subseqüentes atéa expiração de seu contrato. Observe que este comportamento da arquitetura tem como objetivoevitar situações de flash crowds [22, 35], visto que os clientes tornam-se pseudo-servidores sobdemanda.

As seções subseqüentes descrevem os componentes arquiteturais em mais detalhes. Paraefeito de esclarecimento, será considerado como cliente o pseudo-servidor que não tenha recebidoo conteúdo requisitado. Faremos distinção entre um cliente desta arquitetura e o cliente encontradoem um sistema cliente-servidor nos referindo ao último como cliente tradicional.

O Pseudo-servidor

O pseudo-servidor executa essencialmente as mesmas tarefas no acesso ao conteúdo doque um cliente tradicional. No entanto, conta com a funcionalidade adicional de poder serviroutros clientes com o conteúdo recebido. As mensagens trocadas entre pseudo-servidor e super-servidor podem ser descritas da seguinte maneira:

• Quando envia uma requisição, o pseudo-servidor envia informação sobre o nome do con-teúdo desejado e sobre os recursos que ele deseja doar em troca do acesso imediato ao

conteúdo. Estes recursos incluem o intervalo de tempo e o número de clientes que o mesmodeseja servir durante o intervalo de tempo em que este irá atuar como servidor.

• O super-servidor pode enviar o arquivo diretamente para o pseudo-servidor, sendo que nestecaso o pseudo-servidor é questionado em relação a contribuir com alguma quantia de recur-sos, obviamente não excedendo os limites informados pelo pseudo-servidor no momentoda requisição. Vale salientar novamente que esta quantia pode ser zero, por exemplo, emcondições de baixa demanda. Existe a possibilidade do pseudo-servidor receber uma infor-mação de que não é possível serví-lo imediatamente. Neste caso, é informado a expectativade tempo que o mesmo deve esperar antes que o acesso ao conteúdo seja concedido, estetempo calculado em função dos recursos que ele deseja contribuir. Finalmente, caso o con-trato tenha sido estabelecido, pode ser enviado ao pseudo-servidor uma referência a umnó o qual ele pode imediatamente receber o conteúdo. Como medida de segurança, umchecksum para o conteúdo é enviado junto com a referência. Seu propósito é permitir aopseudo-servidor detectar se o arquivo que ele recebeu do respectivo nó foi modificado.

É interessante esclarecer o que um contrato abrange sobre a perspectiva do pseudo-servidor.Em troca de ser servido, o pseudo-servidor garante manter o arquivo que ele recebeu por certo pe-ríodo de tempo. Dentro deste período de tempo contratual, ele concorda em servir o arquivo atédeterminado número de vezes conforme especificado no contrato. Se nenhum cliente chegar den-tro deste período, o pseudo-servidor é liberado de sua obrigação com o super-servidor. Ele tambémé liberado de sua obrigação logo que tenha servido o número de clientes que ele concordou emservir, independente da expiração do intervalo de tempo.

O Super-servidor

Esta seção tem por objetivo descrever o modo como o super-servidor trata as requisições.Para um melhor entendimento, usaremos a Figura 3.19 para descrever o funcionamento. Assumacomo sendo C a capacidade que o super-servidor reserva para servir clientes tradicionais e pseudo-servidores que não tenham satisfeito o contrato, e PSC como sendo a capacidade reservada paraservir pseudo-servidores que sigam o contrato.

Partindo do topo da Figura, podemos observar que as requisições são tratadas diferen-temente, dependendo do tamanho do arquivo requisitado. Se o arquivo é pequeno, o cliente éservido imediatamente pelo super-servidor (Passo 1). Caso contrário, o super-servidor checa seum pseudo-servidor existe para o conteúdo requisitado (Passo 2). Se existe (Passo 3) e as condi-ções do contrato são satisfeitas, o super-servidor diz ao cliente a localização do pseudo-servidormais próximo contendo o arquivo (Passo 4). Informações a respeito dos recursos do cliente e seuendereço IP são armazenados na memória principal do super-servidor, indexados pelo nome doarquivo e pela localização do cliente baseada em seu endereço IP. Esta informação é armazenadapara ser usada em benefício de futuras requisições para o mesmo arquivo.

Se nenhum pseudo-servidor para o conteúdo existe (Passo 5), mas o número de pseudo-servidores que o super-servidor está servindo não tenha chegado a PSC (Passo 6) e o contratotenha sido satisfeito, o próprio super-servidor serve o arquivo para o cliente (Passo 7). Se estelimite tenha sido alcançado (Passo 8), mas o número de clientes tradicionais que o super-servidorestá servindo seja menor que C, então o super-servidor serve o arquivo para o cliente (Passo 9).Esta rota “gratuita” também ocorre mesmo quando um contrato não tenha sido satisfeito (Passo10). Isto é para assegurar que o super-servidor forneça ao menos o mesmo acesso a todos osnós, independente de sua habilidade de contribuir com recursos, como um servidor tradicional

Figura 3.19. Fluxograma do pseudo-servidor

faria com um cliente. Finalmente, quando não é possível dar uma referência a um cliente e não épossível servir um cliente porque a capacidade do servidor foi alcançada, é dito para o cliente paratentar novamente mais tarde (Passo 11).

Políticas de Contrato

O poder de um super-servidor vem de sua abilidade em fazer contratos. Ele pode fa-zer contratos de acordo com a demanda para seus recursos. Conforme a demanda aumenta, osuper-servidor pode criar contratos que favorecem a criação de recursos adicionais. Se a demandadiminui, poucos recursos são necessários e assim as condições do contrato podem ser aliviadas.Assim, esta seção considera os requisitos que guiam o estabelecimento de políticas eficazes decontrato e que propõem tal política.

A fim garantir acesso rápido aos usuários, duas condições necessitam ser estabelecidas.A primeira relaciona-se ao acesso do arquivo requisitado. É desejado que um pseudo-servidorexista para que possa satisfazer uma requisição quando a mesma chega. Isto pode ser alcançadoacumulando pseudo-servidores conforme necessário até que o número dos pseudo-servidores sejasuficientemente grande para tratar a taxa em que as requisições chegam. Isto, por sua vez, pode seralcançado estipulando no contrato que os pseudo-servidores devem tratar mais de uma referência.Este modo de expansão continua até que o tamanho do pool de pseudo-servidores seja igual aoproduto da taxa de requisições pelo tempo que ele demora para realizar o download do conteúdo.Quando isto acontece uma referência pode ser dada assim que chegar uma requisição, e o contratopode ser reduzido de modo que cada pseudo-servidor necessite servir somente uma referência paramanter o tamanho do pool.

Sob tais circunstâncias, o super-servidor está no modo estacionário. Se a taxa das requi-

sições cair, poucos pseudo-servidores serão necessários, e o super-servidor pode entrar no modode contração. Neste modo, são dadas simplesmente a clientes que fazem requisições durante osperíodos de demanda reduzida as referências de onde conseguir o conteúdo, sem nenhuma neces-sidade de seus recursos. Se houver tantos períodos de contração quanto períodos de expansão, opseudo-servidor trata em média somente uma referência.

A segunda condição relaciona-se à distribuição do arquivo requisitado. É desejado que osenlaces entre um cliente e o pseudo-servidor que ele recebe o arquivo estejam sem congestiona-mento. Para isto, é necessário que os clientes possam receber o conteúdo sem atravessar enlacescongestionados. Isto no entanto, requer o conhecimento do tráfego de rede global e não podeconseqüentemente ser feito sem implicar em uma grande quantidade de overhead. Uma aproxi-mação mais razoável deveria aliviar a condição: melhor que procurar uma solução que garantaque o conteúdo possa ser recebido de locais que não atravessam enlaces congestionados, é utilizaruma solução que garanta que o conteúdo possa ser recebido de locais que, na média, são menoscongestionados do que se o conteúdo for recebido diretamente do servidor. Isto pode ser feitono framework de pseudoserving criando contratos baseados no padrão das requisições vindo degrupos de redes de enlaces próximos, ou de clusters de rede, e fazendo referências somente a umpseudo-servidor situado no mesmo cluster de rede que o cliente.

3.3.3.2. O sistema CoopNet

O surgimento de propostas como a de PseudoServing, mostrou os potenciais beneficíos de seutilizar arquiteturas baseadas em redes P2P para distribuição de conteúdo. Isto motivou diversaspesquisas na área. O sistema CoopNet [35] propõe um arquitetura de distribuição de vídeo híbrida,que mescla aspectos da arquitetura tradicional cliente-servidor com aspectos de redes P2P. Comona arquitetura cliente-servidor, existe um servidor encarregado de fornecer o conteúdo para osclientes que desejam conectar-se na rede. No entanto, em momentos de sobrecarga, os clientesutilizam os recursos ociosos que possuem para auxiliar o servidor na distribuição do conteúdo,fornecendo grande escalabilidade ao sistema.

Um fato que distingue o sistema CoopNet dos sistemas P2P puros, como o Gnutella porexemplo, é que o CoopNet visa complementar ao invés de substituir a arquitetura cliente-servidor.De fato, como mencionado acima, existe um servidor que armazena o conteúdo e o serve aosusuários. O sistema CoopNet é invocado somente quando o servidor não consegue tratar a cargaimpostas pelos clientes, isto é, quando o número de usuários ultrapassa sua capacidade de concor-rência ou de largura de banda. No caso de conteúdo sobre-demanda, os clientes efetuam cache dasmídias de áudio e vídeo que eles receberam recentemente. Assim, em um período de sobrecarga,o servidor redireciona novas requisições para os clientes que possuem o conteúdo. No caso deconteúdo ao vivo, os clientes formam um árvore de distribuição multicast tendo o servidor comoraiz. Os clientes que recebem o conteúdo do servidor o repassam a um ou mais clientes dentro dasua árvore de distribuição.

Neste tipo de sistema, é muito comum os clientes permanecerem na rede por um pequenoperíodo de tempo, cerca de alguns minutos, inferior ao que se observa em sistemas P2P de com-partilhamento de arquivo. Isto acaba acarretando em rupturas na árvore de distribuição, o queocasiona desconexão de outros clientes que estão recebendo fluxo de vídeo. Embora os clientesdesconectados possam continuar a utilizar o serviço entrando novamente na árvore de distribuição,este processo demanda tempo e pode resultar em interrupção da recepção de vídeo. Descontinui-dades podem gerar um efeito cascata, onde os clientes não satisfeitos por terem tido o serviço in-terrompido podem deixar o grupo, ocasionando mais saída de clientes, o que pode resultar em umserviço de transmissão de vídeo inaceitável. O sistema CoopNet minimiza este tipo de problema

utilizando múltiplas árvores de distribuição e codificando o vídeo utilizando múltiplos descritores(Seção 3.3.2.2). Neste método o sinal de áudio e vídeo é codificado em vários streams separados,chamados de descritores, onde cada descritor pode ser individualmente decodificado em um sinalcom ruído. Dessa forma, se cada descritor for transportado por uma árvore de distribuição dife-rente, tem-se que o fluxo não é totalmente interrompido quando ocorre uma desconexão. Ao invésdisso, apenas um subconjunto dos descritores deixa temporariamente de ser entregue, ocasionandouma queda momentânea na qualidade de fluxo recebida, obtendo dessa forma um vídeo de menorqualidade.

Arquitetura CoopNet

A arquitetura do sistema é formada por dois componentes: um servidor e um conjuntode clientes. O servidor fornece o conteúdo de vídeo para os clientes e gerencia o processo deentrada e saída dos nós através de uma árvore de distribuição. Os clientes são um conjunto denós heterogêneos que formam a rede P2P cuja função é receber e repassar o conteúdo de vídeopara outros nós. A interação entre cliente e servidor durante o processo de entrada na árvore dedistribuição pode ser descrita da seguinte maneira:

1. Quando um cliente deseja receber o conteúdo de vídeo ele envia uma mensagem ao servidorpara se juntar a árvore de distribuição. Em adição ao nome do conteúdo desejado, o clienteinforma ao servidor sua largura de banda disponível para servir futuras requisições.

2. O servidor responde com uma lista de possíveis nós pai (chamaremos de pai um nó maisacima na hierarquia em relação ao nó em questão) para o cliente, um para cada árvore dedistribuição. O cliente envia imediatamente uma mensagem para cada um dos nós pai quelhe foi informado pelo servidor para juntar-se a respectiva árvore de distribuição e receberos descritores.

O servidor na arquitetura CoopNet se difere essencialmente de um servidor de streamingcomum por possuir a capacidade de repassar a funcionalidade de servir clientes para os nós queformam a rede P2P. Isto ocorre em situações onde o servidor não dispõe mais de recursos paraservir qualquer cliente. Assim podemos dizer que o servidor possui dois estados distintos:

• Número de clientes≤Capacidade: Neste estado, o servidor envia diretamente o conteúdode vídeo para o cliente.

• Número de clientes > Capacidade: Neste estado, o servidor está com sua capacidadeesgotada e neste caso escolhe um cliente na árvore de distribuição para servir o novo cliente.

É esperado que neste modelo de distribuição o servidor possua recursos suficientes paraefetuar o processamento de entrada e saída dos nós na árvore de maneira eficiente. Em relação alargura de banda, o servidor não é sobrecarregado visto que a carga de distribuição do conteúdode vídeo é compartilhada por todos os nós. A centralização simplifica o protocolo mas introduzum único ponto de falha ao sistema. Entretanto, no contexto da proposta, o ponto de centralizaçãoé o próprio servidor que também é a origem do conteúdo. Se a origem do conteúdo falha, não faza mínima diferença se o gerenciamento da árvore também falha. Além disso, vale salientar que oobjetivo do CoopNet é complementar, não substituir, a arquitetura cliente-servidor.

O servidor tem total conhecimento da topologia de todas as árvores de distribuição. Quandoum novo nó i deseja entrar no sistema, ele primeiro contacta o servidor. Este nó i informa o nome

do conteúdo e sua respectiva largura de banda. Através da taxa de transmissão de vídeo e da lar-gura de banda informada por este nó, o servidor estima o número de clientes que o nó i poderáservir no futuro. Após, o servidor envia uma resposta para o nó i com uma lista de nós pai, sendoum nó j por árvore de distribuição. Esta escolha é feita da seguinte maneira: a partir do servidor,o procedimento desce a árvore até encontrar um nível onde existam um conjunto de nós, que re-presentaremos por V , com capacidade suficiente para servir o nó i. O servidor então escolhe umdestes nós j ∈V aleatoriamente para servir como pai do nó i. Observe que este procedimento top-down assegura uma árvore pequena e balanceada, o que tende a minimizar o atraso fim-a-fim entreo servidor e os nós clientes. Isto também contribui para a diminuição da probabilidade de disrup-ção dos ramos da árvore no caso em que ocorra a saída de um nó pai. Após receber a mensagemdo servidor, o nó i envia mensagens para os nós pais designados em cada árvore de distribuiçãopara entrar na árvore como nó filho. Em termos de custo de mensagens, o servidor envia e recebeuma mensagem por nó i. Cada nó pai j também recebe e envia uma mensagem (uma confirmação)por nó i. O nó i envia e recebe M + 1 mensagens, onde M é o número de árvores de distribuiçãousadas.

O processo de saída de nós do sistema é divido em duas classes: saída informada e falhasde nós. Em uma situação ideal, o nó p que deseja sair informa ao servidor sua intenção de deixaro sistema. Neste caso, para cada árvore de distribuição, o servidor identifica os filhos do nó p eexecuta uma nova operação de entrada destes nós no sistema, seguindo o procedimento top-downdescrito anteriormente. O custo de mensagens para o servidor deve ser no máximo ∑i di envios e∑i di recebimentos, onde di expressa o número de filhos do nó p na i-ésima árvore de distribuição.Cada nó filho qi envia e recebe M + 1 mensagens. Para reduzir este volume de mensagens, oservidor poderia determinar um novo pai ki para cada um dos nós filhos qi em cada árvore dedistribuição e então designar um outro nó x para comunicar esta informação para cada nó filhoqi (preferencialmente o nó x deve ser p caso este ainda esteja disponível). Neste caso, o servidorenviaria e receberia somente uma mensagem.

Uma falha de nó no sistema corresponde ao evento em que o nó que deseja partir nãoinforma o servidor sobre sua intenção de deixar o sistema. Isto ocorre em situações em que onó é desligado, em que ocorre uma falha de hardware ou quando o nó é desconectado da rede.Para tratar este tipo de problema é utilizado uma técnica baseada na perda de pacotes. Nestatécnica, as falhas de nós são tratadas como um caso especial onde a perda de pacotes percebidaspelos descendentes do nó com falha é de 100%. Cada nó i monitora sua respectiva taxa de perda depacotes em cada árvore de distribuição. Quando a taxa de perda de pacotes ultrapassa determinadolimiar t, o nó i contacta seu pai j para verificar se ele está sofrendo o mesmo problema. Caso esteja,a origem do problema é a banda de entrada do nó pai j e neste caso, o nó i deixa seu pai lidar como problema. Caso o nó j não esteja sofrendo do mesmo problema ou o mesmo não responda, o nói entra em contato com o servidor para entrar novamente no sistema.

3.3.3.3. O sistema SplitStream

As propostas convencionais baseadas em árvores de distribuição geralmente não são justas como ambiente cooperativo. A razão disto é que em qualquer árvore de distribuição, a carga de du-plicar e encaminhar o tráfego multicast é carregada por um pequeno conjunto de nós que são nósinteriores na árvore de distribuição. A expectativa em um ambiente cooperativo é que todos osnós compartilhem a carga de encaminhar o conteúdo. No entanto isto não acontece, pois os outrosnós que são as folhas da árvore acabam por não contribuir com nenhum recurso ao sistema dedistribuição. Este problema é ainda agravado quando se tem aplicações com altos requisitos delargura de banda, como transmissão de vídeo por exemplo, onde muitos dos nós não tem a capaci-dade e a disponibilidade requerida como a de um roteador em sistema multicast convencional. O

sistema SplitStream [10, 11] visa resolver estes problemas, visto que possibilita uma distribuiçãocooperativa eficiente de conteúdo em uma rede P2P.

A arquitetura SplitStream distribui a carga de encaminhar o conteúdo que antes estavasomente nos nós internos para todos os nós participantes da árvore de distribuição. A idéia édividir o conteúdo em k sub-fluxos (stripes) e realizar a distribuição de cada sub-fluxo usando umaárvore de distribuição diferente. O objetivo é construir uma floresta de árvores de distribuição talque um nó interior em uma árvore é um nó folha em todas as outras árvores. Dessa forma, a cargade encaminhar o tráfego pode ser distribuída por todos os nós participantes do sistema.

O SplitStream ainda oferece robutez no tratamento de falhas de nós e saídas repentinas dosistema. Dado que um nó é interior em somente uma árvore, as falhas que este pode causar sãosomente percebidas na recepção de um sub-fluxo. Com uma apropriada codificação do conteúdode mídia, como a utilização da codificação MDC descrita anteriormente, as aplicações podemmascarar ou minimizar os efeitos das falhas ocorridas nos nós mesmo quando a árvore afetadaestá sendo reparada.

O sistema SplitStream tem como objetivo construir de forma eficiente uma floresta deárvores de distribuição, de forma escalável, auto-organizável e descentralizada. Para isto utilizauma rede overlay P2P chamada Pastry [42] e um sistema de comunicação em grupo chamadoScribe [9], o qual é usado para construir e manter as árvores de distribuição. Isto será visto commais detalhes na próxima Seção.

Funcionamento do Sistema

Em todos os sistemas multicast baseados em uma única árvore de distribuição, os nósparticipantes são ou nós interiores ou nós folhas dentro da topologia da árvore. Nestes sistemassão os nós interiores que carregam toda a carga de encaminhar as mensagens multicast. Paramelhor compreender este fato, suponha a existência de uma árvore hipotética balanceada de grauf e altura h. Nesta árvore o número de nós interiores é f h−1

f−1 e o número de nós folhas é f h. Istoimplica que a fração de nós folhas cresce com f . Desse modo, mais da metade dos clientes sãonós folhas em uma árvore binária e cerca de 90% o são em uma árvore de grau 16. Observe queneste segundo caso toda a tarefa de distribuição de conteúdo é desempenhada por menos de 10%dos clientes [11]. Isto acarreta em um ambiente cooperativo injusto na distribuição do conteúdo.

Uma forma de resolver o problema é utilizar múltiplas árvores de distribuição e codifica-ção em múltiplos descritores, já que na arquitetura SplitStream um nó é admitido como nó interiorem uma única árvore de distribuição. Além disso, se o fluxo não fosse subdividido em descritoresde tamanhos menores, seria impraticável um cliente admitir vários outros abaixo de si, já que abanda de saída demandada seria muito grande [26].

Para realizar o gerenciamento distribuído das árvores de distribuição, o sistema SplitS-tream utiliza os protocolos Pastry e Scribe. No Pastry identificadores aleatórios são atribuídos aosnós e aos objetos de conteúdo. Baseado nestes identificadores, os nós mantém tabelas de rotea-mento que relacionam seus vizinhos próximos na rede overlay. A procura pelo conteúdo é roteadapelo Pastry para o nó que tenha o identificador mais próximo do identificador do objeto, utilizandoas tabelas de roteamento. O protocolo Scribe é baseado no Pastry e implementa um sistema degrupo multicast. Cada grupo possui um identificador, o qual define o nó que é a raiz do grupomulticast. A raiz recebe as mensagens do grupo e as distribui para todos os membros. Devido ànatureza distribuída desta abordagem, consegue-se ter um desempenho eficiente mesmo com umgrande número de grupos constituídos por diversos membros. Ainda, é possível tratar constantes

admissões e desconexões de membros nos diferentes grupos de rede [26].

Figura 3.20. Exemplo de distribuição com o sistema SplitStream (Fonte: [11])

A Figura 3.20 ilustra como o SplitStream realiza o balanceamento da carga entre os nósparticipantes. Neste exemplo simples, o conteúdo original é dividido em dois sub-fluxos e en-caminhado para árvores de distribuição separadas. Por questões de simplicidade, assuma que oconteúdo original tem um requerimento de banda de B, e cada sub-fluxo tem metade do requeri-mento de banda do conteúdo original. Cada nó com exceção da fonte recebe os dois sub-fluxos,induzindo a banda de chegada um requerimento de B. Observe que na Figura 3.20, cada nó éinterno em somente umas árvores e encaminha o sub-fluxo para dois nós filhos, produzindo umabanda de saída com não mais que B.

Em geral, o conteúdo na arquitetura é dividido em k sub-fluxos distintos. Os nós partici-pantes podem receber um subconjunto de sub-fluxos, dessa forma controlando seus requerimentosde banda de chegada em incrementos de B/k. De forma similar, os nós participantes podem con-trolar seus requerimentos de banda de saída em incrementos de B/k limitando o número de filhosque os mesmos adotam. Assim, o SplitStream acomoda nós com diferentes larguras de bandas enós com larguras de banda de entrada e saída assimétricas [11].

Utilizando os protocolos Pastry e Scribe, projetou-se as principais operações de gerencia-mento de árvores de distribuição do sistema SplitStream. Por exemplo, para a realizar a admissãode um cliente como nó interior em apenas uma árvore, usa-se prefixos distintos nos identificadoresde grupos das diferentes árvores multicast. Com isso, somente os clientes que tenham identifica-dores com o mesmo prefixo de um grupo serão nós interiores na árvore multicast daquele grupo,o que ocorre naturalmente através do roteamento do protocolo Pastry. A Figura 3.21 ilustra estecomportamento. A fonte divide o conteúdo e encaminha cada sub-fluxo para cada uma das árvores.Cada sub-fluxo possui um identificador com um dígito diferente para cada um dos grupos. Os nósinteriores das árvores têm seus identificadores compartilhando um prefixo com o identificador dogrupo, logo estes nós são folhas nas outras árvores. Podemos observar na Figura que o nó M temseu identificador começando com 1, e dessa forma é um nó interior na árvore com identificadorcomeçando com o prefixo 1 e folha em todas as demais árvores [11].

O sistema SplitStream é um sistema P2P de fluxo de mídia ao vivo com distribuição sin-cronizada. A principal diferença entre ele e o sistema CoopNet está no gerenciamento distribuídodas árvores de distribuição e no protocolo de admissão. Considerando somente a distribuição de

Figura 3.21. Construção da floresta (Fonte: [11])

conteúdo, pode-se dizer que o SplitStream substitui por completo a arquitetura cliente-servidor.Entretanto, o protocolo distribuído deixa às aplicações a tarefa de disponibilizar o conteúdo a serservido, ou seja, apenas fornece a infra-estrutura necessária à distribuição. Sendo assim, conside-rando que os fluxos de vídeo demandam um grande espaço de armazenamento, eles tendem a seaglomerar em estações mais capacitadas em termos de recursos, formando servidores de armaze-namento na rede [26].

A principal vantagem do SplitStream sobre os outros sistemas está na distribuição da cargade encaminhar o conteúdo entre todos os participantes. Além disso, este sistema implementa asseguintes propriedades:

• Habilidade em lidar com diferentes restrições de largura de banda dos nós;

• Não necessita de componentes de uma infraestrutura centralizada;

• Possui baixo overhead na construção e manutenção da floresta.

Além disso, a distribuição de vídeo em redes P2P apresenta desafios. Um dos problemasé o comportamento egoísta dos usuários, que procuram tirar o máximo de proveito dos recursosda rede, cooperando o mínimo na distribuição dos fluxos. Um outro problema é o curto tempo depermanência dos mesmos no sistema, o que demanda esforços para se contornar as interrupçõescausadas nas entregas dos fluxos quando as deconexões ocorrem. Dessa forma deixar a deci-são de cooperar ou não sob a responsabilidade única dos participantes e sem nenhuma influênciaou incentivo é colocar em risco não somente a eficiência do sistema, mas também a sua própriaviabilidade. Uma possível solução para estes desafios é o uso de mecanismos de incentivo queestimulem os clientes a cooperarem e também a permanecerem conectados durante intervalos detempo maiores, de forma a reduzir os problema de desconexão. Os trabalhos [45, 26] apresen-tam uma série de mecanismos de incentivo, tais como padrões baseados em confiança e padrõesbaseados em comércio.

3.4. OtimizaçõesMuito se tem falado sobre métricas de distância entre nós para tentar melhorar a qualidade dosserviços oferecidos na Internet. Trabalhos como [34, 33] abordam técnicas para tentar estimar alocalização de um nó baseado em seu endereço IP. A idéia é utilizar a localização entre nós da redepara seja possível realizar a escolha de um serviço que seja mais adequado para o usuário. Isto é

especialmente interessante para questões de otimização das técnicas vistas na seção anterior, poispossibilita a construção de árvores de distribuição multicast mais eficientes para redes overlays.

Determinar a localização geográfica de um nó na Internet sabendo somente seu endereçoIP é um grande desafio. A idéia de ter este tipo de informação possibilita uma grande e interessanteclasse de aplicações consciente de localização (location-aware) para nós da Internet. Ao saber alocalização de um nó cliente, uma aplicação, como um serviço web por exemplo, poderia enviar aousuário informação direcionada baseada em sua localização como as de eventos locais, previsãodo tempo regional, propaganda direcionada, entre outras. Além disso seria possível classificar osusuários baseados em sua localização ou mesmo controlar a disponibilidade dos dados efetuandogerenciamento de direitos territoriais semelhantes ao que ocorre nos direitos de difusão de TV.

Muitos dos sistemas de localização atuais são baseados na base de dados Whois [19]. Paracada bloco de endereços IP, o Whois tipicamente grava o nome, endereço, e outras informaçõespertencentes a organização que tem posse do bloco de endereços. Ferramentas baseadas no Whoisusam esta informação de endereço para deduzir a localização correspondente a um determinadoendereço IP. O problema, ocorre quando um ISP de grande porte (ex. AT&T) ou uma organizaçãogeograficamente dispersa (ex. IBM) tenta ser localizada através do Whois. A informação delocalização pode corresponder somente a matriz da organização, o que acaba fornecendo umapequena indicação da localização real do nó em questão.

Uma proposta alternativa usada em alguns sistemas é baseada na execução do traceroute[21] para determinar o caminho de rede a partir de um nó de prova (probe node) para o nó alvo.Os nomes DNS dos roteadores no caminho freqüentemente indicam localização, por exemplo,corerouter1.SanFrancisco.cw.net indica a cidade de São Francisco. Exemplos de ferramentas queexploram esta informação são VisualRoute [46] e GTrace [37].

Nesta seção iremos apresentar três técnicas distintas que tentam solucionar o problemade mapeamento de localização. A primeira, Geotrack, é um refinamento das técnicas existentesbaseadas em traceroute. As outras técnicas, GeoPing e GeoCluster, empregam novas propostasalternativas, e serão abordadas na seqüência.

3.4.1. GeoTrack

A primeira técnica, GeoTrack [34], tenta deduzir a localização baseado nos nomes DNS do nóalvo ou de outros nós de rede próximos. O nome DNS de um nó da Internet as vezes contémdicas sobre sua localização. Operadores de rede freqüentemente inserem nomes geográficos sig-nificativos aos roteadores, presumivelmente para conveniência administrativa. Tal dica, quandopresente, pode indicar localização em diferentes níveis de granularidade como cidade (corerou-ter1.SanFrancisco.cw.net indica a cidade de São Francisco) , estado (www.state.ca.us indica oestado da Califórnia), ou país (www.fapesp.br indica o país Brasil).

A técnica Geotrack se baseia no uso de traceroute para efetuar o mapeamento da locali-zação do usuário. Esta técnica determina o caminho de rede a partir de um nó de prova para onó alvo e então tenta deduzir a localização baseado nos nomes DNS das interfaces dos roteadores(routers labels). A localização do último roteador, isto é, o mais próximo do nó alvo que tenha umrótulo reconhecível é usado como um estimador de localização.

Um roteador é definido como reconhecível se sua localização geográfica puder ser dedu-zida a partir do seu nome DNS. Roteadores que não puderem ter seu endereço IP mapeados emum nome DNS ou que o DNS não contenha nenhuma informação útil sobre sua localização sãoconsiderados como não reconhecíveis.

A técnica GeoTrack ainda incorpora vários refinamentos como:

• Verificação baseada no atraso: São medidos o RTT de cada roteador intermediário ao longode todo o caminho. Se a diferença no RTT entre dois roteadores adjacentes for menor quedeterminado limiar (5 ms por padrão), então é checado se as estimativas da localizaçãocorrespondentes estão separadas a menos que determinado limiar de distância (250 km porpadrão). Caso não estejam, as estimativas de localização para estes roteadores são marcadascomo suspeitas e são ignoradas.

• Multi-source tracing: São realizados traceroutes de várias fontes geograficamente disper-sas. As estimativas de localização para o nó alvo obtidas de todas os nós de prova sãoagregadas para se obter um consenso na estimativa. Esta estimativa tende a ser mais ro-busta que qualquer estimativa individual por causa da diversidade dos caminhos de redeatravessados por cada execução de um traceroute.

3.4.2. GeoPing

A segunda técnica, GeoPing [34] procura determinar a localização geográfica de um nó da Internetexplorando o relacionamento entre o atraso de rede e distância geográfica. A técnica é baseadana premissa que o atraso sofrido pelos pacotes que viajam entre um par de nós em uma rede éfunção da separação geográfica entre os mesmos. Assim, o GeoPing mede os atrasos para um nóalvo através de várias fontes, isto é, utilizando nós de prova em localizações conhecidas e combinaestas medidas de atraso para estimar a localização do nó.

O bom senso na comunidade científica sugere que existe uma fraca relação entre o atrasode rede e a distância geográfica. Isto normalmente é atribuído a presença de caminhos tortuososna Internet e de congestionamento nos enlaces que acabam influenciando as medidas de atraso.Entretanto, nos anos recentes, a Internet tem crescido em passos muito rápidos, tanto em ter-mos de largura de banda como em sua convergência. Isto sugere uma rica conectividade, o quefreqüentemente implica em menos circuitos tortuosos.

Devido a dificuldade de se construir um modelo matemático preciso que capture o rela-cionamento entre o atraso e a localização geográfica, o GeoPing utiliza uma proposta chamadade vizinho mais próximo no espaço de atraso (Nearest Neighbor in Delay Space - NNDS). Estaproposta é motivada pela observação que nós com atrasos de redes similares em relação a outrosnós fixos tendem a estar localizados próximos.

O primeiro passo no NNDS é realizar a construção de um mapa de atrasos que armazenao relacionamento entre o atraso e a localização. Cada entrada neste mapa de atraso contém:

• as coordenadas para um nó em uma localização conhecida;

• um vetor de atrasos, DV = (d1, ...,dN), contendo as medidas mínimas de atraso de um nó apartir de N nós de prova em localizações conhecidas.

O mapa de atrasos constitui os dados de treinamento e é construído offline. Quando de-sejamos determinar a localização de um novo nó T , realizamos as medidas de atraso a partir dosN nós de prova. Então é construído um vetor de distância para T , na forma DV ′ = (d′1, ...,d

′N).

Após, procuramos dentro do mapa de atrasos encontrar um vetor de distância, DV , que melhor seassemelhe a DV ′.

Para encontrar a melhor combinação, é considerado que os vetores de distância do mapa deatrasos estão em um espaço de dimensão N. Então realizamos a procura do vizinho mais próximode DV ′ neste espaço. Para isto, utilizamos a distância Euclidiana entre DV e DV ′, realizada pelaseguinte cálculo

√(d1−d′1)2 + ...+(dN −d′N)2. A estimativa de localização para T é a mesma do

vizinho encontrado pelo método. Além disso, a localização de T é também armazenada no mapade atrasos.

Vários aspectos do NNDS contribuem para sua robustez:

• A medida de atraso é feita de várias localizações distribuídas ao invés de uma única locali-zação;

• O valor mínimo entre várias amostras de atraso é considerado ao invés de amostras de atrasoindividuais;

• as medidas de atraso são usadas como uma assinatura da localização geográfica, ao invésde ser diretamente traduzida em coordenadas de distância e localização.

3.4.3. GeoCluster

A terceira técnica, GeoCluster [34] é diferente das anteriores no sentido de não depender demedidas ativas de rede. Ao invés disso, ela combina informação de mapeamento da forma IP-localização com a informação do prefixo Border Gateway Protocol (BGP) para deduzir a localiza-ção do nó de interesse. Esta informação de mapeamento IP-localização é obtida através de bancode dados de registros de usuários, oriundos de algum site por exemplo. Estes dados são parciaisno sentido que somente incluem um número relativamente pequeno de endereços IP. No entanto ainformação do prefixo BGP foi usada para expandir a convergência destes dados, identificando osclusters de endereço IP que são prováveis que estejam localizados na mesma área geográfica.

No GeoCluster primeiramente o espaço de endereçamento IP é quebrado em clusters deforma que todos os nós com endereços IP dentro de um mesmo cluster são prováveis de estaremco-localizados. Então, conhecendo a localização correspondente de alguns nós em um cluster atécnica deduz a localização do cluster inteiro.

A chave para operação do GeoCluster é o mapeamento da informação IP-localização ob-tidos das bases de dados. Entretanto, a informação destas bases muitas vezes possuem erros noscadastros, seja por parte do usuário, seja pelo acesso através de servidores proxy que não traduzema real localização do usuário.

O GeoCluster tenta solucionar estes problemas agrupando os endereços IP de acordo comsua provável localização. Este processo ajuda a expandir a cobertura da informação parcial demapeamento IP-localização. A agregação desta informação de localização também possibilitaidentificar e eliminar erros causados pelas entradas grosseiras nos dados de localização.

Como exemplo, suponha que saibamos que 128.127.126.0/24 forma um cluster geográ-fico. Além disso, assuma que a informação de mapeamento nos diga que a localização correspon-dente para 10 endereços IP neste cluster está em São Paulo enquanto que um outro endereço IPesteja no Rio Grande do Sul. Então é razoável deduzirmos que o dado do Rio Grande do Sul estáerrado e que todos os 256 endereços IP no cluster são prováveis de corresponder a nós que estãoem São Paulo (ou nas proximidades).

A alocação de endereços e o roteamento na Internet é feita de forma hierárquica. Asinformações de roteamento são agregadas a partir de nós que estão em um único domínio admi-nistrativo, também conhecido como um sistema autônomo (Autonomous System - AS). As rotas

para nós dentro de um AS são anunciadas para o resto da Internet como um único agregado, comopor exemplo através do prefixo de endereço 128.127.0.0/16 , ao invés de 65536 endereços IPsindividuais. Então o conhecimento destes prefixos de endereço (Address Prefixes - APs) usadospelo protocolo de roteamento nos abilita a identificar clusters topológicos.

A informação sobre APs foi derivada do BGP que é utilizado para roteamento entre domí-nios (inter-AS) na Internet. Cada entrada na tabela BGP no roteador especifica um destino AP e ocaminho principal a nível de AS para ele. Como a técnica se preocupa somente com a informaçãosobre AP, é construído uma lista de APs únicos, em [34] em torno de 100000 APs. O número deAPs é de grande ordem de magnitude que o número de ASs. Isto porque um AS, como um ISP porexemplo, pode anunciar rotas mais específicas devido a políticas ou considerações de desempenho(por ex. balanceamento de carga).

Por questões de escalabilidade, freqüentemente ISPs de grande porte anunciam seus res-pectivos APs como um único agregado. Nestes casos, um único AP pode abranger uma grandeárea geográfica. Este problema poderia ser aliviado se tivéssemos conhecimento de mais detalhesde como o agregado é subdivido pelo protocolo de roteamento dentro do domínio (intra-domain).Entretanto, obter este tipo de informação é um tanto quanto complicado e dessa forma, a técnicausa somente a informação de roteamento entre-domínios derivada do BGP.

Uma variante da técnica usa um algoritmo chamado de sub-clustering para subdividirAPs que tenham uma grande área de cobertura. A idéia é primeiramente identificar os clustersgeográficos, utilizando os APs contidos nas tabelas de roteamento BGP para definir o conjuntoinicial destes clusters. Então a lista é podada usando o algoritmo sub-clustering que verifica seexiste consenso suficiente nas estimativas da localização correspondente a um cluster (baseadona informação de mapeamento parcial IP-localização). Caso não tenha, o algoritmo subdivide ocluster em duas metades (produzindo dois ou mais APs específicos a partir do original) e repeteo processo para cada uma das partes. O algoritmo encerra quando a subdivisão contém poucasentradas de mapeamento IP-localização para uma determinação confiável do cluster geográfico.Assim dado um endereço IP, é feita uma procura para determinar o cluster que o endereço pertence,visando um AP com prefixo mais longo possível.

3.4.4. Desempenho

Em [33] é apresentado um comparativo das três técnicas realizado a partir de resultados experi-mentais. O experimento consistia em utilizar 14 nós de prova distribuídos geograficamente portodo os EUA. Estes nós foram usados tanto para iniciar traceroutes para o GeoTrack como pararealizar as medidas de atraso para o GeoPing. Para o GeoCluster, a informação de mapeamentofoi obtida a partir de várias fontes de dados incluindo cadastros de webmail, sites de hospedageme guia de programação de TV on-line.

A Figura 3.22 ilustra a curva da função de distribuição cumulativa (CDF) para o erro daestimativa da localização para as três técnicas. Os nós alvos foram escolhidos a partir de servi-dores localizados em campus de várias universidades americanas. De acordo com os resultados,a técnica GeoCluster é capaz de deduzir a localização de apenas 233 dos 265 nós, isto é, algoem torno de 88%. Isto devido principalmente a qualidade dos dados de mapeamento utilizadosno experimento. Apesar disso, podemos observar na Figura que o GeoCluster consegue realizardeduções significativamente melhores que o GeoPing e o GeoTrack. Se pegarmos a média e asmarcas de 80% das três curvas, teremos os seguintes números, de acordo com a Tabela 3.2:

Figura 3.22. CDF do erro das medidas de distâncias para o GeoTrack, GeoPing eGeoCluster (Fonte: [33])

Tabela 3.2. Erro médio e marca em 80% das três curvas da Figura 3.22

Técnica Erro Médio Marca em 80%GeoCluster 28 Km 226 KmGeoTrack 102 Km 284 KmGeoPing 382 Km 1201 Km

Assim, fica fácil observar que, o GeoCluster realiza deduções sobre a localização de umnó melhor que as outras duas técnicas.

Muitos clientes estão atrás de servidores proxy ou de firewalls. Isto é muito comum emambientes empresariais ou nas redes dos ISPs. Este tipo de configuração é realizada por questõesde desempenho e segurança, mas acabam por separar o cliente do resto da Internet. O endereçoIP dos nós clientes permanecem ocultos da rede externa, o que pode ser problemático para omapeamento de localização. Em alguns casos o cliente e o servidor proxy podem estar em regiõespróximas (ex. um servidor proxy no campus de uma universidade). Entretanto, em outros casoseles podem estar geograficamente dispersos. Um exemplo disto é a rede da AOL [2], a qual temum cluster centralizado de servidores proxy em uma localização (Virgínia) para servir clienteslocalizados por todos os EUA.

Servidores proxy impõe uma limitação fundamental sobre todas as técnicas de mapea-mento de localização que dependam do endereço IP do cliente. Isto inclui técnicas baseadas emWhois, traceroute (ex. GeoTrack) e medidas de atraso da rede (GeoPing). A técnica GeoGlus-ter é uma exceção pelo fato de freqüentemente ser capaz de identificar quando sua estimativa delocalização é provável de ser errônea. Isto é possível através do mapeamento do prefixo AP coma localização. Quando os clientes estão em regiões como uma universidade ou conectando porum ISP através de um servidor proxy local ou regional, o GeoCluster consegue identificar as lo-calizações de forma satisfatória. No entanto, em casos como o da AOL em que os clientes estãogeograficamente dispersos compartilhando um pool de servidores proxy, o GeoCluster pode nãoconseguir um consenso nos dados para que seja capaz de indentificar os clusters. Então ao invésde incorretamente deduzir a localização do cliente baseado no endereço IP do servidor proxy, oGeoCluster poderia privar-se de estimar a localização para estes clientes, considerando que ou-tras técnicas (incluindo GeoTrack e GeoPing) confundiriam a localização do servidor proxy como

sendo a dos clientes.

A técnica GeoCluster ainda oferece vantagens em relação a outras (GeoTrack e Geo-Ping) no sentido de não depender de medidas ativas de rede. No entanto, a eficiência do algo-ritmo sub-clustering depende da disponibilidade de um rico conjunto de dados de mapeamentoIP-localização. Se houver dados insuficientes para certos APs, a técnica será incapaz de determi-nar a localização dos endereços IP que correspondem a estes APs.

Além destas técnicas, outros trabalhos relacionados que endereçam os problemas de loca-lização e distância entre nós são propostos em [25, 32, 12, 44].

3.5. Comentários Finais e Tendências FuturasAtualmente, uma parcela significativa das redes mundiais provê serviços independentes, ofertandosuporte a voz, dados e vídeo de forma isolada. Entretanto, a tendência mundial para os sistemas decomunicação é a convergência destas redes em uma única rede baseada no protocolo IP. As redesconvergentes vêm surgindo como excelente alternativa, agregando tráfego de voz, dados e vídeoatravés de redes com grande largura de banda e proporcionando às operadoras de telecomunicaçõesa redução de custos, o aumento de produtividade e a oferta de novos serviços.

O impacto das redes convergentes apresenta diferentes significados de acordo com o pú-blico alvo a ser alcançado. Para os assinantes, as redes convergentes podem proporcionar a junçãodos equipamentos de mídia, tais como televisão, aparelho telefônico e computador em um únicodispositivo com capacidade de prover acesso a Internet, comunicação por voz e apresentação devídeos e de canais televisivos. Para os tecnocratas, as redes convergentes apresentam-se comoum desafio na busca por uma solução unificada com capacidade suficiente para transportar comqualidade todos os serviços multimídia. Empresas de telecomunicações com infraestrutura paradistribuição de conteúdo poderiam ofertar seus serviços a mais de uma produtora de conteúdo,permitindo o compartilhamento dos recursos e, provavelmente, reduzindo custos e aumentando acapilaridade.

O maior desafio talvez seja a complexidade de se operar, monitorar e gerenciar uma redebaseada no melhor esforço, quando a maioria dos serviços ofertados requer qualidade de serviço.Existe, ainda, a necessidade de garantia de acordo de nível de serviço eficaz, com suporte a dife-rentes níveis de QoS e largura de banda por assinante, que surge em função de um novo modelo denegócios, com a oferta de serviços agregados ao invés de simplesmente prover infra-estrutura. Anecessidade de garantia de SLA ultrapassa a relação tradicional entre o provedor e o assinante, jáque neste novo modelo de negócios, baseado em redes convergentes, há necessidade de estabelecere garantir SLA entre provedores de conteúdo diferentes e, provavelmente, entre redes autônomas.

Atualmente, o fornecimento deste tipo de serviço comercialmente conta com algumaslimitações. Uma delas, é que a maioria dos serviços de TV sobre IP são oferecidos sobre umbackbone proprietário com alcance restrito. As arquiteturas baseadas em P2P procuram solucionaro problema de escalabilidade, onde a meta é oferecer um serviço de alcance global utilizandoa infra-estrutura da Internet. A idéia básica é utilizar os recursos ociosos nos nós clientes, demodo a formar um ambiente totalmente cooperativo. Além disso, estas arquiteturas oferecemoutros benefícios como balanceamento de carga do sistema entre todos os participantes do grupomulticast.

Entretanto, as arquiteturas P2P para transmissão de vídeo também contam com váriaslimitações. Dentre os maiores desafios a serem tratados por estas arquiteturas, destacamos osmecanismos de incentivo a cooperação, a dinamicidade do processo de entrada e saída dos nós nosistema e a complexidade em fornecer qualidade de serviço na Internet pública.

Como áreas interessantes para pesquisa em IPTV cooperativo destacamos as técnicas decompressão e codificação de vídeo em múltiplos descritores, algoritmos eficientes para gerencia-mento da árvore de distribuição multicast e mecanismos que explorem a garantia da qualidade e atarifação do serviço, visando uma adoção comercial deste tipo sistema.

Referências[1] Akamai Inc. A distributed infrastructure for e-business: Real benefits, measurable returns,

2000.

[2] America Online (AOL). http://www.aol.com.

[3] J.G. Apostolopoulos, T. Wong, S.J. Wee, e D. Tan. On multiple description streaming withcontent delivery networks. In INFOCOM, 2002.

[4] A. Basso, C. D. Cranor, R. Gopalakrishnan, M. Green, C. Kalmanek, D. Shur, S. Sibal,C. Sreenan, e J.E. van der Merwe. Prism, an IP-based architecture for broadband accessto TV and other streaming media. In Proccedings of Workshop on Network and OperatingSystem Support for Digital Audio and Video NOSSDAV, Junho 2000.

[5] C. Bastos. TV Digital Terrestre, Minicurso SBRC 2005, Setembro 2005.

[6] V. Becker e C. Montez. TV Digital Interativa: Conceitos, desafios e perspectivas para oBrasil. Editora da UFSC, 2004.

[7] Bittorrent. http://www.bittorrent.com/.

[8] B. Cain, S. Deering, B. Fenner, I. Kouvelas, e A. Thyagarajan. Internet Group ManagementProtocol, Version 3. RFC-3376, IETF, 2002.

[9] M. Castro, P. Druschel, A. M. Kermarrec, e A. Rowstron. SCRIBE: a large-scale and de-centralised application-level multicast infrastructure. IEEE Journal on Selected Areas inCommunications, pp. 1489–1499, 2002.

[10] M. Castro, P. Druschel, A.M. Kermarrec, A. Nandi, A. Rowstron, e A. Singh. Splitstream:High-bandwidth content distribution in a cooperative environment. In Proceedings of the2nd International Workshop on Peer-to-Peer Systems (IPTPS’03), Berkeley, CA, 2003.

[11] M. Castro, P. Druschel, A.M. Kermarrec, A. Nandi, A. Rowstron, e A. Singh. Splitstream:High-bandwidth multicast in cooperative environments. In SOSP ’03: Proceedings of thenineteenth ACM symposium on Operating systems principles, pp. 298–313, New York, NY,USA, 2003. ACM Press.

[12] M. Costa, M. Castro, A.I.T. Rowstron, e P.B. Key. PIC: Practical Internet coordinates fordistance estimation. In ICDCS, pp. 178–187, 2004.

[13] C.D. Cranor, M. Green, C. Kalmanek, D. Shur, S. Sibal, J.E. Van der Merwe, e C.J. Sreenan.Enhanced streaming services in a content distribution network. IEEE Internet Computing,5(4):66–75, 2001.

[14] S. Deering, D.L. Estrin, D. Farinacci, V. Jacobson, C.G. Liu, e L. Wei. The PIM architecturefor wide-area multicast routing. IEEE/ACM Trans. Netw., 4(2):153–162, 1996.

[15] DSL Fórum. http://www.dslforum.org.

[16] Fastweb. http://www.fastweb.it/.

[17] C. Gkantsidis, M. Ammar, e E. Zegura. On the effect of large-scale deployment of paralleldownloading. In WIAPP ’03: Proceedings of the The Third IEEE Workshop on InternetApplications, pp. 79, Washington, DC, USA, 2003. IEEE Computer Society.

[18] Gnutella. http://www.gnutella.com/.

[19] K. Harrenstien, M. Stahl, e E. Feinler. NICKNAME/WHOIS. RFC-954, IETF, Outubro1985.

[20] Akamai Inc. http://www.akamai.com/.

[21] V. Jacobson. Traceroute software, 1989, ftp://ftp.ee.lbl.gov/traceroute.tar.gz.

[22] K. Kong e D. Ghosal. Mitigating server-side congestion in the Internet through pseudoser-ving. IEEE/ACM Trans. Netw., 7(4):530–544, 1999.

[23] F. Kozarmernik e L. Vermaele. Will broadband TV shape the future of the broadcasting?,2005, http://www.ebu.ch/en/technical/trev/trev_302-kozamernik.pdf.

[24] A. Lemos. Anjos interativos e retribalização do mundo: Sobre interatividade e interfaces di-gitais, Setembro 1999, http://www.facom.ufba.br/ciberpesquisa/lemos/interativo.pdf.

[25] Y. Liu, X. Liu, L., L. M. Ni, e X. Zhang. Location-Aware topology matching in P2P systems.In INFOCOM, 2004.

[26] Daniel Antonio Garcia Manzato. Mecanismos de incentivo à cooperação em redes peer-to-peer para distribuição de fluxos de vídeo. Dissertação de Mestrado, Universidade Estadualde Campinas (UNICAMP), Fevereiro 2006.

[27] Microsoft TV: IPTV Edition. http://www.microsoft.com/tv/IPTVEdition.mspx.

[28] Mirror Image Internet Inc. http://www.mirror-image.com/.

[29] J. Moy. Multicast Extension to OSPF. RFC-1584, IETF, 1994.

[30] Napster. http://www.napster.com/.

[31] Internet2’s Abilene Network. http://abilene.internet2.edu, 1999.

[32] T.S. Eugene Ng e H. Zhang. Predicting Internet network distance with coordinates-basedapproaches. In INFOCOM, 2002.

[33] Venkata N. Padamanabban e Lealkshminarayanan Subramanian. Determining the geo-graphic location of Internet hosts. In Proceedings of the 2001 ACM SIGMETRICS inter-national conference on Measurement and modeling of computer systems, pp. 324–325, NewYork, NY, USA, 2001. ACM Press.

[34] V.N. Padmanabhan e L. Subramanian. An investigation of geographic mapping techniquesfor Internet hosts. In SIGCOMM ’01: Proceedings of the 2001 conference on Applications,technologies, architectures, and protocols for computer communications, pp. 173–185, NewYork, NY, USA, 2001. ACM Press.

[35] V.N. Padmanabhan, H.J. Wang, P.A. Chou, e K. Sripanidkulchai. Distributing streamingmedia content using cooperative networking. In NOSSDAV ’02: Proceedings of the 12thinternational workshop on Network and operating systems support for digital audio andvideo, pp. 177–186, New York, NY, USA, 2002. ACM Press.

[36] G. Peng. CDN: Content distribution network. Technical Report TR-125, Stony Brook, NewYork, NY, 2003.

[37] R. Periakruppan e E. Nemeth. GTrace - A Graphical Traceroute Tool. Usenix LISA, Novem-bro 1999.

[38] R. Reisman. Rethinking interactive TV: I want my coactive TV, Setembro 2002, http://www.teleshuttle.com/cotv/CoTVIntroWtPaper.htm.

[39] J. Rocha, M. Domingues, A. Callado, E. Souto, G. Silvestre, C. Kamienski, e D. Sadok.Peer-to-Peer: Computação Colaborativa na Internet, capítulo 1, pp. 3–46. Minicurso SBRC2004, Maio 2004.

[40] P. Rodriguez e E.W. Biersack. Dynamic parallel access to replicated content in the Internet.IEEE/ACM Trans. Netw., 10(4):455–465, 2002.

[41] Pablo Rodriguez, Andreas Kirpal, e Ernst Biersack. Parallel-access for mirror sites in theInternet. In INFOCOM (2), pp. 864–873, 2000.

[42] A. Rowstron e P. Druschel. Pastry: Scalable, decentralized object location, and routing forlarge-scale peer-to-peer systems. Lecture Notes in Computer Science, 2218:329–350, 2001.

[43] Sharman Networks: Kazaa. http://www.kazaa.com/.

[44] L. Tang e M. Crovella. Virtual landmarks for the Internet. In IMC ’03: Proceedings of the3rd ACM SIGCOMM conference on Internet measurement, pp. 143–152, New York, NY,USA, 2003. ACM Press.

[45] Y. Tang, H. Wang, e W. Dou. Trust based incentive in P2P network. In Procedings ofthe EEE International Conference on E-Commerce Technology for Dynamic E-Business, pp.302–305, 2004.

[46] Visualware Inc. Visualroute, http://www.visualroute.com/.

[47] D. Waitzman, C. Partridge, e S. Deering. Distance Vector Routing Multicast Protocol(DVMRP). RFC-1075, IETF, 1988.

[48] Jia Wang. A survey of web caching schemes for the Internet. SIGCOMM Comput. Commun.Rev., 29(5):36–46, 1999.