Implantação e Avaliação de Desempenho de Protocolos de Transmissão Multicast Confiável na RNP

Transcrição

1 Implantação e Avaliação de Desempenho de Protocolos de Transmissão Multicast Confiável na RNP Valter Roesler: roesler@exatas.unisinos.br Unisinos Marinho Barcellos: marinho@exatas.unisinos.br Unisinos, University of Manchester e BT Exact (Inglaterra)

2 Definições básicas Proposta de trabalho Objetivos do GT Multicast Confiável Protocolos a serem avaliados Aplicações a serem analisadas Metodologia de trabalho Fases do projeto Equipe Cronograma 2 de 40

3 Definições básicas 3 de 40

4 Multiponto sem e com Multicast MULTI-UNICAST MULTICAST FON FON ROT A ROT A ROT B ROT C ROT B ROT C ROT D REC 3 ROT F ROT D REC 3 ROT F REC 1 REC 2 REC 4 REC 5 REC 6 REC 1 REC 2 REC 4 REC 5 REC 6 4 de 40

5 Exemplos de Aplicações multicast Transmissão maciça de dados Aplicações tipo push Transmissões multimídia unidirecionais ao vivo (TV, rádio, palestras, conferências) Videoconferências, audioconferências Jogos interativos Aplicações colaborativas 5 de 40

6 Requisitos Típicos para Aplicações Multicast Latência de entrega Jitter Skew Tempo-real (multimídia) Ordenamento de pacotes Confiabilidade Confiável (arquivos) 6 de 40

7 Problemas do multicast confiável Implosão de ACK e NACK 7 de 40

8 Localização do controle de erros em multicast confiável Em protocolos orientados a transmissor Multicast via TCP: não escala devido à implosão de ACKs Em protocolos orientados a receptor: O transmissor nem sempre precisa conhecer os receptores... Menos controle de estado é mantido no transmissor, o que torna o protocolo mais escalável 8 de 40

9 Mecanismo 1 de Controle de Erro ARQ Automatic Repeat Request Controle de erro reativo receptor avisa transmissor da perda de pacotes Seqüência faltante ou via temporizador (no receptor) Necessitam controle de implosão, conforme mostrado anteriormente 9 de 40

10 Mecanismo 2 de controle de Erro FEC - Forward Error Correction Informações de paridade são acrescentadas ao fluxo de dados Receptores podem reconstituir dados perdidos via redundância Vantagens: Receptor não precisa usar NACK dependendo do número de perdas (e quais perdas) Diminui o número de retransmissões multicast Desvantagens: Processamento intensivo para computar códigos de redundância Maior quantidade de dados enviada, mesmo sem erros Problema em antever a taxa de erro da rede para determinar quantidade de redundância Gera atrasos quando receptor perde determinado pacote, pois tem que esperar o final do bloco para reconstituí-lo Sem confiabilidade quando perdas em rajadas 10 de 40

11 Mecanismos híbridos: FEC + ARQ Esquema híbrido FEC + ARQ para reduzir volume de feedback Apenas pacotes que não podem ser reconstituídos são requisitados Exemplo: 16 blocos de dados Transmissor gera um pacote adicional contendo código de paridade para os 16 blocos Um receptor pode reconstituir qualquer um dos 16 blocos através do 17 o pacote Equivalente a uma única retransmissão enviada a todos e que pode recuperar a perda de um pacote qualquer do bloco Perda de dois ou mais pacotes? Nack + retransmissão 11 de 40

12 Outros requisitos do multicast confiável (RFC 3048) Controle de congestionamento Usar uma parcela eqüitativa dos recursos da rede. Algoritmos devem ser tcp tcp-friendly Usar o link de forma eficiente, ou seja, sem excessivo overhead Escalabilidade (não é o foco deste GT) Funcionar com diferentes conjuntos de receptores Trabalhar com diferentes topologias de rede (receptores em redes rápidas e redes lentas (ou congestionadas)) 12 de 40

13 Confiabilidade e transmissão em tempo real Confiabilidade e transmissão em tempo real são objetivos conflitantes A confiabilidade da transmissão é conseguida através de controle de erro (retransmissões), tipicamente gerando atrasos É possível obter transmissões de tempo real (soft( realtime) ) semi-confiáveis, através de mecanismos de FEC Mecanismos de FEC utilizam blocos e o próprio uso de blocos gera atrasos 13 de 40

14 Padronização no Multicast Confiável IETF: Working group on Reliable Multicast Transport RFC 3048 ( (Reliable Multicast Transport Building Blocks...): padroniza sistemas de multicast confiável através de dois conceitos: BB ( (Building Blocks): componentes comuns utilizados por vários protocolos, como mecanismos de FEC, confirmações negativas (NACKs( NACKs), controle de congestionamento e segurança. PI ( (Protocol Instantiations): são os protocolos propriamente ditos, que se utilizam dos BBs necessários e inserem sua lógica de funcionamento. 14 de 40

15 Famílias de protocolos definidas pelo IETF (RFC 3048) NACK-based Reliable Multicast Protocol (NORM ) Protocolos baseados em NACK Tree-based ACK Protocolos baseados em ACK, porém com servidores intermediários a fim de evitar implosões de ACKs. OBS: foi obsoletado Asynchronous Layered Coding (ALC) Protocolos baseados em FEC, não necessitando retransmissões Router Assist Protocolos que necessitam código rodando nos roteadores intermediários. OBS: necessitam redes ativas ou cooperação do fabricante de roteadores, ou seja, atualmente não é viável praticamente 15 de 40

16 Proposta de Trabalho 16 de 40

17 Objetivos Gerais Montar uma estrutura de multicast confiável na RNP, explorando o suporte nativo à multicast atualmente existente Avaliar experimentalmente um conjunto de implementações destes protocolos 17 de 40

18 Protocolos Protocolos com funcionalidade de nível de transporte na prática estão acima do nível de transporte, mas possuem funcionalidades típicas de nível de transporte Ficam fora do kernel,, no nível de aplicação (como bibliotecas que podem ser utilizadas pelo usuário) 18 de 40

19 Protocolos a serem analisados MDP / NRL: implementação do Multicast Dissemination Protocol em desenvolvimento pelo Naval Research Laboratory (NRL) NORM ( (NACK based Reliable Multicast Protocol): implementação em desenvolvimento pelo Naval Research Laboratory NORM, ALC ( (Asynchronous Layered Coding)/LCT ( (Layered Coding Transport) ) e FLUTE ( (File Delivery over Unidirecional Transport): implementações em desenvolvimento pelo INRIA, incluídas na biblioteca MCL (Multicast Communication Library) ALC/LCT e FLUTE: implementações em desenvolvimento pela Tampere University of Technology 19 de 40

20 MDP / NRL (Multicast Dissemination Protocol) Baseado em NACK, mas com suporte a FEC Para evitar implosão de NACK, receptor espera tempo antes de enviar NACK para o grupo. Se alguém enviar antes, ele cancela o envio Implementado em C++, código-fonte com 55k linhas de código Suporte a Unix, Windows Versão para NS (Network Simulator) 20 de 40

21 NORM / NRL (NACK Based Reliable Multicast Protocol) Implementação baseada no MDP Emprega mecanismo de controle de erros baseado em NACK e em FEC Código-fonte de aproximadamente 45k linhas de código Suporta unix e windows Versão para NS (Network Simulator) 21 de 40

22 MCL / INRIA MCL ( (Multicast Communication Library) ) consiste de: ALC ( (Asynchronous Layered Coding): implementação do protocolo ALC/LCT (transmissão unidirecional) e protocolos de controle de congestionamento RLC e FLID-SL LDPC: implementação do codec FEC para blocos grandes (Large( Block) NORM: implementação do protocolo NORM FCAST: aplicação de transferência de arquivos em multicast confiável 22 de 40

23 MCL / INRIA Código em C/C++ Sem controle de congestionamento Linux e windows 23 de 40

24 Aplicações a serem avaliadas O foco principal do GT é a aplicação de transferência de arquivos entre TVs Universitárias (RITU Rede de Interconexão entre TVs Universitárias) Outra aplicação a ser testada é a de jogos MMG (Massively Multiplayer Games) 24 de 40

25 Aplicação 1: RITU Aplicação de teste: RITU: Rede de Intercâmbio entre TVs Universitárias 25 de 40

26 RITU Aplicação 1: RITU 31 emissoras envolvidas Já em negociações com a RNP para efetuar a transmissão 26 de 40

27 Aplicação 2: jogos distribuídos em rede MMG: Massively Multiplayer Games Grande quantidade de participantes simultâneos Envio freqüente de mensagens via rede FreeMMG: Projeto aprovado no Edital CT-INFO CNPq 2003 (Jorge Barbosa Unisinos, Geyer - UFRGS) Em 6 meses devem ter aplicação para permitir teste 27 de 40

28 Metodologia de trabalho 28 de 40

29 Metodologia dividida em 4 fases 1. Estudo das implementações propostas 2. Desenvolvimento de experimentos para automatizar testes dos cenários propostos 3. Execução dos experimentos, coleta de resultados e análise estatística. Comparação com resultados da SuperJanet 4. Documentação: relatório dos resultados e manuais de utilização 29 de 40

30 1. Estudo das implementações Análise detalhada das RFCs e documentação de funcionamento dos protocolos MDP, NORM, ALC e FLUTE Instalação das implementações na rede local da Unisinos. Testes de transferência de arquivos Expansão da implementação entre Unisinos e POP-RS. Testes de transferência de arquivos Espera-se se ter que corrigir eventuais problemas nas implementações 30 de 40

31 2. Automatização para testes Foco nas 2 aplicações a) transferência de arquivos b) jogos distribuídos Desenvolvimento de scripts para automatizar coleta de dados e análise estatística das aplicações acima Execução de experimentos em âmbito local 31 de 40

32 3. Execução dos experimentos Expansão do ambiente para nn locais no Brasil O critério para definição dos locais de teste será a rede RITU, que é o cenário prioritário deste GT Medições exaustivas e coleta de dados de acordo com as métricas definidas a seguir 32 de 40

33 Métricas a serem analisadas Os protocolos e aplicativos serão comparados em relação a: Desempenho: vazão efetiva dos dados Custo: largura de banda consumida x número de usuários atingidos Robustez: percentual de transmissões bem sucedidas Atraso: entre saída do transmissor e chegada no destino (aproximações via NTP Network Time Protocol ou GPS, ambos existentes na RNP) Avaliação de friendliness friendliness dos protocolos na rede 33 de 40

34 4. Relatórios e manuais Análise estatística dos dados coletados Comparações com a rede SuperJanet,, do Reino Unido Determinação das vantagens e desvantagens de cada um dos protocolos Publicações Manuais de usuário para os protocolos instalados na RNP OBS: Nessa fase será feita a expansão do sistema para mais locais no Brasil 34 de 40

35 Rede Super Janet 10 Gbit/s 2,5 Gbit/s 2,5 Gbit/s 622 Mbit/s 155 Mbit/s 35 de 40

36 Projeto MUST (Inglaterra) Iniciativa conjunta de pesquisa BT Exact Technologies (Complexity( research group) Consórcio RealityGrid (University of Manchester) Objetivos Avaliar experimentalmente protocolos de multicast confiável Implementar e distribuir para a comunidade um conjunto de ferramentas em multicast confiável Monitorar experimentos em Access Grid 36 de 40

37 Recursos necessários nos POPs Acesso remoto a máquinas Linux nas instituições parceiras, com conectividade multicast Para a instalação dos protocolos nos POPs da RNP, É RECOMENDÁVEL um computador dedicado com permissão de acesso remoto pela equipe do GT, a fim de que se possa efetuar as instalações e medições necessárias Espera-se se contar com o auxílio eventual de algum técnico dos POPs a fim de resolver problemas eventuais de mal funcionamento dos micros ou necessidades que não possam ser efetuadas remotamente 37 de 40

38 Equipe 1 coordenador no Brasil 1 vice-coordenador coordenador na Inglaterra Dois assistentes 40h Dois estagiários 20h (um por assistente) 38 de 40

39 Cronograma Fase 1: Agosto a outubro / 2004 Fase 2: Novembro a dezembro / 2004 Fase 3: Janeiro a março / 2005 Fase 4: Abril a Julho / de 40

40 Implantação e Avaliação de Desempenho de Protocolos de Transmissão Multicast Confiável na RNP PERGUNTAS?? Valter Roesler: roesler@exatas.unisinos.br Unisinos Marinho Barcellos: marinho@exatas.unisinos.br Unisinos e University of Manchester (Inglaterra) e BT Exact (Inglaterra)