Distribui

1
Distribuição de Mídia ContínuaTransmissão

• Jussara M. Almeida

Março 2004
2
Transmissão de Mídia Contínua

• Transmissão de Fluxos Independentes
• Unicast

Servidor Origem
3
Transmissão de Mídia Contínua

• Transmissão de Fluxos Independentes
• Unicast
• Crescimento linear na demanda por largura de
  banda do servidor e da rede
• Baixa escalabilidade
• Ex 1 arquivo MPEG de 1 hora 1.5 Mbps
• 1500 fluxos simultâneos 2.25 Gbps

4
Transmissão de Mídia Contínua

• Transmissão com Compartilhamento de Fluxos
• Multicast um único fluxo enviado para múltiplos
  clientes
• A nível de protocolo de rede IP ou a nível de
  aplicação

Fluxo multicast
Servidor Origem
roteador
5
Transmissão de Mídia Contínua

• Transmissão com Compartilhamento de Fluxos
• Multicast um único fluxo enviado para múltiplos
  clientes
• A nível de protocolo de rede IP ou a nível de
  aplicação

Fluxo unicast
Servidor Origem
roteador
6
Transmissão de Mídia Contínua

• Transmissão com Compartilhamento de Fluxos
• Redução significativa na demanda por largura de
  banda
• Melhora QoS (qualidade observada pelos clientes)
• Classificação
• Cliente recebe apenas 1 fluxo vs. múltiplos
  fluxos simultâneos
• Demanda por largura de banda do cliente
• Difusão vs. técnicas orientadas às requisições
  dos clientes
• Distribuição sob demanda verdadeira
• Escalabilidade e desempenho sob cargas variadas

7
Batching
8
Batching

• Cliente recebe apenas um fluxo
• Método genérico utilizado em conjunto com outras
  técnicas
• Transmissão orientada pelas requisiçoes dos
  clientes
• Às vezes em conjunto com técnicas baseadas em
  difusão
• Introdução de atrasos de partida adicionais
• Nao provê distribuição sob demanda verdadeira

9
Piggybacking

• Mudança dinâmica da taxa de transmissão e
  exibição para permitir que um fluxo possa
  alcançar e se juntar a outro fluxo
• Baseado em stream merge

10
Piggybacking
Dados recebidos pelos clientes
Tempo
11
Piggybacking

• Provê vídeo sob demanda verdadeiro
• Cliente escuta/recebe apenas um fluxo
• Não introduz atrasos adicionais na partida
• Requer hardware especialiado para suportar
  mudanças dinâmicas na velocidade do canal
• Eficiência limitada pela mudança máxima tolerada
  por um usuário ( 5)

12
Periodic Broadcast

• Vídeos são transmitidos periodicamente
• novo fluxo a cada ? minutos
• Batching de clientes
• ? batching interval
• Latência observada pelo cliente ? (Pior caso)
• Não provê video sob demanda verdadeiro
• Largura de banda fixa, independente da carga
• Eficiente para taxa de chegada de requisições
  alta
• Diversas otimizacões do protocolo base
• Pyramid Broadcast, Permutation-Based Pyramid
  Broadcast
• Skyscraper Broadcast

13
Periodic Broadcast

• Batching de clientes

0
T
...
...
...
...
. . .

• reserva K canais para cada hot popular
• novo fluxo multicast do arquivo a cada T/K unid.
  de tempo
• E.x., K25 maxima latência 0.04T
• Demanda por largura de banda do servidor é
  independente da demanda pelo arquivo (carga)
• Outros arquivos batching sob demanda (FCFS)

14
Pyramid Broadcast

• Divide cada video em K segmentos de tamanhos
  crescentes
• D1, ?D1, ?2D1, ?3D1 , ? gt 1 (crescimento
  geométrico)
• Largura de banda total B dividida em K canais
  lógicos
• Canal i transmite ith segmento de cada video, em
  round robin a uma taxa B/K (gtgt taxa de
  visualização, b)
• Cliente contacta servidor e recebe uma
  programação de quando deve se conectar em cada
  canal
• O download do segmento i pode começar assim que
  cliente começa a visualizar segmento i-1
• Cliente recebe em no máximo 2 canais simultâneos
• Visualiza os dados recebidos em 1 canal
• Armazena dados recebidos no outro canal no disco

15
Pyramid Broadcast

• Latência do cliente diminui com B (bom!!)
• Se B alto suficiente, pode ter a video sob
  demanda verdadeiro
• Alta demanda por largura de banda no cliente
• b 2B/K
• Alta demanda por espaço no cliente
• Precisa armazenar ate 84 do video

16
Permutation-Based Pyramid Broadcast

• Mesmo princípio do Pyramid Broadcast
• Mas
• cada canal lógico e dividido em P subcanais para
  cada video
• Cada segmento i de um video é transmitido nos
  subcanais de i a cada Di/P minutos à taxa B/KPM
• M videos
• Redução na demanda por largura de banda e disco
• Redução limitada na demanda por espaço
• progressão geométrica
• Método mais complexo e com latência mais alta

17
Skyscraper Broadcast

• Divisão da largura de banda total B em B/b canais
• Atribuição de K canais para cada video
• K B/bM, onde M videos
• Cada video é dividido em K segmentos com tamanhos
  crescentes seguindo a progressão
• 1, 2, 2, 5, 5, 12 ,12 ,25, 25, 52, 52,
• Parâmetro W restrição no tamanho máximo de um
  segmento
• Quanto maior W maior a demanda por espaço no
  cliente
• Quanto menor W, maior D1, maior latência

18
Skyscraper Broadcast

• Clientes recebem segmentos em transmission groups
  
• Cada grupo segmentos consecutivos com mesmo
  tamanho
• Tres rotinas
• Carregador de grupos pares (Even Loader)
• Carregador de grupos impares (Odd Loader)
• Visualizador
• Cada carregador recebe os segmentos dentro de um
  grupo em sequência
• Carregador par e impar podem receber
  simultaneamente, armazenando dados em buffer
  local
• Pergunta óbvia qual o tamanho máximo deste
  buffer?
• Recebimento de dados sem jitter

19
Skyscraper Broadcast
Channel 0
...
...
1
...
2
...
3
...
4
...
5
...
6
...
7

• Clientes são agrupados hierarquicamente durante
  transmissão (compartilhamento)
• K 8, tamanhos dos segmentos
  1,2,2,6,6,12,12,12
• W 12
• Latência máxima D1 T/53 ? 0.02T

20
Skyscraper Broadcast

• Alocação estática de canais para cada video
• Se popularidade alta ótimo!!
• Grande economia na largura de banda
• Mas e se popularidade varia com o tempo?
• Dynamic Skyscraper

21
Dynamic Skyscraper Broadcast

• Transmissão sob demanda

• skyscraper transmission clusters
• - sequências que compartilham o mesmo segmento no
  canal K
• - largura W (em cada canal)
• - cada cluster pode transmitir um arquivo
  diferente (sob demanda)

22
Dynamic Skyscraper Broadcast

• Largura de banda do servidor
• Total de C canais e N objetos
• Divisão de C canais em N grupos, de K canais cada
• Cada grupo de K canais, uma progressão de
  tamanhos de segmentos limitada por W (igual a
  static skyscraper)
• Diferencial Alocacão dinâmica dos canais para
  diferentes videos
• Cada transmission cluster alocado para um objeto
  diferente em resposta às requisições dos clientes
• Todas as sequências no mesmo cluster transmitem
  segmentos do mesmo arquivo

23
Dynamic Skyscraper Broadcast

• Transmission cluster (exemplo no paper)
• Contém todos os segmentos nos canais 1..k-1 que
  compartilham cada segmento transmitido no canal k
  
• Um novo cluster no canal 1 a cada W slots
• Não usa nenhum período no canal 1..k-1 que faça
  parte da primeira sequência de segmentos do
  próximo cluster
• Alguns segmentos nao pertencem a nenhum
  transmission cluster
• Ex Segmento com tracejado em diagonal no canal 0
  
• Depende da progressão de tamanhos de segmentos
• Diferentes progressões podem levar a desempenho
  melhor evita desperdício de banda

24
Dynamic Skyscraper Broadcast

• N grupos de K canais
• Cada grupo, sequência de transmission groups
• Transmission groups em diferentes grupos são
  persistently staggered
• Novo transmission group a cada ? W x T1 / N
  (latência)
• Escalonamento de transmission group FCFS (FIFO)

25
Dynamic Skyscraper Broadcast

• Otimização temporary channel stealing
• Requisição para objeto Oi na fila a espera de um
  segmento livre no primeiro canal do transmission
  group alocado para Oi
• Um segmento livre no canal 1 transmission group
  alocado para Oj pode ser temporariamente alocado
  pra transmitir Oi (atender requisição pendente)

26
Dynamic Skyscraper Broadcast

• Nova progressão de tamanhos
• 1, 2, 2, 4, 4, 8, 8, 16, 16 .
• Provê transmissão do arquivo inteiro sem jitter
• Clientes recebem no máximo 2 canais
  simultaneamente
• Clientes que só têm banda suficiente pra receber
  1 canal também são atendidos (1a sequência
  de segmentos)
• Nao acarreta desperdício de banda
• Todos segmentos são utilizados para transmissão
• Todos os transmission groups têm largura W
• Demanda por espaço no cliente O(W)
• 1o cliente recebe segmentos sem necessidade de
  buffer
• Clientes que recebem o último broadcast do 1o
  segmento, recebem este segmento W-1 unidades de
  tempo depois do 1o cliente e compartilham
  transmissão do último segmento (canal K)

27
Dynamic Skyscraper Broadcast

• Progressões alternativas
• 1, 2, 2, 6, 6, 12, 12, 24, 24 .
• 1, 2, 2, 6, 6, 12, 12, 36, 36 .
• Crescimento mais rápido melhor desempenho
  (menor latência)
• Cliente tem que receber no máximo 3 canais
  simultaneamente

28
Compartilhamento de Fluxos Técnicas Orientadas
às Requisições dos Clientes

• Patching e Hierarchical Stream Merging
• Princípio comum
• Cliente escuta a mais de um fluxo simultaneamente
• Dados recebidos em um fluxo são visualizados
  imediatamente
• Dados recebidos no outro fluxo são armazenados
  para visualização futura
• Requer buffer no cliente
• Provê video sob demanda verdadeiro
• Superior a Periodic Broadcast e metodos Skyscraper

29
Patching

• Motivação
• Prover video sob demanda verdadeiro
• Latência do cliente tem que ser bem pequena
  (ou nula)
• Reduzir demanda por largura de banda do servidor
• Resolver o problema de gargalo na rede
  (network-I/O bottleneck)
• Cada fluxo multicast tem que servir um grande
  número de usuários

30
Patching

• Um fluxo multicast transmite
• Arquivo inteiro fluxo regular
• Prefixo fluxo patch

Cliente c1 recebe fluxo patch ao mesmo tempo que
escuta fluxo regular. Depois de t1-t0, os dois
clientes receberam os mesmos dados. Fluxo patch e
finalizado
Dados recebidos pelos clientes
Tempo
31
Patching

• Projeto do cliente e do servidor (paper)
• Questão chave
• Quando iniciar novo fluxo regular?
• Variações
• Greedy Patching
• Somente quando não houver nenhum ativo
  (Agressivo)
• Grace Patching
• Quando prefixo perdido pelo cliente maior que
  buffer local
• Comparação (paper)

32
Early Merging/
Hierarchical Multicast Stream Merging

• Objetivo criar merge trees eficientes (minimiza
  demanda por largura de banda)
• Cliente escuta, simultaneamente, um fluxo com o
  prefixo do arquivo e um fluxo anterior (fluxo
  alvo)
• Pergunta Como escolher o fluxo alvo para cada
  novo cliente? (multiplos merges possiveis)
• Stream Merging Otimo
• Solucao offline Programacao dinamica
• Solucao online computa arvore de custo minimo
  para os fluxos ativos a cada chegada de uma nova
  requisicao
• Complexidade de tempo cubica no de requisicoes
  
• Complexidade de espaco quadratica

33
Early Merging

• Intuicao realizar, primeiramente, os merges que
  puderem ser feitos primeiro
• Principios
• Decisao do fluxo alvo para um cliente (ou grupo
  de clientes) deve ser feita quando o cliente
  chega ou quando ele faz um merge com um outro
  fluxo.
• Cliente deve escutar o fluxo alvo ate que o merge
  seja realizado com sucesso ou ate que ele seja
  preemptado por um (grupo de) cliente que chegou
  depois dele
• Se preemptado, o cliente tem que jogar for a
  (ignorar) todos os dados recebidos no seu fluxo
  alvo corrente, escolher um novo fluxo alvo e
  recomecar a armazenar dados no buffer local,
  recebidos no novo fluxo alvo.
• Early Merging Hierarhical Multicast Stream
  Merging

34
Variantes do
Hierarchical Multicast Stream Merging

• Early Reachable Merge Target (ERMT)
• Fluxo alvo de um cliente fluxo mais proximo com
  o qual ele pode realizar o merge se nao for
  preemptado, no futuro.
• Precisa simular evolucao do sistema
• Simple Reachable Merge Target (SRMT)
• Fluxo alvo de um cliente fluxo mais proximo
  alcancavel se cada fluxo correntemente ativo
  terminar no seu merge point corrente.
• Ignora novos fluxos criados apos um merge

35
Variantes do
Hierarchical Multicast Stream Merging

• Closest Target (CT)
• Fluxo alvo fluxo mais proximo ainda ativo no
  sistema.
• Politica mais simples
• Surpreendentemente, desempenho muito proximo de
  ERMT e otimo

36
Escalabilidade dos Protocolos

• Limite Inferior para servico imediato
• Processo de chegada Poisson, largura de banda do
  cliente infinita
• Demanda por largura de banda do servidor ln
  (N1)
• Optimized Grace Patching
• Janela de patching otima
• Demanda por largura de bandado servidor
• One N de chegadas de clientes por playback
• Dynamic Skyscraper
• Partitioned Dynamic Skyscraper
• Demanda por largura de banda do servidor O(k ?
  ln(N)), 2 ? k ? 3

37
Escalabilidade dos Protocolos

• HMSM
• Calculado via simulacao
• Demanda por largura de banda do servidor B
  1.62 ln(N/1.62 1)
• Muito proximo do otimo

38
Comentarios Finais

• Bandwidth Skimming
• HMSM para clientes com largura de banda limitada
• Cliente pode escutar a 1.2 fluxos
• Interatividade
• Muito pouco explorada
• Skyscraper aplicacao dificil
• Patching e HMSM
• Aplicacao direta
• Mas alguns resultados de simulacao com cargas
  reais mostram que escalabilidade de HMSM
  e Patching cai muito
• Novas propostas para Patching e HMSM a caminho