Capítulo 7 Redes multimídia
2 Redes de computadores I Prof.: Leandro Soares de Sousa E-mail: leandro.uff.puro@gmail.com Site: http://www.ic.uff.br/~lsousa Não deixem a matéria acumular!!! Datas das avaliações, exercícios propostos, transparências,... no site! 2
Multimídia e Qualidade de Serviço: O que são? A Internet oferece: garantia de entrega? Tempo fim a fim? Ordem dos pacotes? Intervalo entre as entregas? Banda mínima, máxima ou média? 3
Multimídia e Qualidade de Serviço: O que são? A Internet oferece: garantia de entrega? NÃO! Tempo fim a fim? NÃO! Ordem dos pacotes? NÃO! Intervalo entre as entregas? NÃO! Banda mínima, máxima ou média? NÃO! 4
Multimídia e Qualidade de Serviço: O que são? O que tem por trás disso? 5
Multimídia e Qualidade de Serviço: O que são? O que tem por trás disso? IP! 6
Multimídia e Qualidade de Serviço: O que são? aplicações multimídia: áudio e vídeo na rede ( mídia contínua ) Quality of Service (QoS): a rede fornece à aplicação o nível de desempenho necessário para que a aplicação funcione como esperado. 7
Aplicações Multimídia na Rede Classes de aplicações Multimídia: 1) fluxo contínuo (streams) de áudio e vídeo armazenados 2) fluxos contínuo (stream) de áudio e vídeo ao vivo 3) vídeo interativo de tempo real Jitter é a variabilidade dos atrasos dos pacotes dentro de um mesmo fluxo de pacotes Características Fundamentais: tipicamente são sensíveis a atrasos atraso fim a fim variação do atraso (jitter), mas são tolerantes a perdas: perdas não muito frequentes causam apenas pequenos distúrbios antítese da transferência de dados que é intolerante a perdas mas tolerante a atrasos. 8
9 Sumário 7.1 Aplicações de rede multimídia 7.2 Vídeo de fluxo contínuo armazenado 7.3 Voz sobre IP: VoIP (Voice-over-IP) 7.4 Protocolos para aplicações interativas em tempo real 7.5 Suporte de rede para multimídia
10 Sumário 7.1 Aplicações de rede multimídia 7.2 Vídeo de fluxo contínuo armazenado 7.3 Voz sobre IP: VoIP (Voice-over-IP) 7.4 Protocolos para aplicações interativas em tempo real 7.5 Suporte de rede para multimídia
Propriedades de vídeo 11 Talvez a característica mais destacada do vídeo seja sua alta taxa de bits. O vídeo distribuído pela Internet costuma variar de 100 kbits/s para videoconferências de baixa qualidade até mais de 3 Mbits/s para os filmes de fluxo de vídeo com alta definição.
Propriedades de vídeo 12 Outra característica importante do vídeo é que ele pode ser compactado, compensando assim a qualidade com a taxa de bits. Também podemos usar a compactação para criar múltiplas versões do mesmo vídeo.
Propriedades de vídeo 13 Vídeo é uma sequência de imagens apresentadas a uma taxa constante ex. 24 imagens/seg Imagem digital: é uma matriz de pixels cada pixel é representado por bits Redundância espacial (dentro da imagem) temporal (de uma imagem p/ a seguinte)
Propriedades de vídeo Exemplos: MPEG1 (CD-ROM) 1,5 Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (frequentemente usado na Internet, < 1 Mbps) Pesquisa: vídeo em camadas (escalável) adapta as camadas à largura de banda disponível 14
Propriedades de áudio 15 O áudio digital tem requisitos de largura de banda muito menores do que o vídeo. Embora as taxas de bit de áudio sejam em geral muito menores do que as de vídeo, os usuários costumam ser muito mais sensíveis a pequenas falha de áudio do que de vídeo.
Propriedades de áudio 16 O sinal analógico amostrado a uma taxa constante telefone: 8.000 amostras/seg Cada amostra é discretizada (arredondada) ex., 28=256 possíveis valores discretos cada valor discretizado é representado por bits exemplo: 8.000 amostras/seg, 256 valores discretos --> 64.000 bps receptor converte-o de volta a um sinal analógico: alguma perda de qualidade
Propriedades de áudio Exemplo de taxas CD: 1,411 Mbps MPEG 1 layer 3 (MP3): 96, 128, 160 kbps Telefonia Internet: 5,3 kbps ou mais 17
Áudio e vídeo de fluxo contínuo armazenados 18 Muitas empresas de Internet oferecem hoje vídeo de fluxo contínuo, incluindo YouTube (Google), Netflix e Hulu. Por algumas estimativas, ele contribui com mais de 50% do tráfego descendente nas redes de acesso à Internet atualmente.
Áudio e vídeo de fluxo contínuo armazenados Ele tem três características distintas importantes: 1. Fluxo contínuo. 2. Interatividade. 3. Reprodução contínua. 19
Voz e vídeo sobre IP interativos 20 A voz interativa em tempo real pela Internet é chamada de telefonia da Internet. A maioria dos sistemas interativos por voz e vídeo permite que os usuários criem conferências com três ou mais participantes. Voz e vídeo interativos são muito usados na Internet hoje, com as empresas Skype, QQ e Google Talk. Aplicações de multimídia interativas são tolerantes à perda. Restrições de tempo fim a fim experiência desagradável quando o retardo é longo.
Áudio e vídeo de fluxo contínuo ao vivo 21 Aplicações ao vivo, do tipo de difusão, normalmente possuem muitos usuários que recebem o mesmo programa de áudio/vídeo ao mesmo tempo. A rede precisa oferecer a cada fluxo de multimídia ao vivo uma vazão média que seja maior que a taxa de consumo de vídeo. Como o evento é ao vivo, o atraso também pode ser um problema. Atrasos de até dez segundos ou mais desde o instante em que o usuário requisita a entrega/reprodução de uma transmissão ao vivo até o início da reprodução podem ser tolerados. Grupos IP, mais comumente por aplicações em camadas (P2P ou CND,mais adiante...) ou múltiplos fluxos individuais separados.
22 Sumário 7.1 Aplicações de rede multimídia 7.2 Vídeo de fluxo contínuo armazenado 7.3 Voz sobre IP: VoIP (Voice-over-IP) 7.4 Protocolos para aplicações interativas em tempo real 7.5 Suporte de rede para multimídia
Vídeo de fluxo contínuo armazenado 23 Os sistemas de vídeo de fluxo contínuo podem ser classificados em três categorias: 1. UDP de fluxo contínuo, 2. HTTP de fluxo contínuo e 3. HTTP de fluxo contínuo adaptativo.. Uma característica comum de todas as três formas de vídeo de fluxo contínuo é o uso extenso de buffer de aplicação no lado do cliente para aliviar os efeitos de variar os atrasos de fim a fim e variar as quantidades de largura de banda disponível entre servidor e cliente.
Vídeo de fluxo contínuo armazenado Atraso de reprodução do cliente no vídeo de fluxo contínuo 24
Vídeo de fluxo contínuo armazenado 25 Atraso de reprodução do cliente no vídeo de fluxo contínuo TCP / UDP?
26 UDP de fluxo contínuo Com o UDP de fluxo contínuo, o servidor transmite vídeo a uma taxa que corresponde à taxa de consumo de vídeo do cliente (RTP Real-Time Protocol). Normalmente usa um pequeno buffer no lado do cliente (depende da aplicação). muito bem numa rede com Funciona congestionamento e que não olhe os fluxos, mas... baixo
27 UDP de fluxo contínuo O UDP de fluxo contínuo com taxa constante pode deixar de oferecer reprodução contínua (trava, congela...). Ele exige um servidor de controle de mídia (RTSP RealTime Streaming Protocol). Muitos firewalls (em NATs inclusive) são configurados para bloquear o tráfego UDP. Algumas aplicações trabalham com fluxo adaptativo, mas devido ao tráfego o TCP, em volume, alcançou e hoje predomina.
28 HTTP de fluxo contínuo No HTTP de fluxo contínuo, o vídeo é apenas armazenado em um servidor HTTP como um arquivo comum com uma URL específica (HTTP GET). O uso do HTTP sobre TCP também permite ao vídeo atravessar firewalls e NATs mais facilmente. Vídeos de fluxo contínuo sobre HTTP também deixam clara a necessidade de um servidor de controle de mídia, tal como um servidor RTSP. Netflix e YouTube (buffers e pré-busca uso normal da banda pelo TCP, tentando alcançar a banda máxima possível)
Buffer de aplicação do cliente e buffers TCP 29 A figura abaixo ilustra a interação entre o cliente e o servidor para HTTP de fluxo contínuo.
Análise do vídeo de fluxo contínuo 30 Análise do uso de buffer no lado do cliente, para vídeo de fluxo contínuo
Análise do vídeo de fluxo contínuo Término antecipado e reposicionamento (cabeçalho do intervalo de bytes HTTP) 31 do vídeo
Fluxo contínuo adaptativo e DASH 32 Pelo DASH (Fluxo Contínuo de Adaptativo Dinamicamente sobre HTTP), o vídeo é codificado em muitas versões diferentes, cada qual com uma taxa de bits e um diferente nível de qualidade. Exemplo: um MPEG-4 pode ser codificado em 8 a 10 diferentes formatos que requisitam taxas distintas e, assim, com qualidade diferente
Fluxo contínuo adaptativo e DASH 33 O servidor contém um arquivo de manifesto com a localização (URL), taxas, codificação... O cliente pode baixas alguns segundos nessas várias codificações e selecionar alguma. Durante a apresentação as codificações/taxas podem ser alteradas para se adaptar à banda disponível no momento. DASH permite aos clientes com diferentes taxas de acesso à Internet fluir em um vídeo por diferentes taxas codificadas. Com o DASH, cada versão do vídeo é armazenada em um servidor HTTP, cada um com uma diferente URL.
Redes de distribuição de conteúdo 34 Uma CDN (Rede de Distribuição de Conteúdo): gerencia servidores geograficamente, em múltiplas localidades distribuídas armazena cópias dos vídeos em seus servidores, e tenta direcionar cada requisição do usuário para uma localidade CDN que proporcionará a melhor experiência para o usuário. Enter-deep: o mais próximo possível dos ISPs, dentro deles (Akamai 1700 locais). Bring-home: grandes clusters, rede de interconexão pesadas, POPs e ISPs nível 1 (Limelight, Google,...) Manutenção, escala... Pode ser uma CDN privada ou uma CDN de terceiros.
35 Operação da CDN A maioria das CDNs utiliza o DNS para interceptar e redirecionar requisições.
Estratégias de seleção de cluster 36 A estratégia de seleção de cluster é um mecanismo para direcionamento dinâmico de clientes para um cluster de servidor ou uma central de dados dentro da CDN. Uma estratégia simples é associar o cliente ao cluster que está geograficamente mais próximo. Para determinar o melhor cluster para um cliente baseado nas atuais condições de tráfego, as CDNs podem realizar medições em tempo real do atraso e problemas de baixo desempenho entre seus clusters e clientes.
Estratégias de seleção de cluster 37 Uma alternativa para medir as propriedades dos caminhos é usar as características do tráfego mais recente entre os clientes e os servidores da CDN. Uma abordagem muito diferente para combinar clientes com servidores CDN é utilizar o IP para qualquer membro do grupo. A ideia por trás do IP para qualquer membro do grupo é colocar os roteadores na rota da Internet dos pacotes do cliente para o cluster mais próximo, como determinado pelo BGP.
Estratégias de seleção de cluster 38 Usando o anycast IP para rotear clientes para o cluster da CDN mais próximo
Estudos de caso 39 Netflix: CDNs (notadamente Akamai) e links de terceiros / HTTP de fluxo contínuo adaptativo. Servidores próprios de registro e pagamentos. Converte os vídeos em várias resoluções e disponibiliza (nuvem da Amazon). YouTube: Data centers da Google, direciona via DNS para seus data centers. Desde seu modelo de negócios Google usa o HTTP de fluxo contínuo. ½ Bilhão de vídeos e de visualizações diárias. Kankan: Maior na China e usa tecnologia proprietária P2P com hash distribuído (tipo Torrent). UDP sempre que possível.
40 Sumário 7.1 Aplicações de rede multimídia 7.2 Vídeo de fluxo contínuo armazenado 7.3 Voz sobre IP: VoIP (Voice-over-IP) 7.4 Protocolos para aplicações interativas em tempo real 7.5 Suporte de rede para multimídia
As limitações de um serviço IP de melhor esforço 41 Perda de pacotes A perda pode ser eliminada enviando os pacotes por TCP, em vez de por UDP (Facilita no NAT). Se tivermos um enlace altamente congestionado ou um wifi ruidoso pode não dar certo. Atraso de 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 nos enlaces e atrasos de processamento em sistemas finais. Variação de atraso do pacote 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.
Eliminação da variação de atraso no receptor para áudio 42 Atraso por reprodução fixa Perda de pacotes para diferentes atrasos por reprodução fixa
Eliminação da variação de atraso no receptor para áudio 43 Atraso por reprodução adaptativa Objetivo: minimizar o atraso de reprodução, mantendo baixa a taxa de perdas Abordagem: ajuste adaptativo do atraso de reprodução: estima o atraso da rede e ajusta o atraso de reprodução no início de cada surto de voz. períodos de silêncio são comprimidos e alongados. pedaços ainda são reproduzidos a cada 20 mseg durante um surto de voz.
Eliminação da variação de atraso no receptor para áudio 44 Atraso por reprodução adaptativa Segue um algoritmo genérico que o receptor pode usar para ajustar seus atrasos de reprodução adaptativamente. Para tal, consideremos: ti = marca de tempo do i-ésimo pacote = o instante em que o pacote foi gerado pelo remetente. ri = o instante em que o pacote i é recebido pelo receptor. pi = o instante em que o pacote i é reproduzido no receptor. ri ti = atraso da rede para o i-ésimo pacote. di = estimativa do atraso médio da rede após receber o i-ésimo pacote. Estimativa dinâmica do atraso médio no receptor : U é uma constante, por exemplo 0,01 di = (1 u)di-1 + u(ri ti)
Eliminação da variação de atraso no receptor para áudio 45 Atraso por reprodução adaptativa Também é útil estimar o desvio médio do atraso, vi: vi = (1 u)vi-1 + u( ri ti di ) estimativas di, vi são calculadas para cada pacote recebido, apesar de serem usados apenas no início de um surto de voz. Para o primeiro pacote de um surto de voz, o tempo de reprodução é: pi = ti + di + Kvi, onde K é uma constante positiva Os pacotes restantes em um surto de voz são reproduzidos periodicamente de acordo com a codificação.
Eliminação da variação de atraso no receptor para áudio 46 Atraso por reprodução adaptativa Pergunta: Como o receptor determina se um pacote é o primeiro de um surto de voz? se nunca houvesse perdas, o receptor poderia simplesmente olhar os carimbos de tempo sucessivos. diferença entre carimbos sucessivos > 20 mseg --> início do surto de voz. mas, dado que perdas são possíveis, o receptor deve olhar tanto para os carimbos de tempo quanto para os números de sequência diferença entre carimbos sucessivos > 20 mseg e números de sequência sem falhas --> início do surto de voz.
Recuperação de perda de pacotes 47 Um pacote será considerado perdido se nunca chegar ao receptor ou se chegar após o tempo de reprodução programado. Aplicações de VoIP frequentemente usam algum tipo de esquema de prevenção de perda.
Recuperação de perda de pacotes 48 Uma ideia simples: para cada grupo de n pedaços criar um pedaço redundante efetuando o OU-exclusivo dos n pedaços originais transmite n+1 pedaços, aumentando a largura de banda por um fator de 1/n. pode reconstruir os n pedaços originais se houver no máximo um pedaço perdido dentre os n+1 pedaços. atraso de reprodução deve ser fixado para o instante de recepção de todos os n+1 pacotes compromissos: aumento de n, menos desperdício de banda aumento de n, atraso de reprodução mais longo aumento de n, maior probabilidade de que 2 ou mais pedaços sejam perdidos
Recuperação de perda de pacotes 49 Forward Error Correction (FEC): A ideia básica da FEC é adicionar informações redundantes ao fluxo de pacotes original. Dando carona à informação redundante de qualidade mais baixa
Recuperação de perda de pacotes 50 Intercalação Como uma alternativa à transmissão redundante, uma aplicação de VoIP pode enviar áudio intercalado.
Estudo de Caso: VoIP com Skype 51 Skype Proprietário: UDP para áudio e vídeo, mas pode enviar com TCP caso encontre algum bloqueio (por exemplo: NAT)
Estudo de Caso: VoIP com Skype Skype Proprietário: mensagens de controle via TCP 52
Estudo de Caso: VoIP com Skype 53 Skype Proprietário: trabalha com FEC (redundância) e ajusta a qualidade do vídeo e áudio de acordo com as condições da rede
Estudo de Caso: VoIP com Skype 54 Skype Proprietário: rede de sobreposição hierárquica, o superpar é um par comum, que provavelmente mantém uma DHT para localização
Estudo de Caso: VoIP com Skype 55 Skype Proprietário: atrás do NAT não se pode receber uma chamada
Estudo de Caso: VoIP com Skype 56 Skype Proprietário: atrás do NAT não se pode estabelecer um fluxo direto, pois um dos dois receberia uma chamada.
Controle do Usuário de Mídia Contínua: RTSP 57 Não é apresentado no livro texto, mas cabe uma visão geral. HTTP não tem como alvo conteúdo multimídia não possui comandos para avanço rápido, etc. RTSP: RFC 2326 protocolo cliente-servidor da camada de aplicação. usuário pode controlar a reprodução: retorno, avanço rápido, pausa, retomada, reposicionamento, etc
Controle do Usuário de Mídia Contínua: RTSP 58 O que ele não faz: não define como o áudio/vídeo é encapsulado para ser transmitido pela rede Não restringe como a mídia tipo fluxo contínuo é transportada; pode ser transportada sobre UDP ou TCP não especifica como o media player utiliza buffers para áudio/vídeo
Controle do Usuário de Mídia Contínua: RTSP 59 O FTP usa um canal de controle fora de banda : um arquivo é transferido sobre uma conexão TCP. a informação de controle (mudanças de diretório, remoção de arquivo, renomeação de arquivo, etc.) é enviada numa conexão TCP à parte os canais fora de banda e dentro da banda utilizam diferentes números de portas Mensagens RTSP também são enviadas fora de banda: as mensagens de controle RTSP usam números de porta diferentes do fluxo contínuo da mídia, e são, portanto, enviadas fora de banda (Porta 554) o fluxo de mídia é considerado dentro da banda.
Controle do Usuário de Mídia Contínua: RTSP 60 Exemplo RTSP: Cenário: meta arquivo enviado para o browser web browser inicia o media player media player estabelece uma conexão de controle RTSP e uma conexão de dados para o servidor de mídia contínua
Controle do Usuário de Mídia Contínua: RTSP Exemplo de Meta-arquivo: <title>twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="pcmu/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session> 61
Controle do Usuário de Mídia Contínua: RTSP Operação do RTSP: 62
Controle do Usuário de Mídia Contínua: RTSP RTSP: exemplo de diálogo: C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=play S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0c: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK 63
64 Sumário 7.1 Aplicações de rede multimídia 7.2 Vídeo de fluxo contínuo armazenado 7.3 Voz sobre IP: VoIP (Voice-over-IP) 7.4 Protocolos para aplicações interativas em tempo real 7.5 Suporte de rede para multimídia
Protocolo de tempo real (RTP) 65 O RTP pode ser usado para transportar formatos comuns como PCM, ACC e MP3 para som e MPEG e H.263 para vídeo. O protocolo também pode ser usado para transportar formatos proprietários de som e de vídeo. Hoje, o RTP é amplamente implementado em muitos produtos e protótipos de pesquisa. Também é complementar a outros importantes protocolos interativos de tempo real, entre eles SIP.
Protocolo de tempo real (RTP) 66 O RTP especifica uma estrutura de pacote para pacotes que transportam dados de áudio e de vídeo RFC 3550 pacote RTP provê identificação do tipo da carga numeração da sequência de pacotes carimbo de tempo
Protocolo de tempo real (RTP) O RTP comumente roda sobre UDP. 67
Protocolo de tempo real (RTP) 68 Se uma aplicação incorporar o RTP, ela interagirá mais facilmente com as outras aplicações de rede multimídia. O RTP não fornece nenhum mecanismo que assegure a entrega de dados a tempo nem fornece garantias de qualidade de serviço. O RTP permite que seja atribuído a cada origem seu próprio fluxo independente de pacotes RTP. Pacotes RTP não são limitados às aplicações individuais.
Protocolo de tempo real (RTP) 69 Exemplo RTP: considere o envio de voz codificada em PCM de 64 kbps sobre RTP. aplicação coleta os dados codificados em pedaços, ex., a cada 20 mseg = 160 bytes num pedaço. o pedaço de áudio junto com o cabeçalho RTP formam um pacote RTP, que é encapsulado num segmento UDP o cabeçalho RTP indica o tipo da codificação de áudio em cada pacote: o transmissor pode mudar a codificação durante a conferência. o cabeçalho RTP também contém números de sequência e carimbos de tempo.
Protocolo de tempo real (RTP) 70 Os quatro principais campos de cabeçalho do pacote RTP são: Tipos de carga útil de áudio suportados pelo RTP:
Protocolo de tempo real (RTP) Alguns tipos de carga útil de vídeo suportados pelo RTP: 71
Protocolo de Controle de Tempo Real (Real-Time Control Protocol - RTCP) 72 O Livro texto não inclui, mas acho interessante como um complemento. trabalha em conjunto com o RTP. cada participante numa sessão RTP periodicamente transmite pacotes de controle RTCP para todos os demais participantes. cada pacote RTCP contém relatos do transmissor e/ou receptor relatam estatísticas úteis para as aplicações : no. pacotes enviados, no. pacotes perdidos, intervalo entre chegadas (jitter), etc. a realimentação de informação pode ser usada para controlar o desempenho o transmissor pode modificar as suas transmissões com base na realimentação
Protocolo de Controle de Tempo Real (Real-Time Control Protocol - RTCP) RTCP Continuação: para uma sessão RTP há tipicamente um único endereço multicast; todos os pacotes RTP e RTCP pertencentes à sessão usam o endereço multicast. pacotes RTP, RTCP são diferenciados uns dos outros através do uso de números de portas distintos. para limitar o tráfego, cada participante reduz o seu tráfego RTCP à medida que cresce o número de participantes da conferência. 73
Protocolo de Controle de Tempo Real (Real-Time Control Protocol - RTCP) 74 Pacotes RTCP: Pacotes de relato do receptor: fração dos pacotes perdidos, último número de sequência, jitter médio entre chegadas Pacotes de relato do transmissor: SSRC do fluxo RTP, tempo atual, número de pacotes enviados e número de bytes enviados. Pacotes de descrição da origem: endereço de e-mail do transmissor, nome do transmissor, o SSRC do fluxo RTP associado. os pacotes provêm um mapeamento entre o SSRC e o nome do usuário/host.
Protocolo de Controle de Tempo Real (Real-Time Control Protocol - RTCP) 75 Sincronização de Fluxos: o RTCP pode ser usado para sincronizar diferentes fluxos de mídia dentro de uma sessão RTP. considere uma aplicação de videoconferência para a qual cada transmissor gera um fluxo RTP para vídeo e outro para áudio. os carimbos de tempo nestes pacotes RTP estão vinculados aos relógios de amostragem de vídeo e de áudio não estão vinculadas ao relógio de tempo real. cada pacote de relato do transmissor contém, para o pacote gerado mais recentemente no fluxo RTP associado, o carimbo de tempo do pacote RTP e instante num relógio de tempo real em que o pacote foi criado. os receptores pode usar esta associação para sincronizar a reprodução de áudio e de vídeo.
Protocolo de Controle de Tempo Real (Real-Time Control Protocol - RTCP) 76 Escalonamento da Largura de Banda p/ o RTCP: O RTCP tenta limitar o seu tráfego a 5% da largura de banda da sessão. Exemplo: Suponha que haja um transmissor enviando vídeo a uma taxa de 2 Mbps. Então o RTCP tenta limitar o seu tráfego a 100 Kbps. RTCP atribui 75% da taxa p/ os receptores; os restantes 25% p/ o transmissor Os 75 Kbps alocados são compartilhados igualmente entre os receptores: com R receptores, cada receptor pode gerar tráfego RTCP a uma taxa de 75/R Kbps. O transmissor pode gerar tráfego RTCP a uma taxa de 25 Kbps. O participante determina a frequência de transmissão de pacotes RTCP, calculando o tamanho médio do pacote RTCP (ao longo da sessão inteira) e dividindo o tamanho médio do pacote RTCP pela taxa alocada.
77 SIP O Protocolo de Inicialização de Sessão (SIP) é um protocolo aberto e simples, que faz o seguinte (Session Initiation Protocol - RFC 3261): Provê mecanismos para estabelecer chamadas entre dois interlocutores por uma rede IP. para que o chamador informe ao chamado que ele deseja estabelecer uma chamada para que o chamador e o chamado concordem no tipo de mídia e na codificação para encerrar a chamada
78 SIP O Protocolo de Inicialização de Sessão (SIP) é um protocolo aberto e simples, que faz o seguinte (Session Initiation Protocol - RFC 3261): Provê mecanismos que permitem a quem chama determinar o endereço IP atual de quem é chamado. mapeia identificador mnemônico para o endereço IP atual.
79 SIP O Protocolo de Inicialização de Sessão (SIP) é um protocolo aberto e simples, que faz o seguinte (Session Initiation Protocol - RFC 3261): Provê mecanismos para gerenciamento de chamadas: adiciona novos fluxos de mídia durante a chamada altera a codificação durante a chamada convida outros participantes transfere e mantém a chamada
80 SIP Visão de longo prazo do SIP: todas as chamadas telefônicas e de videoconferência se realizam sobre a Internet pessoas são identificadas por nomes ou endereços de email, ao invés de números de telefone é possível encontrar o chamado, não importa onde ele esteja, e em qualquer dispositivo IP que o chamado esteja usando no momento Pode acontecer com o SIP ou não, mas é uma tendência
SIP Estabelecimento de chamada SIP quando Alice conhece o endereço IP de Bob Mensagem invite de Alice indica o seu número de porta, endereço IP e a codificação em que Alice prefere receber (PCM ulaw) A mensagem 200 OK de Bob indica o seu número de porta, endereço IP e codificação preferida (GSM) Mensagens SIP podem ser transmitidas sobre TCP ou UDP; aqui está sendo enviada sobre RTP/UDP. número de porta Default do SIP é a 5060. 81
82 SIP Negociação de codificação: Rejeitando a chamada: Suponha que Bob não possui um codificador PCM ulaw. Bob responderá então com um código 606 Not Acceptable Reply e lista os codificadores que ele pode usar. Alice pode então enviar uma nova mensagem INVITE, anunciando um codificador apropriado Bob pode rejeitar com respostas busy (ocupado), gone (fora) payment required (necessário pagamento), forbidden (proibido). A mídia pode ser enviada sobre RTP ou algum outro protocolo
83 SIP Tradução de nome e localização do usuário: chamador deseja contactar o chamado, mas possui apenas o nome ou o endereço de e-mail do chamado. precisa obter o endereço IP do host atual do chamado: usuário se desloca protocolo DHCP usuário possui diferentes dispositivos IP (Note, Celular, dispositivo no automóvel, geladeira, fogão,...)
84 SIP Tradução de nome e localização do usuário (continuação): O resultado pode depender de: hora do dia (trabalho, casa) chamador (não deseja que o chefe lhe chame em casa) status do chamado (chamadas enviadas para correio de voz quando o chamado já estiver falando com alguém) Serviço provido por servidores SIP: Servidor de registro SIP Servidor proxy SIP
85 SIP Servidor de Registro SIP: Quando Bob inicia cliente SIP, o cliente envia uma mensagem REGISTER SIP para o servidor de registros de Bob (função semelhante é necessária para serviço de mensagens instantâneas) Mensagem Register: REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600
86 SIP Servidor proxy SIP: Alice envia mensagem invite para o seu servidor proxy contém endereço sip:bob@domain.com O proxy é responsável por rotear mensagens SIP para o chamado possivelmente através de múltiplos proxies O chamado envia resposta através do mesmo conjunto de proxies. O proxy retorna a mensagem de resposta SIP para Alice contendo o endereço IP de Bob Nota: proxy é análogo a um servidor DNS local
SIP Inicialização de sessão envolvendo proxies e entidades registradoras SIP: Chamador jim@umass.edu faz uma chamada para keith@upenn.edu (1) Jim envia mensagem INVITE para o proxy SIP da umass. (2) Proxy encaminha o pedido para o servidor de registro da upenn. (3) O servidor da upenn retorna resposta de redirecionamento, indicando que deve tentar keith@eurecom.fr 87
SIP de sessão Inicialização envolvendo proxies e entidades registradoras SIP (continuação): (4) O proxy da umass envia INVITE para o registro da eurecom. (5) Registro da eurecom encaminha o INVITE para 197.87.54.21, que está rodando o cliente SIP de Keith. (6-8) retorno da resposta SIP. (9) mídia enviada diretamente entre clientes. Nota: mensagens ack do SIP, não são apresentadas. 88
89 Sumário 7.1 Aplicações de rede multimídia 7.2 Vídeo de fluxo contínuo armazenado 7.3 Voz sobre IP: VoIP (Voice-over-IP) 7.4 Protocolos para aplicações interativas em tempo real 7.5 Suporte de rede para multimídia
Suporte de rede para multimídia 90 Até o momento: extraímos o máximo do melhor esforço Um único tamanho veste todos os modelos de serviço Alternativa: múltiplas classes de serviço dividir o tráfego em classes A rede trata diferentes classes de tráfego de modo diferente (analogia: serviço VIP x serviço regular) granularidade: serviço diferenciado entre múltiplas classes, não entre conexões individuais história: bits ToS
Suporte de rede para multimídia 91 Três técnicas em nível de rede para dar suporte a aplicações de multimídia:
Dimensionando redes de melhor esforço 92 A questão de como projetar uma topologia de rede para alcançar determinado nível de desempenho de fim a fim é um problema de projeto de redes que muitas vezes é chamado de dimensionamento de redes. Sabendo que a Internet de melhor esforço de hoje poderia dar suporte para o tráfego de multimídia em um nível de desempenho apropriado, se fosse dimensionada para fazer isso, a questão é por que a Internet de hoje não o faz. As respostas organizacionais. são principalmente econômicas e
Fornecendo múltiplas classes de serviço 93 Já estamos acostumados com diferentes classes de serviço em nossas vidas diárias. É importante observar que esse serviço diferencial é fornecido entre agregações de tráfego, ou seja, entre classes de tráfego, e não entre conexões individuais. Até mesmo há três décadas, a visão de fornecer diferentes níveis de serviço a diferentes níveis de tráfego estava evidente. No entanto, levou um longo período para que pudéssemos perceber essa visão.
Cenários motivadores 94 Exemplo: Telefone IP de 1Mbps, HTTP compartilhando enlace de 1,5 Mbps. Surtos de HTTP (TCP) podem congestionar o roteador e causar a perda de pacotes de áudio Queremos dar prioridade ao tráfego de áudio sobre o de HTTP Como distinguir?
Cenários motivadores 95 Exemplo: Telefone IP de 1Mbps, HTTP compartilhando enlace de 1,5 Mbps. Surtos de HTTP (TCP) podem congestionar o roteador e causar a perda de pacotes de áudio Queremos dar prioridade ao tráfego de áudio sobre o de HTTP Princípio 1: A marcação de pacotes permite que um roteador faça a distinção de pacotes pertencentes a diferentes classes de tráfego.
Cenários motivadores 96 E se as aplicações se comportarem mal (áudio envia pacotes a taxas mais elevadas do que a declarada)? policiamento: força que origens respeitem as alocações de banda marcação e policiamento nas bordas da rede: similar ao ATM UNI (User Network Interface) Princípio 2: É desejável fornecer algum grau de isolamento de tráfego entre as classes, para que uma classe não seja afetada adversamente por outra classe de comportamento inadequado.
Cenários motivadores 97 Alocar uma largura de banda fixa (não compartilhável) para o fluxo: uso ineficiente da banda se os fluxos não usarem suas alocações 1,0 Mbits/s 0,5 Mbits/s Princípio 3: Ao fornecer isolamento de classes ou fluxos, é desejável que se usem os recursos da maneira mais eficiente possível.
Cenários motivadores 98 Regulação (e marcação) das classes de tráfego de áudio e HTTP
Cenários motivadores Isolamento lógico das classes de tráfego de áudio e HTTP 99
Mecanismos de escalonamento 100 Primeiro a entrar/primeiro a sair (FIFO) política de descarte: se os pacotes ao chegarem encontrarem a fila cheia: quem deve ser descartado? descarta o último (cauda): descarta o pacote que acabou de chegar prioridade: descarta/remove baseado na prioridade randômico: descarta/remove aleatoriamente
Mecanismos de escalonamento 101 Enfileiramento prioritário: transmite pacote enfileirado de mais alta prioridade múltiplas classes, com diferentes prioridades classe pode depender da marcação ou outra informação do cabeçalho (ex. IP origem/destino, números de portas, etc.) De S.O. Qual é o problema dessa abordagem?
Mecanismos de escalonamento 102 Varredura cíclica e WQF (enfileiramento justo ponderado) Round Robin generalizado cada classe recebe um tempo de serviço diferenciado em cada ciclo
Mecanismos de policiamento 103 Objetivo: limita o tráfego para que não exceda os parâmetros declarados Três critérios comumente usados: Taxa Média (de Longo prazo): quantos pacotes podem ser enviados por unidade de tempo (em longo prazo) questão crucial: qual é o comprimento do intervalo: 100 pacotes por seg ou 6000 pacotes por min têm a mesma média! Taxa de Pico: ex., 6000 pacotes por minuto (ppm) em média e taxa de pico de 1500 ppm Comprimento (Máx.) do Surto: número máximo de pacotes enviados consecutivamente (sem intervalo ocioso)
Mecanismos de policiamento e escalonamento 104 Balde furado: o balde pode guardar b permissões Os tokens são gerados a uma taxa de r token/seg a menos que o balde esteja cheio num intervalo de comprimento t: número de pacotes admitidos é menor ou igual a (r t + b).
Mecanismos de policiamento e escalonamento 105 Balde furado + enfileiramento justo ponderado = máximo atraso provável em uma fila (QoS!) limita a entrada para Tamanho do Surto e Taxa Média especificadas.
106 Diffserv Diffserv oferece diferenciação de serviço. A arquitetura Diffserv consiste em dois conjuntos de elementos funcionais: 1. Funções de borda: classificação condicionamento de tráfego. 2. Função central: envio. de pacotes e
107 Diffserv Deseja-se classes de serviço qualitativas comportamento de circuito Distinção relativa do serviço: Platina, Ouro, Prata Escalabilidade: funções simples no núcleo da rede, funções relativamente complexas nos roteadores de borda (ou nos hosts) Sinalização, manter estado por fluxo no roteador é difícil para um grande número de fluxos Não define classes de serviço, provê componentes funcionais para implementação das classes de serviço
Diffserv Exemplo simples de rede Diffserv... Borda: gerenciamento de tráfego por-fluxo marca os pacotes como dentro-perfil e fora-perfil 108
Diffserv 109 Exemplo de uma rede Diffserv simples (Borda) IP: Origem/Destino Porta: Origem/Destino Protocolo de transporte Classe de tráfego
Diffserv 110 Exemplo simples de rede Diffserv... Núcleo (PHB): gerenciamento de tráfego por classe armazenamento e escalonamento baseado na marcação feita na borda preferência para os pacotes dentro-perfil
Garantias de QoS por conexão: reserva de recurso e admissão de chamada 111 Duas aplicações de áudio concorrentes sobrecarregando o enlace de R1 a R2
Garantias de QoS por conexão: reserva de recurso e admissão de chamada 112 Sabendo que essas duas aplicações não podem ser atendidas simultaneamente, o que a rede deve fazer? Um dos fluxos de aplicação deve ser, enquanto o outro deve prosseguir, usando o 1 Mbit/s inteiro necessário pela aplicação. O processo de um fluxo declarar seu requisito de QoS e a rede aceitar o fluxo (na QoS solicitada) ou bloqueá-lo é denominado processo de admissão de chamada.
Garantias de QoS por conexão: reserva de recurso e admissão de chamada 113 Princípio 4: Se recursos suficientes nem sempre estiverem disponíveis e a QoS tiver de ser garantida, é necessário um processo de admissão de chamada no qual os fluxos declaram seus requisitos de QoS e, então, são admitidos à rede ou bloqueados da rede. Nosso exemplo motivador na figura anteriormente apresentada enfatiza a necessidade de diversos novos mecanismos e protocolos de rede, se uma chamada tiver de garantir determinada qualidade de serviço uma vez iniciada
Garantias de QoS por conexão: reserva de recurso e admissão de chamada Reserva de recurso. Admissão de chamada. Sinalização do estabelecimento de chamada. 114
115 Capítulo 7 - FIM