Distribuição de Mídia Contínua Replicacao de Conteudo Jussara M. Almeida Maio 2005.

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


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


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

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 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


• 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


• 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


• 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.


• 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

Distribuição de Mídia Contínua Replicacao de Conteudo Jussara M. Almeida Maio 2005.

Documents

Transcript of Distribuição de Mídia Contínua Replicacao de Conteudo Jussara M. Almeida Maio 2005.