Upload
nickan
View
23
Download
0
Embed Size (px)
DESCRIPTION
Distribuição de Mídia Contínua Replicacao de Conte u do. Jussara M. Almeida. Maio 200 5. Prefix Caching. Reducao da latencia inicial “Esconde” dos clientes a qualidade de servico disponivel no caminho entre proxy e servidor Atrasos no servidor para recuperar conteudo - PowerPoint PPT Presentation
Citation preview
Distribuição de Mídia Contínua
Replicacao de Conteudo
Jussara M. Almeida
Maio 2005
Prefix Caching
1. Reducao da latencia inicial
– “Esconde” dos clientes a qualidade de servico disponivel no caminho entre proxy e servidor
– Atrasos no servidor para recuperar conteudo
– Variabilidade de latencia na rede
– Perda de pacotes (2-10%)
• Critico se TCP ou TCP-friendly e usado para transmitir fluxo : reducao da qualidade
Prefix Caching
2. VBR : Reducao na demanda por banda da rede e do servidor atraves de workahead smoothing (suavizacao da transmissao)
– Grandes frames sao transmitidos antes da hora
– Prefix caching “esconde” atraso de smoothing
– Alternativa: proxy armazena parte variavel do video:
• Desvantagem: custo de armazenamento depende do tamanho do video
Prefix Caching para Reducao da Latencia
Inicial• Tamanho do prefixo depende das propriedades
de desempenho entre servidor e proxy
– Se atraso no servidor entre dmin e dmax e latencia maxima permitida pelo cliente s
Caching de prefixo de tamanho max {dmax-s, 0}
– 5 segundos de MPEG-2 – 2.5 3 Mbytes
– Prefixo no disco e primeiros frames em RAM
• Pode armazenar prefixos de diferentes segmentos (inicios de cenas ou marcadores)
– Interatividade limitada sem latencia extra
– Maior interatividade: tratada no cliente
Prefix Caching para Reducao da Latencia
Inicial• Buffer extra de tamanho dmax – dmin para
absorver jitter
• Proxy pode usar UDP com cliente
• Transparent Caching:
– Caching dinamico ou pre-configurado (CDN)
• Implementacao:
– range request (HTTP 1.1) ou absolute positioning (RTSP)
Prefix Caching para Workahead Smoothing
• Prefix caching permite proxy realizar smoothing no buffer do cliente sem aumentar atraso
• Smoothing:
– minimiza picos e rajadas na demanda por banda de rede/servidor de fluxos VBR
– restricoes de espaco e atrasos
– Se nao existe proxy, servidor pode fazer smoothing no cliente
• Servidor tem que conhecer buffer do cliente
• Atrasos adicionais
Modelo de Smoothing• Parametro chave: janela de smoothing w
– w s, onde s e latencia maxima permitida pelo cliente
• Cliente tem buffer bc
• Proxy tem:
– buffer para prefixo bp = dmax – s + w (em # frames)
– buffer bs para armazenar temporariamente dados do servidor (staging buffer)
• Di = total # bits dos primeiros i frames do video
• Ai = total # bits recebidos pelo proxy ate tempo i
– Inclui prefixo (A0 = Ddmax-s+w )
• Si = total # bits enviados por proxy ate tempo i
Modelo de Smoothing• Cliente envia requisicao:
Proxy responde com prefixo de tamanho Ddmax-
s+w
Proxy requisita transmissao do video ao servidor iniciando do frame dmax – s + w + 1
Modelo de Smoothing
• Ai: padrao de chegada de dados no proxy, sujeito a jitter = dmax - dmin
– Ai [Ai, min , Ai, max ] (equacoes na pagina 5 do paper)
– Se jitter = dmax , Ai=Ai, min :
– Se jitter = dmin , Ai=Ai, max :
Modelo de Smoothing• Smoothing: precisa determinar quando
enviar cada frame a frente do tempo, precisa fazer um schedule de transmissao
– Restricoes de transmissao (restricoes para Si)
• Objetivo : Determinar limites inferiores e superiores para Si que permitam computar um schedule que satisfaça:
– S0 = 0
– SN+s = DN
Modelo de Smoothing• Limites inferiores para Si
– O cliente tem que receber no minimo Di-s+1 bits ate tempo i para que buffer bc nao fique vazio
– O proxy tem que enviar pelo menos Ai,max – bs para impedir que staging buffer exploda
• Limite superior para Si
– Em cada momento i, o proxy nao pode enviar mais dados do que o buffer no cliente permita ou que ele tenha garantidamente recebido.
Modelo de Smoothing• Dadas as restricoes para cada instante i, Li e Ui, precisa
gerar um schedule S, ou um caminho monotonicamente nao-decrescente que nao cruze as curvas de restricao
– Shortest Path Transmission Schedule : O(N)
Modelo de Smoothing• Dadas as restricoes para cada instante i, Li e Ui,
precisa gerar um schedule S, ou um caminho monotonicamente nao-decrescente que nao cruze as curvas de restricao
– Shortest Path Transmission Schedule : O(N)
• Opcoes:
– Pre-calcula schedule e armazena em proxy com prefixo
• Calculo depende apenas dos tamanhos dos frames
• Grandes jitters leva a schedule conservador
– Calcula schedule S dinamicamente a medida que frames chegam do servidor
• Smoothing mais agressivo
Avaliacao• Eficiencia de Smoothing sem prefix
caching
w = s – d
(d = dmax = dmin)
Peak rate diminui muito com aumento de w (aumento de s e/ou diminuicao de d)
Avaliacao
• Eficiencia de Smoothing sem prefix caching
– Ganhos so podem ser alcancados se cliente puder tolerar latencia alta
– Prefix caching permite proxy realizar smoothing com um janela maior (maior ganho) ao custo de latencia menor
Avaliacao
• Impacto da janela de smoothing na demanda por espaco com e sem caching de prefixo
Com prefixo: bp = d – s + w
Calcula otimo schedulede transmissao para cenario com e sem caching de prefixo (sem restrição quanto a bs)
Avaliacao
• Impacto da janela de smoothing na demanda por espaco com e sem caching de prefixo
– Aumenta janela, aumenta demanda por espaco
– Quantidade de espaço total necessária nos dois cenários são comparáveis para diferentes valores de w
– Tamanho total dos buffers nos dois casos: 3-5MB
Avaliacao• Impacto do tamanho do buffer na taxa
maxima de transmissão
Avaliacao• Impacto do tamanho do buffer na taxa maxima
de transmissão – Maior d, maior demanda por espaco para mesma
reducao de banda (maior prefixo deve ser armazenado) (Fig 6)
– Poucos Mbytes de espaco sao suficientes para grande reducao na banda alem de esconder grandes atrasos
• 2MB de espaco total no proxy (bp+bs) na Fig 6:
– reducao de peak rate de 44.5 Mbps para 4 Mbps
– suporte para atrasos de ate 5 segundos
Avaliacao• Como dividir espaço disponível entre bp e bs?
– bp grande: permite smoothing sobre janela w maior
– bs grande: absorve variaçoes de frames grandes
Avaliacao• Peak rate X janela de smoothing w
Avaliacao• Peak rate X janela de smoothing w
– bp aumenta com w, bs = M - bp
– Inicialmente valor otimo bs* tambem aumenta com w (enquanto bs* < bs)
– Se w aumenta ainda mais, bs* e limitado por bs, e ambos diminuem. O peak rate aumenta
• Tamanho pequeno do staging buffer forca proxy a transmitir mais agressivamente para evitar overflow.
– Desempenho degrada para bp > M/2: alocacao simetrica entre prefix buffer e staging buffer (Fig 8)
Replicacao de Conteudo com Compartilhamento de
Fluxos
Exemplo: 10 servidores proxy, taxa de requisição por proxy = 100
vs. um servidor origem com taxa total = 1000
Complexidade extra devido às novas relações de custo
O que é mais barato? 10770 fluxos do proxy ou 12 fluxos da origem ?
0
5
10
15
20
1 10 100 1000
Taxa de Requisições (N)Larg
ura
de B
an
da M
éd
ia
do S
erv
idor
(# fl
uxos)
BandwidthSkimming
Replicacao de Conteudo com Compartilhamento de
Fluxos• Novos trade-offs– Unicast: de forma abstrata, conteudo otimo e o
conteudo correntemente mais popular
– Multicast: mesmo abstratamente, otimo e desconhecido
– Alem de reduzir latencia inicial e permitir smoothing, caching de prefixos pode ter custo-beneficio mesmo para acesso sequencial a arquivo inteiro
• Prefixo e transmitido mais frequentemente
• Sufixo compartilhado por um # maior de clientes (custo do fluxo amortizado entre estes clientes)
– Conteudo otimo depende do numero de servidores proxy e do custo relativo de um fluxo do proxy para o custo de um fluxo da origem
Replicacao de Conteudo com Compartilhamento de
Fluxos• Foco corrente: modelos de otimizacao
para determinacao do conteudo otimo
• Protocolos considerados:
– Dynamic Skyscraper
– Patching
– Bandwidth Skimming
Optimal Proxy Cache Allocation for Efficient Streaming Media
Distribution• Compartilhamento de banda + caching: redução
de carga no servidor e latência
• Este trabalho:
– Combinação de prefix caching no proxy com esquemas de transmissão reativas com auxílio do proxy
– Disponibilidade de multicast limitada: somente entre proxy e cliente, se houver.
• Fácil implantação com servidores já existentes na Internet atual
Perguntas Chaves
• Quais protocolos de transmissão reativos com auxílio de proxy existem?
– Como estender protocolos atuais (Patching e Bandwidth Skimming) para uso de proxy?
• Para um dado protocolo: qual o conteúdo do proxy (prefix caching) que minimiza o custo de transmissão?
• Quais são os tradeoffs entre tamanho do proxy cache e banda de transmissão para os diferentes protocolos?
Contribuição• Técnica de alocação geral para determinar
conteúdo ótimo do protocolo
– Geral, mas utiliza características do protocolo em questão
• Novos métodos de transmissão que exploram uso do proxy para reduzir custo de transmissão
– Nem sempre multicast está disponível (somente no caminho proxy-cliente, se houver)
• Avaliação do impacto de método de transmissão, política de alocação do cache, tamanho do cache e disponibilidade de multicast no custo de transmissão
Modelo• Premissas
– Acesso sequencial sempre iniciando da posição 0
– Requisições do cliente sempre passam pelo proxy
• Foco:
– Um servidor e um proxy
– Arquivos heterogêneos (diferentes tamanhos e bitrates)
Modelo• N videos CBR
• Caching grain u: tamanho da unidade mínima de alocação no cache
• Video i tem:
– Bitrate bi
– Duração Li segundos
– Tamanho ni unidades : niu=biLi
– probabilidade de acesso pi (dada por lei de Zipf nos experimentos)
• Tamanho do cache: S unidades
Modelo• cp: custo associado a transmitir um bit
de video no caminho servidor-proxy
• cs: custo associado a transmitir um bit de video no caminho proxy-cliente
• Ci(vi): custo de transmissão por unidade de tempo para video i, quando prefixo de tamanho vi é armazenado no cache
• Objetivo: minimizar N
iii vC
1
)(
Alocação Ótima do Cache• Ai: conjunto de todos os possíveis prefixos do
video i
– Ai = {mi | 0 mi ni }
• savings(mi) = redução no custo de transmissão quando prefixo de tamanho mi do video i é armazenado no cache, comparado com o custo de transmissão quando não armazena nenhum prefixo
– savings(mi)= Ci(0) – Ci(mi)
Alocação Ótima do Cache• Problema de otimização
• Solução polinomial por programação dinâmica
– Técnica geral.
– Ci(mi) depende do protocolo usado mas pode ser qualquer expressão
• Note que não há restrição na banda do proxy
Protocolos de Transmissão com Auxílio do Proxy
• Projeto de novos protocolos de transmissão com auxílio do proxy
– Com e sem multicast entre proxy e cliente
• Para cada protocolo:
– Deriva Ci(mi)
– Utilização solução do problema de otimização para determinar conteúdo ótimo do cache
Unicast Suffix Batching (Sbatch)
• Todos caminhos são unicast: proxy so fala unicast
• Batching dos sufixos através do prefix cache
– não acarreta latência inicial
• Requisição chegando no instante 0: proxy escalona transmissão do sufixo do servidor para instante vi
• Todas requisições de cliente que chegam entre instantes 0 e vi, compartilham sufixo
• Cliente tem que escutar dois fluxos
Unicast Suffix Batching (Sbatch)
• Quando vi = 0 ou vi = Li: transmissão unicast
Unicast Patching with Prefix Caching (UPatch)
• Todos caminhos são unicast
Unicast Patching with Prefix Caching (UPatch)
• Todos caminhos são unicast
Multicast Patching with Prefix Caching (MPatch)
• Caminho proxy-cliente fala multicast
• Primeira requisição no tempo 0 para arquivo com prefixo vi
• Seja Ti: threshold do Patching para regular frequencia de transmissão de fluxos completos
• Segunda requisição para mesmo arquivo chega no instante 0 t2 Ti
• Dois cenários possíveis
– Ti vi Li
– 0 vi Ti
Multicast Patching with Prefix Caching (MPatch)
Multicast Patching with Prefix Caching (MPatch)
Multicast Merging with Prefix Caching (MMerge)
• Caminho proxy-cliente fala multicast
• Prefixo transmitido do proxy via Bandwidth Skimming (Closest Target)
• Sufixo transmitido do servidor para proxy via unicast o mais tarde possível
• Expressão Ci(vi) obtida via simulacão
Replicacao de Conteudo para Dynamic Skyscraper
• Como estender o protocolo Dynamic Skyscraper para permitir que prefixos sejam armazenados em proxies?
– Partitioned Skyscraper Protocol (melhora desempenho mesmo para um servidor)
• Quais objetos devem ser replicados em um numero de proxies para minimizar o uso do servidor remoto, para custo fixo dos proxies?
• Como particionar os objetos entre servidor origem e proxies para minimizar custo total de transmissao?
– Modelo de otimizacao
• Premissas: homogeneidade de cargas e servidores– Objetivo: insights iniciais (1o trabalho na area)
Dynamic Skyscraper BroadcastChannel 0
12
34
567
...
...
...
...
...
...
...
...
• K canais, T1 = duracao do segmento transmitido no canal 0 • 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)
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)......
...
...
...
...
...
...
...
...
...
...
...
...
...
Dynamic Skyscraper + Caching
• Alternativa 1: replicacao de objetos inteiros
– Transmissao de um unico servidor
– Alocacao de recursos:
• Proxy tem que alocar espaco para objetos replicados localmente
• Proxy tem que alocar largura de banda de rede para repassar conteudo recebido da origem para clientes
• Proxy tem que alocar largura de banda de servidor e de rede para transmitir os objetos locais
– Desvantagem: caching de prefixos pode reduzir custos
Dynamic Skyscraper + Caching
• Alternativa 2 (Ingenua) : Implementacao Compartilhada
– Origem e proxies colaboram para implementar transmission clusters
– Transmissao de um arquivo parcialmente replicado em um proxy: origem e todos proxies cooperam para prover um transmission cluster em todas as regioes
• Novas requisicoes durante transmission cluster
– Desperdicio de banda
Dynamic Skyscraper + Caching• Alternativa 3: Partitioned Dynamic Skyscraper
– Principio: Desacoplar transmissao dos segmentos iniciais da transmissao dos segmentos finais
– Mini-transmission clusters alocados sob-demanda
• k segmentos
• w = tamanho relativo do maior segmento no mini-cluster / duracao de cada mini-cluster
• Um transmission cluster composto de multiplos mini-clusters
– Aloca apenas um mini-cluster em resposta a uma requisicao
– Transmissao dos segmentos restantes mantem mesma estrutura do transmission cluster
Partitioned Dynamic Skyscraper
• Se objeto parcialmente replicado em proxies
– Transmissao de mini-clusters do proxy
– Transmissao do restante seguindo mesma estrutura do transmission cluster original
– Filas nos proxies e no servidor origem: independencia
– Mas: transmissoes tem que ser coordenadas
• Transmissao do mini-cluster o mais cedo possivel
• Transmissao do transmission cluster o mais tarde possivel
• Evita atrasos e maximiza compartilhamento de fluxos
Partitioned Dynamic Skyscraper
• Janelas de catch–up
– Mini-cluster : no maximo (w-1) T1
– Transmission cluster: (W – sk+1 + s) T1
Maior do que no protocolo original (W T1)
– Aumento na janela de catch-up
• Maior chance de compartilhamento: reducao na demanda por banda do servidor
• Aumento na demanda por espaco no cliente ( = janela)
• Aumento na demanda por banda do cliente
Cliente pode ter que escutar a 3 ou 4 fluxos simultaneos
Partitioned Dynamic Skyscraper
• Mini-clusters podem ser usados mesmo para transmissao de um unico servidor
– Melhor desempenho que protocolo original
(Maior janela de catch-up)
Modelo de Otimizacao• Conteudo otimo: minimiza custo de transmissao
– Custo de transmissao banda do servidor e da rede
• Servidores proxy:
– Banda de rede: fixa, independe de onde objeto esta armazenado
– Banda de servidor: depende dos objetos replicados
• Servidor origem:
– Banda de rede e banda de servidor: depende dos objetos replicados
• Objetivo: min. custo total referente a banda media C* dos servidores proxy e origem
Demanda por Banda de Servidor
• Banda necessaria para protocolo original (sem particao)
O numero medio de canais alocados e:
Para cada objeto i
WT1 = duracao do transmission cluster em cada canal
K canais
(W-1)T1 + 1/i = tempo entre criacao de transmission clusters consecutivos para objeto i
C*: proximo do joelho da curva na Fig. 2
n
ii
TWWTKNKC
1 1
1**
1)1(
1
Modelo de Otimizacao para Partitioned Skyscraper
• Particao dos objetos fixa
– Cada objeto pode ter 0, k ou K segmentos replicados no proxy
– Servidores homogeneos em termos de recursos, taxa de chegada de requisicoes e frequencia de selecao de objetos
• Todos os proxies armazenam o mesmo conteudo
• Modelo de otimizacao: paginas 8-9
Conteudo Otimo para Partitioned Skyscraper
• Normalizacao de parametro: resultados independentes de tamanho e bitrate dos arquivos
’: taxa de chegada de requisicoes por unidade de segmento
– Espaco nos proxies: numero de segmentos unitarios
– Banda nos proxies: numero de canais
• Cremote e Cregional para objetos popular e nao popular: Fig 3
– Caching de prefixo leva a grande reducao na demanda por banda remota por unidade de espaco (maior do que caching de sufixo)
• Maior reducao para objetos mais populares
– A medida que aumenta, menor a diferenca entre caching de objeto mais popular e objeto menos popular
Conteudo Otimo para Partitioned Skyscraper
• Minimizando uso de servidor origem ( = 0): Fig 4
– Caching de prefixos
– Uso de mini-cluster reduz custos (ate 42%) a nao ser que taxa de requisicoes muito alta
– Caching de prefixo tambem reduz custos (ate 52 %)
– Se espaco nos proxies e a restricao ativa: caching de prefixos dos arquivos mais populares e, se possivel, arquivos mais populares sao totalmente replicados
– Se banda e a restricao ativa: objetos menos populares sao replicados.
Conteudo Otimo para Partitioned Skyscraper
• Impacto do custo relativo de banda do proxy ( > 0): Fig 5
– A medida que aumenta, armazena objetos menos populares
– Se muito alto, os recursos dos proxies nao sao totalmente utilizados
• Impacto das restricoes nos recursos dos proxies: Figs 6-7
• Fig 8 (a): se grande, o custo total e minimizado se nao fizer caching
• Mensagem principal: Caching pode nao ter bom custo-beneficio para compartilhamento de fluxos