Multimídia

1. Multimídia Prof: Ricardo Gonçalves Quintão http://paginas.terra.com.br/relacionamento/rgquintao E-mail: rgquintao@yahoo.com.br

2. Bibliografia Redes de Computadores e a Internet – Uma Nova Abordagem Autores: James F. Kurose; Keith W. Ross Editora Pearson Education Redes de Computadores Autor: Andrew S. Tanenbaum Editora Campus Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP

3. Introdução Grande desenvolvimento e ampla disseminação das aplicações em rede que transmitem e recebem conteúdo de áudio e vídeo pela Internet. Vídeos de entretenimento; Telefonia IP; Rádio por Internet; Teleconferências; Jogos Interativos; Mundos Virtuais; Ensino à Distância; etc. Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP

4. Introdução As exigências de serviço dessas aplicações diferem de modo significativo daquelas das aplicações tradicionais orientadas a dados. Estas aplicações são muito sensíveis ao atraso fim a fim, a variação de atraso (jitter) mas podem tolerar perdas de dados ocasionais. Essas exigências de serviços fundamentalmente diferentes sugerem que a arquitetura de rede projetada de início para a comunicação de dados pode não se adaptar bem para o suporte de aplicações multimídia. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 4/63

5. Aplicações Multimídia Características importantes: Temporização; Tolerância à perda de dados. Como vimos, aplicações multimídia são altamente sensíveis ao atraso, porém, são tolerantes à perda. Perdas ocasionais causam ligeiras perturbações na recepção de áudio e vídeo e estas perdas podem ser parcialmente ou totalmente escondidas. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 5/63

6. Aplicações Multimídia As aplicações multimídia dividem-se em três classes: Fluxo contínuo de áudio e vídeo armazenados; Áudio e Vídeo de fluxo contínuo ao vivo; Áudio e Vídeo interativos em tempo real. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 6/63

7. Aplicações Multimídia Fluxo contínuo de áudio e vídeo armazenados. Definição: Nesta classe o cliente solicita a qualquer momento arquivos de áudio e vídeo comprimidos que estão armazenados nos servidores. • Os arquivos de áudio armazenados podem conter: • Áudio de uma conferência, Músicas, Programas de rádio famosos, etc • Os arquivos de vídeo armazenados podem conter: • Vídeo de uma palestra, Filmes de longa duração, Programas de televisão gravados, Documentários, Eventos históricos, Desenhos animados, Videoclipes, etc. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 7/63

8. Aplicações Multimídia Aspectos-chave distintos nessa classe de aplicação: Mídia Armazenada: O conteúdo multimídia foi pré gravado e está armazenado no servidor; O usuário pode realizar pausa, retroceder, avançar e escolher itens no conteúdo da apresentação. O tempo entre a solicitação do usuário e a sua manifestação deve ser de no máximo 10 segundos para ser considerada aceitável. Fluxo contínuo: Enquanto a transferência dos dados ocorre, a reprodução é feita no cliente. A reprodução pode ficar em um ponto diferente em relação à transferência de dados. Não é necessário fazer o download completo do arquivo para então reproduzi-lo. Reprodução contínua: Assim que se inicia a reprodução, ela deve prosseguir de acordo com a temporização original da gravação. Possui grandes restrições ao atraso na entrega de dados. Os dados devem ser recebidos do servidor a tempo de serem reproduzidos no cliente, caso contrário serão considerados inúteis. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 8/63

9. Aplicações Multimídia Áudio e vídeo de fluxo contínuo ao vivo Definição: Nesta classe o cliente recebe uma transmissão de dados que não estão armazenados, e sim sendo gerados no “mesmo” momento. • Temos como exemplo: • Transmissão de rádio e televisão ao vivo. • Como o fluxo contínuo de áudio e vídeo ao vivo não é armazenado, o cliente não pode adiantar o programa que está recebendo, contudo, com o armazenamento local de dados recebidos, outras operações interativas, como pausa e retrocesso em multimídia ao vivo são possíveis. • Normalmente este tipo de transmissão é feita para diversos clientes, o que leva ao uso da técnica de multicasting. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 9/63

10. Aplicações Multimídia Áudio e vídeo interativos em tempo real Definição: Nesta classe os clientes podem se comunicar um com os outros interativamente usando áudio/vídeo. • Temos como exemplo: • Telefone pela Internet; • Videoconferências. • Para estas aplicações, o atraso deve ser mínimo para que não haja desconforto na comunicação. Para o caso da voz temos: • Atrasos inferiores a 150 milissegundos: imperceptíveis ao ouvido humano; • Atrasos entre 150 e 400 milissegundos: aceitáveis; • Atrasos superiores a 400 milissegundos: conversação inisteligível. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 10/63

11. Obstáculos para a multimídia na Internet de hoje • A camada de rede da Internet oferece um serviço de melhor esforço para todos os datagramas que transporta. • Não existe promessa em relação ao atraso fim a fim para um pacote individual. • Não existe promessa em relação à variação do atraso de pacote dentro de uma corrente de pacotes. • Como tanto o TCP como o UDP rodam sobre o IP, nenhum desses protocolos dará alguma garantia às aplicações requisitantes. • Devida à falta de qualquer esforço especial para entregar pacotes a tempo, é um problema extremamente desafiador desenvolver aplicações de rede multimídia de sucesso na Internet. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 11/63

12. Obstáculos para a multimídia na Internet de hoje • O telefone por Internet e o vídeo interativo em tempo real alcançaram, até agora, sucesso bem menor do que o fluxo contínuo de áudio/vídeo armazenado. • Voz e vídeo interativos em tempo real impõem rígidas limitações ao atraso de pacote e à variação de atraso do pacote. • Voz e vídeo interativos em tempo real funcionam bem em regiões onde a oferta de largura de banda é abundante e, portanto, o atraso e a variação de atraso são mínimos. • Devida a tolerância a perda de pacotes, o uso do UDP se torna interessante, pois o seu overhead é menor, aumentando o fluxo de dados. • No caso de comunicações não interativas, podemos retardar a reprodução no receptor para diminuir o efeito da variação do atraso. • Inserção de marcas de tempo para que o receptor saiba quando reproduzi-los. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 12/63

13. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Existem três vertentes para o desenvolvimento da Internet para os serviços multimídia. • Aumento da largura de banda: Existe um grupo de pesquisadores que defendem a idéia de que basta aumentar a largura de banda, sem fazer qualquer mudança na estratégia de roteamento, que os problemas com a multimídia seriam resolvidos. • Mudanças na estratégia de roteamento: Um outro grupo de pesquisadores argumentam que devem ser feitas modificações fundamentais na Internet para que as aplicações possam reservar explicitamente uma largura de banda fim a fim. • Eles acham que se um usuário quiser realizar uma chamada telefônica pela Internet do Host A para o Host B, a aplicação de telefone do usuário deverá reservar explicitamente a largura de banda necessária em cada enlace que conecta o Host A ao Host B. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 13/63

14. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Para permitir que as aplicações façam as reservas e exigir que a rede honre essas reservas, são necessária algumas grandes mudanças: • Precisa-se de um protocolo que reserve largura de banda dos remetentes e seus receptores em nome das aplicações; • Deve-se modificar as regras de programação nas filas dos roteadores, de modo que as reservas de largura de banda possam ser honradas; • Com esta nova política de programação, nem todos os pacotes receberiam tratamento igual, ao invés disso, quem reservar (e pagar) mais, recebe mais. • Para honrar as reservas, as aplicações devem dar à rede a descrição do tráfego que pretendem enviar para dentro dela. A rede deve, então, regular o tráfego de cada aplicação para assegurar que ela cumpra o que descreveu. • A rede deve dispor de meios para determinar se tem largura de banda suficiente para suportar qualquer nova solicitação de reserva. • Esses mecanismos, quando combinados, exigem novos e complexos softwares nos Hosts e roteadores. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 14/63

15. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Serviços diferenciados: Outro grupo de pesquisadores defendem que mudanças relativamente pequenas na rede e nas camadas de transporte e a introdução de esquemas simples de preço e regulagem na borda da rede (entre o usuário e o seu ISP) são suficientes. • A idéia é introduzir um pequeno número de classes (possivelmente apenas duas), atribuir a cada datagrama uma dessas classes, oferecer aos datagramas diferentes níveis de serviço nas filas dos roteadores segundo sua classe, e cobrar dos usuários de acordo com a classe dos pacotes que estão enviando 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 15/63

16. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Grande aumento no uso de aplicações de fluxo contínuo. • Custo de armazenamento em disco está decrescendo rapidamente. • Aumento na quantidade de áudio e vídeo armazenados. • Melhorias na infra-estrutura da Internet (banda larga doméstica). • Armazenamento intermediário de vídeo na rede. • Novos protocolos de Internet orientados à QoS. • Demanda reprimida por vídeo de alta qualidade. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 16/63

17. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Solicitação de áudio e vídeo comprimidos que residem em servidores. • Servidores Web comum. • Servidores especiais para fluxo contínuo. • Etapas para a transferência de áudio/vídeo armazenados: • A solicitação do cliente chega ao servidor. • Os arquivos de áudio/vídeo são segmentados. • Cada segmento é encapsulado com cabeçalhos especiais apropriados para o tráfego de áudio/vídeo (protocolo RTP – Real Time Protocol). • Assim que o cliente começa a receber, em alguns segundos ele começa a reproduzi–lo. • Se a aplicação oferecer interatividade (pausa, retrocesso, avanço na imagem) será necessário o uso de um outro protocolo (RTSP – Real Time Streaming Protocol). • Apesar da maioria das requisições ser feita por browsers, a sua reprodução necessita de uma aplicação auxiliar chamada de transdutor. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 17/63

18. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Função dos transdutores: • Descompressão: Áudio e vídeo quase sempre são comprimidos para economizar espaço de armazenamento em disco e largura de banda de rede. Um transdutor deve descomprimir áudio e vídeo enquanto são reproduzidos. • Remoção de Variação de Atraso: O transdutor colocará os pacotes recebidos em um buffer durante um curto período de tempo para remover essa variação. • Correção de erros: Devida à imprevisibilidade do congestionamento na Internet, uma fração de pacotes da corrente de pacotes pode ser perdida. Muitos sistemas tentam recuperar essas perdas: • Reconstruindo os pacotes perdidos por meio da transmissão de pacotes redundantes. • Fazendo com que o cliente solicite explicitamente a retransmissão de pacotes perdidos. • Mascarando as perdas pela interpolação dos dados que faltam nas mensagens recebidas. • Interface gráfica de interação: É através desta interface que o usuário irá interagir com o controle de volume, retrocesso, avanço e outros. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 18/63

19. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Com o uso de plug-ins, pode-se inserir a interface gráfica do transdutor dentro da janela do browser Web. Neste caso, o browser apenas reserva o espaço de tela na página corrente e o transdutor fica incumbido de gerenciar o espaço de tela. Independente de onde apareça a imagem, o transdutor está sendo executado separadamente do browser. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 19/63

20. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Como se trata de um servidor Web, o arquivo de áudio/vídeo não passa de um objeto comum como arquivos HTML e JPEG. • Quando um usuário quer ouvir um arquivo de áudio, o host do usuário estabelece uma conexão TCP com o servidor Web e envia um requisição HTTP para o objeto. • Ao receber a requisição, o servidor Web anexa o arquivo de áudio a uma mensagem de resposta e devolve a mensagem de resposta à conexão TCP. • Para o vídeo, isso pode ser um pouco mais delicado, porque as partes de áudio e vídeo podem estar armazenados em arquivos diferentes. • Neste caso, são feitas duas requisições TCP separadas e os arquivos são enviados em paralelo. • Cabe ao cliente gerenciar a sincronização das duas correntes. • Também é possível que o áudio e vídeo estejam intercalados no mesmo arquivo, simplificando a transferência. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 20/63

21. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • A figura abaixo ilustra este procedimento: Requisição Browser Web Resposta Transdutor • Embora a abordagem seja muito simples, ela tem uma desvantagem importante: o transdutor deve interagir com o servidor por intermédio de um browser Web. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 21/63

22. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Esta abordagem traz alguns problemas: • Normalmente, quando o browser é o intermediário, o objeto inteiro precisa ser transferido antes de o browser passá-lo a uma aplicação auxiliar. • O atraso resultante antes do início da reprodução é tipicamente inaceitável para clipes de áudio/vídeo de tamanho moderado. • Uma outra abordagem é realizar a transferência diretamente para o processo transdutor, em outras palavras, é feita uma conexão direta entre o processo servidor e o processo transdutor. • Esta técnica é feita através de um metarquivo, isto é, um arquivo que fornece informações (por exemplo, URL, tipo de codificação) sobre o arquivo de áudio/vídeo de fluxo contínuo a ser entregue. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 22/63

23. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Neste caso, uma transferência direta entre o servidor e o transdutor segue os seguintes passos: • O usuário clica sobre um hiperlink de um arquivo de áudio/vídeo. • O hiperlink não aponta diretamente para o arquivo de áudio/vídeo, mas para um metarquivo. O metarquivo contém o URL do arquivo de áudio/vídeo. • A mensagem de resposta HTTP que encapsula o metarquivo contém uma linha de cabeçalho de tipo de conteúdo que indica a aplicação de áudio/vídeo específica. • O browser cliente examina a linha de cabeçalho de tipo de conteúdo da mensagem de resposta, lança o transdutor associado e passa todo o corpo da mensagem de resposta (isto é, o metarquivo) para o transdutor. • O transdutor estabelece uma conexão TCP diretamente com o servidor HTTP e envia uma mensagem de requisição HTML do arquivo de áudio/vídeo pela conexão TCP. • O arquivo de áudio/vídeo é enviado ao transdutor dentro de uma mensagem de resposta HTTP. O transdutor exibe o arquivo de áudio/vídeo de fluxo contínuo. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 23/63

24. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • A figura abaixo ilustra este procedimento: Requisição do metarquivo Browser Web Resposta do metarquivo Metarquivo Requisição áudio/vídeo Transdutor Resposta áudio/vídeo • A importância da etapa intermediária de requisição do metarquivo é clara. Quando o browser vê o tipo de conteúdo para o arquivo, ele pode lançar o transdutor adequado e, dessa maneira, fazer com que o transdutor entre em contato direto com o servidor. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 24/63

25. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Como toda a comunicação é feita em um servidor Web usando HTTP, a transmissão será feita sobre o TCP. • O HTTP é muitas vezes considerado insuficientemente rico para permitir interação satisfatória do usuário com o servidor, em particular, não é fácil para o HTTP permitir que um usuário envie por meio do transdutor comandos de pausa/reinício, avanço, retrocesso, etc. • É por isso que muitos fabricantes de produtos multimídia não recomendam esta arquitetura e sim, o uso de um servidor de fluxo contínuo. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 25/63

26. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Com o objetivo de evitar o HTTP e/ou o TCP, áudio e vídeo podem ser armazenados em um servidor de fluxo contínuo e enviados a partir deste ao transdutor. • Com um servidor de fluxo contínuo, áudio e vídeo podem ser enviados sobre UDP. • Essa arquitetura exige dois servidores (serviços): • Um dos servidores, o servidor HTTP, serve páginas Web (incluindo os metarquivos). • O segundo servidor, o servidor de fluxo contínuo, serve os arquivos de áudio/vídeo. • Os dois servidores podem rodar no mesmo sistema final ou em dois sistemas finais distintos. • As etapas dessa arquitetura são semelhantes às descritas para a arquitetura anterior. Contudo, nesse caso o transdutor requisita o arquivo de um servidor de fluxo contínuo, e não de um servidor Web. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 26/63

27. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • A figura abaixo ilustra este procedimento: Requisição HTTP Servidor WEB Browser Web Resposta HTTP Metarquivo Requisição áudio/vídeo Servidor de Fluxo Contínuo Transdutor Resposta áudio/vídeo 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 27/63

28. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Na arquitetura que acabamos de ver, há muitas opções para a entrega de áudio/vídeo do servidor de fluxo contínuo ao transdutor. Abaixo segue a descrição de três delas. • O áudio/vídeo é enviado sobre UDP a uma taxa constante igual à taxa de reprodução do receptor (que é a taxa codificada para áudio/vídeo). Por exemplo, se o áudio for comprimido usando GSM a uma taxa de 13 Kbps, então o servidor transmitirá o arquivo comprimido de áudio a uma taxa de 13 Kbps. Logo que o cliente tenha recebido o áudio/vídeo comprimido da rede, ele o descomprime e o reproduz. • É igual à opção 1, mas o transdutor atrasa a reprodução de dois a cinco segundos para eliminar a variação de atraso induzida pela rede. O cliente realiza essa tarefa colocando a mídia comprimida que recebe da rede em um buffer cliente. Assim que o cliente tiver ‘pré-capturado’ alguns poucos segundos de mídia, ele começa a utilizar a informação do buffer. Para essa opção e também para a anterior, a taxa de preenchimento é igual à taxa de saída, exceto quando há perda de pacotes, caso em que a taxa de preenchimento é momentaneamente menor que a taxa de saída. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 28/63

29. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • A mídia é enviada sobre TCP. O servidor lança o arquivo de mídia para dentro da porta TCP o mais rápido possível; o cliente (isto é, o transdutor) lê da porta TCP o mais rápido possível e coloca o vídeo comprimido no buffer do transdutor. Após um atraso inicial de dois a cinco segundos, o transdutor lê, a partir do seu buffer, a uma taxa d e repassa a mídia comprimida para descompressão e reprodução. Como o TCP retransmite pacotes perdidos, ele tem o potencial de fornecer melhor qualidade de som do que o UDP. Por outro lado, a taxa de preenchimento x(t) varia com o tempo devido ao controle de congestionamento e ao controle de fluxo do TCP. De fato, após a perda de pacotes, o controle de congestionamento TCP pode reduzir a taxa instantânea a valores menores do que d por longos períodos de tempo. Isso pode esvaziar o buffer cliente e introduzir indesejáveis pausas na saída de uma corrente de áudio/vídeo no cliente. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 29/63

30. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Para a terceira opção, o comportamento de x(t) vai depender muitíssimo do tamanho do buffer cliente (que não deve ser confundido com o buffer TCP de recepção). Se o buffer for grande o suficiente para conter todo o arquivo de mídia (possivelmente por armazenagem em disco), então o TCP vai fazer uso de toda a largura de banda instantânea disponível para a conexão, de modo que x(t) pode se tornar muito maior do que d. Se x(t) permanecer muito maior do que d por longos períodos de tempo, então uma grande porção da mídia será pré-capturada para dentro do cliente e um subseqüente inanição do cliente será pouco provável. Se, por outro lado, o buffer cliente for pequeno, então x(t) flutuará ao redor da taxa de saída d. O risco de inanição do cliente é maior nesse caso. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 30/63

31. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Muitos usuários de multimídia pela Internet (em especial aqueles que cresceram com um controle remoto de TV na mão) vão querer controlar a reprodução de mídia de taxa constante fazendo pausa na reprodução, reposicionando a reprodução em um ponto de tempo futuro ou passado, avançando ou atrasando a reprodução em modo rápido e assim por diante. • Essa funcionalidade é semelhante ao que um aparelho de DVD ou Videocassete oferecem ao usuário. • Para permitir que um usuário controle a reprodução, o transdutor e o servidor precisam de um protocolo para trocar informações de controle de reprodução. • O RTSP (Real Time Streaming Protocol) é esse protocolo. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 31/63

32. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • O que o RTSP não faz! • O RTSP não define esquemas de compressão para áudio e vídeo. • O RTSP não define como áudio e vídeo são encapsulados em pacotes para transmissão sobre uma rede; o encapsulamento para mídia de fluxo constante pode ser fornecido por RTP ou por um protocolo proprietário. • O RTSP não restringe o modo como a mídia de fluxo contínuo é transportada; ela pode ser transportada sobre UDP ou TCP. • O RTSP não restringe o modo como o transdutor armazena o áudio/vídeo. O áudio/vídeo pode ser reproduzido logo que começa a chegar cliente, após um atraso de alguns segundos, ou pode ser descarregado na íntegra antes de ser reproduzido. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 32/63

33. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Qual a finalidade do RTSP? • O RTSP é um protocolo que permite que um transdutor controle a transmissão de uma corrente de mídia, isto é: pausa, retrocesso, avanço, etc. • As mensagens RTSP são enviadas através de uma conexão extra à conexão de corrente de dados. Por esse motivo é chamado de protocolo fora da banda. • As mensagens RTSP podem ser enviadas sobre o TCP ou UDP. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 33/63

34. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • A figura abaixo ilustra este procedimento: Requisição HTTP Browser Web Servidor Web Resposta HTTP Metarquivo SETUP Transdutor Servidor de Mídia PLAY Corrente de Mídia PAUSE TEAR DOWN 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 34/63

35. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • O protocolo IP da Internet presta um serviço de melhor esforço. • A Internet faz seu melhor esforço para transportar cada datagrama da fonte ao destino o mais rápido possível. • Contudo, o serviço de melhor esforço nada promete quanto ao atraso fim a fim de um pacote individual, muito menos quanto a variação de atraso em uma corrente de pacotes. • As aplicações de multimídia interativas em tempo real (telefone e videoconferência) são muito sensíveis ao atraso, à variação de atraso e à perda. • Existem mecanismos que podem úteis que conseguem preservar a boa qualidade do áudio e do vídeo para que o atraso, variação do atraso e perda não sejam excessivos. • Utilizaremos uma aplicação de telefone por Internet como exemplo de uso destes mecanismos. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 35/63

36. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Características: • O interlocutor de nossa aplicação de telefone por Internet gera um sinal de áudio constituído de rajadas de voz alternadas com períodos de silêncio. • A fim de conservar a largura de banda, nossa aplicação de telefone por Internet gera pacotes somente durante as rajadas de voz. • Durante uma rajada de voz, o remetente gera bytes a uma taxa de 8 Kbytes por segundo (64 Kbps) e, a cada 20 milissegundos, junta os bytes em porções. Assim, o total de bytes em uma porção é de: Total de bytes da porção = (20 ms) x (8 Kbytes/s) = 160 bytes. • Um cabeçalho especial é agregado a cada porção. • A porção, juntamente com seu cabeçalho, é encapsulada em um datagrama UDP e, em seguida, o datagrama UDP é enviado para dentro da porta da interface. • Logo, durante uma rajada de voz, um datagrama UDP é enviado a cada 20 milissegundos. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 36/63

37. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Se cada pacote conseguir chegar ao receptor e se tiver um atraso fim a fim pequeno e constante, então um pacote chegará ao receptor periodicamente, a cada 20 milissegundos, durante um rajada de voz. • Nessas condições ideais, o receptor pode simplesmente reproduzir cada porção assim que ela chega. • Mas, infelizmente, alguns pacotes podem ser perdidos e a maioria dos pacotes não sofrerá idêntico atraso fim a fim, mesmo quando a Internet estiver apenas levemente congestionada. • Por essa razão, o receptor deve tomar mais cuidado ao: • Determinar quando reproduzir uma rajada; • Estabelecer o que fazer com uma porção perdida. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 37/63

38. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Limitações de um serviço de melhor esforço (perdas de pacotes, atraso fim a fim e variação de atraso) • Perdas de pacotes: Considere um dos segmentos UDP gerados por nossa aplicação de telefone por Internet. O segmento UDP é encapsulado em um datagrama IP. Enquanto o datagrama vagueia pela rede, ele passa por buffers (isto é, por filas) nos roteadores, para poder alcançar os enlaces de saída. É possível que um ou mais dos buffers na rota entre o remetente e o destinatário estejam lotados e não possam aceitar o datagrama IP. Nesse caso, o datagrama IP será descartado e nunca chegará à aplicação receptora. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 38/63

39. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Perdas de pacotes (continuação): A perda pode ser eliminada enviando os pacotes sobre TCP, em vez de sobre UDP. Lembre-se de que o TCP retransmite pacotes que não chegam ao destino. Contudo, os mecanismos de retransmissão freqüentemente são considerados inaceitáveis para aplicações interativas de áudio em tempo real, como o telefone por Internet, porque aumentam o atraso fim a fim. Além disso, devido ao controle de congestionamento do TCP, após a perda de pacote, a taxa de transmissão pode ser reduzida a uma taxa mais baixa do que a taxa de reprodução no receptor. Isso pode causar um forte impacto sobre a inteligibilidade da voz no receptor. Por essas razões, quase todas as aplicações de telefone por Internet existentes rodam sobre UDP e não se preocupam em retransmitir pacotes perdidos. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 39/63

40. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Perdas de pacotes (continuação): Perder pacotes não é necessariamente tão grave quanto se possa imaginar. Na verdade, taxas de perda de pacotes entre 1% e 20% podem ser toleradas, dependendo de como a voz é codificada e transmitida e de como a perda é ocultada do receptor. Por exemplo, o mecanismo de correção de erros de repasse (FEC – forward error correction) pode ajudar a ocultar a perda de pacotes. Se um ou mais dos enlaces entre o remetente e o receptor estiverem fortemente congestionados e a perda de pacotes exceder 20%, então nada poderá, de fato, ser feito para conseguir uma qualidade de som aceitável. Assim, fica claro que o serviço de melhor esforço tem sua limitações. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 40/63

41. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Atraso fim a fim: O atraso fim a fim é o acúmulo de atrasos de processamento de transmissão e de formação de filas nos roteadores, atrasos de propagação e atrasos de processamento nos sistemas finais ao longo do trajeto da fonte ao destino. Para as aplicações de áudio altamente interativas, como o telefone por Internet, atrasos fim a fim menores do que 150 milissegundos não são percebidos pelo ouvido humano. Atrasos entre 150 e 400 milissegundos podem ser aceitáveis, mas não são o ideal. Atrasos que excedem 400 milissegundos podem atrapalhar seriamente a interatividade nas conversações. O receptor da aplicação de telefone por Internet em geral desconsiderará quaisquer pacotes cujos atrasos ultrapassarem um determinado patamar. Logo, os pacotes cujos atrasos ultrapassem este patamar são efetivamente perdidos. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 41/63

42. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Variação de Atraso: Um componente importante do atraso fim a fim são os atrasos aleatórios de fila nos roteadores. Por causa desses atrasos variáveis dentro da rede, o tempo decorrido entre o momento em que um pacote é gerado na fonte e o momento em que é recebido no destinatário pode variar de pacote para pacote. Como exemplo, considere dois pacotes consecutivos dentro de uma rajada de voz em nossa aplicação de telefone por Internet. O remetente envia o segundo pacote 20 milissegundos após ter enviado o primeiro. Mas, no receptor, o espaçamento entre esses pacotes pode ficar maior do que 20 milissegundos. Para observar isso, suponha que o primeiro pacote chegue a uma fila de roteador praticamente vazia, mas que, exatamente antes de o segundo pacote chegar à fila, um grande número de pacotes vindos de outras fontes chegue à mesma fila. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 42/63

43. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Variação de Atraso (continuação): Como o segundo pacote sofre um grande atraso de fila, o primeiro e o segundo pacotes ficam espaçados em mais de 20 milissegundos. O espaçamento entre pacotes consecutivos também pode ficar menor do que 20 milissegundos. Para observar isso, considere novamente dois pacotes consecutivos dentro de uma rajada de voz. Suponha que o primeiro pacote se junte ao final de uma fila com um grande número de pacotes e que o segundo pacote chegue à fila antes dos pacotes da outra fonte. Nesse caso, nossos dois pacotes se encontram um exatamente atrás do outro na fila. Se o tempo que leva para transmitir um pacote no roteador de entrada for menor do que 20 milissegundos, então o primeiro e o segundo pacotes ficarão espaçados em menos de 20 milissegundos. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 43/63

44. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Variação de Atraso (continuação): Se o receptor ignorar a presença de variação de atraso e reproduzir as porções assim que elas chegam, então a qualidade de áudio resultante poderá facilmente se tornar ininteligível no receptor. Felizmente, a variação de atraso pode, com freqüência, ser removida usando-se números de seqüência, marcas de tempo e atraso de reprodução. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 44/63

45. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Remoção da variação de atraso no receptor de áudio Para uma aplicação de voz como o telefone por Internet ou o áudio sob demanda, o receptor deve tentar fornecer uma reprodução sincronizada de porções de voz combinando os seguintes mecanismos: • Preceder cada porção com um número de seqüência. O remetente aumenta em um o número de seqüência para cada um dos pacotes que gera. • Preceder cada porção com uma marca de tempo. O remetente marca cada porção com o tempo em que ela foi gerada. • Atrasar a reprodução das porções no receptor. O atraso da reprodução das porções de áudio recebidas deve ser suficientemente longo para que a maioria dos pacotes seja recebida antes de seu tempo de reprodução programado. Ele pode ser fixado para todo o período de duração de uma conferência ou pode variar de maneira adaptativa durante o período útil da conferência. Os pacotes que não chegarem antes de seu tempo de reprodução programado serão considerados perdidos e esquecidos. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 45/63

46. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Atraso de reprodução fixo: Com a estratégia do atraso fixo, o receptor tenta reproduzir cada porção exatamente q milissegundos após a porção ter sido gerada. Assim, se uma porção tem marca de tempo t, o receptor reproduz a porção no tempo t + q, presumindo que a porção já tenha chegado naquele tempo. Os pacotes que chegam após seu tempo de reprodução programada são descartados e considerados perdidos. Qual é uma boa escolha para q? O telefone por Internet pode suportar atrasos de até cerca de 400 milissegundos, embora com valores menores que q a experiência interativa resultante seja mais satisfatória. Por outro lado, caso se escolha um q muito menor do que 400 milissegundos, muitos pacotes podem perder seus tempos de reprodução programados devido à variação de atraso induzida pela rede. Em termos gerais, se grandes variações no atraso também forem pequenas, será preferível usar um q pequeno, talvez menor do que 150 milissegundos. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 46/63

47. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Atraso de reprodução fixo (continuação) Pacotes Tempo de reprodução p Reprodução perdida Tempo de reprodução p’ Pacotes gerados Pacotes recebidos Tempo r p p’ 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 47/63

48. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Atraso de reprodução fixo (continuação): O compromisso entre o atraso de reprodução e a perda de pacotes foi ilustrado na figura anterior. A figura mostra os tempos em que os pacotes são gerados e reproduzidos para uma única rajada de voz. Dois atrasos iniciais de reprodução distintos são considerados. Como mostram os degraus mais à esquerda do gráfico, o remetente gera pacotes a intervalos regulares, digamos, a cada 20 milissegundos. O primeiro pacote dessa rajada de voz é recebido no tempo r. Como mostra a figura, as chegadas dos pacotes subseqüentes não são espaçadas regularmente devida à variação de atraso da rede. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 48/63

49. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Atraso de reprodução fixo (continuação): Para o primeiro esquema de reprodução, o atraso inicial de reprodução está estabelecido em p – r. Com esse esquema, o quarto pacote não chega dentro de seu atraso de reprodução programado e o receptor o considera perdido. Pelo segundo esquema de reprodução, o atraso inicial de reprodução fixo está estabelecido em p’ – r. Por esse esquema, todos os pacotes chegam antes de seu tempo de reprodução e, portanto, não há perda. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 49/63

50. Como a Internet deveria se desenvolver para dar melhor suporte à multimídia • Atraso de reprodução adaptativo: O exemplo anterior demonstra um importante compromisso entre atraso e perda que surge ao se projetar uma estratégia de reprodução com atrasos de reprodução fixos. Ao se decidir por um atraso inicial de reprodução grande, a maioria dos pacotes vai cumprir suas programações e, portanto, haverá perda insignificante; Contudo, para serviços interativos como o telefone por Internet, atrasos longos podem se tornar incômodos, se não intoleráveis. Idealmente, gostaríamos que o atraso de reprodução fosse minimizado, mas que mantivesse a limitação de perda abaixo de uns poucos por cento. 11/11/2014 Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 50/63