Distribuição de Mídia Contínua

Voz sobre IP

Jussara M. Almeida

Junho 2005

Voz sobre IP• Comunicação interativa• Altos requisitos de latência e perdas de

pacotes– Atrasos de 100-150 ms ou acima disto são

perceptíveis ao ouvido humano– Seres humanos têm baixa tolerância à

degradação de áudio • Objetivo primário: minimizar latência• Objetivo secundário: minimizar perdas de

pacotes

Voz sobre IP• Métodos atuais:

– UDP• Retransmissão de pacotes perdidos podem não

chegar a tempo no destino• Protocolos confiáveis como TCP travam em

falhas de retransmissão ou timeouts

– FEC e/ou packet loss concealment– Recuperação limitada para perdas em

rajadas ou perdas súbitas

Voz sobre IP na Internet Atual

• Perdas em rajadas são comuns• Probabilidade condicional de um pacote

ser perdido dado que o ultimo pacote foi perdido é de 0.72 (muito alto)

– Modelo de perdas: 2 estados

• Falhas de links podem durar muito tempo : 5% das falhas duram mais que 2 horas

– Estas características limitam eficácia de VoIP

Voz sobre IP: Avaliação Inicial

• Avaliação no ambiente Emulab– Transferência de 5 minutos de voz – Rede com atrasos de 50 ms e banda de

10Mbps: link transcontinental– Taxas de perdas variáveis

• Métrica: – PESQ: Perceptual Evaluation of Speech

Quality– PESQ = 4 : qualidade de telefone

Voz sobre IP: Avaliação Inicial

• Mesmo perda de 0.5%, PESQ < 4 para prob. rajada de 0.75– Internet atual: perda de 0.42% com prob. rajada de 0.72 – Logo: precisa de novas soluções

Proposta• Arquitetura overlay que melhora o

desempenho de aplicações VoIP quando serviço da Internet sofre

– Taxa de entrega de pacotes alta mesmo frente a altas perdas com baixo overhead (baixa latência)

• Comunicação end-to-end pelo overlay: divisão do caminho em vários segmentos de overlay

– É possível recuperar pacotes com pouco atraso: recuperação local tem baixo overhead pois links do overlay tem baixo RTT se comparado à latência do caminho total

– Algoritmo de roteamento pode se adaptar evitando links do overlay congestionados (alta perda ou indisponíveis)

Proposta• Contribuições:

– Um protocolo de recuperação de pacotes em tempo real que entrega pacotes recebidos como UDP mas que realiza recuperação de pacotes de forma local • Tenta-se a recuperação somente uma vez e somente se

for provável que o pacote chegue ao destino em tempo

– Protocolo de roteamento no overlay adaptativo específico para VoIP que seleciona o caminho com base em uma métrica que combina a latência e a perda observada nos links

Arquitetura Overlay• Spines: implementa protocolos específico

para a aplicação– Manutenção da rede: pings periódicos– Pacotes com número de sequência: deteção de

perdas– Atribui um custo a cada link do overlay com base

na perda e latência observadas no link– Custo de links disseminados pela rede de forma

incremental

• Melhorar VoIP: novos protocolos para– Recuperação localizada de pacotes– Roteamento adaptativo

Protocolo de Retransmissão em Tempo

Real• Recupera pacotes somente se há uma possibilidade

dele chegar a tempo no destino• Cada nó no overlay mantém um buffer circular de

pacotes para cada link de saída– Pacotes são mantidos no buffer por um período igual ao

atraso máximo suportado pelo codificador de voz

• Nós intermediários enviam pacotes à medida que eles chegam, mesmo fora de ordem

• Ao detetar uma perda, um nó envia um NACK requisitando cópia ao vizinho superior

– Pedido de retransmissão enviado somente uma vez– NACKs limitam tráfego de controle quando não há perda

Protocolo de Retransmissão em Tempo

Real• Quando um nó recebe um pedido de

retransmissão, ele:– Checa se ele tem o pacote no seu buffer circular– Se tem re-envia, se não tem, não faz nada– Número máximo de retransmissões regulado em

função do número de pacotes enviados: limita retransmissões em links com muitas perdas

• Se um nó recebe o mesmo pacote duas vezes, somente a primeira cópia será transmitida para frente

Protocolo de Retransmissão em Tempo

Real• Protocolo não envia ACKs positivos:

– Não acarreta tráfego adicional se não há perda (exceto pelos pings)

• Protocolo não trava para recuperar pacotes – Não tem timeouts

• Desvantagem: não recupera todos pacotes– Pedido de retransmissão é perdido:

• Se perdas independentes a taxa p, probabilidade é p (1-p) p = p2 – p3

– A retransmissão é perdida:• Probabilidade: p (1-p) (1 – p) p = p2 – 2p3 + p4

– Probabilidade de perda total ~ 2p2 – 3p3

Protocolo de Retransmissão em Tempo

Real• Distribuição da latência dos pacotes em um link com

atraso T e taxa de perda p:– (1 – p) dos pacotes terão latência T– (p - 2p2 + 3p3) dos pacotes terão latência 3T + = tempo para nó detetar perda

depende dos tempos entre chegadas de pacotes e do número máximo de pacotes fora de ordem que o protocolo suporta

– Um pacote fora de ordem dispara pedido de retransmissão: latência é crucial

• Distribuição de latência em caminho com múltiplos links é composta das latências em cada segmento

Avaliação• Implementação em Spines e avaliação no Emulab• Cada experimento : 10 fluxos de VoIP• Perda de pacotes após protocolo:

– link de 10 ms: vários níveis de perdas e rajadas

Nível de rajada com pouco impacto

Aplicação do protocolo em link com 5% de perda reduz perda por um fator de 10 (0.5%)

Avaliação• Perda de pacotes após protocolo:

– Dois links concatenados de 10 ms cada

Nível de rajada com pouco impacto

Aplicação do protocolo em link com 5% de perda reduz perda por um fator de 10 (0.5%)

Avaliação• Distribuição da latência

– Um link de 10 ms e 5% de perdas

• 95% dos pacotes chegam em 10 ms• 4.5% chegam em 30 ms mais tempo entre chegadas de pacotes

• Varia com rajadas•0.5% dos pacotes são perdidos

Avaliação• Distribuição da latência

– Concatenação de 2 links: cada um 10 ms e 5% de perdas

• Somente 1% dos pacotes são efetivamente perdidos• 0.25% dos pacotes chegam com latência de 66ms: perdas nos dois links (0.05 X 0.05)

Avaliação• Impacto do protocolo na qualidade da voz• Rede com 5 segmentos de 10 ms cada

– 10 fluxos VoIP de A pra F– Perdas entre C e D– Limite de atraso de 100 ms

•

Avaliação

• Com novo protocolo, independente de rajada ou não, o codec em questão pode supeortar até 3.5% de perdas para garantir qualidade de telefone

Protocolo de Roteamento em Tempo Real

• Objetivo: max # pacotes que chegam no destino dentro do limite imposto pelo codec (ex: 100ms)

– Duas métricas por link: latência e taxa de perda– Computar a distribuição de latência para todos os

caminhos possíveis e escollher o melhor é ótimo mas muito caro

• Solução: – aproxima custo de cada link por uma métrica

dependente da latência e taxa de perdas– Usa algoritmo do caminho mais curto com esta

métrica

Protocolo de Roteamento em Tempo Real

• Métrica: latência esperada– Latência esperada em um link: Texp = (1 – p)T + (p - 2p2 + 3p3 )(3T+ ) + (2p2 +

3p3)Tmax

– Latência esperada em um caminho: soma das latências nos links

Avaliação• Topologias aleatórias criadas com o gerador Brite• Para cada topologia, avalia o roteamento entre o

par de nós que estão mais distantes– % de pacotes que chegam ao destino a tempo (100

ms)

• Métricas para roteamento– Latência esperada: Cost = Texp– Distância em hops : Cost = 1– Latência do Link: Cost = T– Taxa de perdas: Cost = - log(1 – p)– Otimizador guloso: Dijkstra modificado onde a cada

iteração, escolhe o próximo nó com taxa de entrega máxima

– Ótimo

Avaliação

• Topologias com diâmetro pequeno: roteamento baseado na taxa de perdas é melhor

• Topologias com diâmetro grande: latência é + importante• Latência esperada: bom compromisso